HP Unified Wired-WLAN Products

Transcription

1 HP Unified Wired-WLAN Products Security Configuration Guide HP 830 Unified Wired-WLAN PoE+ Switch Series HP 850 Unified Wired-WLAN Appliance HP 870 Unified Wired-WLAN Appliance HP 11900/10500/ G Unified Wired-WLAN Module Part number: Software version: R3507P26 (HP 830 PoE+ Switch Series) R2607P26 (HP 850 Appliance) R2607P26 (HP 870 Appliance) R2507P27 (HP 11900/10500/ G Module) Document version: 6W

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

3 Contents Security overview 1 Network security threats 1 Network security services 1 Network security technologies 1 Identity authentication 1 Access security 2 Data security 3 Firewall 3 Attack detection and protection 4 Additional security technologies 4 Configuring AAA 6 Overview 6 RADIUS 7 HWTACACS 12 LDAP 14 Domain-based user management 16 Protocols and standards 17 RADIUS attributes 17 FIPS compliance 20 AAA configuration considerations and task list 20 Configuring AAA schemes 22 Configuring local users 22 Configuring RADIUS schemes 27 Configuring HWTACACS schemes 39 Configuring LDAP schemes 45 Configuring AAA methods for ISP domains 49 Creating an ISP domain 50 Configuring ISP domain attributes 51 Configuring authentication methods for an ISP domain 52 Configuring authorization methods for an ISP domain 54 Configuring accounting methods for an ISP domain 56 Tearing down user connections 58 Configuring local EAP authentication 58 Configuration procedure 58 Configuring the local EAP authentication server 58 Configuring a NAS ID-VLAN binding 59 Specifying the device ID 60 Displaying and maintaining AAA 60 AAA configuration examples 60 HWTACACS authentication and authorization for Telnet users 61 Local authentication and HWTACACS authorization for Telnet users 62 LDAP authentication for Telnet users 64 Authentication and authorization for portal users by a RADIUS server 68 Authentication and authorization for 802.1X users by a RADIUS server 74 Local EAP authentication and authorization for 802.1X users 80 RADIUS offload for 802.1X users 82 Level switching authentication for Telnet users by an HWTACACS server 85 Local EAP authentication for 802.1X users by an LDAP server 88 i

4 Temporary access control of wireless users 90 Troubleshooting AAA 93 Troubleshooting RADIUS 93 Troubleshooting HWTACACS 94 Troubleshooting LDAP X overview X architecture 96 Controlled/uncontrolled port and port authorization status X-related protocols 97 Packet formats 98 EAP over RADIUS 99 Initiating 802.1X authentication X client as the initiator 99 Access device as the initiator X authentication procedures 100 Comparing EAP relay and EAP termination 101 EAP relay 101 EAP termination 103 Configuring 802.1X 105 HP implementation of 802.1X 105 Access control methods X stateful failover 105 Using 802.1X authentication with other features 105 Configuration prerequisites X configuration task list 108 Enabling EAP relay or EAP termination 108 Setting the port authorization state 109 Specifying an access control method 110 Setting the maximum number of concurrent 802.1X users on a port 110 Setting the maximum number of authentication request attempts 111 Setting the 802.1X authentication timeout timers 111 Configuring the online user handshake function 111 Configuration guidelines 112 Configuration procedure 112 Configuring the authentication trigger function 112 Configuration guidelines 113 Configuration procedure 113 Specifying a mandatory authentication domain on a port 113 Configuring the quiet timer 114 Enabling the periodic online user re-authentication function 114 Configuring an 802.1X guest VLAN 115 Configuration guidelines 115 Configuration prerequisites 115 Configuration procedure 116 Configuring an Auth-Fail VLAN 116 Configuration guidelines 116 Configuration prerequisites 116 Configuration procedure 117 Specifying supported domain name delimiters 117 Configuring the accounting delay feature 118 Displaying and maintaining 802.1X X with ACL assignment configuration example 119 Network requirements 119 ii

5 Configuration procedure 119 Verifying the configuration 121 Configuring MAC authentication 123 Overview 123 User account policies 123 Authentication approaches 123 MAC authentication timers 124 Using MAC authentication with other features 124 VLAN assignment 124 ACL assignment 124 Guest VLAN 124 MAC-after-portal 125 Configuration task list 125 Basic configuration for MAC authentication 125 Configuring MAC authentication globally 126 Configuring MAC authentication on a port 126 Specifying a MAC authentication domain 127 Configuring a MAC authentication guest VLAN 127 Configuring the MAC-after-portal feature 128 Displaying and maintaining MAC authentication 129 MAC authentication configuration examples 129 Local MAC authentication configuration example 129 RADIUS-based MAC authentication configuration example 132 ACL assignment configuration example 134 Configuring portal authentication 138 Overview 138 Extended portal functions 138 Portal system components 138 Portal system using the local portal server 140 Portal authentication modes 141 Portal support for EAP 142 Layer 3 portal authentication process 142 MAC-based quick portal authentication 146 Portal stateful failover 147 Portal configuration task list 149 Configuration prerequisites 150 Specifying a portal server for Layer 3 portal authentication 150 Configuring the local portal server 151 Customizing authentication pages 151 Configuring the local portal server 154 Enabling Layer 3 portal authentication 155 Controlling access of portal users 156 Configuring a portal-free rule 156 Configuring a portal-forbidden rule 157 Configuring an authentication source subnet 157 Setting the maximum number of online portal users 158 Specifying a portal authentication domain 158 Configuring Layer 3 portal authentication to support Web proxy 159 Configuring RADIUS related attributes 160 Specifying the NAS ID value carried in a RADIUS request 160 Specifying NAS-Port-Type for an interface 160 Specifying the NAS-Port-ID for an interface 161 Specifying a NAS ID profile for an interface 161 iii

6 Specifying a source IP address for outgoing portal packets 162 Configuring MAC-based quick portal authentication 162 Configuring portal stateful failover 163 Associating an SSID and AP with a portal server and an authentication domain 165 Specifying an autoredirection URL for authenticated portal users 165 Configuring portal detection functions 166 Configuring online Layer 3 portal user detection 166 Configuring the portal server detection function 167 Configuring portal user information synchronization 168 Logging off portal users 169 Enabling forced logoff for user SSID switching 169 Enabling logging for portal packets 169 Specifying the parameters to be carried in the redirection URL 170 Enabling host identity check through DHCP snooping 170 Configuring mandatory webpage pushing 171 Displaying and maintaining portal 171 Portal configuration examples 172 Configuring direct portal authentication 173 Configuring re-dhcp portal authentication 177 Configuring direct portal authentication with extended functions 179 Configuring re-dhcp portal authentication with extended functions 180 Configuring portal stateful failover 183 Configuring portal server detection and portal user information synchronization 191 Configuring direct portal authentication using local portal server 197 Configuring portal stateful failover with local portal servers 199 Configuring MAC-based quick portal authentication 205 Troubleshooting portal 215 Inconsistent keys on the access device and the portal server 215 Incorrect server port number on the access device 215 Configuring port security 216 Overview 216 Port security features 216 Port security modes 216 Support for WLAN 219 Working with guest VLAN and Auth-Fail VLAN 220 Port security stateful failover 220 Configuration task list 220 Enabling port security 221 Setting port security's limit on the number of MAC addresses on a port 221 Setting the port security mode 222 Configuring port security features 223 Configuring NTK 223 Configuring intrusion protection 223 Enabling port security traps 224 Configuring port security for WLAN ports 224 Setting the port security mode of a WLAN port 225 Enabling key negotiation 225 Configuring a PSK 226 Ignoring authorization information from the server 226 Configuring NAS ID profile for port security 226 Configuring port security stateful failover 227 Displaying and maintaining port security 228 Port security configuration examples 228 Configuring the userloginwithoui mode 228 iv

7 Configuring the userloginsecureext mode on a WLAN port 233 Configuring an 802.1X guest VLAN for a port security-enabled port 236 Configuring port security with guest VLAN and VLAN assignment 238 Configuring 802.1X stateful failover for port security 242 Troubleshooting port security 247 Cannot change port security mode when a user is online 247 Configuring a user profile 248 Overview 248 User profile configuration task list 248 Creating a user profile 248 Performing configurations in user profile view 249 Enabling a user profile 249 Displaying and maintaining user profile 249 Configuring password control 250 Overview 250 FIPS compliance 252 Password control configuration task list 253 Enabling password control 253 Setting global password control parameters 254 Setting user group password control parameters 255 Setting local user password control parameters 256 Setting super password control parameters 256 Setting a local user password in interactive mode 257 Displaying and maintaining password control 257 Password control configuration example 258 Managing public keys 261 Configuration task list 261 Creating a local asymmetric key pair 262 Displaying or exporting the local host public key 262 Displaying and recording the host public key information 263 Displaying the host public key in a specific format and saving it to a file 263 Exporting the host public key in a specific format to a file 263 Destroying a local asymmetric key pair 264 Specifying the peer public key on the local device 264 Displaying public keys 265 Public key configuration examples 266 Manually specifying the peer public key on the local device 266 Importing a public key from a public key file 268 Configuring PKI 271 Overview 271 PKI terms 271 PKI architecture 272 PKI operation 273 PKI applications 273 PKI configuration task list 273 Configuring a PKI entity 274 Configuring a PKI domain 275 Requesting a certificate 276 Configuring automatic certificate request 276 Manually requesting a certificate 277 Obtaining certificates 278 Verifying PKI certificates 279 v

8 Verifying certificates with CRL checking 279 Verifying certificates without CRL checking 279 Destroying the local RSA key pair 280 Removing a certificate 280 Configuring a certificate access control policy 280 Displaying and maintaining PKI 281 PKI configuration examples 281 Certificate request from an RSA Keon CA server 282 Certificate request from a Windows 2003 CA server 285 Certificate access control policy configuration example 288 Troubleshooting PKI 290 Failed to obtain the CA certificate 290 Failed to request local certificates 290 Failed to obtain CRLs 291 Configuring SSH 292 Overview 292 How SSH works 292 SSH authentication 293 FIPS compliance 294 Configuring the device as an SSH server 294 SSH server configuration task list 294 Generating local DSA and RSA key pairs 295 Enabling the SSH server function 296 Enabling the SFTP server function 296 Configuring the user interfaces for SSH clients 296 Configuring a client's host public key 297 Configuring an SSH user 298 Setting the SSH management parameters 299 Configuring the device as an Stelnet client 300 Stelnet client configuration task list 300 Specifying a source IP address or source interface for SSH packets 300 Enabling and disabling first-time authentication 301 Establishing a connection to an Stelnet server 302 Configuring the device as an SFTP client 302 SFTP client configuration task list 303 Specifying a source IP address or source interface for SFTP packets 303 Establishing a connection to an SFTP server 303 Working with SFTP directories 304 Working with SFTP files 305 Displaying help information 305 Terminating the connection with the SFTP server 306 Configuring the device as an SCP client 306 SCP client configuration task list 306 Transferring files with an SCP server 307 Displaying and maintaining SSH 307 Stelnet configuration examples 308 Password authentication enabled Stelnet server configuration example 308 Publickey authentication enabled Stelnet server configuration example 312 Password authentication enabled Stelnet client configuration example 317 Publickey authentication enabled Stelnet client configuration example 319 SFTP configuration example 321 Network requirements 321 Configuration procedure 322 SCP configuration example 325 vi

9 Network requirements 325 Configuration procedure 325 Configuring SSL 327 Overview 327 SSL security mechanism 327 SSL protocol stack 327 Configuration task list 328 Configuring an SSL server policy 328 Configuring an SSL client policy 330 Displaying SSL 331 SSL server policy configuration example 331 Troubleshooting SSL 333 SSL handshake failure 333 Configuring TCP attack protection 334 Overview 334 Enabling the SYN Cookie feature 334 Displaying TCP attack protection 335 Configuring ARP attack protection 336 Overview 336 ARP attack protection configuration task list 336 Configuring unresolvable IP attack protection 337 Configuring ARP source suppression 337 Enabling ARP blackhole routing 337 Displaying and maintaining ARP source suppression 338 Configuration example 338 Configuring ARP packet rate limit 339 Configuring source MAC-based ARP attack detection 339 Displaying and maintaining source MAC-based ARP attack detection 340 Source MAC-based ARP attack detection configuration example 340 Configuring ARP packet source MAC consistency check 342 Configuring ARP active acknowledgement 342 Configuring authorized ARP 342 Authorized ARP configuration example (on a DHCP server) 343 Authorized ARP configuration example (on a DHCP relay agent) 344 Configuring ARP detection 346 Configuring user validity check 346 Configuring ARP packet validity check 347 Configuring ARP restricted forwarding 348 Displaying and maintaining ARP detection 348 User validity check configuration example 348 User validity check and ARP packet validity check configuration example 351 Configuring ARP gateway protection 353 Configuration example 354 Configuring ARP filtering 355 Configuration example 355 Configuring IPsec 357 Overview 357 Basic concepts 357 IPsec stateful failover 360 Protocols and standards 361 Implementing ACL-based IPsec 361 Configuring an ACL 361 vii

10 Configuring an IPsec transform set 364 Configuring an IPsec policy 365 Applying an IPsec policy group to an interface 370 Configuring the IPsec anti-replay function 370 Enabling invalid SPI recovery 371 Configuring IPsec stateful failover 371 Displaying and maintaining IPsec 373 IPsec configuration examples 374 Configuration example for IPsec between AC and AP 374 IPsec stateful failover for LWAPP protection configuration example 374 Configuring IKE 384 Overview 384 IKE security mechanism 384 IKE operation 384 IKE functions 385 Relationship between IKE and IPsec 386 Protocols and standards 386 Configuration task list for IKE 386 Configuring a name for the local security gateway 387 Configuring an IKE proposal 387 Configuring an IKE peer 388 Setting keepalive timers 391 Setting the NAT keepalive timer 391 Configuring a DPD detector 391 Disabling next payload field checking 392 Displaying and maintaining IKE 392 IKE configuration examples 393 Troubleshooting IKE 393 Proposal mismatch 393 Failing to establish an IPsec tunnel 394 Configuring ALG 395 ALG process 395 Enabling ALG 397 ALG configuration examples 397 FTP ALG configuration example 397 SIP/H.323 ALG configuration example 398 NBT ALG configuration example 399 Configuring firewall 400 Overview 400 ACL based packet filter 400 ASPF 401 Configuring a packet-filter firewall 403 Packet-filter firewall configuration task list 403 Enabling the firewall function 403 Configuring the default filtering action of the firewall 403 Applying an ACL packet-filter firewall to an interface 404 Applying an ACL packet-filter firewall to a user profile 405 Displaying and maintaining a packet-filter firewall 405 Packet-filter firewall configuration example 405 Configuring an ASPF 407 ASPF configuration task list 407 Enabling the firewall function 407 Configuring an ASPF policy 407 viii

11 Applying an ASPF policy to an interface 408 Applying an ASPF policy to a user profile 408 Configuring port mapping 409 Displaying and maintaining ASPF 409 ASPF configuration example 409 Managing sessions 411 Overview 411 How session management works 411 Session management functions 411 Session management task list 412 Setting session aging time for different protocol states 412 Configuring session aging time for different application layer protocols 413 Enabling checksum verification 413 Specifying persistent sessions 414 Specifying the operating mode for session management 414 Configuring session logging 415 Enabling session logging 415 Setting session logging thresholds 415 Displaying and maintaining session management 416 Configuring Web filtering 417 Overview 417 URL address filtering 417 IP address-supported URL address filtering 417 URL parameter filtering 418 Java blocking 418 ActiveX blocking 419 Configuring Web filtering 419 Configuring URL address filtering 419 Configuring IP address-supported URL address filtering 419 Configuring URL parameter filtering 420 Configuring Java blocking 420 Configuring ActiveX blocking 421 Displaying and maintaining Web filtering 421 Web filtering configuration examples 421 URL address filtering configuration example 422 URL parameter filtering configuration example 423 Java blocking configuration example 425 Troubleshooting Web filtering 426 Failed to add filtering entry or suffix keyword due to upper limit 426 Invalid characters are present in the configured parameter 426 Invalid use of wildcard 427 Invalid blocking suffix 428 ACL configuration failed 428 Unable to access the HTTP server by IP address 428 Configuring user isolation 429 VLAN-based user isolation 429 SSID-based user isolation 430 Configuring VLAN-based user isolation 430 Configuring SSID-based user isolation 431 Displaying and maintaining user isolation 431 User isolation configuration example 431 Network requirements 432 Configuration procedure 432 ix

12 Configuring source IP address verification 433 Overview 433 Configuring source IP address verification 433 Displaying and maintaining source IP address verification 434 Source IP address verification configuration example 434 Source IPv4 address verification configuration example 435 Source IPv6 address verification configuration example (using DHCPv6 server) 436 Source IPv6 address verification configuration example (using ND) 438 Configuring FIPS 441 Overview 441 FIPS self-tests 441 Power-up self-tests 441 Conditional self-tests 442 Triggering self-tests 442 Configuration considerations 442 Enabling FIPS mode 443 Configuration changes in FIPS mode 443 Displaying and maintaining FIPS 443 FIPS configuration example 443 Network requirements 444 Configuration procedure 444 Verifying the configuration 445 Configuring protocol packet rate limit 446 Enabling protocol packet rate limit 446 Enabling per-protocol bandwidth limit 446 Configuring the threshold for per-protocol bandwidth limit 446 Configuring the threshold for per-flow bandwidth limit 447 Displaying and maintaining protocol packet rate limit 447 Support and other resources 448 Contacting HP 448 Subscription service 448 Related information 448 Documents 448 Websites 448 Conventions 449 Index 451 x

13 Security overview Network security services provide solutions to solve or reduce security threats. Network security threats are existing or potential threats to data confidentiality, data integrity, and data availability. Network security threats Information disclosure Information is leaked to an unauthorized person or entity. Data integrity damage Data integrity is damaged by unauthorized modification or malicious destruction. Denial of service Makes information or other network resources unavailable to their intended users. Unauthorized usage Resources are used by unauthorized persons or in unauthorized ways. Network security services A security service is implemented by one or more network security technologies. One technology involves multiple services. The following are the most important security services: Identity authentication Identifies users and determines if a user is valid. Typical methods include AAA-based username plus password authentication, and PKI digital certificate-based authentication. Access security Prevents unauthorized access and use of network resources by implementing AAA-based identity authentication. Access security protocols such as 802.1X, MAC authentication, and portal authentication work together with AAA to implement user identity authentication. Data security Encrypts and decrypts data during data transmission and storage. Typical encryption mechanisms include symmetric encryption and asymmetric encryption, and their common applications are IPsec, SSL, and SSH. IPsec secures IP communications. SSL and SSH protect data transfer based on TCP. Firewall A highly effective network security model to block unauthorized Internet access to a protected network. Major firewall implementations are ACL based packet filter, ASPF, and ALG. Network security technologies Identity authentication AAA AAA provides a uniform framework for implementing network access management. It provides the following security functions: Authentication Identifies network users and determines whether the user is valid. 1

14 PKI Authorization Grants user rights and controls user access to resources and services. For example, a user who has successfully logged in to the device can be granted read and print permissions to the files on the device. Accounting Records all network service usage information, including the service type, start time, and traffic. The accounting function provides information for charging and user behavior auditing. AAA can be implemented through multiple protocols, such as RADIUS, HWTACACS, and LDAP, among which RADIUS is used most often. PKI is an asymmetric key infrastructure to encrypt and decrypt data for securing network services. PKI uses digital certificates to distribute and employ public keys, and provides network communication and e-commerce with security services such as user authentication, data confidentiality, and data integrity. HP's PKI system provides digital certificate management for IPsec and SSL. Access security 802.1X 802.1X is a port-based network access control protocol for securing wireless LANs (WLANs), and it has also been widely used on Ethernet networks for access control X controls network access by authenticating the devices connected to 802.1X-enabled LAN ports. MAC authentication Port security MAC authentication controls network access by authenticating source MAC addresses on a port. It does not require client software and users do not need to enter a username and password for network access. The device initiates a MAC authentication process when it detects an unknown source MAC address on a MAC authentication enabled port. If the MAC address passes authentication, the user can access authorized network resources. Port security combines and extends 802.1X and MAC authentication to provide MAC-based network access control. It applies to networks that require different authentication methods for different users on a port, such as a WLAN. Port security prevents unauthorized access to a network by checking the source MAC address of inbound traffic and prevents access to unauthorized devices by checking the destination MAC address of outbound traffic. Portal authentication Portal authentication, also called "Web authentication," controls user access at the access layer and other data entrance that needs protection. It does not require client software to authenticate users. Users only need to enter a username and a password on the webpage for authentication. With portal authentication, an access device redirects all unauthenticated users to a webpage. All users can access resources on the webpage without passing portal authentication. However, to access the Internet, a user must pass portal authentication on the portal authentication page. 2

15 Data security Managing public keys IPsec and IKE SSL SSH Firewall Public key configuration enables you to manage the local asymmetric key pairs (for example, creating or destroying a local asymmetric key pair, and displaying or exporting a local host public key), and configure the peer host public keys on the local device. IPsec is a security framework for securing IP communications. It is a Layer 3 VPN technology used for data encryption and data origin authentication. IKE provides automatic negotiation security parameters for IPsec, simplifying the configuration and maintenance of IPsec. Security parameters for IKE negotiation include authentication and encryption algorithms, authentication and encryption keys, IP packet encapsulation modes (tunnel mode and transport mode), and key lifetime. SSL is a security protocol that provides communication security for TCP-based application layer protocols by using the public key mechanism and digital certificates. SSL is independent of the application layer protocol, and enables an application layer protocol to use an SSL-based secure connection. A common application is HTTPS HTTP over SSL or HTTP Secure. SSH is a network security protocol that provides secure remote login and file transfer over an insecure network. Using encryption and authentication, SSH protects devices against attacks such as IP spoofing and plaintext password interception. ACL based packet-filter An ACL packet-filter implements IP packet specific filtering. ASPF Before forwarding an IP packet, the device obtains the following header information: Number of the upper layer protocol carried by the IP layer Source address Destination address Source port number Destination port number The device compares the head information against the preset ACL rules and processes (discards or forwards) the packet based on the comparison result. An ASPF implements status-based packet filtering, and provides the following functions: Transport layer protocol inspection (generic TCP and UDP inspection) ASPF checks a TCP/UDP packet's source and destination addresses and port numbers to determine whether to permit the packet to pass through the firewall into the internal network. 3

16 Application layer protocol inspection ASPF checks application layer information for packets, such as the protocol type and port number, and monitors the application layer protocol status for each connection. ASPF maintains status information for each connection, and based on status information, determines whether to permit a packet to pass through the firewall into the internal network, thus defending the internal network against attacks. ASPF also supports other security functions, such as port to application mapping, ICMP error message inspection and first packet inspection for TCP connection. At the border of a network, an ASPF can work in coordination with a packet-filter firewall to provide the network with a security policy that is more comprehensive and better satisfies the actual needs. ALG ALG processes payload information for application layer packets. Working with NAT, ALG implements address translation in packet payloads. Working with ASPF, ALG implements data connection detection and application layer status checking. Session management Session management is a common feature designed to implement session-based services such as NAT and ASPF. Session management tracks the connection status by inspecting the transport layer protocol (TCP or UDP) information, and regards packet exchanges at transport layer as sessions, performing unified status maintenance and management of all connections. In actual applications, session management works together with ASPF to dynamically determine whether a packet can pass the firewall and enter the internal network according to connection status, thus preventing intrusion. The session management function only implements connection status tracking. It does not block potential attack packets. Attack detection and protection ARP attack protection ARP provides no security mechanism and is vulnerable to network attacks. An attacker can exploit ARP vulnerabilities to attack network devices. To protect the device against user and gateway spoofing attacks and flood attacks, HP provides multiple ARP attack protection features. For information about these features, see "Configuring ARP attack protection." TCP attack protection Web filtering Attackers can attack the device during the process of TCP connection establishment. To prevent such attacks, the device provides the SYN Cookie feature. Web filtering can help devices prevent internal users from accessing unauthorized websites and block Java applets and ActiveX objects from webpages to improve internal network security. Additional security technologies The device also provides additional network security technologies to implement a multifunctional and full range of security protection for users. 4

17 User profile Password control A user profile provides a configuration template to save predefined configurations, such as a CAR policy or a QoS policy. Different user profiles are applicable to different application scenarios. The user profile works with PPPoE, 802.1X, MAC authentication, and portal authentication. It is capable of restricting authenticated users' behaviors. After the authentication server verifies a user, it sends the device the name of the user profile that is associated with the user. Password control is a set of functions for enhancing the local password security. It controls user login passwords, super passwords, and user login status based on predefined policies. Those policies include minimum password length, minimum password update interval, password aging, and early notice on pending password expiration. 5

18 Configuring AAA Overview Authentication, Authorization, and Accounting (AAA) provides a uniform framework for implementing network access management. It provides the following security functions: Authentication Identifies users and determines whether a user is valid. Authorization Grants user rights and controls user access to resources and services. For example, a user who has successfully logged in to the device can be granted read and print permissions to the files on the device. Accounting Records all network service usage information, including service type, start time, and traffic. It provides information required for accounting and allows for network security surveillance. AAA typically uses a client/server model, as shown in Figure 1. The client runs on the network access server (NAS), which is also called the access device. The server maintains user information centrally. In an AAA network, the NAS is a server for users but a client for AAA servers. Figure 1 AAA application scenario Internet Network Remote user NAS RADIUS server HWTACACS server The NAS uses the authentication server to authenticate any user who tries to log in, use network resources, or access other networks. The NAS transparently transmits authentication, authorization, and accounting information between the user and the servers. The RADIUS and HWTACACS protocols define how a NAS and a remote server exchange user information. The network shown in Figure 1 includes a RADIUS server and an HWTACACS server. You can use different servers to implement different security functions. For example, you can use the HWTACACS server for authentication and authorization, and the RADIUS server for accounting. You can implement any of the security functions provided by AAA as needed. For example, if your company wants employees to be authenticated before they access specific resources, you would configure an authentication server. If network usage information is needed, you would also configure an accounting server. AAA can be implemented through multiple protocols. The device supports RADIUS, HWTACACS, and LDAP, and RADIUS is used most often. 6

19 RADIUS Remote Authentication Dial-In User Service (RADIUS) is a distributed information interaction protocol that uses a client/server model. It can protect networks against unauthorized access and is often used in network environments that require both high security and remote user access. RADIUS uses UDP port 1812 for authentication and UDP port 1813 for accounting. RADIUS was originally designed for dial-in user access. RADIUS has been extended to support additional access methods, including Ethernet and ADSL. RADIUS provides access authentication, authorization, and accounting services. The accounting function collects and records network resource usage information. Client/server model RADIUS clients run on NASs located throughout the network. NASs pass user information to RADIUS servers, and reject or accept user access requests depending on the responses from RADIUS servers. The RADIUS server runs on the computer or workstation at the network center and maintains information related to user authentication and network access. It receives connection requests, authenticates users, and returns access control information (for example, rejecting or accepting the user access request) to the clients. The RADIUS server typically maintains the following databases: Users, Clients, and Dictionary, as shown in Figure 2. Figure 2 RADIUS server databases RADIUS servers Users Clients Dictionary Users Stores user information, such as usernames, passwords, applied protocols, and IP addresses. Clients Stores information about RADIUS clients, such as shared keys and IP addresses. Dictionary Stores RADIUS protocol attributes and their values. Security and authentication mechanisms The RADIUS client and the RADIUS server use a shared key to authenticate RADIUS packets and encrypt user passwords exchanged between them. For security, this key must be manually configured on the client and the server. RADIUS servers support multiple authentication protocols, including PPP PAP and CHAP. A RADIUS server can also act as the client of another AAA server to provide authentication proxy services. Basic RADIUS message exchange process Figure 3 illustrates the interactions between the host, the RADIUS client, and the RADIUS server. 7

20 Figure 3 Basic RADIUS message exchange process RADIUS uses the following workflow: 1. The host initiates a connection request that includes the user's username and password to the RADIUS client. 2. The RADIUS client sends an authentication request (Access-Request) to the RADIUS server after it received the username and password. The user password is encrypted with the MD5 algorithm and the shared key. 3. The RADIUS server authenticates the username and password. If the authentication succeeds, the server returns an Access-Accept message that includes 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 the result permits the user, the RADIUS client sends a start-accounting request (Accounting-Request) to the RADIUS server. 5. The RADIUS server returns an acknowledgement (Accounting-Response) and starts accounting. 6. The user accesses the network resources. 7. The host requests the RADIUS client to tear down the connection and the RADIUS client sends a stop-accounting request (Accounting-Request) to the RADIUS server. 8. The RADIUS server returns an acknowledgement (Accounting-Response) and stops accounting for the user. RADIUS packet format RADIUS uses UDP to transmit messages. To ensure smooth message exchange between the RADIUS server and the client, RADIUS uses a timer management mechanism, a retransmission mechanism, and a backup server mechanism. Figure 4 shows the RADIUS packet format. 8

21 Figure 4 RADIUS packet format 0 Code Identifier Length Authenticator Attributes Descriptions of the fields are as follows: The Code field (1 byte long) indicates the type of the RADIUS packet. Table 1 Main values of the Code field Code Packet type Description 1 Access-Request 2 Access-Accept 3 Access-Reject 4 Accounting-Request 5 Accounting-Response From the client to the server. A packet of this type includes 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. From the server to the client. If all attribute values included in the Access-Request are acceptable, the authentication succeeds, and the server sends an Access-Accept response. From the server to the client. If any attribute value included in the Access-Request is unacceptable, the authentication fails, and the server sends an Access-Reject response. From the client to the server. A packet of this type includes 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. From the server to the client. The server sends a packet of this type to notify the client that it has received the Accounting-Request and has successfully recorded the accounting information. The Identifier field (1 byte long) is used to match request packets and response packets and to detect duplicate request packets. Request and response packets of the same type have the same identifier. The Length field (2 bytes long) indicates the length of the entire packet, including the Code, Identifier, Length, Authenticator, and Attributes fields. Bytes beyond this length are considered padding and are ignored by the receiver. If the length of a received packet is less than this length, the packet is dropped. The value of this field is in the range 20 to The Authenticator field (16 bytes long) is used to authenticate responses from the RADIUS server and to encrypt user passwords. There are two types of authenticators: request authenticator and response authenticator. The Attributes field (variable in length) includes the specified 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: 9

22 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 Table 2 shows a list of the attributes. For more information, see "Commonly used standard RADIUS attributes." Length (1 byte long) Length of the attribute in bytes, including the Type, Length, and Value sub-fields. Value (Up to 253 bytes) Value of the attribute. Its format and content depend on the Type and Length sub-fields. Table 2 Commonly used RADIUS attributes No. Attribute No. Attribute 1 User-Name 45 Acct-Authentic 2 User-Password 46 Acct-Session-Time 3 CHAP-Password 47 Acct-Input-Packets 4 NAS-IP-Address 48 Acct-Output-Packets 5 NAS-Port 49 Acct-Terminate-Cause 6 Service-Type 50 Acct-Multi-Session-Id 7 Framed-Protocol 51 Acct-Link-Count 8 Framed-IP-Address 52 Acct-Input-Gigawords 9 Framed-IP-Netmask 53 Acct-Output-Gigawords 10 Framed-Routing 54 (unassigned) 11 Filter-ID 55 Event-Timestamp 12 Framed-MTU (unassigned) 13 Framed-Compression 60 CHAP-Challenge 14 Login-IP-Host 61 NAS-Port-Type 15 Login-Service 62 Port-Limit 16 Login-TCP-Port 63 Login-LAT-Port 17 (unassigned) 64 Tunnel-Type 18 Reply-Message 65 Tunnel-Medium-Type 19 Callback-Number 66 Tunnel-Client-Endpoint 20 Callback-ID 67 Tunnel-Server-Endpoint 21 (unassigned) 68 Acct-Tunnel-Connection 22 Framed-Route 69 Tunnel-Password 23 Framed-IPX-Network 70 ARAP-Password 24 State 71 ARAP-Features 25 Class 72 ARAP-Zone-Access 26 Vendor-Specific 73 ARAP-Security 27 Session-Timeout 74 ARAP-Security-Data 28 Idle-Timeout 75 Password-Retry 29 Termination-Action 76 Prompt 10

23 No. Attribute No. Attribute 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 Attribute 26 (Vendor-Specific), an attribute defined in RFC 2865, allows a vendor to define extended attributes to implement functions that the standard RADIUS protocol does not provide. A vendor can encapsulate multiple sub-attributes as TLVs in attribute 26 to provide extended functions. As shown in Figure 5, a sub-attribute encapsulated in attribute 26 consists of the following parts: Vendor-ID ID of the vendor. Its most significant byte is 0. The other three bytes contains a code that is compliant to RFC The vendor ID of HP is For more information about the proprietary RADIUS sub-attributes of HP, see "HP proprietary RADIUS sub-attributes." Vendor-Type Type of the sub-attribute. Vendor-Length Length of the sub-attribute. Vendor-Data Contents of the sub-attribute. Figure 5 Format of attribute 26 11

24 HWTACACS HW Terminal Access Controller Access Control System (HWTACACS) is an enhanced security protocol based on TACACS (RFC 1492). HWTACACS is similar to RADIUS, and uses a client/server model for information exchange between the NAS and the HWTACACS server. HWTACACS typically provides AAA services for PPP, VPDN, and terminal users. In a typical HWTACACS scenario, terminal users need to log in to the NAS. Working as the HWTACACS client, the NAS sends users' usernames and passwords to the HWTACACS sever for authentication. After passing authentication and obtaining authorized rights, a user logs in to the device and performs operations. The HWTACACS server records the operations that each user performs. Differences between HWTACACS and RADIUS HWTACACS and RADIUS have many features in common, including using a client/server model, using shared keys for user information security, and providing flexibility and extensibility. Table 3 lists the primary differences. Table 3 Primary differences between HWTACACS and RADIUS HWTACACS Uses TCP, which provides more reliable network transmission. Encrypts the entire packet except for the HWTACACS header. Protocol packets are complicated and authorization is independent of authentication. Authentication and authorization can be deployed on different HWTACACS servers. Supports authorization of configuration commands. Access to commands depends on both the user level and AAA authorization. A user can use only commands that are at, or lower than, the user level and authorized by the HWTACACS server. RADIUS Uses UDP, which provides higher transport efficiency. Encrypts only the user password field in an authentication packet. Protocol packets are simple and the authorization process is combined with the authentication process. Does not support authorization of configuration commands. Access to commands 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. 12

25 Figure 6 Basic HWTACACS message exchange process for a Telnet user HWTACACS operates using the following workflow: 1. A Telnet user sends an access request to the HWTACACS client. 2. The HWTACACS client sends a start-authentication packet to the HWTACACS server when it receives the request. 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 includes the username. 7. The HWTACACS server sends back an authentication response to request the login password. 8. Upon receipt of the response, the HWTACACS client prompts the user for the login password. 13

26 9. The user enters the password. 10. After receiving the login password, the HWTACACS client sends the HWTACACS server a continue-authentication packet that includes the login password. 11. The HWTACACS server sends back an authentication response to indicate that the user has passed authentication. 12. The HWTACACS client sends the user authorization request packet to the HWTACACS server. 13. The HWTACACS server sends back the authorization response, indicating that the user is now authorized. 14. The HWTACACS client pushes its CLI to the user. 15. The HWTACACS client sends a start-accounting request to the HWTACACS server. 16. The HWTACACS server sends back an accounting response, indicating that it has received the start-accounting request. 17. The user logs off. 18. The HWTACACS client sends a stop-accounting request to the HWTACACS server. 19. The HWTACACS server sends back a stop-accounting response, indicating that the stop-accounting request has been received. LDAP Based on TCP/IP, the Lightweight Directory Access Protocol (LDAP) provides standard multi-platform directory service. LDAP was developed on the basis of the X.500 protocol, and improves the read/write interactive access, and browse and search functions of X.500. It is suitable for storing data that is not often changed. LDAP is typically used to store user information. For example, Microsoft Windows uses Active Directory Server to store user information and user group information for login authentication and authorization. LDAP directory service LDAP uses directories to maintain organization, personnel, and resource information. The directories are organized in a tree structure and include entries. An entry is a set of attributes with distinguished names (DNs). The LDAP directory service is based on a client/server model. All directory information is stored in the LDAP server. Commonly used LDAP server products include Microsoft Active Directory Server, IBM Tivoli Directory Server, and Sun ONE Directory Server. LDAP authentication and authorization LDAP defines a set of operations to implement functions. LDAP operations for authentication and authorization are the bind operation and search operation: Bind operation Allows an LDAP client to establish a connection with the LDAP server, obtain the access rights to the LDAP server, and check the validity of user information. Search operation Constructs search conditions and obtains the directory resource information of the LDAP server. The basic LDAP authentication process is as follows: 1. An LDAP client uses the LDAP server administrator DN to bind with the LDAP server, establishes a connection to the server, and obtains the search rights. 14

27 2. The LDAP client, using the username in the authentication information of a user, constructs search conditions to search for the user in the specified root directory of the server, and obtains a user DN list. 3. The LDAP client uses each user DN in the obtained user DN list and the user password to bind with the LDAP server. If a binding succeeds, the user is legal. The LDAP authorization process is similar to the LDAP authentication process, except that the client obtains the authorization information and the user DN list at step 2 in the workflow. If the authorization information meets the authorization requirements, the authorization process ends. If the authorization information does not meet the authorization requirements, the client sends an administrator bind request to the LDAP server to obtain search right for authorization information about users on the user DN list. Basic LDAP message exchange process The following example illustrates the basic message exchange process during LDAP authentication and authorization for a Telnet user. Figure 7 Basic message exchange process for LDAP authentication of a Telnet user Host LDAP client LDAP server 1) The user logs in by Telnet 2) Establish a TCP connection 3) Administrator bind request 4) Bind response 5) User DN search request 6) Search response 7) User DN bind request 8) Bind response 10) The user logs in successfully 9) Authorization The basic message exchange process during LDAP authentication and authorization is as follows: 1. A Telnet user initiates a connection request and sends the username and password to the LDAP client. 2. After receiving the request, the LDAP client establishes a TCP connection with the LDAP server. 3. To obtain the search right, the LDAP client uses the administrator DN and password to send an administrator bind request to the LDAP server. 4. The LDAP server processes the request. If the bind operation is successful, the LDAP server sends an acknowledgement to the LDAP client. 15

28 5. The LDAP client sends a user DN search request with the username of the Telnet user to the LDAP server. 6. After receiving the request, the LDAP server searches for the user DN by the base DN, search scope, and filtering conditions. If a match is found, the LDAP server sends a response to notify the LDAP client of the successful search. There may be one or more user DNs found. 7. The LDAP client uses the obtained user DN and the entered user password as parameters to send a user DN bind request to the LDAP server, which checks whether the user password is correct. 8. The LDAP server processes the request, and sends a response to notify the LDAP client of the bind operation result. If the bind operation fails, the LDAP client uses another obtained user DN as the parameter to send a user DN bind request to the LDAP server. This process continues until a DN is bound successfully or all DNs fail to be bound. If all user DNs fail to be bound, the LDAP client notifies the user of the login failure and denies the access request. 9. The LDAP client and server exchange authorization messages. If another scheme, for example, an HWTACACS scheme, is expected for authorization, the LDAP client exchanges authorization messages with the HWTACACS authorization server instead. 10. After successful authorization, the LDAP client notifies the user of the successful login. LDAP authentication and authorization restrictions The device supports LDAP authentication, but it does not support LDAP authorization. To configure a separate authorization method, use the HWTACACS authorization method. For more information, see "Configuring HWTACACS schemes." Domain-based user management A NAS manages users based on ISP domains. On a NAS, each user belongs to one ISP domain. A NAS determines the ISP domain for a user by the username entered by the user at login, as shown in Figure 8. Figure 8 Determining the ISP domain of a user by the username Authentication, authorization, and accounting of a user depends on the AAA methods configured for the domain that the user belongs to. If no specific AAA methods are configured for the domain, the default methods are used. By default, a domain uses local authentication, local authorization, and local accounting. AAA allows you to manage users based on their access types: LAN users Users on a LAN who must pass 802.1X or MAC address authentication to access the network. 16

29 Login users Users who want to log in to the device, including SSH users, Telnet users, Web users, FTP users, and terminal users. Portal users Users who must pass portal authentication to access the network. PPP users Users who access the network through PPP. Support for PPP users depends on the device model. For more information, see About the Configuration Guides for HP Unified Wired-WLAN Products. In addition, AAA provides the following login services to enhance device security: Command authorization Enables the NAS to defer to the authorization server to determine whether a command entered by a login user is permitted, and allows login users to execute only authorized commands. For more information about command authorization, see Fundamentals Configuration Guide. Command accounting Allows the accounting server to record all commands executed or successfully authorized on the device. 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. When users pass level switching authentication, they can switch their user privilege levels without logging out and disconnecting current connections. For more information about user privilege level switching, see Fundamentals Configuration Guide. You can configure different AAA methods for different types of users in a domain. See "Configuring AAA methods for ISP domains." Protocols and standards The following protocols and standards are related to AAA, RADIUS, HWTACACS, and LDAP: 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 RFC 1777, Lightweight Directory Access Protocol RFC 2251, Lightweight Directory Access Protocol (v3) RADIUS attributes This section provides tables of commonly used standard RADIUS attributes and HP proprietary RADIUS sub-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, only present in Access-Request packets when PAP authentication is used. 17

30 No. Attribute Description 3 CHAP-Password 4 NAS-IP-Address Digest of the user password for CHAP authentication, only present in Access-Request packets when CHAP authentication is used. IP address for the server to use to identify a client. A client is typically identified by the IP address of its access interface. This attribute is only present in Access-Request packets. 5 NAS-Port Physical port of the NAS that the user accesses. 6 Service-Type Type of service that the user has requested or type of service to be provided: X authentication. 10 MAC authentication. 7 Framed-Protocol Encapsulation protocol for framed access. 8 Framed-IP-Address IP address assigned to the user. 11 Filter-ID Name of the filter list. 12 Framed-MTU MTU for the data link between the user and NAS. For example, with 802.1X EAP authentication, NAS uses this attribute to notify the server of the MTU for EAP packets, so as to avoid oversized EAP packets. 14 Login-IP-Host IP address of the NAS interface that the user accesses. 15 Login-Service Type of the service that the user uses for login. 18 Reply-Message 26 Vendor-Specific Text to be displayed to the user, which can be used by the server to communicate information, for example, the reason of the authentication failure. Vendor specific, proprietary attribute. A packet can contain one or more proprietary attributes, each of which can contain one or more sub-attributes. 27 Session-Timeout Maximum service duration for the user before termination of the session. 28 Idle-Timeout Maximum idle time permitted for the user before termination of the session. 31 Calling-Station-Id User identification that the NAS sends to the server. For the LAN access service provided by an HP device, this attribute includes the MAC address of the user in the format HH-HH-HH-HH-HH-HH. 32 NAS-Identifier Identification that the NAS uses to identify itself to the RADIUS server. 40 Acct-Status-Type 45 Acct-Authentic Type of the Accounting-Request packet. Possible values include: 1 Start. 2 Stop. 3 Interim-Update. 4 Reset-Charge. 7 Accounting-On. (Defined in the 3rd Generation Partnership Project.) 8 Accounting-Off. (Defined in the 3rd Generation Partnership Project.) 9 to 14 Reserved for tunnel accounting. 15 Reserved for failed. Authentication method used by the user. Possible values include: 1 RADIUS. 2 Local. 3 Remote. 18

31 No. Attribute Description 60 CHAP-Challenge 61 NAS-Port-Type 79 EAP-Message 80 Message-Authenticator 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 include: 15 Ethernet. 16 Any type of ADSL. 17 Cable (with cable for cable TV). 19 WLAN-IEEE 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. Used to encapsulate EAP packets to allow RADIUS to support EAP authentication. Used for authentication and verification of authentication packets to prevent spoofing Access-Requests. This attribute is present when EAP authentication is used. 87 NAS-Port-Id String for describing the port of the NAS that is authenticating the user. 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. 15 Remanent_Volume 20 Command 24 Control_Identifier Total remaining available traffic for the connection, in different units for different server types. Operation for the session, used for session control. Possible values include: 1 Trigger-Request. 2 Terminate-Request. 3 SetPolicy. 4 Result. 5 PortalClear. Identification for retransmitted packets. For retransmitted packets from the same session, this attribute must be the same value. For retransmitted packets from different sessions, this attribute does not have to be the same value. The client response from a retransmitted packet must also include this attribute and the value of this attribute must be the same. For Accounting-Request packets from the start, stop, and interim update types, the Control-Identifier attribute does not take effect. 19

32 No. Sub-attribute Description 25 Result_Code Result of the Trigger-Request or SetPolicy operation, zero for success and any other value for failure. 26 Connect_ID Index of the user connection. 28 Ftp_Directory FTP user working directory. When the RADIUS client acts as the FTP server, this attribute is used to set the FTP directory for an FTP user on the RADIUS client. 29 Exec_Privilege EXEC user priority. 59 NAS_Startup_Timestamp 60 Ip_Host_Addr Startup time of the NAS in seconds, which is represented by the time elapsed after 00:00:00 on Jan. 1, 1970 (UTC). User IP address and MAC address included in authentication and accounting requests, in the format A.B.C.D hh:hh:hh:hh:hh:hh. A space is required between the IP address and the MAC address. 61 User_Notify Information that must be sent from the server to the client transparently. 62 User_HeartBeat 140 User_Group 141 Security_Level Hash value assigned after an 802.1X user passes authentication, which is a 32-byte string. This attribute is stored in the user list on the NAS and verifies the handshake messages from the 802.1X user. This attribute only exists in Access-Accept and Accounting-Request packets. User groups assigned after the SSL VPN user passes authentication. A user might belong to more than one user group, which are separated by semi-colons. This attribute is used to communicate with the SSL VPN device. Security level assigned after the SSL VPN user passes security authentication. 201 Input-Interval-Octets Number of bytes input within a real-time accounting interval. 202 Output-Interval-Octets Number of bytes output within a real-time accounting interval. 203 Input-Interval-Packets 204 Output-Interval-Packets Number of packets input within an accounting interval in the unit set on the NAS. Number of packets output within an accounting interval in the unit set on the NAS. 205 Input-Interval-Gigawords Amount of bytes input within an accounting interval, in units of 4G bytes. 206 Output-Interval-Gigawords Amount of bytes output within an accounting interval, in units of 4G bytes. 207 Backup-NAS-IP Backup source IP address for sending RADIUS packets. 255 Product_ID Product name. FIPS compliance The device supports the FIPS mode that complies with NIST FIPS 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 on the NAS: 20

33 1. Configure the required AAA schemes. Local authentication Configure local users and the related attributes, including the usernames and passwords for the users to be authenticated. Remote authentication Configure the required RADIUS, HWTACACS, and LDAP schemes. You must configure user attributes on the servers accordingly. 2. Configure AAA methods for the ISP domain. Authentication method No authentication (none), local authentication (local), or remote authentication (scheme) Authorization method No authorization (none), local authorization (local), or remote authorization (scheme) Accounting method No accounting (none), local accounting (local), or remote accounting (scheme) See Figure 9 for the configuration procedure. Figure 9 AAA configuration procedure Table 4 AAA configuration task list Task Configuring AAA schemes Configuring local users Configuring RADIUS schemes Configuring HWTACACS schemes Configuring LDAP schemes Remarks Required. Complete at least one task. 21

34 Task Configuring AAA methods for ISP domains Creating an ISP domain Configuring ISP domain attributes Configuring authentication methods for an ISP domain Configuring authorization methods for an ISP domain Configuring accounting methods for an ISP domain Remarks Required. Required. Complete at least one task. Tearing down user connections Configuring local EAP authentication Configuring a NAS ID-VLAN binding Specifying the device ID Required. NOTE: To use AAA methods to control access of login users, you must configure the authentication-mode command. For more information, see Fundamentals Configuration Guide. Configuring AAA schemes Configuring local users To implement local AAA, you must create local users and configure user attributes on the device. The local users and attributes are stored in the local user database on the device. A local user is uniquely identified by a username. Configurable local user attributes are as follows: Service type. Services that the user can use. Local authentication checks the service types of a local user. If none of the service types is available, the user cannot pass authentication. Service types include FTP, LAN access, portal, PPP, SSH, Telnet, terminal, and Web. Support for the PPP service depends on the device model. For more information, see About the Configuration Guides for HP Unified Wired-WLAN Products. User state. Indicates whether or not a local user can request network services. There are two user states: active and blocked. A user in active state can request network services, but a user in blocked state cannot. Maximum number of users using the same local user account. Indicates how many users can use the same local user account for local authentication. Validity time and expiration time. Indicates the validity time and expiration time of a local user account. A user must use a valid local user account to pass local authentication. For temporary network access needs, you can create a guest account and specify a validity time and an expiration time for the account. User group. 22

35 Each local user belongs to a local user group and has 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 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, and you can make the attribute effective for all local users, all local users in a group, or only the local user. A password control attribute with a smaller effective range has a higher priority. For more information about password management and global password configuration, see "Configuring password control." For more information about password control commands, see Security Command Reference. Binding attributes. Binding attributes control the scope of users, and 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. Authorization attributes. Authorization attributes indicate the user's rights after it passes local authentication. Authorization attributes include the ACL, PPP callback number, idle cut function, user level, user role, user profile, VLAN, and FTP/SFTP work directory. For more information about authorization attributes, see "Configuring local user attributes." Every configurable authorization attribute has its definite application environments and purposes. When you configure authorization attributes for a local user, consider which attributes are needed and which are not. For example, for PPP users, you do not need to configure the work directory attribute. You can configure an authorization attribute in user group view or local user view to make the attribute effective for all local users in the group or for only the local user. The setting of an authorization attribute in local user view takes precedence over that in user group view. Local user configuration task list Task Configuring local user attributes Configuring user group attributes Displaying and maintaining local users and local user groups Remarks Required. Configuring local user attributes Follow these guidelines when you configure local user attributes: When you use the password-control enable command to globally enable the password control feature, local user passwords are not displayed. At the same time, you cannot use the password hash cipher command to configure passwords for local users. If the user interface authentication mode set by the authentication-mode command in user interface view is AAA (scheme), command access for the login user depends on the privilege level authorized to the user. If the user interface authentication mode is password (password) or no authentication (none), command access for the login user depends on the level configured for the 23

36 user interface by using the user privilege level command in user interface view. For an SSH user using public key authentication, command access for the login user 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 the setting in ISP domain view has the lowest priority. For more information about user profiles, see "Configuring a user profile." If a local user is the only one security log manager in the system, this local user cannot be deleted. You cannot change or delete the security log manager role of this user unless you specify another local user as a security log manager. 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. 3. Configure a password for the local user. 4. Assign service types for the local user. 5. Place the local user to the active or blocked state. 6. Set the maximum number of concurrent users of the local user account. local-user user-name password [ [ hash ] { cipher simple } password ] service-type { ftp lan-access { ssh telnet terminal } * portal ppp web } state { active block } access-limit max-user-number By default, a local user named admin exists. 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. This command is not supported in FIPS mode. To configure passwords for local users, use the password control feature. By default, no service is authorized to a local user. The ftp and telnet keywords are not supported in FIPS mode. Support for the ppp keyword depends on the device model. For more information, see About the Command References for HP Unified Wired-WLAN Products. By default, a created local user is in active state and can request network services. By default, there is no limit to the maximum number of concurrent users of a local user account. The limit is effective only for local accounting, and is not effective for FTP users. 24

37 Step Command Remarks 7. Configure password control attributes for the local user. 8. Configure binding attributes for the local user. 9. Configure authorization attributes for the local user. 10. Set the validity time of the local user. 11. Set the expiration time of the local user. 12. Assign the local user to a user group. Set the password aging time: password-control aging aging-time Set the minimum password length: password-control length length Configure the password composition policy: password-control composition type-number type-number [ type-length type-length ] bind-attribute { call-number call-number [ : subcall-number ] ip ip-address location port slot-number subslot-number port-number mac mac-address vlan vlan-id } * authorization-attribute { acl acl-number callback-number callback-number idle-cut minute level level user-profile profile-name user-role { guest guest-manager security-audit } vlan vlan-id work-directory directory-name } * validity-date time expiration-date time group group-name By default, the local user uses password control attributes of the user group to which the local user belongs, and uses the global setting for any password control attribute that is not configured in the user group. The global settings include a 90-day password aging time, a minimum password length of 10 characters, and at least one password composition type and at least one character required for each password composition type. In FIPS mode, the value for the type-number argument must be 4. By default, no binding attribute is configured for a local user. By default, no authorization attribute is configured for a local user. For PPP users, only acl, callback-number, idle-cut, and user-profile are supported. For LAN and portal users, only acl, idle-cut, user-profile, and vlan are supported. For SSH, 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. Not set by default. Not set by default. By default, a local user belongs to the default user group system. 25

38 Configuring user group attributes User groups simplify local user configuration and management. A user group includes 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 new local user belongs to the default user group system and has all attributes of the group. To assign a local user to a different user group, use the 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. 3. Configure password control attributes for the user group. 4. Configure authorization attributes for the user group. 5. Set the guest attribute for the user group. user-group group-name Set the password aging time: password-control aging aging-time Set the minimum password length: password-control length length Configure the password composition policy: password-control composition type-number type-number [ type-length type-length ] authorization-attribute { acl acl-number callback-number callback-number idle-cut minute level level user-profile profile-name vlan vlan-id work-directory directory-name } * group-attribute allow-guest N/A By default, the user group uses global settings, including a 90-day password aging time, a minimum password length of 10 characters, and at least one password composition type and at least one character required for each password composition type. In FIPS mode, the value for the type-number argument must be 4. By default, no authorization attribute is configured for a user group. 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 the user group configuration. display local-user [ idle-cut { disable enable } service-type { ftp lan-access portal ppp ssh telnet terminal web } state { active block } user-name user-name vlan vlan-id ] [ { begin exclude include } regular-expression ] display user-group [ group-name ] [ { begin exclude include } regular-expression ] Available in any view. The ftp and telnet keywords are not supported in FIPS mode. Available in any view. 26

39 Configuring RADIUS schemes A RADIUS scheme specifies the RADIUS servers that the device can work with and defines a set of parameters that the device uses to exchange information with the RADIUS servers. For example, there might be authentication/authorization servers and accounting servers, or primary servers and secondary servers. The parameters include the IP addresses of the servers, the shared keys, and the RADIUS server type. RADIUS scheme configuration task list Task Creating a RADIUS scheme Specifying the RADIUS authentication/authorization servers Specifying the RADIUS accounting servers and the relevant parameters Specifying the shared keys for secure RADIUS communication Setting the username format and traffic statistics units Setting the supported RADIUS server type Setting the maximum number of RADIUS request transmission attempts Setting the status of RADIUS servers Specifying the source IP address for outgoing RADIUS packets Specifying a backup source IP address for outgoing RADIUS packets Setting RADIUS timers Configuring RADIUS accounting-on Configuring the IP address of the security policy server Enabling the RADIUS offload feature Configuring interpretation of the RADIUS class attribute as CAR parameters Enabling the trap function for RADIUS Enabling logging of RADIUS packets Enabling the RADIUS client service Displaying and maintaining RADIUS Remarks Required. Required. Creating a RADIUS scheme Before you perform other RADIUS configurations, first create a RADIUS scheme and enter RADIUS scheme view. A RADIUS scheme can be referenced by multiple ISP domains at the same time. To create a RADIUS scheme and enter RADIUS scheme view: Step Command Remarks 1. Enter system view. system-view N/A 2. Create a RADIUS scheme and enter RADIUS scheme view. radius scheme radius-scheme-name By default, no RADIUS scheme is created. 27

40 Specifying the RADIUS authentication/authorization servers In RADIUS, user authorization information is piggybacked in authentication responses sent to RADIUS clients. It is neither allowed nor needed to specify a separate RADIUS authorization server. You can specify one primary authentication/authorization server and up to 16 secondary authentication/authorization servers for a RADIUS scheme. When the primary server is not available, a secondary server is used. If redundancy is not required, specify only the primary server. A RADIUS authentication/authorization server can function as the primary authentication/authorization server for one scheme and a secondary authentication/authorization server for another scheme at the same time. You can enable the server status detection feature. With the feature, the device periodically sends an authentication request to check whether or not the target RADIUS authentication/authorization server is reachable. If the server can be reached, the device sets the status of the server to active. If the server cannot be reached, the device sets the status of the server to block. This feature promptly notifies authentication modules of latest server status information. To specify RADIUS authentication/authorization servers for a RADIUS scheme: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme view. radius scheme radius-scheme-name N/A Configure at least one command. By default, no authentication/authorization server is specified. 3. Specify RADIUS authentication/authorization servers. Specify the primary RADIUS authentication/authorization server: primary authentication { ip-address ipv6 ipv6-address } [ port-number key [ cipher simple ] key probe username name [ interval interval ] ] * 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 ] ] * In FIPS mode, the shared key for secure RADIUS authentication/authorization communication must be at least eight characters that contain digits, uppercase letters, lowercase letters, and special characters, and must use 3DES for encryption and decryption. The IP addresses of the primary and secondary authentication/authorization servers for a scheme must be different. Otherwise, the configuration will fail. All servers for authentication/authorization and accounting, primary or secondary, must use IP addresses of the same IP version. 28

41 Specifying the RADIUS accounting servers and the relevant parameters You can specify one primary accounting server and up to 16 secondary accounting servers for a RADIUS scheme. When the primary server is not available, a secondary server is used. When redundancy is not required, specify only the primary server. A RADIUS accounting server can function as the primary accounting server for one scheme and a secondary accounting server for another scheme at the same time. When the device receives a connection teardown request from a host or a connection teardown command from an administrator, it sends a stop-accounting request to the accounting server. When the maximum number of real-time accounting attempts is reached, the device disconnects users who have no accounting responses. You can enable buffering of non-responded stop-accounting requests to allow the device to buffer and resend a stop-accounting request until it receives a response. If the number of stop-accounting attempts reaches the upper limit, the device discards the buffered request. If you delete an accounting server that is serving users, the device no longer sends real-time accounting requests or stop-accounting requests for the users to that server, or buffers the stop-accounting requests. RADIUS does not support accounting for FTP users. To specify RADIUS accounting servers and set relevant parameters for a scheme: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme view. 3. Specify RADIUS accounting servers. 4. Set the maximum number of real-time accounting attempts. 5. Enable buffering of stop-accounting requests to which no responses are received. radius scheme radius-scheme-name Specify the primary RADIUS accounting server: primary accounting { ip-address ipv6 ipv6-address } [ port-number key [ cipher simple ] key probe username name [ interval interval ] ] * Specify a secondary RADIUS accounting server: secondary accounting { ip-address ipv6 ipv6-address } [ port-number key [ cipher simple ] key probe username name [ interval interval ] ] * retry realtime-accounting retry-times stop-accounting-buffer enable N/A Configure at least one command. By default, no accounting server is specified. In FIPS mode, the shared key for secure RADIUS accounting communication must be at least eight characters that contain digits, uppercase letters, lowercase letters, and special characters, and must use 3DES for encryption and decryption. The IP addresses of the primary and secondary accounting servers must be different from each other. Otherwise, the configuration fails. All servers for authentication/authorization and accounting, primary or secondary, must use IP addresses of the same IP version. The default setting is 5. Enabled by default. 29

42 Step Command Remarks 6. Set the maximum number of stop-accounting attempts. retry stop-accounting retry-times The default setting is 500. Specifying the shared keys for secure RADIUS communication The RADIUS client and RADIUS server use the MD5 algorithm and a shared key pair for packet authentication and password encryption to secure communication. A shared key configured in RADIUS scheme view applies to all servers of the specified type (accounting or authentication) in that scheme, and has a lower priority than those configured for individual RADIUS servers. To specify a shared key for secure RADIUS communication: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme view. 3. Specify a shared key for secure RADIUS authentication/authorization or accounting communication. radius scheme radius-scheme-name key { accounting authentication } [ cipher simple ] key N/A By default, no shared key is specified. The shared key configured on the device must be the same as that configured on the RADIUS server. In FIPS mode, the shared key must be at least eight characters that contain digits, uppercase letters, lowercase letters, and special characters. Setting the username format and traffic statistics units A username is typically in the format userid@isp-name, where isp-name represents the user's ISP domain name. By default, the ISP domain name is included in a username. However, older RADIUS servers might not recognize usernames that contain the ISP domain names. In this case, you can configure the device to remove the domain name from each username to be sent. The device periodically sends accounting updates to RADIUS accounting servers to report the traffic statistics of online users. For normal and accurate traffic statistics, make sure that the units for data flows and data packets on the device are consistent with units on the RADIUS server. To set the username format and the traffic statistics units for a RADIUS scheme: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme view. radius scheme radius-scheme-name N/A 30

43 Step Command Remarks 3. Set the format for usernames sent to the RADIUS servers. 4. Specify the unit for data flows or packets sent to the RADIUS servers. user-name-format { keep-original with-domain without-domain } data-flow-format { data { byte giga-byte kilo-byte mega-byte } packet { giga-packet kilo-packet mega-packet one-packet } }* By default, the ISP domain name is included in a username. Do not apply the RADIUS scheme to more than one ISP domain if you have configured the user-name-format without-domain command for that RADIUS scheme. Otherwise, users in different ISP domains are considered the same user if they use the same username. For level switching authentication, user-name-format keep-original and user-name-format without-domain commands all produce the same result to remove ISP domain names from usernames sent to the RADIUS server. The default unit is byte for data flows and 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 device uses to communicate with the RADIUS server: Standard Uses the standard RADIUS protocol, compliant to RFC 2865 and RFC 2866 or later. Extended Uses the HP proprietary RADIUS protocol. 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. Changing the RADIUS server type will restore the units for data flows and data packets that are sent to the RADIUS server to be the defaults. To set the RADIUS server type: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme view. radius scheme radius-scheme-name N/A 3. Set the RADIUS server type. server-type { extended standard } The default RADIUS server type is standard. Setting the maximum number of RADIUS request transmission attempts RADIUS uses UDP packets to transfer data. Because UDP communication is not reliable, RADIUS uses a retransmission mechanism to improve reliability. If a NAS sends a RADIUS request to a RADIUS server but receives no response before the response timeout timer (defined by the timer response-timeout command) expires, the NAS retransmits the request. If the number of transmission attempts exceeds the specified limit but the NAS does not receive a response, it tries to communicate with other RADIUS 31

44 servers in active state. If no other servers are in active state at the time, the NAS considers the authentication or accounting attempt a failure. For more information about RADIUS server states, see "Setting the status of RADIUS servers." The maximum number of transmission attempts of RADIUS packets multiplied by the RADIUS server response timeout period cannot be greater than 75 seconds. For more information about the RADIUS server response timeout timer, see "Setting RADIUS timers." To set the maximum number of RADIUS request transmission attempts for a scheme: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme view. radius scheme radius-scheme-name N/A 3. Set the maximum number of RADIUS request transmission attempts. retry retry-times The default setting is 3. Setting the status of RADIUS servers To control the AAA servers with which the device communicates when the current servers are no longer available, set the status of RADIUS servers to blocked or active. You can specify one primary RADIUS server and multiple secondary RADIUS servers, with the secondary servers functioning as the backup of the primary servers. Typically, the device chooses servers based on these rules: When the primary server is in active state, the device communicates with the primary server. If the primary server fails, the device changes the server's status to blocked, starts a quiet timer for the server, and tries to communicate with a secondary server in active state (a secondary server configured earlier has a higher priority). If the secondary server is unreachable, the device changes the server's status to blocked, starts a quiet timer for the server, and continues to check the next secondary server in active state. This search process continues until the device finds an available secondary server or has checked all secondary servers in active state. If the quiet timer of a server expires or an authentication or accounting response is received from the server, the status of the server automatically changes back to active, but the device does not check the server again during the authentication or accounting process. If no server is found reachable during one search process, the device considers the authentication or accounting attempt a failure. Once the accounting process of a user starts, the device continues to send the user's real-time accounting requests and stop-accounting requests to the same accounting server. If you remove the accounting server, real-time accounting requests and stop-accounting requests for the user are no longer delivered to the server. If you remove an authentication or accounting server in use, the communication of the device with the server will soon time out, and the device will look for a server in active state by checking the primary server first and then the secondary servers in the order they are configured. When the primary server and secondary servers are all in blocked state, the device communicates with the primary server. If the primary server is available, its status changes to active. Otherwise, its status remains to be blocked. If one server is in active state and all the others are in blocked state, the device only tries to communicate with the server in active state, even if the server is unavailable. 32

45 After receiving an authentication/accounting response from a server, the device changes the status of the server identified by the source IP address of the response to active if the current status of the server is blocked. The device does not change the status of an unreachable authentication or accounting server if the server quiet timer is set to 0. Instead, the device keeps the server status as active and sends authentication or accounting packets to another server in active state, so subsequent authentication or accounting packets can still be sent to that server. For more information about the server quiet timer, see "Setting RADIUS timers." By default, the device sets the status of all RADIUS servers to active. In some situations, you might need to change the status of a server. For example, if a server fails, you can change the status of the server to blocked to avoid communication attempts to the server. To set the status of RADIUS servers in a RADIUS scheme: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme view. 3. Set the RADIUS server status. 4. (Optional) Display the states of the servers. radius scheme radius-scheme-name Set the status of the primary RADIUS authentication/authorization server: state primary authentication { active block } Set the status of the primary RADIUS accounting server: state primary accounting { active block } Set the status of a secondary RADIUS authentication/authorization server: state secondary authentication [ ip ipv4-address ipv6 ipv6-address ] { active block } Set the status of a secondary RADIUS accounting server: state secondary accounting [ ip ipv4-address ipv6 ipv6-address ] { active block } display radius scheme N/A By default, all servers in the RADIUS scheme are in active state. The server status set by the state command cannot be saved to the configuration file. After the device restarts, the status of each server is restored to active. N/A 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 it is, the server processes the packet. If it is not, the server drops the packet. The source address of outgoing RADIUS packets is typically the IP address of an egress interface on the NAS to communicate with the RADIUS server. However, in some situations, you must change the source IP address. You can specify a source IP address for outgoing RADIUS packets for a specific RADIUS scheme or all RADIUS schemes. Before sending a RADIUS packet, the NAS selects a source IP address in the following order: 1. The source IP address specified for the RADIUS scheme. 2. The source IP address specified in system view. 33

46 3. The 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 } By default, the IP address of the outbound interface is used as the source IP address. To specify a source IP address for a specific RADIUS scheme: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme view. 3. Specify a source IP address for outgoing RADIUS packets. radius scheme radius-scheme-name nas-ip { ip-address ipv6 ipv6-address } N/A 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 Support for this feature depends on the device model. For more information, see About the Configuration Guides for HP Unified Wired-WLAN Products. 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 device. In a stateful failover scenario, the active device authenticates portal users by interacting with the RADIUS server, and synchronizes its online portal user information to the standby device through the backup link established between them. The standby device only receives and processes synchronization messages from the active device. However, if the active device fails, the RADIUS server cannot send RADIUS packets to the standby device because it does not have the IP address of the standby device. To prevent problems, configure the source IP address for outgoing RADIUS packets on each device as the backup source IP address for outgoing RADIUS packets on the other device. With this configuration, the active device will send the source IP address for outgoing RADIUS packets configured on the standby device to the RADIUS server, so that the RADIUS server can send unsolicited RADIUS packets to the standby device. You can specify a backup IP address for outgoing RADIUS packets for a specific RADIUS scheme or all RADIUS schemes. Before sending a RADIUS packet, the NAS selects a backup source IP address in the following order: 1. The backup source IP address specified for the RADIUS scheme. 2. The backup source IP address specified in system view. 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: 34

47 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 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. 3. Specify a backup source IP address for outgoing RADIUS packets. radius scheme radius-scheme-name nas-backup-ip ip-address N/A Not specified by default. Setting RADIUS timers The device uses the following types of timers to control communication with a RADIUS server: Server response timeout timer (response-timeout) Defines the RADIUS request retransmission interval. After sending a RADIUS request (authentication/authorization or accounting request), the device starts the server response timeout timer. If the device receives no response from the RADIUS server before the timer expires, it resends the request. Server quiet timer (quiet) Defines the duration to keep an unreachable server in blocked state. If one server is not reachable, the device changes the server's status to blocked, starts this timer for the server, and tries to communicate with another server in active state. After the server quiet timer expires, the device changes the status of the server back to active. Real-time accounting timer (realtime-accounting) Defines the interval for the device to send real-time accounting packets to the RADIUS accounting server for online users. To implement real-time accounting, the device must periodically send real-time accounting packets to the accounting server for online users. Follow these guidelines when you set RADIUS timers: For the same type of users, the maximum number of transmission attempts multiplied by the RADIUS server response timeout period must be less than the client connection timeout time and cannot exceed 75 seconds. Otherwise, stop-accounting messages cannot be buffered, and the primary/secondary server switchover cannot take place. For example, the product of the two parameters must be less than 10 seconds for voice users and less than 30 seconds for Telnet users, because the client connection timeout period for voice users is 10 seconds and that for Telnet users is 30 seconds. When you configure the maximum number of RADIUS packet transmission attempts and the RADIUS server response timeout timer, consider the number of secondary servers. If the retransmission process takes too long, the client connection in the access module may time out while the device is trying to find an available server. For more information about the maximum number of RADIUS packet transmission attempts, see "Setting the maximum number of RADIUS request transmission attempts." When a number of secondary servers are configured, the client connections of access modules that have a short client connection timeout period may still be timed out during initial authentication or accounting, even if the packet transmission attempt limit and server response timeout period are configured with small values. In this case, the next authentication or accounting attempt can 35

48 succeed because the device has set the status of the unreachable servers to blocked and the amount of time for finding a reachable server has been shortened. Properly set the server quiet timer. Too short a quiet timer can result in frequent authentication or accounting failures because the device has to repeatedly attempt to communicate with an unreachable server that is in active state. To set RADIUS timers: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme view. 3. Set the RADIUS server response timeout timer. radius scheme radius-scheme-name timer response-timeout seconds N/A The default RADIUS server response timeout timer is 3 seconds. 4. Set the server quiet timer. timer quiet minutes The default server quiet timer is 5 minutes. 5. Set the real-time accounting interval. timer realtime-accounting minutes The default real-time accounting interval is 12 minutes. Configuring RADIUS accounting-on The accounting-on feature enables the device to send an accounting-on packet to the RADIUS server after it reboots so the server can log out users who logged in through the device before the reboot. Without this feature, users who were online before the reboot cannot log in again after the reboot, because the RADIUS server would consider them to be online already. If the device receives no response to the accounting-on packet, it re-sends the packet to the RADIUS server at a particular interval for the specified number of times. The accounting-on feature must work with the HP IMC network management system. To configure the accounting-on feature for a RADIUS scheme: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme view. 3. Enable accounting-on and configure parameters. radius scheme radius-scheme-name accounting-on enable [ interval seconds send send-times ] * N/A Disabled by default. The default interval is 3 seconds, and the default number of send-times is 50. Configuring the IP address of the security policy server The security policy server is the management and control center for Endpoint Admission Defense (EAD). The NAS checks the validity of received control packets and accepts only control packets from known servers. To use a security policy server that is independent of the AAA servers, you must configure the IP address of the security policy server on the NAS. To implement all EAD functions, configure both the IP address of the security policy server and the IP address of the IMC Platform on the NAS. 36

49 To configure the IP address of the security policy server for a scheme: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme view. 3. Specify a security policy server. radius scheme radius-scheme-name security-policy-server ip-address N/A No security policy server is specified by default. You can specify up to eight security policy servers for a RADIUS scheme. Enabling the RADIUS offload feature RADIUS servers that do not support EAP authentication cannot process EAP packets. To work with these servers, the device must process EAP packets from EAP clients before forwarding them to the servers. The RADIUS offload feature enables the device to process EAP packets. The RADIUS offload feature must work with the local EAP authentication server as follows: 1. After receiving EAP packets from an EAP client, the local EAP authentication server interacts with the client, encapsulates the authentication information of the client into the RADIUS MS-CHAPv2 attribute and sends the attribute in a RADIUS authentication request to the RADIUS server. 2. When a RADIUS server receives the requests, it resolves the authentication information in the request, performs authentication, and then encapsulates and sends the authentication result in a RADIUS packet to the local EAP authentication server. To deploy the RADIUS offload feature, complete the following tasks on the device: Configure the local EAP authentication server to use PEAP-MSCHAPv2 as the EAP authentication method. For more information about the configuration, see "Configuring local EAP authentication." Enable the EAP offload feature for the RADIUS schemes. To enable the EAP offload feature: 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 the EAP offload feature. eap offload method peap-mschapv2 Disabled by default. Configuring interpretation of the RADIUS class attribute as CAR parameters This task is required when the RADIUS server supports assigning CAR parameters through the class attribute. According to RFC 2865, a RADIUS server assigns the RADIUS class attribute (attribute 25) to a RADIUS client. However, the RFC does not require the RADIUS client to interpret the attribute and only requires the RADIUS client to send the attribute to the accounting server on an "as is" basis. When RADIUS servers use the class attribute to deliver the assigned CAR parameters, the device must interpret the attribute as the CAR parameters to implement user-based traffic monitoring and controlling. To configure the device to interpret the RADIUS class attribute as CAR parameters: 37

50 Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme view. 3. Interpret the class attribute as CAR parameters. radius scheme radius-scheme-name attribute 25 car N/A By default, RADIUS attribute 25 is not interpreted as CAR parameters. Enabling the trap function for RADIUS With the trap function, the NAS sends a trap message when either of the following events occurs: The status of a RADIUS server changes. If the NAS receives no response to an accounting or authentication request before the specified maximum number of RADIUS request transmission attempts is exceeded, it considers the server unreachable, sets the status of the server to block, and sends a trap message. If the NAS receives a response from a RADIUS server that it considers unreachable, the NAS considers that the RADIUS server is reachable again, sets the status of the server to active, and sends a trap message. The ratio of failed transmission attempts to the total authentication request transmission attempts exceeds a threshold. The threshold ranges from 1% to 100% and defaults to 30%. The threshold can only be configured through the MIB. Typically, the failure ratio is small. If a trap message is triggered because the failure ratio is higher than the threshold, troubleshoot the configuration on and the communication between the NAS and the RADIUS server. To enable the trap function for RADIUS: Step Command Remarks 1. Enter system view. system-view N/A 2. Enable the trap function for RADIUS. radius trap { accounting-server-down authentication-error-threshold authentication-server-down } Disabled by default. Enabling logging of RADIUS packets You can enable the device to generate logs for RADIUS packets. Make sure the device has sufficient system resources. To enable logging of RADIUS packets: Step Command Remarks 1. Enter system view. system-view N/A 2. Enable logging of RADIUS packets. radius log packet 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: 38

51 Step Command Remarks 1. Enter system view. system-view N/A 2. Enable the RADIUS client service. radius client enable Enabled by default. Displaying and maintaining RADIUS Task Command Remarks Display the configuration of RADIUS schemes. Display the RADIUS packet statistics. Display information about buffered stop-accounting requests for which no responses have been received. display radius scheme [ radius-scheme-name ] [ { begin exclude include } regular-expression ] display radius statistics [ { begin exclude include } regular-expression ] display stop-accounting-buffer { radius-scheme radius-scheme-name session-id session-id time-range start-time stop-time user-name user-name } [ { begin exclude include } regular-expression ] Available in any view. Available in any view. Available in any view. Clear RADIUS statistics. reset radius statistics Available in user view. Clear the buffered stop-accounting requests for which no responses have been received. reset stop-accounting-buffer { radius-scheme radius-scheme-name session-id session-id time-range start-time stop-time user-name user-name } Available in user view. Configuring HWTACACS schemes You cannot remove the HWTACACS schemes that are in use or change the IP addresses of the HWTACACS servers that are in use. HWTACACS configuration task list Task Creating an HWTACACS scheme Specifying the HWTACACS authentication servers Specifying the HWTACACS authorization servers Specifying the HWTACACS accounting servers and the relevant parameters Specifying the shared keys for secure HWTACACS communication Setting the username format and traffic statistics units Specifying the source IP address for outgoing HWTACACS packets Setting HWTACACS timers Displaying and maintaining HWTACACS Remarks Required. Required. Required. 39

52 Creating an HWTACACS scheme The HWTACACS protocol is configured on a per-scheme basis. Before you perform other HWTACACS configurations, create an HWTACACS scheme and enter HWTACACS scheme view. You can configure up to 16 HWTACACS schemes. You can delete an HWTACACS scheme only when it is not in use. 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. Specifying the HWTACACS authentication servers You can specify one primary authentication server and one secondary authentication server for an HWTACACS scheme. When the primary server is not available, the secondary server is used. If redundancy is not required, specify only the primary server. An HWTACACS server can function as the primary authentication server of one scheme and as the secondary authentication server of another scheme at the same time. You cannot specify the same IP address as both the primary and the secondary authentication servers in a scheme. 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. 3. Specify HWTACACS authentication servers. hwtacacs scheme hwtacacs-scheme-name Specify the primary HWTACACS authentication server: primary authentication ip-address [ port-number ] Specify a secondary HWTACACS authentication server: secondary authentication ip-address [ port-number ] N/A Configure at least one command. No authentication server is specified by default. Specifying the HWTACACS authorization servers You can specify one primary authorization server and one secondary authorization server for an HWTACACS scheme. When the primary server is not available, the secondary server is used. If redundancy is not required, specify only the primary server. An HWTACACS server can function as the primary authorization server of one scheme and as the secondary authorization server of another scheme at the same time. You cannot specify the same IP address as both the primary and the secondary authorization servers in a scheme. You can remove an authorization server only when no active TCP connection for sending authorization packets is using it. 40

53 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. 3. Specify HWTACACS authorization servers. hwtacacs scheme hwtacacs-scheme-name Specify the primary HWTACACS authorization server: primary authorization ip-address [ port-number ] Specify a secondary HWTACACS authorization server: secondary authorization ip-address [ port-number ] N/A Configure at least one command. No authorization server is specified by default. Specifying the HWTACACS accounting servers and the relevant parameters You can specify one primary accounting server and one secondary accounting server for an HWTACACS scheme. When the primary server is not available, the secondary server is used. If redundancy is not required, specify only the primary server. When the device receives a connection teardown request from a host or a connection teardown command from an administrator, it sends a stop-accounting request to the accounting server. You can enable buffering of non-responded stop-accounting requests to allow the device to buffer and resend a stop-accounting request until it receives a response or the number of stop-accounting attempts reaches the configured limit. When the number of stop-accounting attempts reaches the configured limit, the device discards the packet. An HWTACACS server can function as the primary accounting server of one scheme and as the secondary accounting server of another scheme at the same time. You cannot specify the same IP address as both the primary and the secondary accounting servers in a scheme. HWTACACS does not support accounting for FTP users. You can remove an accounting server only when no active TCP connection for sending accounting packets is using it. 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. 3. Specify HWTACACS accounting servers. hwtacacs scheme hwtacacs-scheme-name Specify the primary HWTACACS accounting server: primary accounting ip-address [ port-number ] Specify a secondary HWTACACS accounting server: secondary accounting ip-address [ port-number ] N/A Configure at least one command. No accounting server is specified by default. 41

54 Step Command Remarks 4. Enable buffering of stop-accounting requests to which no responses are received. stop-accounting-buffer enable Enabled by default. 5. Set the maximum number of stop-accounting attempts. retry stop-accounting retry-times The default setting is 100. Specifying the shared keys for secure HWTACACS communication The HWTACACS client and HWTACACS server use the MD5 algorithm and a shared key pair for password encryption. To specify a shared key for secure HWTACACS communication: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter HWTACACS scheme view. 3. Specify a shared key for secure HWTACACS authentication, authorization, or accounting communication. hwtacacs scheme hwtacacs-scheme-name key { accounting authentication authorization } [ cipher simple ] key N/A By default, no shared key is specified. The shared key configured on the device must be the same as the shared key configured on the HWTACACS server. In FIPS mode, the shared key for secure HWTACACS communication must be at least eight characters that contain digits, uppercase letters, lowercase letters, and special characters. Setting the username format and traffic statistics units A username is typically in the format userid@isp-name, where isp-name represents the user's ISP domain name. By default, the ISP domain name is included in a username. However, some HWTACACS servers do not recognize usernames that contain the ISP domain names. In this case, you can configure the device to remove the domain name from each username to be sent. The device periodically sends accounting updates to HWTACACS accounting servers to report the traffic statistics of online users. For normal and accurate traffic statistics, make sure that the units for data flows and for data packets on the device are consistent with the units configured on the HWTACACS servers. To set the username format and the traffic statistics units for an HWTACACS scheme: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter HWTACACS scheme view. hwtacacs scheme hwtacacs-scheme-name N/A 42

55 Step Command Remarks 3. Set the format of usernames sent to the HWTACACS servers. 4. Specify the unit for data flows or packets sent to the HWTACACS servers. user-name-format { keep-original with-domain without-domain } data-flow-format { data { byte giga-byte kilo-byte mega-byte } packet { giga-packet kilo-packet mega-packet one-packet } }* By default, the ISP domain name is included in a username. If an HWTACACS server does not support a username that includes the domain name, configure the device to remove the domain name before sending the username to the server. For level switching authentication, user-name-format keep-original and user-name-format without-domain commands make sure that usernames sent to the HWTACACS server do not include ISP domain names. The default unit is byte for data flows and one-packet for data packets. Specifying the source IP address for outgoing HWTACACS packets The source IP address of HWTACACS packets that a NAS sends must match the IP address of the NAS configured on the HWTACACS server. An HWTACACS server identifies a NAS by IP address. When the HWTACACS server receives a packet, it checks whether the source IP address of the packet is the IP address of a managed NAS. If it is, the server processes the packet. If it is not, the server drops the packet. To communicate with the HWTACACS server, the source address of outgoing HWTACACS packets is typically the IP address of an egress interface on the NAS. However, in some situations, you must change the source IP address. You can specify the source IP address for outgoing HWTACACS packets for a specific HWTACACS scheme or all HWTACACS schemes. Before sending an HWTACACS packet, the NAS selects a source IP address in the following order: 1. The source IP address specified for the HWTACACS scheme. 2. The source IP address specified in system view. 3. The 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 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: 43

56 Step Command Remarks 1. Enter system view. system-view N/A 2. Enter HWTACACS scheme view. 3. Specify a source IP address for outgoing HWTACACS packets. hwtacacs scheme hwtacacs-scheme-name nas-ip ip-address N/A By default, the IP address of the outbound interface is used as the source IP address. Setting HWTACACS timers The device uses the following timers to control communication with an HWTACACS server: Server response timeout timer (response-timeout) Defines the HWTACACS request retransmission interval. After sending an HWTACACS request (authentication, authorization, or accounting request), the device starts the server response timeout timer. If the device does not receive a response from the server before the timer expires, it resends the request. Primary server quiet timer (quiet) Defines the duration to keep an unreachable primary server in blocked state. If a primary server is not reachable, the device changes the server's status to blocked, starts this timer for the server, and tries to communicate with the secondary server if the secondary server is configured and in active state. After the primary server quiet timer expires, the device changes the status of the primary server back to active. To set HWTACACS timers: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter HWTACACS scheme view. 3. Set the HWTACACS server response timeout timer. 4. Set the quiet timer for the primary server. hwtacacs scheme hwtacacs-scheme-name timer response-timeout seconds timer quiet minutes N/A The default HWTACACS server response timeout timer is 5 seconds. The default quiet timer for the primary server is 5 minutes. Displaying and maintaining HWTACACS Task Command Remarks Display the configuration or statistics of HWTACACS schemes. Display information about buffered stop-accounting requests for which no responses have been received. Clear HWTACACS statistics. display hwtacacs [ hwtacacs-server-name [ statistics ] ] [ { begin exclude include } regular-expression ] display stop-accounting-buffer hwtacacs-scheme hwtacacs-scheme-name [ { begin exclude include } regular-expression ] reset hwtacacs statistics { accounting all authentication authorization } Available in any view. Available in any view. Available in user view. 44

57 Task Command Remarks Clear buffered stop-accounting requests that do not get responses. reset stop-accounting-buffer hwtacacs-scheme hwtacacs-scheme-name Available in user view. Configuring LDAP schemes LDAP configuration task list Task Creating an LDAP scheme Specifying the LDAP authentication server Specifying the LDAP authorization server Specifying the LDAP version Specifying the LDAP server type Setting the LDAP server timeout period Configuring administrator attributes Configuring LDAP user attributes Configuring LDAP group attributes Displaying and maintaining LDAP Remarks Required. Required. Required. Required. Creating an LDAP scheme Before performing other LDAP configurations, you must create an LDAP scheme and enter LDAP scheme view. You can configure up to 16 LDAP schemes. An LDAP scheme can be referenced by multiple ISP domains, and can be deleted only when it is not referenced. To create an LDAP scheme and enter LDAP scheme view: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an LDAP scheme and enter LDAP scheme view. ldap scheme ldap-scheme-name By default, no LDAP scheme is present. Specifying the LDAP authentication server Changing the IP address and port number of the LDAP authentication server only affects LDAP authentication processes that occur after your change. To specify the LDAP authentication server: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter LDAP scheme view. ldap scheme ldap-scheme-name N/A 3. Specify the LDAP authentication server. authentication-server ip-address [ port-number ] Not specified by default. 45

58 Specifying the LDAP authorization server Changing the IP address and port number of the LDAP authorization server only affects LDAP authorization processes that occur after your change. To specify the LDAP authorization server: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter LDAP scheme view. ldap scheme ldap-scheme-name N/A 3. Specify the LDAP authorization server. authorization-server ip-address [ port-number ] Not specified by default. Specifying the LDAP version The device supports LDAPv2 and LDAPv3. A Microsoft LDAP server supports only LDAPv3. To specify the LDAP version: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter LDAP scheme view. ldap scheme ldap-scheme-name N/A 3. Specify the LDAP version. protocol-version { v2 v3 } LDAPv3 is used by default. Specifying the LDAP server type The device supports LDAP servers by IBM, Microsoft, and Sun. To specify the type of the LDAP server: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter LDAP scheme view. ldap scheme ldap-scheme-name N/A 3. Specify the LDAP server type. server-type { ibm microsoft sun } The default LDAP server type is microsoft. Setting the LDAP server timeout period If the device sends a bind or search request to an LDAP server but does not receive a response from the server within the LDAP server timeout period, the device considers that the authentication or authorization request has timed out and tries the backup authentication or authorization method, if any. If no backup method is configured, the device considers the authentication or authorization attempt as a failure. To set the LDAP server timeout period: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter LDAP scheme view. ldap scheme ldap-scheme-name N/A 46

59 Step Command Remarks 3. Set the LDAP server timeout period. server-timeout time-interval The default LDAP server timeout period is 10 seconds. Configuring administrator attributes To configure the administrator DN and password for binding with the LDAP server during LDAP authentication: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter LDAP scheme view. ldap scheme ldap-scheme-name N/A 3. Specify the administrator DN. login-dn dn-string 4. Configure the administrator password. login-password [ cipher simple ] password Not specified by default. The administrator DN specified on the device must be consistent with the administrator DN specified on the LDAP server. Not specified by default. Configuring LDAP user attributes To authenticate a user, an LDAP client must establish a connection to the LDAP server, obtain the user DN, and use the user DN and the user's password to bind with the LDAP server. According to the LDAP DN search mechanism, an LDAP client sends search requests to the server based on the search policy determined by the LDAP user attributes of the LDAP client. The LDAP user attributes include: Search base DN Search scope User group attribute Username attribute Username format User object class If the user group attribute is configured on the LDAP server, the user group attribute setting on the device must match the setting on the LDAP server. A user DN search starting from the root directory might take a long time if the LDAP server has many levels of directories. To improve search efficiency, you can change the start point by specifying the search base DN. If the usernames configured on the LDAP server do not contain domain names, configure the device to remove domain names from the usernames to be sent to the LDAP server. Otherwise, configure the device to send usernames containing domain names to the LDAP server. The Microsoft LDAP server defines a default user group attribute named memberof. If the Microsoft LDAP server is used, the device obtains the user group by searching for the user DN. 47

60 The IBM LDAP server and Sun LDAP server have no default user group attribute, and you can configure a user group attribute by modifying the schema file on the LDAP server. If the IBM server or Sun server is used and there is no user-defined user group attribute, the device figures out the user group by checking each user group to see whether it contains the user DN. For more information about user group attribute configuration, see "Configuring LDAP group attributes." To configure LDAP user attributes: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter LDAP scheme view. ldap scheme ldap-scheme-name N/A 3. Specify the user search base DN. 4. Specify the user search scope. 5. Specify the required user group attribute. 6. Specify the username attribute. 7. Specify the username format. 8. Specify the user object class. user-parameters search-base-dn base-dn user-parameters search-scope { all-level single-level } user-parameters user-group-attribute attribute-name user-parameters user-name-attribute { name-attribute cn uid } user-parameters user-name-format { with-domain without-domain } user-parameters user-object-class object-class-name Not specified by default. The default user search scope is all-level. By default, no user group attribute is specified, and the default user group attribute defined on the LDAP server is used. The default username attribute is cn. The default username format is without-domain. By default, no user object class is specified, and the default user object class on the LDAP server is used. The default user object class varies by device. Configuring LDAP group attributes User authorization is implemented by searching user groups and obtaining authorization information. For a user group search, specify the search method and criteria (LDAP group attributes). Specifying group attributes is necessary for IBM and Sun LDAP servers. Because the user object class of Microsoft LDAP server contains user group attributes, specifying group attributes is unnecessary for Microsoft LDAP server. Configurable LDAP group attributes are as follows: Group name attribute Group object class Member name attribute Search base DN Search scope 48

61 Typically, the group object class and member name attribute take the default values defined by the server manufacturers. If no default values are specified or you want to customize them, you can use commands to configure the values. A user group search starting from the root directory might take a long time if the LDAP server has many levels of directories. To improve search efficiency, you can change the start point by specifying the search base DN. Support for the group object class default and member name attribute default depends on the LDAP server manufacturers. IBM and Sun support the default group object class and member name attribute, but Microsoft does not have these defaults. To configure LDAP group attributes: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter LDAP scheme view. ldap scheme ldap-scheme-name N/A 3. Specify the search base DN for group search. 4. Specify the search scope for group search. 5. Specify a user-defined group object class for group search. 6. Specify the member name attribute for group search. 7. Specify the group name attribute for group search. group-parameters search-base-dn base-dn group-parameters search-scope { all-level single-level } group-parameters group-object-class object-class-name group-parameters member-name-attribute attribute-name group-parameters group-name-attribute { name-attribute cn uid } Not specified by default. The default search scope for group search is all-level. Not specified by default. Not specified by default. The default group name attribute for group search is cn. Displaying and maintaining LDAP Task Command Remarks Display the configuration of LDAP schemes. display ldap scheme [ scheme-name ] [ { begin exclude include } regular-expression ] Available in any view. Configuring AAA methods for ISP domains By default, the device uses local (default) AAA methods for users in an ISP domain. To use other AAA methods for them, configure the device to reference existing AAA schemes for the ISP domain. For information about configuring AAA schemes, see "Configuring RADIUS schemes," "Configuring HWTACACS schemes," and "Configuring LDAP schemes." To use local authentication for users in an ISP domain, first configure local user accounts on the device (see "Configuring local user attributes"). 49

62 Creating an ISP domain In a networking scenario with multiple ISPs, the device can connect users from different ISPs. Different ISP users can have different user attributes (such as username and password structures), different service types, and different rights. To manage these ISP users, you need to create ISP domains and then configure AAA methods and domain attributes for each ISP domain. The device can accommodate up to 16 ISP domains, including the system-defined ISP domain system. You can specify one ISP domain as the default domain. On the device, each user belongs to an ISP domain. If a user provides no ISP domain name at login, the device considers the user belongs to the default ISP domain. The device chooses an authentication domain for each user in the following order: The authentication domain specified for the access module The ISP domain in the username The default ISP domain of the device The ISP domain specified for users with unknown domain names If all the domains are unavailable, user authentication will fail. NOTE: Support for the authentication domain configuration depends on the access module. You can specify an authentication domain for 802.1X, portal, or MAC address authentication. To create an ISP domain: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an ISP domain and enter ISP domain view. domain isp-name N/A 3. Return to system view. quit N/A 4. Specify the default ISP domain. 5. Specify an ISP domain for users with unknown domain names. domain default enable isp-name domain if-unknown isp-name By default, the default ISP domain is the system-defined ISP domain system. 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. By default, no ISP domain is specified for users with unknown domain names. To delete the ISP domain that is functioning as the default ISP domain, you must change it to a non-default ISP domain by using the undo domain default enable command. 50

63 Configuring ISP domain attributes In an ISP domain, you can configure the following attributes: Domain status By placing the ISP domain to the active or blocked state, you allow or deny network service requests from users in the domain. Maximum number of online users The device controls the number of online users in a domain to ensure reliable system performance and services. Idle cut Enables the device to check the traffic of each online user in the domain at the idle timeout interval, and to log out any user in the domain whose traffic during the idle timeout period is less than the specified minimum traffic. Self-service server location Allows users to access the self-service server to manage their own accounts and passwords. A self-service RADIUS server running on IMC is required for the self-service server location function to work. IP address pool for allocating addresses to PPP users The device assigns IP addresses from the pool to PPP users in the domain. Default authorization user profile If a user passes authentication but is not authorized with a user profile, the device authorizes the default user profile of the ISP domain to the user and restricts the user's behavior based on the profile. For more information about user profiles, see "Configuring a user profile." An ISP domain attribute applies to all users in the domain. 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 3. Place the ISP domain to the active or blocked state. 4. Specify the maximum number of online users in the ISP domain. 5. Configure the idle cut function. 6. Enable the self-service server location function and specify the URL of the self-service server. state { active block } access-limit enable max-user-number idle-cut enable minute [ flow ] self-service-url enable url-string By default, an ISP domain is in active state, and users in the domain can request network services. No limit is specified by default. Disabled by default. This command is effective only for LAN, portal, and PPP users. In a portal stateful failover scenario, set the idle cut interval to be greater than 5 minutes to make sure data of online users can be backed up. Disabled by default. 51

64 Step Command Remarks 7. Define an IP address pool for allocating addresses to PPP users. 8. Specify the default authorization user profile. 9. Set the device to include the idle cut time in the user online time to be uploaded to the server. ip pool pool-number low-ip-address [ high-ip-address ] authorization-attribute user-profile profile-name session-time include-idle-time By default, no IP address pool is configured for PPP users. By default, an ISP domain has no default authorization user profile. By default, the user online time uploaded to the server excludes the idle cut time. Configuring authentication methods for an ISP domain In AAA, authentication, authorization, and accounting are separate processes. Authentication refers to the interactive authentication process of username/password/user information during an access or service request. The authentication process does not send authorization information to a supplicant or trigger any accounting. AAA supports the following authentication methods: No authentication (none) The method trusts all users and does not perform authentication. For security purposes, do not use the 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 provides high speed and low cost benefits, but the amount of information that can be stored is limited by the size of the storage space. Remote authentication (scheme) The NAS works with a RADIUS, HWTACACS, or LDAP server to authenticate users. Remote authentication provides centralized information management, high capacity, high reliability, and support for centralized authentication service for multiple NASs. You can configure local or no authentication as the backup method, which will be used when the remote server is not available. The no authentication method can only be configured for LAN users as the backup method of remote authentication. You can configure AAA authentication to work alone without authorization and accounting. By default, an ISP domain uses the local authentication method. Configuration prerequisites Before configuring authentication methods, complete the following tasks: For RADIUS, HWTACACS, or LDAP authentication, configure the RADIUS, HWTACACS, or LDAP scheme to be referenced first. Local and none authentication methods do not require a scheme. Determine the access type or service type to be configured. With AAA, you can configure an authentication method for each access type and service type to limit the authentication protocols that users can use for access. Determine whether to configure the default authentication method for all access types or service types. 52

65 Configuration guidelines When configuring authentication methods, follow these guidelines: If you configure an authentication method that references a RADIUS scheme and an authorization method that does not reference a RADIUS scheme, AAA accepts only the authentication result from the RADIUS server. The Access-Accept message from the RADIUS server also includes the authorization information, but the device ignores the information. You can configure a default authentication method for an ISP domain. The default method will be used for all users who support the authentication method and have no specific authentication method configured. You can configure local authentication (local) or no authentication (none) as the backup for remote authentication that is used when the remote authentication server is unavailable. Local authentication (local) and no authentication (none) cannot have a backup method. By default, the device uses the login username of the user for level switching authentication if the method for level switching authentication references an HWTACACS scheme. If the method for level switching authentication references a RADIUS scheme, the system uses the username configured for the corresponding privilege level on the RADIUS server for level switching authentication, rather than the login username. A username configured on the RADIUS server is in the format $enablevel$, where level specifies the privilege level that the user wants to enter. For example, if user user1 of domain aaa wants to switch the privilege level to 3, the system uses $enab3@aaa$ for authentication when the domain name is required and uses $enab3$ for authentication when the domain name is not required. Configuration procedure To configure authentication methods for an ISP domain: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter ISP domain view. domain isp-name N/A 3. Specify the default authentication method for all types of users. 4. Specify the authentication method for LAN users. 5. Specify the authentication method for login users. 6. Specify the authentication method for portal users. authentication default { hwtacacs-scheme hwtacacs-scheme-name [ local ] ldap-scheme ldap-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] } authentication lan-access { local none radius-scheme radius-scheme-name [ local none ] } authentication login { hwtacacs-scheme hwtacacs-scheme-name [ local ] local ldap-scheme ldap-scheme-name [ local ] none radius-scheme radius-scheme-name [ local ] } authentication portal { ldap-scheme ldap-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] } 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. The default authentication method is used by default. 53

66 Step Command Remarks 7. Specify the authentication method for PPP users. 8. Specify the authentication method for privilege level switching. 9. Specify the authentication method for users accessing through APs. authentication ppp { hwtacacs-scheme hwtacacs-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] } authentication super { hwtacacs-scheme hwtacacs-scheme-name radius-scheme radius-scheme-name } authentication wlan-ap radius-scheme radius-scheme-name The default authentication method is used by default. Support for this feature depends on the device model. For more information, see About the Configuration Guides for HP Unified Wired-WLAN Products. The default authentication method is used by default. The default authentication method is used by default. Configuring authorization methods for an ISP domain In AAA, authorization is a separate process at the same level as authentication and accounting. It sends authorization requests to the specified authorization servers and sends authorization information to users after successful authorization. Authorization method configuration is optional in AAA configuration. AAA supports the following authorization methods: No authorization (none) The NAS performs no authorization exchange. After passing authentication, non-login users can access the network, FTP users can access the root directory of the NAS, and other login users have Level 0 (visiting) access. Local authorization (local) The NAS performs authorization according to the user attributes configured for users. Remote authorization (scheme) The NAS works with a RADIUS, HWTACACS, or LDAP 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 included in the Access-Accept message. HWTACACS/LDAP authorization is separate from HWTACACS/LDAP authentication, and the authorization information is included in the authorization response after successful authentication. You can configure local authorization or no authorization as the backup method. The backup method will be used when the remote server is not available. Configuration prerequisites Before configuring authorization methods, complete the following tasks: 1. For HWTACACS or LDAP authorization, configure the HWTACACS or LDAP scheme to be referenced first. For RADIUS authorization, the RADIUS authorization scheme must be the same as the RADIUS authentication scheme. Otherwise, it does not take effect. 2. Determine the access type or service type to be configured. With AAA, you can configure an authorization scheme for each access type and service type to limit the authorization protocols that can be used for access. 54

67 3. Determine whether to configure an authorization method for all access types or service types. Configuration guidelines When configuring authorization methods, follow these guidelines: To configure RADIUS authorization, you must also configure RADIUS authentication, and reference the same RADIUS scheme for RADIUS authentication and authorization. If the RADIUS authorization configuration is invalid or RADIUS authorization fails, the RADIUS authentication also fails. If RADIUS authorization fails, the server sends an error message to the NAS, indicating that the server itself is not responding. You can configure a default authorization method for an ISP domain. This method will be used for all users who support the authentication method and have no specific authorization method configured. You can configure local authorization (local) or no authorization (none) as the backup for remote authorization that is used when the remote authorization server is unavailable. Local authorization (local) and no authorization (none) cannot have a backup method. Configuration procedure To configure authorization methods for an ISP domain: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter ISP domain view. domain isp-name N/A 3. Specify the default authorization method for all types of users. 4. Specify the command authorization method. 5. Specify the authorization method for LAN users. 6. Specify the authorization method for login users. 7. Specify the authorization method for portal users. authorization default { hwtacacs-scheme hwtacacs-scheme-name [ local ] local ldap-scheme ldap-scheme-name [ local ] none radius-scheme radius-scheme-name [ local ] } authorization command { hwtacacs-scheme hwtacacs-scheme-name [ local none ] local none } authorization lan-access { local none radius-scheme radius-scheme-name [ local none ] } authorization login { hwtacacs-scheme hwtacacs-scheme-name [ local ] local ldap-scheme ldap-scheme-name [ local ] none radius-scheme radius-scheme-name [ local ] } authorization portal { local none radius-scheme radius-scheme-name [ local ] } The default authorization method is local for all types of users. The default authorization method is used by default. The default authorization method is used by default. The default authorization method is used by default. The default authorization method is used by default. 55

68 Step Command Remarks 8. Specify the authorization method for PPP users. authorization ppp { hwtacacs-scheme hwtacacs-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] } The default authorization method is used by default. Support for this feature depends on the device model. For more information, see About the Configuration Guides for HP Unified Wired-WLAN Products. Configuring accounting methods for an ISP domain In AAA, accounting is a separate process at the same level as authentication and authorization. This process sends accounting start/update/end requests to the specified accounting server. Accounting is optional. AAA supports the following accounting methods: No accounting (none) The NAS does not perform accounting for the users. Local accounting (local) Local accounting is implemented on the NAS. It counts and controls the number of concurrent users who use the same local user account. 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 will be used when the remote server is not available. By default, an ISP domain uses the local accounting method. Configuration prerequisites Before configuring accounting methods, complete the following tasks: 1. For RADIUS or HWTACACS accounting, configure the RADIUS or HWTACACS scheme to be referenced first. The local and none accounting methods do not require a scheme. 2. Determine the access type or service type to be configured. With AAA, you can configure an accounting method for each access type and service type to limit the accounting protocols that can be used for access. 3. Determine whether to configure an accounting method for all access types or service types. Configuration guidelines When configuring accounting methods, follow these guidelines: You can configure a default accounting method for an ISP domain. This method will be used for all users who support the accounting method and have no specific accounting method configured. You can configure local accounting (local) or no accounting (none) as the backup for remote accounting that is used when the remote accounting server is unavailable. Local accounting (local) and no accounting (none) cannot have a backup method. Accounting is not supported for FTP services. 56

69 If you enable the accounting optional feature, the limit on the number of local user connections does not take effect. Configuration procedure To configure accounting methods for an ISP domain: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter ISP domain view. domain isp-name N/A 3. Enable the accounting optional feature. 4. Specify the default accounting method for all types of users. 5. Specify the command accounting method. 6. Specify the accounting method for LAN users. 7. Specify the accounting method for login users. 8. Specify the accounting method for portal users. 9. Specify the accounting method for PPP users. accounting optional accounting default { hwtacacs-scheme hwtacacs-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] } accounting command hwtacacs-scheme hwtacacs-scheme-name accounting lan-access { local none radius-scheme radius-scheme-name [ local none ] } accounting login { hwtacacs-scheme hwtacacs-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] } accounting portal { local none radius-scheme radius-scheme-name [ local ] } accounting ppp { hwtacacs-scheme hwtacacs-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] } Disabled by default. With the accounting optional feature, a device allows users to use network resources when no accounting server is available or communication with all accounting servers fails. 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. The default accounting method is used by default. Support for this feature depends on the device model. For more information, see About the Configuration Guides for HP Unified Wired-WLAN Products. 57

70 Tearing down user connections Step Command Remarks 1. Enter system view. system-view N/A 2. 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 } The command applies only to LAN, portal, and PPP user connections. Configuring local EAP authentication Local EAP authentication can be used in some simple application environments to authenticate 802.1X users. In addition, it can help implement the RADIUS offload feature, which enables the NAS to terminate EAP packets when the remote RADIUS server does not support EAP authentication. For more information about RADIUS offload, see "Enabling the RADIUS offload feature." Local EAP authentication is performed by the local EAP authentication server based on either the local user database (the default) or an LDAP database. The local user database maintains all user accounts configured on the NAS, but an LDAP database maintains user accounts configured on the LDAP server. Using the local user database is cost effective but the maximum number of users is limited by the device's hardware. If an LDAP server is available, using an LDAP database is a good practice because it allows you to implement centralized user information management in scenarios with multiple NASs. Configuration procedure To implement local EAP authentication, complete these tasks: 1. Configure the local EAP authentication server. See "Configuring the local EAP authentication server." 2. Configure the device to use local authentication for LAN users. This step is optional. See "Configuring authentication methods for an ISP domain." 3. Configure local users on the device, or add users on an LDAP server and configure an LDAP scheme on the device. See "Configuring local users," "Configuring LDAP schemes," or the user manuals of the LDAP server. 4. Configure 802.1X on the device. Configuring the local EAP authentication server A local EAP authentication server is a local authentication server that uses an EAP profile. An EAP profile is a collection of local EAP authentication settings, including the authentication method and user database to be used and, for some authentication methods, the SSL server policy to be referenced. The following EAP authentication methods are supported: MD5 challenge PEAP-GTC PEAP-MSCHAPv2 58

71 TLS TTLS The device supports these user information query mechanisms: local query, LDAP query, and LDAP query plus local query. With the last mechanism, local query is used when the LDAP server is not reachable, the specified LDAP scheme does not exist, or the LDAP server does not support the query. You can cannot modify or remove an EAP profile that is referenced by the local authentication server. To configure the local EAP authentication server: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an EAP profile and enter EAP profile view. 3. Specify the EAP authentication method. 4. Specify the user credential verification approach for local EAP authentication. 5. Specify the SSL server policy for EAP authentication. eap-profile profile-name method { md5 peap-gtc peap-mschapv2 tls ttls } user-credentials { ldap-scheme ldap-scheme-name [ local ] local } ssl-server-policy policy-name N/A By default, no EAP authentication method is specified for an EAP profile. To configure multiple EAP authentication methods, repeat this step. A method configured earlier has a higher priority. PEAP-GTC and PEAP-MSCHAPv2 are mutually exclusive. By default, the local user database is used for user credential verification. Perform this step when the EAP authentication method of PEAP-GTC, PEAP-MSCHAPv2, TLS, or TTLS is configured. By default, no SSL server policy is specified for an EAP profile. For more information about SSL server policy configuration, see "Configuring SSL." 6. Return to system view. quit N/A 7. Specify the EAP profile for the local authentication server. local-server authentication eap-profile profile-name N/A Configuring a NAS ID-VLAN binding The access locations of users can be identified by their access VLANs. Configure NAS ID-VLAN bindings on the device in application scenarios where identifying the access locations of users is required. When a user goes online, the device obtains the NAS ID by the access VLAN of the user and sends the NAS ID to the RADIUS server through the NAS-identifier attribute. To configure a NAS ID-VLAN binding: 59

72 Step Command Remarks 1. Enter system view. system-view N/A 2. Create a NAS ID profile and enter NAS ID profile view. 3. Configure a NAS ID-VLAN binding. aaa nas-id profile profile-name nas-id nas-identifier bind vlan vlan-id You can apply a NAS ID profile to an interface enabled with portal. See "Configuring portal authentication." By default, no NAS ID-VLAN binding exists. Specifying the device ID Support for this feature depends on the device model. For more information, see About the Configuration Guides for HP Unified Wired-WLAN Products. Devices operating in stateful failover mode for portal services are uniquely identified by their device IDs. In stateful failover mode, a device ID can only be 1 or 2. For more information about the stateful failover mode for portal services, see "Configuring portal authentication." Do not configure any device ID for a device operating in standalone mode. Configuring or changing the device ID of a device will log out all online users of the device. HP recommends that you save the configuration and reboot the device after configuring or changing the device ID. To specify the device ID: Step Command Remarks 1. Enter system view. system-view N/A 2. Specify the device ID. nas device-id device-id By default, the device ID is 1. Displaying and maintaining AAA Task Command Remarks Display the configuration of ISP domains. Display information about user connections. display domain [ isp-name ] [ { begin exclude include } regular-expression ] 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 ] [ { begin exclude include } regular-expression ] Available in any view. Available in any view. AAA configuration examples The configuration examples were created on the 11900/10500/ G unified wired-wlan module and might vary with device models. 60

73 When configuring the 11900/10500/ G unified wired-wlan module, make sure the settings are correct (including VLAN settings) on the internal Ethernet interface that connects the module to the switch. For more information, see HP 11900/10500/ G Unified Wired-WLAN Module Basic Configuration Guide. By default, the aggregate interfaces between the access controller engine and the switching engine on an 830 switch or an 870 appliance are Access interfaces in VLAN 1. When configuring the two aggregate interfaces, make sure their permitted VLANs are the same. HP also recommends that you set their link type to be the same. HWTACACS authentication and authorization for Telnet users Network requirements As shown in Figure 10, an HWTACACS server is located on /24 and uses the shared key expert to authenticate AAA packets. Configure the AC to do the following: Use the HWTACACS server for user authentication and authorization. Send usernames that do not include domain names to the server. Use the shared key expert to authenticate packets exchanged with the server. Figure 10 Network diagram Authentication server /24 IP network Telnet user AP AC Configuration procedure 1. On the HWTACACS server, set the shared key to expert and add the Telnet user account information. (Details not shown.) 2. Configure the AC: # Assign IP addresses to the interfaces. (Details not shown.) # Enable the Telnet server on the AC. <AC> system-view [AC] telnet server enable # Configure the AC to use AAA for Telnet users. [AC] user-interface vty 0 4 [AC-ui-vty0-4] authentication-mode scheme [AC-ui-vty0-4] quit # Create an ISP domain bbb and set it as the default ISP domain. [AC] domain bbb 61

74 [AC-isp-bbb] quit [AC] domain default enable bbb # Create HWTACACS scheme hwtac. [AC] hwtacacs scheme hwtac # Specify the primary authentication server and the service port number. [AC-hwtacacs-hwtac] primary authentication # Specify the primary authorization server and the service port number. [AC-hwtacacs-hwtac] primary authorization # Set the shared keys for authentication and authorization to expert. [AC-hwtacacs-hwtac] key authentication simple expert [AC-hwtacacs-hwtac] key authorization simple expert # Configure the scheme to remove the domain name from a username before sending the username to the HWTACACS server. [AC-hwtacacs-hwtac] user-name-format without-domain [AC-hwtacacs-hwtac] quit # Use either of the following methods to configure the authentication and authorization methods: Create an ISP domain, and configure authentication and authorization methods for all login users in the domain. [AC] domain bbb [AC-isp-bbb] authentication login hwtacacs-scheme hwtac [AC-isp-bbb] authorization login hwtacacs-scheme hwtac [AC-isp-bbb] quit Create an ISP domain, and configure the default authentication and authorization methods for all types of users in the domain. [AC] domain bbb [AC-isp-bbb] authentication default hwtacacs-scheme hwtac [AC-isp-bbb] authorization default hwtacacs-scheme hwtac Verifying the configuration 1. Telnet to the AC, and enter the correct username and password. 2. Use the display connection command on the AC to display information about the user connection. Local authentication and HWTACACS authorization for Telnet users Network requirements As shown in Figure 11, an HWTACACS server is located on /24 and uses the shared key expert to authenticate AAA packets. Configure the AC to do the following: Perform local authentication for Telnet users. Use the HWTACACS server for Telnet user authorization. Send usernames that do not include domain names to the server. Use the shared key expert to authenticate packets exchanged with the server. 62

75 Add a local user account on the AC, and set both the username and password to telnet. The user uses this account to Telnet to the AC. Figure 11 Network diagram Configuration procedure The local authentication and HWTACACS authorization configuration described in this section applies to other types of users if you correctly modify the service type in the commands. # Assign IP addresses to the interfaces. (Details not shown.) # Enable the Telnet server on the AC. <AC> system-view [AC] telnet server enable # Configure the AC to use AAA for Telnet users. [AC] user-interface vty 0 4 [AC-ui-vty0-4] authentication-mode scheme [AC-ui-vty0-4] quit # Create an ISP domain named bbb and set it as the default ISP domain. [AC] domain bbb [AC-isp-bbb] quit [AC] domain default enable bbb # Create HWTACACS scheme hwtac. [AC] hwtacacs scheme hwtac # Specify the primary authorization server and the service port number. [AC-hwtacacs-hwtac] primary authorization # Set the shared key for authorization to expert. [AC-hwtacacs-hwtac] key authorization simple expert # Configure the scheme to remove the domain name from a username before sending the username to the HWTACACS server. [AC-hwtacacs-hwtac] user-name-format without-domain [AC-hwtacacs-hwtac] quit # Configure a local user with the name telnet and password telnet. [AC] local-user telnet [AC-luser-telnet] service-type telnet [AC-luser-telnet] password simple telnet # Use either of the following methods to configure the AAA methods: 63

76 Create an ISP domain, and configure authentication and authorization methods for all login users in the domain. [AC] domain bbb [AC-isp-system] authentication login local [AC-isp-bbb] authorization login hwtacacs-scheme hwtac [AC-isp-bbb] quit Create an ISP domain, and configure the default authentication and authorization methods for all types of users. [AC] domain bbb [AC-isp-bbb] authentication default local [AC-isp-bbb] authorization default hwtacacs-scheme hwtac Verifying the configuration 1. Telnet to the AC, and enter the username telnet and password telnet. 2. Use the display connection command on the AC to display information about the user connection. LDAP authentication for Telnet users Network requirements As shown in Figure 12, Active Directory of the Microsoft Windows 2003 Server is an LDAP server located on /24, and the server domain name is ldap.com. On the LDAP server, set the administrator password as admin!123456, and add a user with the username of aaa and password of ldap! Configure the AC to use the LDAP server to authenticate Telnet users. Figure 12 Network diagram LDAP server /24 IP network Vlan-int /24 Telnet user /24 Configuration procedure The AC does not support LDAP authorization. You can configure an HWTACACS scheme as the authorization scheme to work with LDAP authentication. For more information about HWTACACS scheme configuration, see "Configuring HWTACACS schemes." 1. Configure user aaa and the administrator password on the LDAP server: a. Select Administrative Tools > Active Directory Users and Computers from the Start menu or launch it from the Windows Control Panel. The Active Directory Users and Computers window appears. b. Select Action > New > User in the top menu bar. The New Object - User window appears. 64

77 c. Enter aaa in the First name, Full name, User logon name, and User logon name (pre-windows 2000) fields, as shown in Figure 13, and then click Next. Figure 13 Creating user aaa d. Enter ldap! in both the Password and Confirm password fields, select the password strategy options as needed, and then click Next. The New Object - User window closes. Figure 14 Setting the user's password e. Click ldap.com from the navigation tree. The list of users in the ldap.com domain appears. f. Right-click aaa and select Properties from the shortcut menu. 65

78 The aaa Properties window appears. g. Click the Member Of tab, and then click Add. The Select Groups window appears. Figure 15 Modifying user properties h. Enter Users in the Enter the object names to select field and click OK. User aaa is added to the group Users. Figure 16 Adding user aaa to group Users i. Right-click Administrator and select Set Password from the shortcut menu. j. In the dialog box, set the password to admin! (Details not shown.) 66

79 2. Configure the AC: # Enable the AC to provide the Telnet service. (This step is optional because the Telnet service is enabled by default.) <AC> system-view [AC] telnet server enable # Assign the IP address /24 to interface VLAN-interface 2, through which Telnet users access the AC. [AC] vlan 2 [AC-vlan2] quit [AC] interface vlan-interface 2 [AC-Vlan-interface2] ip address [AC-Vlan-interface2] quit # Configure the AC to use AAA for Telnet users. [AC] user-interface vty 0 4 [AC-ui-vty0-4] authentication-mode scheme [AC-ui-vty0-4] quit # Create ISP domain bbb and set it as the default ISP domain. [AC] domain bbb [AC-isp-bbb] quit [AC] domain default enable bbb # Configure an LDAP scheme. [AC] ldap scheme ldap1 # Specify the IP address of the LDAP authentication server. [AC-ldap-ldap1] authentication-server # Specify the administrator DN. [AC-ldap-ldap1] login-dn cn=administrator,cn=users,dc=ldap,dc=com # Set the administrator password. [AC-ldap-ldap1] login-password simple admin! # Configure the base DN for user search. [AC-ldap-ldap1] user-parameters search-base-dn dc=ldap,dc=com [AC-ldap-ldap1] quit # Use either of the following methods to configure the authentication method: Configure the LDAP scheme to provide the authentication method for login users. [AC] domain bbb [AC-isp-bbb] authentication login ldap-scheme ldap1 [AC-isp-bbb] quit Configure the LDAP scheme to provide the default authentication method for all types of users. [AC] domain bbb [AC-isp-bbb] authentication default ldap-scheme ldap1 Verifying the configuration # Use the username aaa and password ldap! to Telnet to the AC. After authentication in the default ISP domain bbb is passed, you access the AC user interface. 67

80 Authentication and authorization for portal users by a RADIUS server Network requirements As shown in Figure 17, the client has a public network IP address assigned manually or obtained through DHCP. Configure the AC to provide the following functions: Authenticate and authorize portal users through the RADIUS server. Direct portal authentication so that the client can access the Internet only when portal authentication is passed. Include the domain name in the usernames sent to the RADIUS server. Set the shared keys for secure RADIUS communication to expert, and set the ports for authentication/authorization to Figure 17 Network diagram Configuration prerequisites Configure IP addresses for the devices as shown in Figure 17 and make sure the devices can reach each other. (Details not shown.) Configuring the RADIUS server In this section, the server runs on IMC PLAT 5.1 SP1 (E0202P05) and IMC UAM 5.1 (E0301). 1. Add the AC to the IMC Platform as an access device: a. Click the Service tab. b. From the navigation tree, select User Access Manager > Access Device Management > Access Device. The Access Device page appears. c. Click Add. The Add Access Device page appears, as shown in Figure 18. d. In the Access Configuration area, configure the following parameters for the access device: Enter expert in the Shared Key field. 68

81 Select LAN Access Service from the Service Type list. Select HP(General) from the Access Device Type list. Use the default settings for other parameters. e. In the Device List area, select the access device from the device list or manually add the device with the IP address The IP address of the access device must be the same as the source IP address of the RADIUS packets sent from the AC, which is chosen in the following order: IP address specified with the nas-ip command. IP address specified with the radius nas-ip command. IP address of the outbound interface (the default). f. Click OK. Figure 18 Adding an access device 2. Add a service: a. Click the Service tab. b. From the navigation tree, select User Access Manager > Service Configuration. The Service Configuration page appears. c. Click Add. The Add Service Configuration page appears, as shown in Figure 19. d. Enter Portal-auth in the Service Name field. e. Enter dm1 in the Service Suffix field. Make sure the service suffix is the same as the name of the domain in which portal users are authenticated. f. Click OK. 69

82 Figure 19 Adding a service 3. Add an account for portal users and assign the previous service to the account: a. Click the User tab. b. From the navigation tree, select Access User View > All Access Users. The All Access Users page appears. c. Click Add. The Add Access User page appears, as shown in Figure 20. d. In the Access Information area, configure the user account: Select or add a platform user named hello. Enter portal in the Account Name field. Set a password for the user and confirm the password. e. In the Access Service area, select Portal auth on the Access Service list. f. Click OK. Figure 20 Adding an access user account Configuring the portal server In this section, the server runs on IMC PLAT 5.1 SP1 (E0202P05) and IMC UAM 5.1 (E0301). 1. Configure the portal server: a. Click the Service tab. b. From the navigation tree, select User Access Manager > Portal Service > Server. The Server page appears, as shown in Figure

83 c. In the Portal Page field, enter the URL address of the portal authentication main page, in the format of where ip and port are those configured during IMC UAM installation. The default setting of port 8080 is typically used. d. Click OK. Figure 21 Portal server configuration 2. Configure an IP address group: a. From the navigation tree, select User Access Manager > Portal Service > IP Group. The IP Group page appears. b. Click Add. The Add IP Group page appears, as shown in Figure 22. c. Enter Portal_user in the IP Group Name field. d. Set the start IP address to and the end IP address to Make sure the IP address group contains the IP address of the AC. e. Select Normal from the Action list. f. Click OK. Figure 22 Adding an IP address group 71

84 3. Configure the AC as a portal device: a. From the navigation tree, select User Access Manager > Portal Service > Device. The Device page appears. b. Click Add. The Add Device page appears, as shown in Figure 23. c. Enter NAS in the Device Name field. d. Enter in the IP Address field, which is the IP address of the access interface on the AC. e. Enter portal in the Key field. Make sure the key is the same as that configured on the AC. f. Select No from the Reallocate IP list to disable IP address reallocation in this example. g. Click OK. Figure 23 Adding a portal device 4. Associate the portal device with the IP address group: a. On the Device Information List as shown in Figure 24, click the icon in the Port Group column for NAS. The Configure Port Group page appears. b. Click Add. The Add Port Group page appears, as shown in Figure 25. c. Enter group in the Port Group Name field. d. Select Portal_user from the IP Group list. e. Click OK. Figure 24 Portal device list 72

85 Figure 25 Associating the portal device with the IP address group 5. Select User Access Manager > Service Parameters > Validate System Configuration from the navigation tree to validate the portal server configuration. Configuring the AC 1. Configure a RADIUS scheme: # Create a RADIUS scheme named rs1 and enter its view. <AC> system-view [AC] radius scheme rs1 # Set the server type for the RADIUS scheme. To support IMC, set the server type to extended. [AC-radius-rs1] server-type extended # Specify the primary authentication server and the service port number. [AC-radius-rs1] primary authentication # Set the shared key to expert in plain text for secure RADIUS communication. [AC-radius-rs1] key authentication simple expert # Specify the scheme to include the domain names in usernames to be sent to the RADIUS server. [AC-radius-rs1] user-name-format with-domain [AC-radius-rs1] quit 2. Configure an authentication domain: # Create an ISP domain named dm1 and enter its view. [AC] domain dm1 # Configure the ISP domain to use RADIUS scheme rs1. [AC-isp-dm1] authentication portal radius-scheme rs1 [AC-isp-dm1] authorization portal radius-scheme rs1 [AC-isp-dm1] quit 3. Configure portal authentication: # Configure the portal server. [AC] portal server newpt ip key portal port url [AC] portal free-rule 0 source interface ten-gigabitethernet 1/0/1 destination any # Enable portal authentication on the interface connecting the wireless client. [AC] interface vlan-interface 2 [AC-Vlan-interface2] portal server newpt method direct 73

86 Verifying the configuration # Specify the portal authentication domain. [AC Vlan-interface2] portal domain dm1 [AC Vlan-interface2] quit The user can initiate portal authentication by using the inode client or by accessing a web page. All the initiated web requests will be redirected to the portal authentication page at Before passing portal authentication, the user can access only the authentication page. After passing portal authentication, the user can access the Internet. After the user passes portal authentication, display the portal user information on the AC. [AC] display portal user interface vlan-interface 2 Index:19 State:ONLINE SubState:NONE ACL:NONE Work-mode:stand-alone MAC IP Vlan Interface e9a6-7cfe Vlan-interface2 Total 1 user(s) matched, 1 listed. # Use the display connection command to view the connection information on the AC. [AC] display connection Index=20,Username=portal@dm1 MAC=00-15-E9-A6-7C-FE IP= IPv6=N/A Online=03h01m37s Total 1 connection(s) matched. Authentication and authorization for 802.1X users by a RADIUS server Network requirements As shown in Figure 26, configure the AC to provide the following functions: Implement authentication and authorization for the 802.1X user on the client through the RADIUS server. Use the WLAN-ESS port as the authentication port. Include the domain name in the username sent to the RADIUS server. The username is dot1x@bbb. Set the shared key for secure RADIUS communication to expert, and set the port for authentication/authorization to Configure the RADIUS server to assign the client to VLAN 4 when authentication is passed. 74

87 Figure 26 Network diagram Configuration prerequisites Configure the interfaces and VLANs as shown in Figure 26. Make sure the client can get a new IP address manually or automatically and can access resources in the authorized VLAN after passing authentication. Configuring the RADIUS server In this section, the server runs on IMC PLAT 5.1 SP1 (E0202P05) and IMC UAM 5.1 (E0301). 1. Add the AC to the IMC Platform as an access device: a. Click the Service tab. b. From the navigation tree, select User Access Manager > Access Device Management > Access Device. The Access Device page appears. c. Click Add. The Add Access Device page appears, as shown in Figure 27. d. In the Access Configuration area, configure the access device: Enter expert in the Shared Key field. Select LAN Access Service from the Service Type list. Select HP(General) from the Access Device Type list. Use the default settings for other parameters. e. In the Device List area, select the access device from the device list or manually add the device with the IP address The IP address of the access device must be the same as the source IP address of the RADIUS packets sent from the AC, which is chosen in the following order: IP address specified with the nas-ip command. IP address specified with the radius nas-ip command. IP address of the outbound interface (the default). f. Click OK. 75

88 Figure 27 Adding an access device 2. Add a service: a. Click the Service tab. b. From the navigation tree, select User Access Manager > Service Configuration. The Service Configuration page appears. c. Click Add. The Add Service Configuration page appears, as shown in Figure 28. d. Enter Dot1x auth in the Service Name field. e. Enter bbb in the Service Suffix field. Make sure the service suffix is the same as the name of the domain in which the 802.1X user is authenticated. f. If certificate authentication is required, configure parameters in the Authorization Information area: Click EAP next to the Certificate Authentication field. Select EAP-PEAP AuthN from the Certificate Type list. Select MS-CHAPv2 AuthN from the Certificate Sub-Type list. Select the Deploy VLAN option, and enter 4 in the box. g. Click OK. 76

89 Figure 28 Adding a service 3. Add an account for portal users and assign the previous service to the account: a. Click the User tab. b. From the navigation tree, select Access User View > All Access Users. The All Access Users page appears. c. Click Add. The Add Access User page appears, as shown in Figure 29. d. In the Access Information area, configure the access user: Select or add a platform user named test. Enter dot1x in the Account Name field. Set a password for the user and confirm the password. e. In the Access Service area, select Dot1x auth on the Access Service list. f. Click OK. 77

90 Figure 29 Adding an access user account Configuring the AC 1. Configure a RADIUS scheme: # Create a RADIUS scheme named rad and enter its view. <AC> system-view [AC] radius scheme rad # Set the server type for the RADIUS scheme. To support IMC, set the server type to extended. [AC-radius-rad] server-type extended # Specify the primary authentication server and the service port number. [AC-radius-rad] primary authentication # Set the shared key to expert in plain text for secure RADIUS communication. [AC-radius-rad] key authentication simple expert # Specify the scheme to include the domain names in usernames to be sent to the RADIUS server. [AC-radius-rad] user-name-format with-domain [AC-radius-rad] quit 2. Configure an authentication domain: # Create an ISP domain named bbb and enter its view. [AC] domain bbb # Configure the ISP domain to use RADIUS scheme rad. [AC-isp-bbb] authentication lan-access radius-scheme rad [AC-isp-bbb] authorization lan-access radius-scheme rad [AC-isp-bbb] quit 3. Configure 802.1X authentication: # Enable port security globally. [AC] port-security enable # Specify the 802.1X authentication method. [AC] dot1x authentication-method eap # Create a WLAN-ESS interface and configure the port security mode as userloginsecureext. [AC] interface wlan-ess 1 [AC-WLAN-ESS1] port-security port-mode userlogin-secure-ext # Enable the key negotiation function for the port. [AC-WLAN-ESS1] port-security tx-key-type 11key 78

91 # Disable the online user handshake function. [AC-WLAN-ESS1] undo dot1x handshake # Disable the 802.1X multicast trigger function. [AC-WLAN-ESS1] undo dot1x multicast-trigger # Configure the port to use mandatory authentication domain bbb. The AC will use the authentication and authorization methods of this domain for all users accessing this port. This step is optional. [AC-WLAN-ESS1] dot1x mandatory-domain bbb [AC-WLAN-ESS1] quit # Configure the WLAN service template. [AC] wlan service-template 1 crypto [AC-wlan-st-1] ssid sectest [AC-wlan-st-1] bind WLAN-ESS 1 [AC-wlan-st-1] authentication-method open-system [AC-wlan-st-1] cipher-suite tkip [AC-wlan-st-1] security-ie wpa [AC-wlan-st-1] service-template enable [AC-wlan-st-1] quit # Create an AP template named ap1, and specify its model as MSM460-WW and serial number as CN2AD330S8. [AC] wlan ap ap1 model MSM460-WW [AC-wlan-ap-ap1] serial-id CN2AD330S8 # Bind service template 1 to radio 1. [AC-wlan-ap-ap1] radio 1 type dot11an [AC-wlan-ap-ap1-radio-1] service-template 1 [AC-wlan-ap-ap1-radio-1] radio enable [AC-wlan-ap-ap1-radio-1] quit [AC-wlan-ap-ap1] quit Verifying the configuration To use the 802.1X client of Windows XP, follow these steps: 1. Click the Authentication tab on the Properties dialog box of 802.1X connection, select the Enable IEEE 802.1X authentication for this network option and select Protected EAP (PEAP) from the EAP Type list. 2. Enter the correct username and password in the authentication page. To use the inode client, enter username dot1x@bbb and the correct password in the client property window. After the user passes authentication, the server assigns the port connecting the client to VLAN 4. # Use the display connect command to view the connection information on the AC. [AC] display connection Index=22, Username=dot1x@bbb MAC=0015-e9a6-7cfe IP= IPv6=N/A Online=00h01m37s Total 1 connection(s) matched. 79

92 # View the information of the specified connection on the AC. [AC] display connection ucibindex 22 Index=22, MAC=0015-e9a6-7cfe IP= IPv6=N/A Access=8021X,AuthMethod=EAP Port Type=Wireless ,Port Name=WLAN-DBSS1:1 Initial VLAN=2, Authorized VLAN=4 ACL Group=Disable User Profile=N/A CAR=Disable Traffic Statistic: InputOctets = OutputOctets =12120 InputGigawords=1 OutputGigawords=0 Priority=Disable SessionTimeout=60(s), Terminate-Action=Radius-Request Start= :41:12,Current= :41:25,Online=00h00m14s Total 1 connection matched. The Authorized VLAN field in the output shows VLAN 4 has been assigned to the user. Local EAP authentication and authorization for 802.1X users Network requirements As shown in Figure 30, configure the AC to perform local EAP authentication and authorization for 802.1X users. Use the EAP-MD5 authentication method for the 802.1X user. Add the 802.1X user to user group dot1x. Configure the authorized VLAN of VLAN 100 for the user group. Figure 30 Network diagram Internet Client 802.1X user AP Vlan-int /24 AC Configuration procedure 1. Configure the 802.1X connection properties if the 802.1X client of Windows XP is used: a. Open the Properties dialog box of the 802.1X connection. b. On the Authentication tab, select the Enable IEEE 802.1X authentication for this network option and select MD5-Challenge from the EAP Type list. c. Click OK. 80

93 2. Configure the AC: # Create user group dot1x, configure the authorized VLAN as VLAN 100. <AC> system-view [AC] user-group dot1x [AC-ugroup-dot1x] authorization-attribute vlan 100 [AC-ugroup-dot1x] quit # Create local user usera, and add the user to user group dot1x. [AC] local-user usera [AC-luser-usera] group dot1x [AC-luser-usera] password simple 1234 [AC-luser-usera] service-type lan-access [AC-luser-usera] quit # Configure the ISP domain to use local authentication and authorization. [AC] domain mydomain [AC-isp-mydomain] authentication lan-access local [AC-isp-mydomain] authorization lan-access local [AC-isp-mydomain] quit # Configure an EAP profile, specifying to use EAP-MD5 for authentication. [AC] eap-profile eapsvr [AC-eap-prof-eapsvr] method md5 [AC-eap-prof-eapsvr] quit # Configure the local EAP authentication server, specifying to use EAP profile eapsvr. [AC] local-server authentication eap-profile eapsvr # Enable port security globally. [AC] port-security enable # Specify the 802.1X authentication method. [AC] dot1x authentication-method eap # Create a WLAN interface and configure the port security mode as userloginsecureext. [AC] interface wlan-ess 1 [AC-WLAN-ESS1] port-security port-mode userlogin-secure-ext # Enable the key negotiation function for the port. [AC-WLAN-ESS1] port-security tx-key-type 11key # Disable the online user handshake function. [AC-WLAN-ESS1] undo dot1x handshake # Disable the 802.1X multicast trigger function. [AC-WLAN-ESS1] undo dot1x multicast-trigger # Configure the port to use mandatory authentication domain mydomain. The AC will use the authentication, authorization, and accounting methods of this domain for all users accessing this port. This step is optional. [AC-WLAN-ESS1] dot1x mandatory-domain mydomain [AC-WLAN-ESS1] quit # Create a WLAN service template. [AC] wlan service-template 1 crypto [AC-wlan-st-1] ssid sectest [AC-wlan-st-1] bind WLAN-ESS 1 [AC-wlan-st-1] authentication-method open-system 81

94 [AC-wlan-st-1] cipher-suite tkip [AC-wlan-st-1] security-ie wpa [AC-wlan-st-1] service-template enable [AC-wlan-st-1] quit # Create an AP template named ap1, and specify its model as MSM460-WW and serial number as CN2AD330S8. [AC] wlan ap ap1 model MSM460-WW [AC-wlan-ap-ap1] serial-id CN2AD330S8 # Bind service template 1 to radio 1. [AC-wlan-ap-ap1] radio 1 type dot11an [AC-wlan-ap-ap1-radio-1] service-template 1 [AC-wlan-ap-ap1-radio-1] radio enable [AC-wlan-ap-ap1-radio-1] quit [AC-wlan-ap-ap1] quit Verifying the configuration 1. Trigger EAP authentication and enter the 802.1X username usera@mydomain and password Use the display connection command on the AC to view the user's connection information. 3. Use the display interface wlan-dbss command to check that the WLAN-DBSS access port belongs to VLAN 100. RADIUS offload for 802.1X users Network requirements As shown in Figure 31, configure the AC to work with the RADIUS server for RADIUS authentication, authorization, and accounting of 802.1X users. The RADIUS server does not support EAP authentication. Configure PEAP-MSCHAPv2 authentication between the 802.1X client and the AC. Configure the AC and the RADIUS server to use the shared key expert to secure RADIUS authentication and accounting. Figure 31 Network diagram 82

95 Configuration prerequisites To use the 802.1X client of Windows XP, configure the 802.1X connection properties as follows: a. Open the Properties dialog box of the 802.1X connection. b. On the Authentication tab, select the Enable IEEE 802.1X authentication for this network option and select Protected EAP (PEAP) from the EAP Type list. c. Click Properties, and in the popup dialog box, select Secured password (EAP-MSCHAP v2) from the Select Authentication Method list and click OK. d. Click OK. To use the inode client, configure the 802.1X connection properties as follows: a. Open the Properties dialog box of the 802.1X connection in the inode client. b. On the General tab, select the Enable advanced authentication option and select the Certificate authentication option. c. Click OK. On the RADIUS server, configure the shared key for authenticating packets exchanged with the AC to expert, and add a username and password for the 802.1X user. (Details not shown.) Configuration procedure 1. Obtain the CA certificate and local certificate. If the CA certificate file and local certificate file are already saved on the AC, import the certificates in offline mode. Otherwise, you must request a local certificate for the AC and obtain the CA certificate in online mode. Suppose that the PKI domain is eappki. For more information about the configuration steps, see "Configuring PKI." 2. Create SSL server policy eapsvr and configure it to use PKI domain eappki. <AC> system-view [AC] ssl server-policy eapsvr [AC-ssl-server-policy-eapsvr] pki-domain eappki [AC-ssl-server-policy-eapsvr] quit 3. Configure the local EAP authentication server: # Create an EAP profile. [AC] eap-profile eapsvr # Configure the EAP profile to use PEAP-MSCHAPv2 authentication. [AC-eap-prof-eapsvr] method peap-mschapv2 # Configure the EAP profile to use SSL server policy eapsvr for EAP authentication. [AC-eap-prof-eapsvr] ssl-server-policy eapsvr [AC-eap-prof-eapsvr] quit # Configure the local EAP authentication server, specifying to use EAP profile eapsvr. [AC] local-server authentication eap-profile eapsvr 4. Configure AAA: # Configure a RADIUS scheme that supports the EAP offload function. [AC] radius scheme radoff [AC-radius-radoff] primary authentication [AC-radius-radoff] primary accounting [AC-radius-radoff] key authentication simple expert [AC-radius-radoff] key accounting simple expert 83

96 [AC-radius-radoff] eap offload method peap-mschapv2 [AC-radius-radoff] quit # Configure the AAA method for the ISP domain. [AC] domain bbb [AC-isp-bbb] authentication lan-access radius-scheme radoff [AC-isp-bbb] authorization lan-access radius-scheme radoff [AC-isp-bbb] accounting lan-access radius-scheme radoff [AC-isp-bbb] quit 5. Configure 802.1X: # Enable port security globally. [AC] port-security enable # Specify the 802.1X authentication method. [AC] dot1x authentication-method eap # Create a WLAN interface and configure the port security mode as userloginsecureext. [AC] interface wlan-ess 1 [AC-WLAN-ESS1] port-security port-mode userlogin-secure-ext # Enable the key negotiation function for the port. [AC-WLAN-ESS1] port-security tx-key-type 11key # Disable the online user handshake function. [AC-WLAN-ESS1] undo dot1x handshake # Disable the 802.1X multicast trigger function. [AC-WLAN-ESS1] undo dot1x multicast-trigger # Configure the port to use mandatory authentication domain bbb. The AC will use the authentication, authorization, and accounting methods of this domain for all users accessing this port. This step is optional. [AC-WLAN-ESS1] dot1x mandatory-domain bbb [AC-WLAN-ESS1] quit # Configure the WLAN service template. [AC] wlan service-template 1 crypto [AC-wlan-st-1] ssid sectest [AC-wlan-st-1] bind WLAN-ESS 1 [AC-wlan-st-1] authentication-method open-system [AC-wlan-st-1] cipher-suite tkip [AC-wlan-st-1] security-ie wpa [AC-wlan-st-1] service-template enable [AC-wlan-st-1] quit # Create an AP template named ap1, and specify its model as MSM460-WW and serial number as CN2AD330S8. [AC] wlan ap ap1 model MSM460-WW [AC-wlan-ap-ap1] serial-id CN2AD330S8 # Bind service template 1 to radio 1. [AC-wlan-ap-ap1] radio 1 type dot11an [AC-wlan-ap-ap1-radio-1] service-template 1 [AC-wlan-ap-ap1-radio-1] radio enable [AC-wlan-ap-ap1-radio-1] quit [AC-wlan-ap-ap1] quit 84

97 Verifying the configuration 1. Use the display radius scheme radoff and display domain bbb commands to view AAA configuration. 2. Use the display dot1x interface wlan-ess1 command to view 802.1X configuration. 3. After the 802.1X user passes EAP authentication by using the username in the format and successfully logs in, use the display connection command to display the user's connection information. Level switching authentication for Telnet users by an HWTACACS server Network requirements As shown in Figure 32, the Telnet user communicates with the AC through the AP and the AC connects to the HWTACACS server. Configure the AC to use the HWTACACS server for level switching authentication of the Telnet user: Configure an ACS server to act as an HWTACACS server for Telnet user authentication. The IP address of the server is /24. Set the shared key for authenticating authentication packets to expert, and specify that usernames sent to the HWTACACS server do not include domain names. Configure the AC to use local authentication for the Telnet user and assign the privilege level of 0 for the user after login. Configure the AC to use the HWTACACS server and, if HWTACACS authentication is not available, use local authentication for level switching authenticate of the Telnet user. Figure 32 Network diagram Configuration procedure 1. Configure the HWTACACS server. In this example, the HWTACACS server runs ACSv4.0. Add a user named test on the HWTACACS server, and configure advanced attributes for the user as follows: a. 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. b. Select Use separate password and specify the password as enabpass. 85

98 Figure 33 Configuring advanced attributes for the Telnet user 2. Configure the AC: # Assign an IP address to VLAN-interface 2, the interface used to connect the client. <AC> system-view [AC] interface vlan-interface 2 [AC-Vlan-interface2] ip address [AC-Vlan-interface2] quit # Assign an IP address to VLAN-interface 3, the interface used to connect the server. [AC] interface vlan-interface 3 [AC-Vlan-interface3] ip address [AC-Vlan-interface3] quit # Enable the AC to provide Telnet services. [AC] telnet server enable # Configure the AC to use AAA for Telnet users. [AC] user-interface vty 0 4 [AC-ui-vty0-4] authentication-mode scheme [AC-ui-vty0-4] quit # Create an ISP domain bbb and set it as the default ISP domain. [AC] domain bbb [AC-isp-bbb] quit [AC] domain default enable bbb # Create an HWTACACS scheme named hwtac. [AC] hwtacacs scheme hwtac # Specify the IP address of the primary authentication server as and the port for authentication as 49. [AC-hwtacacs-hwtac] primary authentication

99 # Set the shared key for authenticating authentication packets to expert. [AC-hwtacacs-hwtac] key authentication simple expert # Specify that usernames sent to the HWTACACS server do not include domain names. [AC-hwtacacs-hwtac] user-name-format without-domain [AC-hwtacacs-hwtac] quit # Configure ISP domain bbb to use local authentication for Telnet users. [AC] domain bbb [AC-isp-bbb] authentication login local # Configure to use HWTACACS scheme hwtac for privilege level switching authentication. [AC-isp-bbb] authentication super hwtacacs-scheme hwtac [AC-isp-bbb] quit # Create a local Telnet user account test. [AC] local-user test [AC-luser-test] service-type telnet [AC-luser-test] password simple aabbcc # Configure the user level of the Telnet user as 0 after user login. [AC-luser-test] authorization-attribute level 0 [AC-luser-test] quit # Configure the AC to use the HWTACACS server for level switching authentication, and to use local authentication as the backup method. [AC] super authentication-mode scheme local # Configure the password for privilege level switching authentication as [AC] super password simple [AC] quit Verifying the configuration 1. Telnet to the AC from the client, and enter the username test and password aabbcc. After login, you can access level 0 commands. 2. Perform user privilege level switching: # Execute the command for switching to user privilege level 3 and enter password pass3 as prompted. <AC> 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 ACS server is not reachable, enter password as prompted for local authentication. <AC> super 3 Password: Enter the password for HWTACACS level switching authentication Error: Invalid configuration or no response from the authentication server. Info: Change authentication mode to local. Password: Enter the password for local level switching authentication User privilege level is 3, and only those commands can be used whose level is equal or less than this. Privilege note: 0-VISIT, 1-MONITOR, 2-SYSTEM, 3-MANAGE 87

100 Local EAP authentication for 802.1X users by an LDAP server Network requirements As shown in Figure 34, an 802.1X client connects to an AC that connects to an LDAP server. The IP address of the LDAP server is /24 and the domain name is ldap.com. Configure the AC to perform local EAP authentication for 802.1X users and to use the LDAP server for user identity authentication. Figure 34 Network diagram Configuration prerequisites Configure the 802.1X connection properties if the 802.1X client of Windows XP is used: a. Open the Properties dialog box of the 802.1X connection. b. On the Authentication tab, select the Enable IEEE 802.1X authentication for this network option and select the smart card or other certificates as the EAP authentication type. To use the inode client, configure the 802.1X connection properties as follows: a. Open the Properties dialog box of the 802.1X connection in the inode client. b. On the General tab, select the Enable advanced authentication option and select the Certificate authentication option. c. Click Settings, and in the popup dialog box, select the EAP-TLS in the Authentication Type area and click OK. d. Click OK. Configuration procedure 1. Configure the LDAP server. Set the administrator's password to admin!123456, add user aaa (this username is the DN of the local certificate) and set the password for the user to ldap! For more information about LDAP server configuration, see "LDAP authentication for Telnet users." 2. Configure the AC: # Obtain the CA certificate and the local certificate. If the AC has saved the CA certificate file and local certificate file, import them in offline mode. Otherwise, you must request a local certificate for the AC and obtain the CA certificate in online mode. Suppose that the PKI domain is eappki. For more information about the configuration steps, see "Configuring PKI." 88

101 # Specify an LDAP scheme. <AC> system-view [AC] ldap scheme ldap1 # Specify the IP address of the LDAP authentication server. [AC-ldap-ldap1] authentication-server # Specify the administrator DN. [AC-ldap-ldap1] login-dn cn=administrator,cn=users,dc=ldap,dc=com # Specify the administrator password. [AC-ldap-ldap1] login-password simple admin! # Configure the base directory for user search. [AC-ldap-ldap1] user-parameters search-base-dn dc=ldap,dc=com [AC-ldap-ldap1] quit # Specify the domain to use local authentication/authorization. (Authorization for 802.1X users by an LDAP server is not supported. Local authorization is used here) [AC] domain bbb [AC-isp-bbb] authentication lan-access local [AC-isp-bbb] authorization lan-access local [AC-isp-bbb] quit # Configure the SSL server policy sp1, specifying the PKI domain to be used as eappki. [AC] ssl server-policy sp1 [AC-ssl-server-policy-sp1] pki-domain eappki [AC-ssl-server-policy-sp1] quit # Create an EAP profile and configure it to use EAP-TLS for authentication. [AC] eap-profile eapsvr [AC-eap-prof-eapsvr] method tls # Specify the SSL server policy for EAP authentication as sp1. [AC-eap-prof-eapsvr] ssl-server-policy sp1 # Use the LDAP database for user credential verification and reference the LDAP scheme ldap1. [AC-eap-prof-eapsvr] user-credentials ldap-scheme ldap1 [AC-eap-prof-eapsvr] quit # Configure the local EAP authentication server, specifying to use EAP profile eapsvr. [AC] local-server authentication eap-profile eapsvr # Enable port security globally. [AC] port-security enable # Specify the 802.1X authentication method. [AC] dot1x authentication-method eap # Create a WLAN interface and configure the port security mode as userloginsecureext. [AC] interface wlan-ess 1 [AC-WLAN-ESS1] port-security port-mode userlogin-secure-ext # Enable the key negotiation function for the port. [AC-WLAN-ESS1] port-security tx-key-type 11key # Disable the online user handshake function. [AC-WLAN-ESS1] undo dot1x handshake # Disable the 802.1X multicast trigger function. [AC-WLAN-ESS1] undo dot1x multicast-trigger 89

102 # Configure the port to use mandatory authentication domain bbb. The AC will use the authentication, authorization, and accounting methods of this domain for all users accessing this port. This step is optional. [AC-WLAN-ESS1] dot1x mandatory-domain bbb [AC-WLAN-ESS1] quit # Configure the WLAN service template. [AC] wlan service-template 1 crypto [AC-wlan-st-1] ssid sectest [AC-wlan-st-1] bind WLAN-ESS 1 [AC-wlan-st-1] authentication-method open-system [AC-wlan-st-1] cipher-suite tkip [AC-wlan-st-1] security-ie wpa [AC-wlan-st-1] service-template enable [AC-wlan-st-1] quit # Create an AP template named ap1, and specify its model as MSM460-WW and serial number as CN2AD330S8. [AC] wlan ap ap1 model MSM460-WW [AC-wlan-ap-ap1] serial-id CN2AD330S8 # Bind service template 1 to radio 1. [AC-wlan-ap-ap1] radio 1 type dot11an [AC-wlan-ap-ap1-radio-1] service-template 1 [AC-wlan-ap-ap1-radio-1] radio enable [AC-wlan-ap-ap1-radio-1] quit [AC-wlan-ap-ap1] quit Verifying the configuration 1. Use the display dot1x interface wlan-ess 1 command to check the configuration. 2. After the 802.1X user passes certificate-based EAP authentication, check the user's connectivity status by using the display connection command. Temporary access control of wireless users Network requirements Wireless users temporarily access the network through an AP whose ID is CN2AD330S8. The AC uses local EAP authentication (EAP-TLS) for user authentication. Configure a guest account on the AC for the wireless users and configure the following restrictions for the guest account: The expiration time of the guest account is 12:00:00 on August 8, Only users with the SSID aabbcc can use the guest account for login. 90

103 Figure 35 Network diagram AC Internet Client AP L2 switch Client Configuration prerequisites Configure the 802.1X connection properties if the 802.1X client of Windows XP is used: a. Open the Properties dialog box of the 802.1X connection. b. On the Authentication tab, select the Enable IEEE 802.1X authentication for this network option and select the smart card or other certificates as the EAP authentication type. To use the inode client, configure the 802.1X connection properties as follows: a. Open the Properties dialog box of the 802.1X connection in the inode client. b. On the General tab, select the Enable advanced authentication option and select the Certificate authentication option. c. Click Settings, and in the popup dialog box, select the EAP-TLS in the Authentication Type area and click OK. d. Click OK. Configuration procedure 1. Obtain the CA certificate and the local certificate. If the AC has a copy of the CA certificate file and local certificate file, import the certificates in offline mode. Otherwise, request a certificate for the AC and obtain the CA certificate in online mode. The PKI domain for the certificate is eappki. (Details not shown. For information about PKI configuration, see Security Configuration Guide.) 2. Create the SSL server side policy eapsvr and specify the PKI domain as eappki. <AC> system-view [AC] ssl server-policy eapsvr [AC-ssl-server-policy-eapsvr] pki-domain eappki [AC-ssl-server-policy-eapsvr] quit 3. Configure port security: # Enable port security globally. [AC] port-security enable # Set the 802.1X authentication method to EAP. [AC] dot1x authentication-method eap # Create a WLAN interface and configure the port security mode. [AC] interface wlan-ess 1 [AC-WLAN-ESS1] port-security port-mode userlogin-secure-ext 91

104 # Disable the multicast trigger function. [AC-WLAN-ESS1] undo dot1x multicast-trigger # Disable the online user handshake function. [AC-WLAN-ESS1] undo dot1x handshake # Configure the port to use mandatory authentication domain test. With this configuration, the AC will use the authentication, authorization, and accounting methods of this domain for all 802.1X users accessing the port. This configuration is optional. [AC-WLAN-ESS1] dot1x mandatory-domain test [AC-WLAN-ESS1] quit 4. Configure AAA methods: # Create an ISP domain and configure the domain to use local authentication and authorization methods. [AC] domain test [AC-isp-test] authentication lan-access local [AC-isp-test] authorization lan-access local [AC-isp-test] quit # Configure domain test as the default domain. [AC] domain default enable test 5. Configure the local EAP authentication server # Create an EAP profile and configure it to use EAP-TLS for authentication. [AC] eap-profile eapsvr [AC-eap-prof-eapsvr] method tls # Specify the SSL server side policy for EAP authentication as eapsvr. [AC-eap-prof-eapsvr] ssl-server-policy eapsvr [AC-eap-prof-eapsvr] quit # Configure the local EAP authentication server, specifying to use EAP profile eapsvr. [AC] local-server authentication eap-profile eapsvr 6. Configure WLAN service: # Configure the service template. [AC] wlan service-template 1 clear [AC-wlan-st-1] ssid aabbcc [AC-wlan-st-1] bind WLAN-ESS 1 [AC-wlan-st-1] authentication-method open-system [AC-wlan-st-1] service-template enable [AC-wlan-st-1] quit # Configure the AP. [AC] wlan ap 1 model MSM460-WW [AC-wlan-ap-1] serial-id CN2AD330S8 [AC-wlan-ap-1] radio 1 type dot11an [AC-wlan-ap-1-radio-1] service-template 1 [AC-wlan-ap-1-radio-1] radio enable [AC-wlan-ap-1-radio-1] quit [AC-wlan-ap-1] quit 7. Create a user profile and configure it to permit users with an SSID of aabbcc. For more information about SSID-based WLAN access control, see WLAN Configuration Guide. [AC] user-profile manager 92

105 Verifying the configuration [AC-user-profile-manager] wlan permit-ssid aabbcc [AC-user-profile-manager] quit # Enable the user profile. [AC] user-profile manager enable # Create guest account guest and specify the password and service type. [AC] local-user guest [AC-luser-guest] password simple guest [AC-luser-guest] service-type lan-access # Set the expiration time of the guest account to 12:00:00 on August 8, [AC-luser-guest] expiration-date 12:00: /08/08 # Specify the authorization user profile of the guest account as manager. [AC-luser-guest] authorization-attribute user-profile manager [AC-luser-guest] quit # Verify that wireless clients using the SSID of aabbcc can pass local EAP authentication and log in as guests before 12:00:00 August 8, Troubleshooting AAA Troubleshooting RADIUS Symptom 1 Analysis Solution User authentication/authorization always fails. Possible reasons include: A communication failure exists between the NAS and the RADIUS server. The username is not in the format userid@isp-name or the ISP domain is not correctly configured on the NAS. The user is not configured on the RADIUS server. The password entered by the user is incorrect. The RADIUS server and the NAS are configured with different shared keys. Check the following: The NAS and the RADIUS server can ping each other. The username is in the userid@isp-name format and the ISP domain is correctly configured on the NAS. The user is configured on the RADIUS server. The correct password is entered. The same shared key is configured on both the RADIUS server and the NAS. 93

106 Symptom 2 Analysis Solution Symptom 3 Analysis Solution RADIUS packets cannot reach the RADIUS server. Possible reasons include: A communication failure exists between the NAS and the RADIUS server. The NAS is not configured with the IP address of the RADIUS server. The authentication/authorization and accounting UDP ports configured on the NAS are incorrect. The RADIUS server's authentication/authorization and accounting port numbers are being used by other applications. Check the following: The link between the NAS and the RADIUS server work well at both the physical and data link layers. The IP address of the RADIUS server is correctly configured on the NAS. The authentication/authorization and accounting UDP ports configured on the NAS are the same as those of the RADIUS server. The RADIUS server's authentication/authorization and accounting port numbers are available. A user is authenticated and authorized, but accounting for the user is not normal. The accounting server configuration on the NAS is not correct. Possible reasons include: The accounting port number configured on the NAS is incorrect. The accounting server IP address configured on the NAS is incorrect. For example, the NAS is configured to use a single server to provide authentication, authorization, and accounting services, but in fact the services are provided by different servers. Check the following: The accounting port number is correctly configured. The accounting server IP address is correctly configured on the NAS. Troubleshooting HWTACACS Similar to RADIUS troubleshooting. See "Troubleshooting RADIUS." Troubleshooting LDAP Symptom User authentication/authorization fails. 94

107 Analysis Solution Possible reasons include: A communication failure exists between the NAS and the LDAP server. The LDAP server IP address or port number configured on the NAS is not correct. The username is not in the format userid@isp-name, or the ISP domain is not correctly configured on the NAS. The user is not configured on the LDAP server. The password entered by the user is not correct. The administrator DN or password is not configured. Some user attributes (for example, the username attribute) and the group attributes configured on the NAS are not consistent with those configured on the server. No user search base DN for authentication is specified for the LDAP scheme. No group search base DN for authorization is specified for the LDAP scheme. Check the following: The NAS and the LDAP server can ping each other. The IP addresses and port numbers of authentication and authorization servers configured on the NAS match those of the servers. The username is in the correct format and the ISP domain is correctly configured on the NAS. The user is configured on the LDAP server. The correct password is entered. The administrator DN and the administrator password are correctly configured. The user attributes (for example, the username attribute) and group attributes configured on the NAS are consistent with those configured on the LDAP servers. The user search base DN for authentication is specified. The group search base DN for authorization is specified. 95

108 802.1X overview 802.1X is a port-based network access control protocol initially proposed by the IEEE 802 LAN/WAN committee for securing WLANs, and it has also been widely used on Ethernet networks for access control X controls network access by authenticating the devices connected to 802.1X-enabled LAN ports X 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 X architecture Client A user terminal seeking access to the LAN. It must have 802.1X software to authenticate to the network access device. 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. Authentication server Provides authentication services for the network access device. The authentication server authenticates 802.1X clients by using the data sent from the network access device, and returns the authentication results for the network access device to make access decisions. The authentication server is typically a 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 37. The controlled port is set in the authorized state if the client has passed authentication, and in the unauthorized state, if the client has failed authentication. Uncontrolled port Always open to receive and transmit EAPOL frames. 96

109 Figure 37 Authorization state of a controlled port In unauthorized state, a controlled port controls traffic in one of the following ways: Performs bidirectional traffic control to deny traffic to and from the client. Performs unidirectional traffic control to deny traffic from the client. The HP devices support only unidirectional traffic control X-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) X 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." 97

110 Packet formats EAP packet format Figure 38 shows the EAP packet format. Figure 38 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 length is the sum of the Code, Identifier, Length, and Data fields. Data Content of the EAP packet. This field appears only in a Request or Response EAP packet. The Data field comprises the request type (or the response type) and the type data. Type 1 (Identify) and type 4 (MD5-challenge) are two examples for the type field. EAPOL packet format Figure 39 shows the EAPOL packet format. Figure 39 EAPOL packet format Protocol version PAE Ethernet type Length Type Packet body N PAE Ethernet type Protocol type. It takes the value 0x888E for EAPOL. Protocol version The EAPOL protocol version used by the EAPOL packet sender. Type Type of the EAPOL packet. Table 5 lists the types of EAPOL packets supported by HP implementation of 802.1X. Table 5 Types of EAPOL packets Value Type Description 0x00 0x01 EAP-Packet EAPOL-Start The client and the network access device uses EAP-Packets to transport authentication information. The client sends an EAPOL-Start message to initiate 802.1X authentication to the network access device. 98

111 Value Type Description 0x02 EAPOL-Logoff The client sends an EAPOL-Logoff message to tell the network access device that it is logging off. Length Data length in bytes, or length of the Packet body. If packet type is EAPOL-Start or EAPOL-Logoff, this field is set to 0, and no Packet body field follows. Packet body Content of the packet. When the EAPOL packet type is EAP-Packet, the Packet body field contains an EAP packet. EAP over RADIUS EAP-Message RADIUS adds two attributes, EAP-Message and Message-Authenticator, for supporting EAP authentication. For the RADIUS packet format, see "Configuring AAA." RADIUS encapsulates EAP packets in the EAP-Message attribute, as shown in Figure 40. 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 40 EAP-Message attribute format Message-Authenticator RADIUS includes the Message-Authenticator attribute in all packets that have an EAP-Message attribute to check their integrity. The packet receiver drops the packet if the calculated packet integrity checksum is different from the Message-Authenticator attribute value. The Message-Authenticator prevents EAP authentication packets from being tampered with during EAP authentication. Figure 41 Message-Authenticator attribute format Initiating 802.1X authentication Both the 802.1X client and the access device can initiate 802.1X authentication X 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 C or the broadcast MAC address. If any intermediate device between the client and 99

112 the authentication server does not support the multicast address, 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 cannot send EAPOL-Start packets. One example is the 802.1X client available with Windows XP. The access device supports the following modes: Multicast trigger mode The access device multicasts Identity EAP-Request packets periodically (every 30 seconds by default) to initiate 802.1X authentication. Unicast trigger mode Upon receiving a frame with the source MAC address not in the MAC address table, the access device sends an Identity EAP-Request packet out of the receiving port to the unknown MAC address. It retransmits the packet if no response has been received within a certain time interval X authentication procedures 802.1X authentication provides two methods: EAP relay and EAP termination. You choose either mode depending on the support of the RADIUS server for EAP packets and EAP authentication methods. EAP relay mode: 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 42. Figure 42 EAP relay In EAP relay mode, the client must use the same authentication method as the RADIUS server. On the network access device, you only need to use the dot1x authentication-method eap command to enable EAP relay. Some network access devices provide the EAP server function so you can use EAP relay even if the RADIUS server does not support any EAP authentication method or no RADIUS server is available. For the local EAP authentication configuration procedure, see "Configuring AAA." 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 PAP or CHAP to authenticate to the RADIUS server, as shown in Figure

113 Figure 43 EAP termination Comparing EAP relay and EAP termination Packet exchange method Benefits Limitations EAP relay EAP termination Supports various EAP authentication methods. The configuration and processing is simple on the network access device. Works with any RADIUS server that supports PAP or CHAP authentication. The RADIUS server must support the EAP-Message and Message-Authenticator attributes, and the EAP authentication method used by the client. Supports only MD5-Challenge 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 44 shows the basic 802.1X authentication procedure in EAP relay mode, assuming that EAP-MD5 is used. 101

114 Figure X authentication procedure in EAP relay mode Client Device Authentication server EAPOL EAPOR (1) EAPOL-Start (2) EAP-Request/Identity (3) EAP-Response/Identity (6) EAP-Request/MD5 challenge (7) EAP-Response/MD5 challenge (10) EAP-Success (4) RADIUS Access-Request (EAP-Response/Identity) (5) RADIUS Access-Challenge (EAP-Request/MD5 challenge) (8) RADIUS Access-Request (EAP-Response/MD5 challenge) (9) RADIUS Access-Accept (EAP-Success) (11) EAP-Request/Identity Port authorized (12) EAP-Response/Identity... (13) EAPOL-Logoff (14) EAP-Failure Port unauthorized 1. When a user launches the 802.1X client software and enters a registered username and password, the 802.1X client software sends an EAPOL-Start packet to the network access device. 2. The network access device responds with an Identity EAP-Request packet to ask for the client username. 3. In response to the Identity EAP-Request packet, the client sends the username in an Identity EAP-Response packet to the network access device. 4. The network access device relays the Identity EAP-Response packet in a RADIUS Access-Request packet to the authentication server. 5. The authentication server uses the identity information in the RADIUS Access-Request to search its user database. If a matching entry is found, the server uses a randomly generated challenge (EAP-Request/MD5 challenge) to encrypt the password in the entry, and sends the challenge in a RADIUS Access-Challenge packet to the network access device. 6. The network access device relays the EAP-Request/MD5 Challenge packet in a RADIUS Access-Request packet to the client. 7. The client uses the received challenge to encrypt the password, and sends the encrypted password in an EAP-Response/MD5 Challenge packet to the network access device. 8. The network access device relays the EAP-Response/MD5 Challenge packet in a RADIUS Access-Request packet to the authentication server. 102

115 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. 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 45 shows the basic 802.1X authentication procedure in EAP termination mode, assuming that CHAP authentication is used. 103

116 Figure X authentication procedure in EAP termination mode In EAP termination mode, the network access device rather than the authentication server generates an MD5 challenge for password encryption (see Step 4). The network access device then sends the MD5 challenge together with the username and encrypted password in a standard RADIUS packet to the RADIUS server. 104

117 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 (for example, a WLAN) that requires different authentication methods for different users on a port. For more information about port security, see "Configuring port security." 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 X stateful failover 802.1X stateful failover enables two stateful failover ACs to back up 802.1X sessions in real time on WLAN interfaces. When a primary/backup AC switchover occurs, the backup AC can immediately take over to provide 802.1X services without disrupting 802.1X sessions. To configure 802.1X stateful failover, enable port security stateful failover. For more information, see "Configuring port security." Using 802.1X authentication with other features VLAN assignment You can configure the authentication server to assign a VLAN for an 802.1X user that has passed authentication. The way that the network access device handles VLANs on an 802.1X-enabled port differs by 802.1X access control mode. Access control Port-based VLAN manipulation Assigns the VLAN to the port as the port VLAN (PVID). The authenticated 802.1X user and all subsequent 802.1X users can access the VLAN without authentication. When the user logs off, the previous PVID restores, and all other online users are logged off. 105

118 Access control MAC-based VLAN manipulation If the port is a hybrid port with MAC-based VLAN enabled, maps the MAC address of each user to the VLAN assigned by the authentication server. The PVID of the port does not change. When a user logs off, the MAC-to-VLAN mapping for the user is removed. If the port is an access, trunk, or MAC-based VLAN disabled hybrid port, assigns the first authenticated user's VLAN to the port as the PVID. If a different VLAN is assigned to a subsequent user, the user cannot pass the authentication. To avoid the authentication failure of subsequent users, be sure to assign the same VLAN to all 802.1X users on these ports. Guest VLAN 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. On a periodic online user re-authentication enabled port, if a user has been online before you enable the MAC-based VLAN function, the access device does not create a MAC-to-VLAN mapping for the user unless the user passes re-authentication and the VLAN for the user has changed. For more information about VLAN configuration and MAC-based VLAN, see Layer 2 Configuration Guide. You can configure a guest VLAN on a port to accommodate users that have not performed 802.1X authentication, so they can access a limited set of network resources, such as a software server, to download anti-virus software and system patches. Once a user in the guest VLAN passes 802.1X authentication, it is removed from the guest VLAN and can access authorized network resources. Guest VLAN is supported only on ports that perform MAC-based access control. The following table describes how the network access device handles VLANs on these ports. Authentication status A user has not passed 802.1X authentication yet A user in the 802.1X guest VLAN fails 802.1X authentication A user in the 802.1X guest VLAN passes 802.1X authentication VLAN manipulation 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. 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. Auth-Fail VLAN 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. The network device assigns a hybrid port to an 802.1X guest VLAN as an untagged member. For more information about VLAN configuration and MAC-based VLAN, see Layer 2 Configuration Guide. 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. 106

119 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. Auth-Fail VLAN is supported only on ports that perform MAC-based access control. The following table describes how the network access device handles VLANs on these ports. Authentication status A user fails 802.1X authentication A user in the Auth-Fail VLAN fails 802.1X re-authentication A user in the Auth-Fail VLAN passes 802.1X authentication VLAN manipulation Re-maps the MAC address of the user to the Auth-Fail VLAN. The user can access only resources in the Auth-Fail VLAN. The user is still in the Auth-Fail VLAN. 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. ACL assignment To perform the 802.1X Auth-Fail VLAN function on a port that performs MAC-based access control, you must ensure that the port is a hybrid port, and enable MAC-based VLAN on the port. The network device assigns a hybrid port to an 802.1X Auth-Fail VLAN as an untagged member. For more information about VLAN configuration and MAC-based VLAN, see Layer 2 Configuration Guide. 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 Disable ARP snooping. Configure an ISP domain and AAA scheme (local or RADIUS authentication) for 802.1X users. If RADIUS authentication is used, create user accounts on the RADIUS server. If local authentication is used, create local user accounts on the access device and set the service type to lan-access. If you want to use EAP relay when the RADIUS server does not support any EAP authentication method or no RADIUS server is available, configure the EAP server function on your network access device. For information about RADIUS client and local EAP authentication configuration, see "Configuring AAA." 107

120 802.1X configuration task list Task Enable port security to enable 802.1X Enabling EAP relay or EAP termination Setting the port authorization state Specifying an access control method Setting the maximum number of concurrent 802.1X users on a port Setting the maximum number of authentication request attempts Setting the 802.1X authentication timeout timers Configuring the online user handshake function Configuring the authentication trigger function Specifying a mandatory authentication domain on a port Configuring the quiet timer Enabling the periodic online user re-authentication function Configuring an 802.1X guest VLAN Configuring an Auth-Fail VLAN Specifying supported domain name delimiters Configuring the accounting delay feature Remarks Required. By default, the 802.1X function of port security is disabled X must work with the port security feature to function on a WLAN port. Enabling EAP relay or EAP termination When configuring EAP relay or EAP termination, consider the following factors: The support of the RADIUS server for EAP packets The authentication methods supported by the 802.1X client and the RADIUS server If the client is using only MD5-Challenge EAP authentication or the "username + password" EAP authentication initiated by an 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 "Comparing 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: 108

121 Step Command Remarks 1. Enter system view. 2. Configure EAP relay or EAP termination. system-view dot1x authentication-method { chap eap pap } N/A By default, the network access device performs EAP termination and uses CHAP to communicate with the RADIUS server. Specify the eap keyword to enable EAP termination. Specify the chap or pap keyword to enable CHAP-enabled or PAP-enabled EAP relay. NOTE: If EAP relay mode is used, the user-name-format command configured in RADIUS scheme view does not take effect. The access device sends the authentication data from the client to the server without any modification. Setting the port authorization state The port authorization state determines whether the client is granted access to the network. You can control the authorization state of a port by using the dot1x port-control command and the following keywords: authorized-force Places the port in the authorized state, enabling users on the port to access the network without authentication. unauthorized-force Places the port in the unauthorized state, denying any access requests from users on the port. auto Places the port initially in the unauthorized state to allow only EAPOL packets to pass, and after a user passes authentication, sets the port in the authorized state to allow access to the network. You can use this option in most scenarios. You can set authorization state for one port in interface view, or for multiple ports in system view. If different authorization state is set for a port in system view and interface view, the one set later takes effect. To set the authorization state of a port: Step Command Remarks 1. Enter system view. 2. Set the port authorization state in system view, Layer 2 Ethernet interface view, or WLAN-ESS interface view. system-view In system view: dot1x port-control { authorized-force auto unauthorized-force } [ interface interface-list ] In Layer 2 Ethernet interface view or WLAN-ESS interface view: a. interface interface-type interface-number b. dot1x port-control { authorized-force auto unauthorized-force } N/A By default, auto applies. 109

122 Specifying an access control method You can specify an access control method for one port in interface view, or for multiple ports in system view. If different access control methods are specified for a port in system view and interface view, the one specified later takes effect. To specify the access control method: Step Command Remarks 1. Enter system view. system-view N/A 2. Specify an access control method in system view, Layer 2 Ethernet interface view, or WLAN-ESS interface view. In system view: dot1x port-method { macbased portbased } [ interface interface-list ] In Layer 2 Ethernet interface view or WLAN-ESS interface view: a. interface interface-type interface-number b. dot1x port-method { macbased portbased } By default, MAC-based access control applies. 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." Setting the maximum number of concurrent 802.1X users on a port You can set the maximum number of concurrent 802.1X users for ports individually in interface view or in bulk in system view. If different settings are configured for a port in both views, the setting configured later takes effect. To set the maximum number of concurrent 802.1X users on a port: Step Command Remarks 1. Enter system view. system-view N/A 2. Set the maximum number of concurrent 802.1X users on a port in system view, Layer 2 Ethernet interface view, or WLAN-ESS interface view. In system view: dot1x max-user user-number [ interface interface-list ] In Layer 2 Ethernet interface view or WLAN-ESS interface view: a. interface interface-type interface-number b. dot1x max-user user-number [ interface interface-list ] The default varies with devices. For more information, see About the Command References for HP Unified Wired-WLAN Products. 110

123 Setting the maximum number of authentication request attempts The network access device retransmits an authentication request if it receives no response to the request it has sent to the client within a period of time (specified by using the dot1x timer tx-period tx-period-value command or the dot1x timer supp-timeout supp-timeout-value command). The network access device stops retransmitting the request if it has made the maximum number of request transmission attempts but still received no response. To set the maximum number of authentication request attempts: Step Command Remarks 1. Enter system view. system-view N/A 2. Set the maximum number of attempts for sending an authentication request. dot1x retry max-retry-value The default setting is 2. 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. 3. Set the server timeout timer. dot1x timer supp-timeout supp-timeout-value dot1x timer server-timeout server-timeout-value 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 111

124 of handshake attempts (set by the dot1x retry command), 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 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 ensure the normal operation of the online user handshake security function. If the network has 802.1X clients that cannot exchange handshake packets with the network access device, disable the online user handshake function to prevent their connections from being inappropriately torn down. 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. 3. Enter Layer 2 Ethernet interface view or WLAN-ESS interface view. 4. Enable the online handshake function. 5. Enable the online handshake security function. dot1x timer handshake-period handshake-period-value interface interface-type interface-number dot1x handshake dot1x handshake secure The default is 15 seconds. N/A By default, the function is enabled. 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 112

125 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. Disable the multicast trigger in a wireless LAN. Wireless clients and the wireless module of the network access device can both initiate 802.1X authentication. Enable the unicast trigger on a port if only a few 802.1X clients are attached to the port and these clients cannot initiate authentication. To avoid duplicate authentication packets, do not enable both triggers on a port. Configuration procedure To configure the authentication trigger function on a port: Step Command Remarks 1. Enter system view. system-view N/A 2. Set the username request timeout timer. 3. Enter Layer 2 Ethernet interface view or WLAN-ESS interface view. 4. Enable an authentication trigger. dot1x timer tx-period tx-period-value interface interface-type interface-number dot1x { multicast-trigger unicast-trigger } The default setting is 30 seconds. N/A Required if you want to enable the unicast trigger. By default, the multicast trigger is enabled, and the unicast trigger is disabled. Unicast trigger is not available on a WLAN-ESS port. 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: 113

126 Step Command Remarks 1. Enter system view. system-view N/A 2. Enter Layer 2 Ethernet interface view or WLAN-ESS interface view. 3. Specify a mandatory 802.1X authentication domain on the port. interface interface-type interface-number dot1x mandatory-domain domain-name N/A By default, no mandatory 802.1X authentication domain is specified. Configuring the quiet timer The quiet timer enables the network access device to wait a period of time before it can process any authentication request from a client that has failed an 802.1X authentication. You can set the quiet timer to a high value in a vulnerable network or a low value for quicker authentication response. To configure the quiet timer: Step Command Remarks 1. Enter system view. system-view N/A 2. Enable the quiet timer. dot1x quiet-period By default, the timer is disabled. 3. Set the quiet timer. dot1x timer quiet-period quiet-period-value The default setting is 60 seconds. Enabling the periodic online user re-authentication function Periodic online user re-authentication tracks the connection status of online users and updates the authorization attributes assigned by the server, such as the ACL, VLAN, and user profile-based QoS. The re-authentication interval is user configurable. To enable the periodic online user re-authentication function: Step Command Remarks 1. Enter system view. system-view N/A 2. Set the periodic re-authentication timer. 3. Enter Layer 2 Ethernet interface view or WLAN-ESS interface view. 4. Enable periodic online user re-authentication. dot1x timer reauth-period reauth-period-value interface interface-type interface-number dot1x re-authenticate The default setting is 3600 seconds. N/A By default, the function is disabled. 114

127 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. RADIUS server unreachable can cause an online user being re-authenticated to be logged off. Configuring an 802.1X guest VLAN Configuration guidelines Follow these guidelines when you configure an 802.1X guest VLAN: 802.1X guest VLAN is supported only on a port that performs MAC-based access control. 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 PVID and the 802.1X guest VLAN on a port, so the port can correctly process incoming VLAN tagged traffic. Use Table 6 when configuring multiple security features on a port. Table 6 Relationships of the 802.1X guest VLAN and other security features Feature Relationship description Reference MAC authentication guest VLAN on a port that performs MAC-based access control 802.1X Auth-Fail VLAN on a port that performs MAC-based access control Port intrusion protection 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. The 802.1X Auth-Fail VLAN has a higher priority. The 802.1X 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 MAC authentication." See "Using 802.1X authentication with other features." See "Configuring port security." Configuration prerequisites Create the VLAN to be specified as the 802.1X guest VLAN. 115

128 On the 802.1X-enabled port that 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 Configuration Guide. Configuration procedure To configure an 802.1X guest VLAN: Step Command Remarks 1. Enter system view. system-view N/A 2. Configure an 802.1X guest VLAN for one or more ports in system view, Layer 2 Ethernet interface view, or WLAN-ESS interface view. In system view: dot1x guest-vlan guest-vlan-id [ interface interface-list ] In Layer 2 Ethernet interface view or WLAN-ESS interface view: a. interface interface-type interface-number b. dot1x guest-vlan guest-vlan-id By default, no 802.1X guest VLAN is configured on any port. Configuring an Auth-Fail VLAN Configuration guidelines Follow these guidelines when configuring an 802.1X Auth-Fail VLAN: 802.1X Auth-Fail VLAN is supported only on ports that perform MAC-based access control. Assign different IDs to the PVID and the 802.1X Auth-Fail VLAN on a port, so the port can correctly process VLAN tagged incoming traffic. You can configure only one 802.1X Auth-Fail VLAN on a port. The 802.1X Auth-Fail VLANs on different ports can be different. Use Table 7 when configuring multiple security features on a port. Table 7 Relationships of the 802.1X Auth-Fail VLAN with other features Feature Relationship description Reference MAC authentication guest VLAN on a port that performs MAC-based access control Port intrusion protection on a port that performs MAC-based access control The 802.1X Auth-Fail VLAN has a high priority. The 802.1X Auth-Fail 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 MAC authentication." See "Configuring port security." Configuration prerequisites Create the VLAN to be specified as the 802.1X Auth-Fail VLAN. 116

129 On the 802.1X-enabled port that 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 Configuration Guide. Configuration procedure To configure an Auth-Fail VLAN: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter Layer 2 Ethernet interface view or WLAN-ESS interface view. 3. Configure the Auth-Fail VLAN on the port. interface interface-type interface-number dot1x auth-fail vlan authfail-vlan-id N/A By default, no Auth-Fail VLAN is configured. 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 /, 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 /, and \. To specify a set of domain name delimiters: Step Command Remarks 1. Enter system view. system-view N/A 2. Specify a set of domain name delimiters for 802.1X users. dot1x domain-delimiter string By default, only the at sign (@) delimiter is supported. NOTE: If you configure the access device to include the domain name in the username sent to the RADIUS server, make sure the domain delimiter in the username can be recognized by the RADIUS server. For username format configuration, see the user-name-format command in Security Command Reference. 117

130 Configuring the accounting delay feature By default, the accounting delay feature is disabled. The device sends an accounting request to the accounting server for an 802.1X user immediately after the user passes authentication, regardless of whether an IP address has been assigned to the user. The accounting delay feature enables the device to wait a period of time for an authenticated 802.1X user to obtain an IP address before sending an accounting request. If the device gets the IP address of the user before the delay expires, it sends an accounting request for the user. If not, the device proceeds to the accounting procedure or ends the procedure depending on your configuration. Enable the accounting delay feature if 802.1X users obtain IP addresses through DHCP and the accounting server requires user IP addresses. For a network that deploys inode clients, follow these configuration guidelines: If the inode clients can upload their IP addresses during authentication, disable the accounting delay feature for efficiency. If the inode clients cannot upload their IP addresses, make sure the delay setting is equal to or less than the accounting delay that the EAD policy allows to prevent access failures. HP recommends a delay equal to or less than 20 seconds. To configure the accounting delay feature on an 802.1X-enabled port: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter Layer 2 Ethernet interface view or WLAN-ESS interface view. 3. Configure the accounting delay settings. interface interface-type interface-number dot1x accounting-delay [ logoff time time ] * N/A By default, accounting delay is disabled. Displaying and maintaining 802.1X Task Command Remarks Display 802.1X session information, statistics, or configuration information of specified or all ports. Display 802.1X stateful failover information. display dot1x [ sessions statistics ] [ interface interface-list ] [ { begin exclude include } regular-expression ] display dot1x synchronization { connection statistics status } [ interface interface-type interface-number ] [ { begin exclude include } regular-expression ] Available in any view. Available in any view. Clear 802.1X statistics. reset dot1x statistics [ interface interface-list ] Available in user view. Clear 802.1X stateful failover packet statistics. reset dot1x synchronization statistics [ interface interface-type interface-number ] Available in any view. 118

131 802.1X with ACL assignment configuration example This section describes how to configure 802.1X with ACL assignment. For more information about 802.1X configuration, see WLAN Configuration Guide. The configuration example was created on the 11900/10500/ G unified wired-wlan module and might vary with device models. When configuring the 11900/10500/ G unified wired-wlan module, make sure the settings are correct (including VLAN settings) on the internal Ethernet interface that connects the module to the switch. For more information, see HP 11900/10500/ G Unified Wired-WLAN Module Basic Configuration Guide. By default, the aggregate interfaces between the access controller engine and the switching engine on an 830 switch or an 870 appliance are Access interfaces in VLAN 1. When configuring the two aggregate interfaces, make sure their permitted VLANs are the same. HP also recommends that you set their link type to be the same. Network requirements As shown in Figure 46, the client at connects to port WLAN-ESS 1 of the AC. Perform 802.1X authentication on the port. Set the port security mode to userlogin-secure-ext. Use the RADIUS server at as the authentication and authorization server and the RADIUS server at as the accounting server. Assign an ACL to WLAN-ESS 1 to deny the access of 802.1X users to the FTP server at Figure 46 Network diagram Authentication servers (RADIUS server cluster) IP network Client AP FTP server AC Configuration procedure # Assign IP addresses to interfaces. (Details not shown.) 119

132 # Configure the RADIUS server and specify the ACL to be assigned. (Details not shown.) # Configure the RADIUS scheme. <AC> system-view [AC] radius scheme 2000 [AC-radius-2000] primary authentication [AC-radius-2000] primary accounting [AC-radius-2000] key authentication abc [AC-radius-2000] key accounting abc [AC-radius-2000] user-name-format without-domain [AC-radius-2000] quit # Create an ISP domain and specify the RADIUS scheme 2000 as the default AAA schemes for the domain. [AC] domain 2000 [AC-isp-2000] authentication default radius-scheme 2000 [AC-isp-2000] authorization default radius-scheme 2000 [AC-isp-2000] accounting default radius-scheme 2000 [AC-isp-2000] quit # Configure ACL 3000 to deny packets destined for the FTP server at [AC] acl number 3000 [AC-acl-adv-3000] rule 0 deny ip destination # Set the authentication method to EAP. [AC] dot1x authentication-method eap # Enable port security. [AC] port-security enable # Set the port security mode to userlogin-secure-ext, and enable port-security tx-key-type 11key. [AC] interface wlan-ess 1 [AC-WLAN-ESS1] port link-type hybrid [AC-WLAN-ESS1] port hybrid vlan 2 untagged [AC-WLAN-ESS1] port hybrid pvid vlan 2 [AC-WLAN-ESS1] mac-vlan enable [AC-WLAN-ESS1] port-security port-mode userlogin-secure-ext [AC-WLAN-ESS1] port-security tx-key-type 11key [AC-WLAN-ESS1] dot1x mandatory-domain 2000 # Disable the multicast trigger function and online user handshake function. [AC-WLAN-ESS1] undo dot1x multicast-trigger [AC-WLAN-ESS1] undo dot1x handshake [AC-WLAN-ESS1] quit # Create service template 1 of crypto type, configure its SSID as dot1x, and configure the tkip and ccmp cipher suite. [AC] wlan service-template 1 crypto [AC-wlan-st-1] ssid dot1x [AC-wlan-st-1] bind wlan-ess 1 [AC-wlan-st-1] cipher-suite tkip [AC-wlan-st-1] cipher-suite ccmp [AC-wlan-st-1] security-ie rsn [AC-wlan-st-1] service-template enable 120

133 [AC-wlan-st-1] quit # Create an AP template named ap1 and its model is MSM460-WW, and configure the serial ID of the AP as CN2AD330S8. [AC] wlan ap ap1 model MSM460-WW [AC-wlan-ap-ap1] serial-id CN2AD330S8 [AC-wlan-ap-ap1] radio 1 type dot11an # Bind service template 1 to radio 1. [AC-wlan-ap-ap1-radio-1] service-template 1 [AC-wlan-ap-ap1-radio-1] radio enable Verifying the configuration # After a user passes authentication, use the display connection command to verify that the 802.1X connection has been set up. [AC] display connection Index=1,Username=localuser@2000 MAC= B3-8A-77 IP= IPv6=N/A Online=00h00m53s Total 1 connection(s) matched. [AC] display connection ucibindex 1 Index=1, Username= localuser@2000 MAC= B3-8A-77 IP= IPv6=N/A Access=8021X,AuthMethod=EAP Port Type=Wireless ,Port Name=WLAN-DBSS1:1 Initial VLAN=2, Authorization VLAN=N/A ACL Group=3000 User Profile=N/A CAR=Disable Traffic Statistic: InputOctets = OutputOctets =12120 InputGigawords=1 OutputGigawords=0 Priority=Disable Start= :29:39,Current= :30:51,Online=00h01m13s Total 1 connection matched. # Use the user account to pass authentication, and then ping the FTP server. C:\>ping Pinging with 32 bytes of data: Request timed out. Request timed out. Request timed out. 121

134 Request timed out. Ping statistics for : 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. 122

135 Configuring MAC authentication Overview MAC authentication controls network access by authenticating source MAC addresses on a port. It does not require client software and users do not need to enter a username and password for network access. The device initiates a MAC authentication process when it detects an unknown source MAC address on a MAC authentication enabled port. If the MAC address passes authentication, the user can access authorized network resources. If the authentication fails, the device marks the MAC address as a silent MAC address, drops the packet, and starts a quiet timer. The device drops all subsequent packets from the MAC address within the quiet time. The quiet mechanism avoids repeated authentication during a short time. NOTE: If the MAC address that has failed authentication is a static MAC address or a MAC address that has passed any security authentication, the device does not mark 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 RADIUS server. Suppose a source MAC unknown packet arrives at a MAC authentication enabled port. Local authentication: If MAC-based accounts are used, the access device uses the source MAC address of the packet as the username and password to search its local account database for a match. If a shared account is used, the access device uses the shared account username and password to search its local account database for a match. RADIUS authentication: If MAC-based accounts are used, the access device sends the source MAC address as the username and password to the RADIUS server for authentication. If a shared account is used, the access device sends the shared account username and password to the RADIUS server for authentication. 123

136 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 within the interval, the device logs the user out and stops accounting for the user. Quiet timer Sets the interval that the device must wait before it can perform MAC authentication for a user that has failed MAC authentication. All packets from the MAC address are dropped during the quiet time. This quiet mechanism prevents repeated authentication from affecting system performance. Server timeout timer Sets the interval that the access device waits for a response from a RADIUS server before it regards the RADIUS server unavailable. If the timer expires during MAC authentication, the user cannot access the network. Using MAC authentication with other features VLAN assignment You can specify a VLAN in the user account for a MAC authentication user to control its access to network resources. After the user passes MAC authentication, the authentication server, either the local access device or a RADIUS server, assigns the VLAN to the port as the default VLAN. After the user logs off, the initial default VLAN, or the default VLAN configured before any VLAN is assigned by the authentication server, restores. If the authentication server assigns no VLAN, the initial default VLAN applies. A hybrid port is always assigned to a server-assigned VLAN as an untagged member. After the assignment, do not re-configure the port as a tagged member in the VLAN. If MAC-based VLAN is enabled on a hybrid port, the device maps the server-assigned VLAN to the MAC address of the user. The default VLAN of the hybrid port does not change. ACL assignment You can specify an ACL in the user account for a MAC authentication user to control its access to network resources. After the user passes MAC authentication, the authentication server, either the local access device or a RADIUS server, assigns the ACL to the access port to filter the traffic from this user. You must configure the ACL on the access device for the ACL assignment function. You can change ACL rules while the user is online. 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 124

137 MAC authentication guest VLAN is configured, the user that fails MAC authentication cannot access any network resources. 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. MAC-after-portal The MAC-after-portal feature triggers MAC authentication for only portal-authenticated users. The AC allows only these users to pass MAC authentication and assigns them to VLANs that perform local forwarding on an AP. For more information about local forwarding, see WLAN Configuration Guide. When a user accesses the wireless network for the first time, the AC uses the process to implement the MAC-after-portal feature: 1. Identifies that the user is not portal authenticated and assigns the user to the MAC authentication guest VLAN on the access interface. 2. Performs portal authentication for the user. After the user passes portal authentication, MAC authentication is triggered. 3. Determines that the portal-authenticated user passes MAC authentication. 4. Assigns the user to the server-authorized VLAN that performs local forwarding. The AC issues the MAC-VLAN entry of the user to the AP for local forwarding. The portal module tags a portal-authenticated user as always online unless the idle-cut period is reached. When the user accesses the network during the idle-cut period, the user passes MAC authentication directly. The AC does not perform portal authentication because the user is tagged as portal authenticated. Configuration task list Task Basic configuration for MAC authentication: Configuring MAC authentication globally Configuring MAC authentication on a port Specifying a MAC authentication domain Configuring a MAC authentication guest VLAN Configuring the MAC-after-portal feature Remarks Required. Basic configuration for MAC authentication Before you perform basic configuration for MAC authentication, complete the following tasks: Create and configure an authentication domain, also called "an ISP domain." 125

138 For local authentication, create local user accounts, and specify the lan-access service for the accounts. For RADIUS authentication, check that the device and the RADIUS server can reach each other, and create user accounts on the RADIUS server. If you are using MAC-based accounts, make sure the username and password for each account is the same as the MAC address of the MAC authentication users. Configuring MAC authentication globally MAC authentication can take effect on a port only when it is enabled globally and on the port. To configure MAC authentication globally: Step Command Remarks 1. Enter system view. system-view N/A 2. Enable MAC authentication globally. 3. Configure MAC authentication timers. 4. Configure the properties of MAC authentication user accounts. mac-authentication mac-authentication timer { offline-detect offline-detect-value quiet quiet-value server-timeout server-timeout-value } mac-authentication user-name-format { fixed [ account name ] [ password { cipher simple } password ] mac-address [ { with-hyphen without-hyphen } [ lowercase uppercase ] ] } By default, MAC authentication is disabled globally. MAC authentication is enabled globally after the port security feature is enabled. By default, the offline detect timer is 300 seconds, the quiet timer is 60 seconds, and the server timeout timer is 100 seconds. By default, the username and password for a MAC authentication user account must be a MAC address, and the letters in the MAC address are unhyphenated and in lower case. Configuring MAC authentication on a port You cannot add a MAC authentication-enabled port in to a link aggregation group, or enable MAC authentication on a port already in a link aggregation group. To configure MAC authentication on a port: Step Command Remarks 1. Enter system view. system-view N/A 126

139 Step Command Remarks 2. Enable MAC authentication. 3. Set the maximum number of concurrent MAC authentication users allowed on a port. On a group of Ethernet interfaces in system view: mac-authentication interface interface-list On an Ethernet interface in interface view: a. interface interface-type interface-number b. mac-authentication On a WLAN-ESS or WLAN-MESH interface: See "Configuring port security"). mac-authentication max-user user-number Use one of the methods. By default, MAC authentication is disabled on a port. The default depends on the device model. For more information, see About the Command References for HP Unified Wired-WLAN Products. Specifying a MAC authentication domain By default, MAC authentication users are in the system default authentication domain. To implement different access policies for users, you can specify authentication domains for MAC authentication users in the following ways: Specify a global authentication domain in system view. This domain setting applies to all ports. Specify an authentication domain for an individual port in interface view. MAC authentication chooses an authentication domain for users on a port in the following order: the port-specific domain, the global domain, and the default domain. For more information about authentication domains, see "Configuring AAA." To specify an authentication domain for MAC authentication users: Step Command Remarks 1. Enter system view. system-view N/A 2. Specify an authentication domain for MAC authentication users in system view or interface view. In system view: mac-authentication domain domain-name In interface view: a. interface interface-type interface-number b. mac-authentication domain domain-name By default, the system default authentication domain is used for MAC authentication users. Configuring a MAC authentication guest VLAN Before you configure a MAC authentication guest VLAN on a port, complete the following tasks: Enable MAC authentication. 127

140 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 WLAN-ESS interface view. 3. Specify a MAC authentication guest VLAN. interface interface-type interface-number mac-authentication guest-vlan guest-vlan-id N/A By default, no MAC authentication guest VLAN is configured. You can configure only one MAC authentication guest VLAN on a port. Follow the guidelines in Table 8 when configuring a MAC authentication guest VLAN on a port. Table 8 Relationships of the MAC authentication guest VLAN with other security features Feature Relationship description Reference Quiet function of MAC authentication Port intrusion protection 802.1X guest VLAN on a port that performs MAC-based access control The MAC authentication guest VLAN function has higher priority. A user can access any resources in the guest VLAN. 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. The MAC authentication guest VLAN has a lower priority. See "MAC authentication timers." See "Configuring port security." See "Configuring 802.1X." Configuring the MAC-after-portal feature Use the MAC-after-portal feature with the local forwarding and local portal server functions. Before you configure this feature on a WLAN-ESS interface, complete the following tasks: Configure a clear-type service. Enable MAC authentication globally and on the interface. Enable the MAC-based VLAN function on the interface. Enable the local portal server function in the MAC authentication guest VLAN. Configure the MAC authentication guest VLAN, and specify it as the VLAN to perform centralized forwarding. Configure VLAN assignment for MAC-authenticated users, and specify the VLAN to perform local forwarding. Configure local portal and local MAC authentication parameters. To configure the MAC-after-portal feature: 128

141 Step Command Remarks 1. Enter system view. system-view N/A 2. Enter WLAN-ESS interface view. 3. Configure MAC-after-portal. interface interface-type interface-number mac-authentication trigger after-portal N/A By default, this feature is disabled. Displaying and maintaining MAC authentication Task Command Remarks Display MAC authentication information. Clear MAC authentication statistics. display mac-authentication [ interface interface-list ] [ { begin exclude include } regular-expression ] reset mac-authentication statistics [ interface interface-list ] Available in any view. Available in user view. MAC authentication configuration examples The configuration examples were created on the 11900/10500/ G unified wired-wlan module and might vary with device models. When configuring the 11900/10500/ G unified wired-wlan module, make sure the settings are correct (including VLAN settings) on the internal Ethernet interface that connects the module to the switch. For more information, see HP 11900/10500/ G Unified Wired-WLAN Module Basic Configuration Guide. By default, the aggregate interfaces between the access controller engine and the switching engine on an 830 switch or an 870 appliance are Access interfaces in VLAN 1. When configuring the two aggregate interfaces, make sure their permitted VLANs are the same. HP also recommends that you set their link type to be the same. Local MAC authentication configuration example Network requirements In the network in Figure 47, perform local MAC and PSK authentication on WLAN-ESS interface of the AC to control Internet access. Make sure: 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 AC detects whether a user has gone offline every 180 seconds. 129

142 Figure 47 Network diagram Supplicant Authenticator IP network Client MAC: 00-e0-fc AP L2switch AC Configuration procedure # Add a local user account, set both the username and password to 00-e0-fc , the MAC address of the user host, and enable LAN access service for the account. <AC> system-view [AC] local-user 00-e0-fc [AC-luser-00-e0-fc ] password simple 00-e0-fc [AC-luser-00-e0-fc ] service-type lan-access [AC-luser-00-e0-fc ] quit # Configure ISP domain aabbcc.net to perform local authentication for access users. [AC] domain aabbcc.net [AC-isp-aabbcc.net] authentication lan-access local [AC-isp-aabbcc.net] quit # Specify the ISP domain for MAC authentication. [AC] mac-authentication domain aabbcc.net # Set the MAC authentication timers. [AC] mac-authentication timer offline-detect 180 # Configure MAC authentication to use MAC-based accounts. The MAC address usernames and passwords are hyphenated and in lower case. [AC] mac-authentication user-name-format mac-address with-hyphen lowercase # Enable port security. [AC] port-security enable # Configure WLAN port security, using MAC and PSK authentication. [AC] interface wlan-ess 0 [AC-WLAN-ESS0] port-security port-mode mac-and-psk [AC-WLAN-ESS0] port-security tx-key-type 11key [AC-WLAN-ESS0] port-security preshared-key pass-phrase [AC-WLAN-ESS0] quit # Create service template 2 of crypto type, configure its SSID as mac-authentication-local, and bind port WLAN-ESS 0 to service template 2. [AC] wlan service-template 2 crypto [AC-wlan-st-2] ssid mac-authentication-local [AC-wlan-st-2] bind wlan-ess 0 [AC-wlan-st-2] authentication-method open-system [AC-wlan-st-2] cipher-suite ccmp 130

143 [AC-wlan-st-2] security-ie rsn [AC-wlan-st-2] service-template enable [AC-wlan-st-2] quit # Create an AP template named ap1, specify the model as MSM460-WW and serial number as CN2AD330S8. [AC] wlan ap ap1 model MSM460-WW [AC-wlan-ap-ap1] serial-id CN2AD330S8 # Bind service template 2 to radio 1. [AC-wlan-ap-ap1] radio 1 type dot11an [AC-wlan-ap-ap1-radio-1] service-template 2 [AC-wlan-ap-ap1-radio-1] radio enable [AC-wlan-ap-ap1-radio-1] return Verifying the configuration # After the WLAN user passes MAC authentication, display MAC authentication settings and statistics. <AC> display mac-authentication interface WLAN-DBSS 0:0 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 60s Server response timeout value is 100s The max allowed user number is per slot Current user number amounts to 1 Current domain is aabbcc.net Silent MAC User info: MAC Addr From Port Port Index WLAN-DBSS0:0 is link-up MAC address authentication is enabled Authenticate success: 1, failed: 0 Max number of on-line users is 4096 Current online user number is 1 MAC Addr Authenticate State Auth Index 00e0-fc MAC_AUTHENTICATOR_AUTHOR 1299 # Display the online user information. <AC>display connection Index=1299,Username=00-e0-fc-l @aabbcc.net MAC=00-E0-FC IP=N/A IPv6=N/A Online=00h00m53s Total 1 connection(s) matched. 131

144 RADIUS-based MAC authentication configuration example Network requirements As shown in Figure 48, a WLAN client connects to the AC through a Layer 2 switch. The AC uses RADIUS servers for authentication, authorization, and accounting. Perform MAC authentication on WLAN-ESS interface to control Internet access. Make sure that: The AC detects whether a user has gone offline every 180 seconds. All MAC authentication users belong to ISP domain 2000 and share the user account aaa with password Figure 48 Network diagram Configuration procedure Make sure the RADIUS server and the AC can reach each other. # Create a shared account for MAC authentication users on the RADIUS server, and set the username aaa and password for the account. (Details not shown.) # Configure IP addresses of the interfaces. (Details not shown.) # Configure a RADIUS scheme. <AC> system-view [AC] radius scheme 2000 [AC-radius-2000] primary authentication [AC-radius-2000] primary accounting [AC-radius-2000] key authentication simple abc [AC-radius-2000] key accounting simple abc [AC-radius-2000] user-name-format without-domain [AC-radius-2000] quit # Apply the RADIUS scheme to ISP domain 2000 for authentication, authorization, and accounting. [AC] domain 2000 [AC-isp-2000] authentication default radius-scheme 2000 [AC-isp-2000] authorization default radius-scheme 2000 [AC-isp-2000] accounting default radius-scheme

145 [AC-isp-2000] quit # Enable port security. [AC] port-security enable # Configure the WLAN port security, using MAC and PSK authentication, and specify the domain 2000 as the authentication domain for MAC authentication users on the port. [AC] interface wlan-ess 0 [AC-WLAN-ESS0] port-security port-mode mac-and-psk [AC-WLAN-ESS0] port-security tx-key-type 11key [AC-WLAN-ESS0] port-security preshared-key pass-phrase [AC-WLAN-ESS0] mac-authentication domain 2000 [AC-WLAN-ESS0] quit # Create service template 2 of crypto type, configure its SSID as mac-authentication-radius and bind port WLAN-ESS 0 to service template 2. [AC] wlan service-template 2 crypto [AC-wlan-st-2] ssid mac-authentication-radius [AC-wlan-st-2] bind wlan-ess 0 [AC-wlan-st-2] authentication-method open-system [AC-wlan-st-2] cipher-suite ccmp [AC-wlan-st-2] security-ie rsn [AC-wlan-st-2] service-template enable [AC-wlan-st-2] quit # Create an AP template named ap1, specify the model as MSM460-WW and serial number as CN2AD330S8. [AC] wlan ap ap1 model MSM460-WW [AC-wlan-ap-ap1] serial-id CN2AD330S8 # Bind service template 2 to radio 1. [AC-wlan-ap-ap1] radio 1 type dot11an [AC-wlan-ap-ap1-radio-1] service-template 2 [AC-wlan-ap-ap1-radio-1] radio enable [AC-wlan-ap-ap1-radio-1] quit [AC-wlan-ap-ap1] quit # Set the MAC authentication timers. [AC] mac-authentication timer offline-detect 180 # Specify username aaa and plaintext password for the account shared by MAC authentication users. [AC] mac-authentication user-name-format fixed account aaa password simple Verifying the configuration # After a WLAN user passes MAC authentication, display MAC authentication settings and statistics. <AC> display mac-authentication interface WLAN-DBSS0:7 MAC address authentication is enabled. User name format is fixed account Fixed username:aaa Fixed password:****** Offline detect period is 180s Quiet period is 60s 133

146 Server response timeout value is 100s The max allowed user number is per slot Current user number amounts to 1 Current domain is 2000 Silent MAC User info: MAC Addr From Port Port Index WLAN-DBSS0:7 is link-up MAC address authentication is enabled Authenticate success: 1, failed: 0 Max number of on-line users is 4096 Current online user number is 1 MAC Addr Authenticate State Auth Index 000e-35b2-8be9 MAC_AUTHENTICATOR_SUCCESS 1297 # Display the online user information. <AC> display connection Index=1297,Username=aaa@2000 MAC=00-0E-35-B2-8B-E9 IP=N/A IPv6=N/A Online=00h00m53s Total 1 connection(s) matched. ACL assignment configuration example Network requirements As shown in Figure 49, a WLAN client connects to the AC and the AC uses RADIUS servers to perform authentication, authorization, and accounting. Perform MAC authentication on port WLAN-ESS 0 to control Internet access. Make sure that an authenticated user can access the Internet but the FTP server at Use MAC-based user accounts for MAC authentication users. The MAC addresses are hyphen separated and in lower case. 134

147 Figure 49 Network diagram Authentication servers (RADIUS server cluster) IP network Client AP FTP server AC Configuration procedure Make sure the RADIUS server and the AC can reach each other. 1. Add a user account with 00-e0-fc 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.) 2. Configure the ACL: # Configure IP addresses of the interfaces. (Details not shown.) # Configure ACL 3000 to deny packets destined to <AC> system-view [AC] acl number 3000 [AC-acl-adv-3000] rule 0 deny ip destination [AC-acl-adv-3000] quit 3. Configure RADIUS-based MAC authentication on the AC: # Configure a RADIUS scheme. [AC] radius scheme 2000 [AC-radius-2000] primary authentication [AC-radius-2000] primary accounting [AC-radius-2000] key authentication simple abc [AC-radius-2000] key accounting simple abc [AC-radius-2000] user-name-format without-domain [AC-radius-2000] quit # Apply the RADIUS scheme to an ISP domain for authentication, authorization, and accounting. [AC] domain 2000 [AC-isp-2000] authentication default radius-scheme 2000 [AC-isp-2000] authorization default radius-scheme 2000 [AC-isp-2000] accounting default radius-scheme 2000 [AC-isp-2000] quit # Configure the AC to use MAC-based user accounts, the MAC addresses are hyphen separated and in lower case. [AC] mac-authentication user-name-format mac-address with-hyphen lowercase 135

148 # Enable port security. [AC] port-security enable # Configure the WLAN port security, using MAC and PSK authentication, and specify the domain 2000 as the authentication domain for MAC authentication users on the port. [AC] interface wlan-ess 0 [AC-WLAN-ESS0] port-security port-mode mac-and-psk [AC-WLAN-ESS0] port-security tx-key-type 11key [AC-WLAN-ESS0] port-security preshared-key pass-phrase [AC-WLAN-ESS0] mac-authentication domain 2000 [AC-WLAN-ESS0] quit # Create service template 2 of crypto type, configure its SSID as mac-authentication-acl, and bind port WLAN-ESS 0 to service template 2. [AC] wlan service-template 2 crypto [AC-wlan-st-2] ssid mac-authentication-acl [AC-wlan-st-2] bind wlan-ess 0 [AC-wlan-st-2] authentication-method open-system [AC-wlan-st-2] cipher-suite ccmp [AC-wlan-st-2] security-ie rsn [AC-wlan-st-2] service-template enable [AC-wlan-st-2] quit # Create an AP template named ap1, specify the model as MSM460-WW and serial number as CN2AD330S8. [AC] wlan ap ap1 model MSM460-WW [AC-wlan-ap-ap1] serial-id CN2AD330S8 # Bind service template 2 to radio 1. [AC-wlan-ap-ap1] radio 1 type dot11an [AC-wlan-ap-ap1-radio-1] service-template 2 [AC-wlan-ap-ap1-radio-1] radio enable [AC-wlan-ap-ap1-radio-1] return Verifying the configuration # After a WLAN client passes authentication, display MAC authentication settings and statistics. <AC>display mac-authentication interface WLAN-DBSS 0:9 MAC address authentication is enabled. User name format is MAC address in lowercase, like xx-xx-xx-xx-xx-xx Fixed username:mac Fixed password:not configured Offline detect period is 300s Quiet period is 60s Server response timeout value is 100s The max allowed user number is per slot Current user number amounts to 1 Current domain is 2000 Silent MAC User info: MAC Addr From Port Port Index WLAN-DBSS0:9 is link-up 136

149 MAC address authentication is enabled Authenticate success: 1, failed: 0 Max number of on-line users is 4096 Current online user number is 1 MAC Addr Authenticate State Auth Index 00e0-fc MAC_AUTHENTICATOR_SUCCESS 1301 # Display online user information. <AC> display connection Index=1301,Username=00-e0-fc @2000 MAC=00-E0-FC-L IP=N/A IPv6=N/A Online=00h00m53s Total 1 connection(s) matched. # Ping the FTP server from the client to verify that the ACL 3000 has been assigned to port WLAN-ESS 0 to deny access to the FTP server. <Client> ping PING : 56 data bytes, press CTRL_C to break Request time out Request time out Request time out Request time out Request time out ping statistics packet(s) transmitted 0 packet(s) received % packet loss 137

150 Configuring portal authentication Overview Portal authentication helps control access to the Internet. Portal authentication is also called Web authentication. A website implementing portal authentication is called a portal website. With portal authentication, an access device redirects all users to the portal authentication page. All users can access the free services provided on the portal website. However, to access the Internet, a user must pass portal authentication. A user can access a known portal website and enter a username and password for authentication. This authentication mode is called active authentication. There is another authentication mode, forced authentication, in which the access device forces a user who is trying to access the Internet through HTTP to log on to a portal website for authentication. The portal feature provides the flexibility for ISPs to manage services. A portal website can, for example, present advertisements and deliver community and personalized services. In this way, broadband network providers, equipment vendors, and content service providers form an industrial ecological system. Extended portal functions By forcing patching and anti-virus policies, extended portal functions help users to defend against viruses. Portal authentication supports the following extended functions: Security check Works after identity authentication succeeds to check whether the required anti-virus software, virus definition file, and operating system patches are installed, and whether there is any unauthorized software installed on the user host. Resource access restriction Allows users passing identity authentication to access only network resources in the quarantined area, such as the anti-virus server and the patch server. Only users passing both identity authentication and security check can access restricted network resources. Portal system components As shown in Figure 50, a typical portal system has these basic components: Authentication client Access device Portal server Authentication/accounting server Security policy server 138

151 Figure 50 Portal system components Authentication client Security policy server Authentication client Access device Portal server Authentication client Authentication/accounting server Authentication client Access device Portal server An authentication client is an entity seeking access to network resources. It is typically an end-user terminal such as a PC. A client can use a browser or portal client software for portal authentication. Client security check is implemented through communications between the client and the security policy server. To implement security check, the client must be the HP inode client. 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. A portal server listens to authentication requests from authentication clients and exchanges client authentication information with the access device. It provides free portal services and pushes Web authentication pages to users. A portal server can be an entity independent of the access device or an entity embedded in the access device. In this document, the term "portal server" refers to an independent portal server, and the term "local portal server" refers to an embedded portal server. 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. Security policy server A security policy server interacts with authentication clients and access devices for security check and resource authorization. 139

152 The components of a portal system interact as follows: 1. When an unauthenticated user enters a website address in the browser's address bar to access the Internet, the system creates an HTTP request and sends it to the access device. The access device then redirects the HTTP request to the portal server's Web authentication homepage. For extended portal functions, authentication clients must run the portal client software. 2. On the authentication homepage/authentication dialog box, the user enters and submits the authentication information, which the portal server then transfers to the access device. 3. Upon receipt of the authentication information, the access device communicates with the authentication/accounting server for authentication and accounting. 4. After successful authentication, the access device checks whether there is a corresponding security policy for the user. If not, it allows the user to access the Internet. Otherwise, the client communicates with the access device and the security policy server for security check. If the client passes the security check, the security policy server authorizes the user to access the Internet resources. NOTE: Portal authentication supports NAT traversal whether it is initiated by a Web client or an 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 In addition to using 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. In this case, the portal system consists of only three components: authentication client, access device, and authentication/accounting server, as shown in Figure 51. Figure 51 Portal system using the local portal server No security policy server is needed for local portal service because the portal system using the local portal server does not support extended portal functions. 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. Protocols used for interaction between the client and local portal server You can use HTTP and HTTPS for interaction between an authentication client and an access device providing the local portal server function. If you use HTTP, there are potential security problems because HTTP packets are transferred in plain text. If you use HTTPS, secure data transmission is ensured because HTTPS packets are transferred in cipher text based on SSL. 140

153 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 the following authentication pages: Logon page Logon success page Online page Logoff success page Logon failure page System busy page A local portal server pushes a corresponding authentication page at each authentication phase. If you do not customize the authentication pages, the local portal server pushes the default authentication pages. For information about authentication page customization rules, see "Customizing authentication pages." Portal authentication modes Portal authentication may work at Layer 2 or Layer 3 of the OSI model. The device supports only 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. 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. 141

154 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 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 Only Layer 3 portal authentication that uses a remote portal server supports EAP authentication. Authentication by using the username and password is less secure. Digital certificate authentication is usually used to ensure higher security. The Extensible Authentication Protocol (EAP) supports several digital certificate-based authentication methods, for example, EAP-TLS. Working together with EAP, portal authentication can implement digital certificate-based user authentication. Figure 52 Portal support for EAP working flow diagram As shown in Figure 52, 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 HP IMC portal server and the HP inode portal client. Layer 3 portal authentication process Direct authentication and cross-subnet authentication share the same authentication process. Re-DHCP authentication has a different process because of the presence of two address allocation procedures. 142

155 Direct authentication/cross-subnet authentication process (with CHAP/PAP authentication) Figure 53 Direct authentication/cross-subnet authentication process The direct authentication/cross-subnet authentication process is as follows: 1. An authentication client initiates authentication by sending an HTTP request. When the HTTP packet arrives at the access device, the access device allows it to pass if it is destined for the portal server or a predefined free website, or redirects it to the portal server if it is destined for other websites. The portal server pushes a Web authentication page to the user, and the user enters the username and password. 2. The portal server and the access device exchange CHAP messages. This step is skipped for PAP authentication. 3. The portal server assembles the username and password into an authentication request message, and it sends the message 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. 143

156 Re-DHCP authentication process (with CHAP/PAP authentication) Figure 54 Re-DHCP authentication process Authentication client Portal server Access device Authentication/ accounting server Security policy server 1) Initiate a connection 2) CHAP authentication 3) Authentication request Timer 5) Authentication reply 6) Authentication succeeds 7) The user obtains a new IP address 8) Discover user IP change 4) RADIUS authentication 9) Detect user IP change 10) Notify login success 11) IP change acknowledgment 12) Security check 13) Authorization The re-dhcp authentication process is as follows: Step 1 through step 6 are the same as those in the direct authentication/cross-subnet authentication process. 7. After receiving the authentication success message, the authentication client obtains a new public IP address through DHCP and notifies the portal server that it now has a public IP address. 8. The portal server notifies the access device that the authentication client has obtained a new public IP address. 9. Detecting the change of the IP address by examining ARP packets received, the access device notifies the portal server of the change. 10. The portal server notifies the authentication client of logon success. 11. The portal server sends a user IP address change acknowledgment message to the access device. With extended portal functions, the process includes additional steps: 12. The security policy server exchanges security check information with the authentication client to check whether the authentication client meets the security requirements. 13. Based on the security check result, the security policy server authorizes the user to access certain resources, and sends the authorization information to the access device. The access device then controls access of the user based on the authorization information. 144

157 Authentication process with the local portal server Figure 55 Authentication process with the local portal server With the local portal server, the direct/cross-subnet authentication process is as follows: 1. A portal client initiates authentication by sending an HTTP request. When the HTTP packet arrives at an access device using the local portal server, it is redirected to the local portal server, which then pushes a Web authentication page for the user to enter the username and password. 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 authentication client. 2. The access device and the RADIUS server exchange RADIUS packets to authenticate the user. 3. If the user passes authentication, the local portal server pushes a logon success page to the authentication client, informing the user of the authentication (logon) success. Portal support for EAP authentication process Figure 56 Portal support for EAP authentication process All portal authentication modes share the same EAP authentication steps. The following example uses direct portal authentication to show the EAP authentication process: 1. The authentication client sends an EAP Request/Identity message to the portal server to initiate an EAP authentication process. 145

158 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 the request to the RADIUS server. The EAP-Message attributes in the RADIUS authentication request are those carried in the received portal authentication request. 4. The access device sends a certificate request to the portal server according to the reply received from the RADIUS server. The certificate request also contains several EAP-Message attributes, which are used to transfer the certificate information of the RADIUS server. The EAP-Message attributes in the certificate request are those carried in the RADIUS authentication reply. 5. After receiving the certificate request, the portal server sends an EAP authentication reply to the authentication client, carrying the EAP-Message attribute values. 6. The authentication client sends another EAP request to continue the EAP authentication with the RADIUS server, during which there may be several portal authentication requests. The subsequent authentication processes are the same as that initiated by the first EAP request, except that the EAP request types vary with the EAP authentication phases. 7. After the authentication client passes the EAP authentication, the RADIUS server sends an authentication reply to the access device. This reply carries the EAP-Success message in the EAP-Message attribute. 8. The access device sends an authentication reply to the portal server. This reply carries the EAP-Success message in the EAP-Message attribute. 9. The portal server notifies the authentication client of the authentication success. 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. MAC-based quick portal authentication Typically, users must provide username and password for portal authentication each time they access the network. Users who access the network frequently may want to pass authentication without entering username and password. To meet such requirements, portal supports a MAC-based quick authentication scheme, which is also referred to as MAC-triggered authentication. With MAC-triggered authentication, the access device obtains the source MAC address of a user. When the network traffic of the user is below the specified threshold (1024 bytes for example), the access device allows the user to access the network without portal authentication. When the user's network traffic reaches the threshold, the access device triggers portal authentication for the user. The authentication procedure is as follows: 1. The access device sends a MAC binding query to the MAC binding server. 2. When the MAC binding server receives the query, it checks whether the MAC address is bound with a portal user account. If yes, the MAC binding server obtains the account information of the portal user, and sends the username and password of the user to the access device to initiate portal authentication. The user can pass portal authentication without entering the username and password. 146

159 If not, the MAC binding server notifies the access device to perform normal portal authentication for the user. The access device redirects the subsequent HTTP packet of the user to the portal server, which provides a portal authentication page for the user. The user must enter the username and password to pass portal authentication. MAC-triggered authentication provides a quick, effective portal authentication for users whose MAC addresses have been bound with portal user accounts on the MAC binding servers. A MAC binding server is required for MAC-triggered authentication. An HP IMC portal server should be used as the MAC binding server. The MAC-to-account bindings of portal users are recorded on the MAC binding server. A MAC binding server performs the following functions: Records bindings between endpoints (identified by MAC addresses) and user accounts. The bindings facilitate user auditing. Endpoint-to-account bindings are added to the endpoint device list of the MAC binding server in the following ways: The MAC binding server automatically learns and records the binding between an endpoint and an account. The binding does not update automatically. The endpoint is bound only to the first account that passes authentication on the endpoint, no matter how many accounts pass authentication later. To unbind the endpoint and the account, you need to delete the binding from the endpoint device list. A user manually adds endpoint-to-account bindings on the user self-service center. This method allows multiple endpoints to be bound to an account. Records bindings between endpoints (identified by MAC addresses) and manufacturer/device type/operating system information. The bindings facilitate endpoint auditing. The MAC binding server automatically obtains the manufacturer, device type, and operating system information of an endpoint. The binding between the endpoint and the information obtained the first time is saved in the endpoint device list. When a user initiates authentication on the endpoint, the MAC binding server compares the current information of the endpoint with the recorded information. If inconsistency occurs, the MAC binding server logs the endpoint information conflict. Provides quick enabling/disabling of MAC-triggered authentication. If MAC-triggered authentication for endpoints is enabled on the MAC binding server, you can quickly enable or disable MAC-triggered authentication for specific endpoints in the endpoint device list. On an HP IMC portal server, you can configure the fast authentication on smart terminals function to implement MAC-triggered authentication. For more information about the configuration procedure, see the configuration manuals for the IMC portal server. Portal stateful failover Overview Support for this feature depends on the device model. For more information, see About the Configuration Guides for HP Unified Wired-WLAN Products. Stateful failover supports hot backup of services on two devices. Stateful failover can be configured on key devices to avoid service interruptions caused by single point failures. When operating normally, the two devices synchronize service information. If one device fails, the other device takes over the services. 147

160 To implement stateful failover, specify an stateful failover interface on each device and connect the two stateful failover interfaces through a failover link, or specify a dedicated VLAN (called the backup VLAN) on each device for stateful failover packets. When 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. Figure 57 Network diagram for portal stateful failover configuration Basic concepts As shown in Figure 57, users have to pass portal authentication to access the Internet. To avoid portal service interruption caused by single point failures, deploy two access devices (Gateway A and Gateway B) and configure the portal stateful failover function so that they back up the portal online user information of each other through the failover link. If either one (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. 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 it has not synchronized the user data to the peer device yet. 148

161 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. 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 configuration task list To configure Layer 3 portal authentication: Task Specifying a portal server for Layer 3 portal authentication Configuring the local portal server Enabling Layer 3 portal authentication Remarks Required. Required. Controlling access of portal users Configuring RADIUS related attributes Configuring a portal-free rule Configuring a portal-forbidden rule Configuring an authentication source subnet Setting the maximum number of online portal users Specifying a portal authentication domain Configuring Layer 3 portal authentication to support Web proxy Specifying the NAS ID value carried in a RADIUS request Specifying NAS-Port-Type for an interface Specifying the NAS-Port-ID for an interface Specifying a NAS ID profile for an interface Specifying a source IP address for outgoing portal packets Configuring MAC-based quick portal authentication Configuring portal stateful failover Associating an SSID and AP with a portal server and an authentication domain Specifying an autoredirection URL for authenticated portal users Configuring portal detection functions Logging off portal users Configuring online Layer 3 portal user detection Configuring the portal server detection function Configuring portal user information synchronization Enabling forced logoff for user SSID switching Enabling logging for portal packets 149

162 Task Specifying the parameters to be carried in the redirection URL Enabling host identity check through DHCP snooping Configuring mandatory webpage pushing Remarks Configuration prerequisites Although the portal feature provides a solution for user identity authentication and security check, the portal feature cannot implement this solution by itself. RADIUS authentication must be configured on the access device to cooperate with the portal feature to complete user authentication. The prerequisites for portal authentication configuration are as follows: The portal server and the RADIUS server have been installed and configured properly. Local portal authentication requires no independent portal server be installed. With re-dhcp authentication, the IP address check function of the DHCP relay agent is enabled on the access device, and the DHCP server is installed and configured properly. The portal client, access device, and servers can reach each other. With RADIUS authentication, usernames and passwords of the users are configured on the RADIUS server, and the RADIUS client configurations are performed on the access device. For information about RADIUS client configuration, see "Configuring AAA." To implement extended portal functions, install and configure IMC EAD, and make sure that the ACLs configured on the access device correspond to those specified for the resources in the quarantined area and for the restricted resources on the security policy server. For information about security policy server configuration on the access device, see "Configuring AAA." For installation and configuration about the security policy server, see IMC EAD Security Policy Help. The ACL for resources in the quarantined area and that for restricted resources correspond to isolation ACL and security ACL on the security policy server. You can modify the authorized ACLs on the access device. However, your changes take effect only for portal users logging on after the modification. Specifying a portal server for Layer 3 portal authentication Perform this task to specify portal server parameters for Layer 3 portal authentication, including the portal server IP address, shared encryption key, server port, and the URL address for Web authentication. According to the networking environment, you can configure a remote portal server or a local portal server as needed. To configure a remote portal server, specify the IP address of the remote portal server. To use the local portal server of the access device, specify the IP address of a Layer 3 interface on the device as the portal server's IP address. The specified interface must be reachable to the client. Follow these guidelines when you specify a portal server for Layer 3 authentication: 150

163 The specified parameters of a portal server can be modified or deleted only if the portal server is not referenced on any interface. For local portal server configuration, the keywords key, port, and url are usually not required and, if configured, do not take effect. When using local portal servers for stateful failover in wireless environments, however, the keyword url is required and the address format must be or Which address format is used depends the protocol type (HTTP or HTTPS, configured by the portal local-server command) supported by the local portal servers. The ip-address is the virtual IP address of the VRRP group to which the downlink belongs. When a local portal server is used, the re-dhcp portal authentication mode (redhcp) can be configured but, if configured, does not take effect. The maximum number of portal servers that you can specify on the access device depends on the device model. For more information, see About the Command References for HP Unified Wired-WLAN Products. To specify a portal server for Layer 3 authentication: Step Command Remarks 1. Enter system view. system-view N/A 2. 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 ] * ipv6 ipv6-address [ key [ cipher simple ] key-string port port-id url url-string ] * } By default, no portal server is specified. The portal server name and URL string cannot contain any of the following characters: question mark (?), angle brackets (<>), backward slash (\), double quotation mark ("), single quotation mark ('), percent sign (%), ampersand (&), and pound sign (#). 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 are used during the authentication process. In a wireless network, you can bind an SSID to a set of authentication pages. The system selects authentication pages for a user in this order: the authentication pages bound with the SSID of the user, the user-defined default authentication pages, and the system default authentication pages. 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 151

164 File name rules only some of the main authentication pages, the system uses the default authentication pages for the undefined ones. For the local portal server to operate normally and steadily, use the following rules when customizing authentication pages: The names of the main authentication page files cannot be changed. You can define the names of the files other than the main authentication page files. File names and directory names are case-insensitive. Table 9 Main authentication page file names Main authentication page Logon page Logon success page Logon failure page Online page Pushed after the user gets online for online notification System busy page Pushed when the system is busy or the user is in the logon process Logoff success page File name logon.htm logonsuccess.htm logonfail.htm online.htm busy.htm logoffsuccess.htm Page request rules The local portal server supports only Get and Post requests. Get requests 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 Used when users submit username and password pairs, log on the system, and log off the system. Post request attribute rules 1. Observe the following requirements when editing a form of an authentication page: 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. The password attribute is fixed as PtPwd. Attribute PtButton is required to indicate the action that the user requests, either Logon or Logoff. A logon Post request must contain PtUser, PtPwd, and PtButton attributes. A logoff Post request must contain the PtButton attribute. 2. 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> 152

165 <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. 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> Page file compression and saving rules 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. You can transfer zip files to the device through FTP or TFTP. You must save the default authentication pages file in the root directory of the device. You can save other authentication files 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 Feb :53:31 ssid2.zip 1 -rw Feb :53:20 ssid1.zip 2 -rw Feb :53:39 ssid3.zip 3 -rw Feb :53:44 ssid4.zip 2540 KB total (1319 KB free) File size and content rules The following size and content requirements for authentication pages allows the system to push customized authentication pages smoothly: 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> 153

166 <script type="text/javascript" language="javascript" src="pt_private.js"></script> </head> <body onload="pt_init();" onbeforeunload="return pt_unload();"> <form action=logon.cgi method = post onsubmit="pt_submit()"> </body> </html> 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. 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. Redirecting authenticated users to a specific webpage To make the device automatically redirect authenticated users to a specific webpage, 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> NOTE: HP recommends using Microsoft IE 6.0 or later on the authentication clients. 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 the following configurations first: 154

167 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 loads the default authentication page file, which is supposed to be saved in the root directory of the device. Therefore, to make sure the local portal server uses the user-defined default authentication pages, you must edit and save them properly or else 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. 3. Configure a binding between one or more SSIDs and an authentication page file. 4. Configure the welcome banner of the default authentication pages of the local portal server. portal local-server { http https server-policy policy-name } portal local-server bind ssid ssidname&<1-10> file filename portal server banner banner-string By default, the local portal server does not support any protocol. By default, no binding is configured. The file to be bound to the SSIDs must exist. No welcome banner by default. In Layer 3 cross-subnet portal authentication mode, an AC cannot obtain the SSID of a client associated with an AP. In this case, the system does not support binding SSIDs to an authentication page file. For more information about SSID, see WLAN Configuration Guide. Enabling Layer 3 portal authentication You must first enable portal authentication on an access interface before it can perform portal authentication for connected clients. Configuration guidelines The destination port number that the access device uses for sending unsolicited packets to the portal server must be the same as the port number that the remote portal server actually uses. The portal server and its parameters can be deleted or modified only when the portal server is not referenced by any interface. Cross-subnet authentication mode (portal server server-name method layer3) does not require Layer 3 forwarding devices between the access device and the authentication clients. However, if Layer 3 forwarding devices exist between the authentication client and the access device, you must select the cross-subnet portal authentication mode. In re-dhcp authentication mode, a client can use a public IP address to send packets before passing portal authentication. However, responses to the packets are restricted. 155

168 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. Configuration prerequisites Before enabling Layer 3 portal authentication on an interface, make sure that: An IP address is configured for the interface. The portal server to be referenced on the interface exists. Configuration procedure To enable Layer 3 portal authentication: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Enable Layer 3 portal authentication on the interface. interface interface-type interface-number portal server server-name method { direct layer3 redhcp } The interface must be a Layer 3 interface. Not enabled by default. Controlling access of portal users Configuring a portal-free rule A portal-free rule allows specified users to access specified external websites without portal authentication. The matching items for a portal-free rule include the source and destination IP address, TCP/UDP port number, source MAC address, inbound interface, and VLAN. Packets matching a portal-free rule do not trigger portal authentication, so users sending the packets can directly access the specified external websites. Configuration guidelines If you specify both a VLAN and an interface in a portal-free rule, the interface must belong to the VLAN. Otherwise, the rule does not take effect. You cannot configure two or more portal-free rules with the same filtering criteria. Otherwise, the system prompts that the rule already exists. Regardless of whether portal authentication is enabled or not, you can only add or remove a portal-free rule. You cannot modify it. Configuration procedure To configure a portal-free rule: Step Command Remarks 1. Enter system view. system-view N/A 156

169 Step Command Remarks 2. Configure a portal-free rule. To configure an IPv4 portal-free rule: portal free-rule rule-number { destination { any ip { ip-address mask { mask-length mask } any } [ tcp tcp-port-number udp udp-port-number ] hostname hostname } source { any [ { interface interface-type interface-number wlan ssid ssid [ spot spot ] } ip { ip-address mask { mask-length mask } any } [ tcp tcp-port-number udp udp-port-number ] mac mac-address vlan vlan-id ] * } } * 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 wlan ssid ssid [ spot spot ] } ipv6 { ipv6-address prefix-length any } mac mac-address vlan vlan-id ] * } } * Configure at least one command. Configuring a portal-forbidden rule A portal forbidden rule can deny users' access to some specific resources. It contains such criteria as IP address, domain name, TCP port number, or UDP port number. Any packet that matches the rule cannot be forwarded. To configure a portal-forbidden rule: Step Command 1. Enter system view. system-view 2. Configure a portal-forbidden rule. portal forbidden-rule rule-number destination { ip { hostname ip-address [ mask { mask-length netmask } ] } { { tcp udp } port-number } } * Configuring an authentication source subnet By configuring authentication source subnets, you specify that only HTTP packets from users on the authentication source subnets can trigger portal authentication. If an unauthenticated user is not on any authentication source subnet, the access device discards all the user's HTTP packets that do not match any portal-free rule. Configuration of authentication source subnets applies to only cross-subnet authentication. In direct authentication mode, the authentication source subnet is /0. 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. 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 157

170 Step Command Remarks 3. Configure an authentication source subnet. portal auth-network { ipv4-network-address { mask-length mask } ipv6 ipv6-network-address prefix-length } By default, the authentication source IPv4 and IPv6 subnets are /0 and ::/0, respectively, which mean that users from any subnets must pass portal authentication. You can configure up to 32 authentication source subnets by executing the portal auth-network command. Setting the maximum number of online portal users You can use this feature to control the total number of online portal users in the system. If the maximum number of online portal you set is less than that of the current online portal users, the limit can be set successfully and does not impact the online portal users, but the system does not allow new portal users to log on until the number drops down below the limit. To set the maximum number of online portal users allowed in the system: Step Command Remarks 1. Enter system view. system-view N/A 2. Set the maximum number of online portal users. portal max-user max-number The default maximum number of online portal users allowed depends on the device model. For more information, see About the Command References for HP Unified Wired-WLAN Products. Specifying a portal authentication domain After you specify an authentication domain for portal users on an interface, the device uses the authentication domain for AAA of all portal users on the interface, ignoring the domain names carried in the usernames. This allows you to specify different authentication domains for different interfaces as needed. To specify the authentication domain for portal users on an interface: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Specify an authentication domain for portal users on the interface. interface interface-type interface-number portal domain [ ipv6 ] domain-name N/A By default, no authentication domain is specified for portal users. The device selects the authentication domain for a portal user on an interface in this order: the authentication domain specified for the interface, the authentication domain carried in the username, and the system default authentication domain. For information about the default authentication domain, see "Configuring AAA." 158

171 Configuring Layer 3 portal authentication to support Web proxy By default, only HTTP requests from non-proxy users can trigger Layer 3 portal authentication. Proxied HTTP requests cannot trigger Layer 3 portal authentication, and they are silently dropped. To allow such HTTP requests to trigger portal authentication, configure the port numbers of the Web proxy servers on the device. Configuration prerequisites Different clients may have different Web proxy configurations. The following prerequisites must be met for these clients to trigger portal authentication: Web proxy configuration on clients Scenario 1: All or some clients use a Web proxy, and the portal server's IP address is not a proxy exception. Scenario 2: All or some clients use a Web proxy, and the portal server's IP address is a proxy exception. Scenario 3: All clients use a Web proxy server, but only some clients specify the portal server's IP address as a proxy exception. Configuration prerequisites If you use an IMC portal server, perform the following configurations on the IMC portal server: Select NAT as the type of the IP group associated with the portal device. Specify the proxy server's IP address as the IP address after NAT. Configure the port group to support NAT The portal server and the Web proxy server have IP connectivity to each other. If you use an IMC portal server, configure the IP group and port group to not support NAT. If you use an IMC portal server, add the client IP addresses to two IP groups according to whether the portal server's IP address is a proxy exception, and then configure the IP groups and the port group according to scenarios 1 and 2. The portal server and the Web proxy server have IP connectivity to each other. Configuration procedure To configure Layer 3 portal authentication to support a Web proxy: Step Command Remarks 1. Enter system view. system-view N/A 2. Add a Web proxy server port number. portal web-proxy port port-number By default, no Web proxy server port number is configured, and proxied HTTP requests cannot trigger portal authentication. If a user's browser uses the WPAD protocol to discover Web proxy servers, add the port numbers of the Web proxy servers on the device, and configure portal-free rules to allow user packets destined for the IP address of the WPAD server to pass without authentication. 159

172 If the Web proxy server port 80 is added on the device, clients that do not use a proxy server can trigger portal authentication only when they access a reachable host enabled with the HTTP service. Authorized ACLs to be assigned to users who have passed portal authentication must contain a rule that permits the Web proxy server's IP address. Otherwise, the users cannot receive heartbeat packets from the remote portal server. Configuring RADIUS related attributes Specifying the NAS ID value carried in a RADIUS request If the device uses a RADIUS server for authentication, authorization, and accounting of portal users, when a portal user logs on from an interface, the device sends a RADIUS request that carries the NAS-Identifier attribute to the RADIUS server. The RADIUS server uses the NAS-Identifier attribute in the RADIUS request to identify the device. You can specify the NAS-identifier attribute value to be carried in a RADIUS request in system view or interface view. The device prefers the value specified in interface view. If no NAS ID is configured for the interface, the device uses the NAS ID configured in system view. To specify the NAS ID value carried in a RADIUS request: Step Command Remarks 1. Enter system view. system-view N/A 2. Specify the NAS ID value carried in a RADIUS request. In system view: portal nas-id nas-identifier In interface view: a. interface interface-type interface-number b. portal nas-id nas-identifier. By default, the device name configured by the sysname command is used as the NAS ID. For information about the sysname command, see Fundamentals Command Reference. Specifying NAS-Port-Type for an interface NAS-Port-Type is a standard RADIUS attribute for indicating a user access port type. With this attribute specified on an interface, when a portal user logs on from the interface, the device uses the specified NAS-Port-Type value as that in the RADIUS request to be sent to the RADIUS server. If NAS-Port-Type is not specified, the device uses the access port type obtained. If there are multiple network devices between the Broadband Access Server (the portal authentication access device) and a portal client, the BAS may not be able to obtain a user's correct access port information. 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: 160

173 Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Specify the NAS-Port-Type value for the interface. interface interface-type interface-number portal nas-port-type { ethernet wireless } N/A Not configured by default. Specifying the NAS-Port-ID for an interface If the device uses a RADIUS server for authentication, authorization, and accounting of portal users, when a portal user logs on from an interface, the device sends a RADIUS request that carries the NAS-Port-ID attribute to the RADIUS server. The portal server configuration determines the usage of the NAS-Port-ID attribute. To specify the NAS-Port-ID value carried in a RADIUS request sent from an interface: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Configure the NAS-Port-ID value. interface interface-type interface-number portal nas-port-id nas-port-id-value N/A By default, no NAS-Port-ID value is specified for an interface, and the device uses the information obtained from the physical interface where the portal user accesses as the NAS-Port-ID value in a RADIUS request. Specifying a NAS ID profile for an interface In some networks, user access points are identified by their access VLANs. Network carriers need to use NAS-identifiers to identify user access points. With the NAS ID profile specified on an interface, when a user logs in from the interface, the access device checks the specified profile to obtain the NAS ID that is bound with the access VLAN. The value of this NAS ID is used as the NAS-identifier attribute in the RADIUS packets to be sent to the RADIUS server. The NAS ID profile defines the binding relationship between VLANs and NAS IDs. A NAS ID-VLAN binding is defined by the nas-id id-value bind vlan vlan-id command, which is described in detail in AAA configuration commands in the Security Command Reference. If no NAS-ID profile is specified for an interface or no matching binding is found in the specified profile: If the NAS ID is configured using the portal nas-id command, the device uses the configured NAS ID as that of the interface. If the interface has no NAS ID configured, the device uses the device name as the interface NAS ID. To configure a NAS ID profile on an interface: 161

174 Step Command Remarks 1. Enter system view. system-view N/A 2. Create a NAS ID profile and enter NAS ID profile view. 3. Bind a NAS ID with a VLAN. aaa nas-id profile profile-name nas-id nas-identifier bind vlan vlan-id For more information about the command, see Security Command Reference. For more information about the command, see Security Command Reference. 4. Return to system view. quit N/A 5. Enter interface view. 6. Specify a NAS ID profile for the interface. interface interface-type interface-number portal nas-id-profile profile-name N/A By default, an interface is specified with no NAS ID profile. Specifying a source IP address for outgoing portal packets After you specify a source IP address for outgoing portal packets on an interface, the IP address is used as the source IP address of packets that the access device sends to the portal server, and the destination IP address of packets that the portal server sends to the access device. To specify a source IP address for outgoing portal packets: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Specify a source IP address for outgoing portal packets. interface interface-type interface-number portal nas-ip { ipv4-address ipv6 ipv6-address } N/A By default, no source IP address is specified, and the IP address of the user logon interface is used as the source IP address of outgoing portal packets. In NAT environments, HP recommends specifying the interface's public IP address as the source IP address of outgoing portal packets. Configuring MAC-based quick portal authentication To configure MAC-based quick portal authentication (MAC-triggered authentication), you must complete the following tasks: Configure basic Layer 3 portal authentication. Specify the IP address and port number of a MAC binding server. 162

175 Enable MAC-triggered authentication on the interface enabled with portal authentication. Specify the MAC binding server as a portal server. For configuration information, see "Specifying a portal server for Layer 3 portal authentication." After MAC-triggered authentication takes effect, the access device checks a user's traffic at a specific interval (specified by the period period-value option). Before the user traffic reaches the threshold (specified by the threshold threshold-value option), the user can access the external network without authentication. When the user traffic reaches the threshold, the device performs MAC-triggered authentication. To configure MAC-triggered authentication: Step Command Remarks 1. Enter system view. system-view N/A 2. Specify a MAC binding server. 3. Enter interface view. 4. Enable MAC-triggered authentication. 5. () Configure the NAS-Port-Type value carried in RADIUS accounting requests. portal mac-trigger server ip ip-address [ port port-number ] interface interface-type interface-number portal mac-trigger enable [ period period-value ] [ threshold threshold-value ] portal mac-trigger nas-port-type value By default, no MAC binding server is specified. N/A By default, MAC-triggered authentication is disabled. By default, the port link type determines the NAS-Port-Type value. Configuring portal stateful failover CAUTION: Specifying or changing the device ID of a device will log off all online users on the device. Therefore, configure the device ID only when necessary and, after the configuration, save the configuration and restart the device. When two devices are running in stateful failover mode (one active, the other standby), do not delete the configured backup source IP addresses. Otherwise, online users on the backup may not be able to receive packets from the server. Support for this feature depends on the device model. For more information, see About the Configuration Guides for HP Unified Wired-WLAN Products. 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: Specify an interface for backing up portal services, which is referred to as 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 the device ID of the local device is different from that of the peer device. 163

176 Specify the backup source IP address for outgoing RADIUS packets 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 on the VLAN interface. For related configuration, see High Availability Configuration Guide. After the stateful failover 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. Configuration guidelines 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, information about 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. 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. Configuration procedure To configure stateful failover: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Specify the portal group to which the portal service backup interface belongs. interface interface-type interface-number portal backup-group group-id N/A By default, the portal service backup interface does not belong to any portal group. The portal service backup interfaces on the two devices for stateful failover must belong to the same portal group. 4. Return to system view. quit N/A 5. Specify the device ID in stateful failover mode. nas device-id device-id By default, the device ID is 1. For more information about the command, see Security Command Reference. 164

177 Step Command Remarks Use either method. 6. Specify a backup source IP address for outgoing RADIUS packets. Method 1: radius nas-backup-ip ip-address Method 2: a. radius scheme radius-scheme-name b. nas-backup-ip ip-address By default, no backup source IP address is specified. 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. Associating an SSID and AP with a portal server and an authentication domain After you associate an SSID and AP with a portal server and an authentication domain, the device looks up the associations for the SSID and AP the user uses when a wireless user attempts to access external network. If no match is found, the device uses the portal server specified when portal authentication is enabled on the user connected interface, and the authentication domain configured in system view. To make the association effective, make sure the specified portal server and authentication domain already exist, and configure a portal-free rule so that the portal server can receive the packets from the device. The AP name configured on the AC must be consistent with the NAS ID or NAS port ID configured in AP template view or radio view. If you configure both NAS ID and NAS port ID, the AP name must be consistent with the NAS port ID. To associate an SSID and AP with a portal server and an authentication domain: Step Command Remarks 1. Enter system view. system-view N/A 2. Associate an SSID and AP name with a portal server and an authentication domain. portal wlan ssid ssid-name [ spot spot-name ] server server-name [ domain domain-name ] By default, an SSID and AP name are not associated with any portal server or authentication domain. Specifying an autoredirection URL for authenticated portal users If you specify an autoredirection URL on the access device, after an unauthenticated user passes portal authentication through the portal authentication page, the access device redirects the user to the URL after a specific period of time. When no autoredirection URL is specified for authenticated portal users, an authenticated user is usually redirected to the URL the user entered in the address bar before portal authentication. However, with 165

178 local portal authentication, if the URL a user entered 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 use this feature for remote Layer 3 portal authentication, the portal server must be an IMC portal server that supports the page auto-redirection function. To specify an autoredirection URL for authenticated portal users: Step Command Remarks 1. Enter system view. system-view N/A 2. Specify an autoredirection URL for authenticated portal users. portal redirect-url url-string [ wait-time period ] By default, an authenticated user is redirected to the URL the user typed in the address bar before portal authentication. The wait-time period option is effective only on local portal authentication. Configuring portal detection functions Configuring online Layer 3 portal user detection This feature is available only for the direct portal authentication configured on a Layer 3 interface. With online portal user detection enabled on an interface, the device periodically sends probe packets (ARP requests) to the portal users on the interface to check whether the portal users are still online, to find portal users who get offline without logging off. If the device receives a reply from a portal user before sending probe packets to the portal user for the maximum number of times, it considers that the portal user is online and keeps sending probe packets to the portal user. If the device receives no reply from a portal user after sending probe packets to the portal user for the maximum number of times, it considers that the portal user is offline, stops sending probe packets to the portal user, and deletes the user. To configure online Layer 3 portal user detection: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Configure online Layer 3 portal user detection. interface interface-type interface-number access-user detect type arp retransmit number interval interval N/A Not configured by default. In stateful failover mode, the actual interval for sending probe packets is the sum of probe intervals configured on the two devices. NOTE: Adjust the maximum number of transmission attempts and the interval of sending probe packets according to the actual network conditions. 166

179 Configuring the portal server detection function During portal authentication, if the communication between the access device and portal server is broken, new portal users are not able to log on and the online portal users are not able to log off normally. To address this problem, the access device needs to be able to detect the reachability changes of the portal server quickly and take corresponding actions to deal with the changes. For example, once detecting that the portal server is unreachable, the access device allows portal users to access network resources without authentication. This function is referred to as portal authentication bypass. It allows for flexible user access control. With the portal server detection function, the device can detect the status of a specific portal server. The specific configurations include: 1. Detection methods (you can choose either or both) Probing HTTP connections The access device periodically sends TCP connection requests to the HTTP service port of the portal servers configured on its interfaces. If the TCP connection with a portal server can be established, the access device considers that the probe succeeds (the HTTP service of the portal server is open and the portal server is reachable). If the TCP connection cannot be established, the access device considers that the probe fails and the portal server is unreachable. Probing portal heartbeat packets A portal server that supports the portal heartbeat function (only the IMC portal server supports this function) sends portal heartbeat packets to portal access devices periodically. If an access device receives a portal heartbeat packet or an authentication packet within a probe interval, the access device considers that the probe succeeds and the portal server is reachable. Otherwise, it considers that the probe fails and the portal server is unreachable. 2. Probe parameters Probe interval Interval at which probe attempts are made. Maximum number of probe attempts Maximum number of consecutive probe attempts allowed. If the number of consecutive probes reaches this value, the access device considers that the portal server is unreachable. 3. Actions to be taken when the server reachability status changes (you can choose one or more) Sending a trap message When the status of a portal server changes, the access device sends a trap message to the NMS. The trap message contains the portal server name and the current state of the portal server. Sending a log When the status of a portal server changes, the access device sends a log message. The log message indicates the portal server name and the current state and original state of the portal server. Disabling portal authentication (enabling portal authentication bypass) When the device detects that a portal server is unreachable, it disables portal authentication on the interfaces that use the portal server (allows all portal users on the interfaces to access network resources). When the device receives from the portal server portal heartbeat packets or authentication packets (such as logon requests and logout requests), it re-enables the portal authentication function. You can configure any combination of the configuration items described as needed, with respect to the following: 167

180 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. The portal authentication bypass function is not supported on an interface where different portal servers are specified for different SSID-and-AP associations. To configure the portal server detection function: Step Command Remarks 1. Enter system view. system-view N/A 2. Configure the portal server detection function. portal server server-name server-detect method { http portal-heartbeat } * action { log permit-all trap } * [ interval interval ] [ retry retries ] Not configured by default. The portal server specified in the command must exist and must be an IPv4 portal server. The portal heartbeat detection method works only when the portal server supports the portal server heartbeat function. Only the IMC portal server supports the portal server heartbeat function. To implement detection with this method, you also need to configure the portal server heartbeat function on the IMC portal server and make sure that the product of interval and retry is greater than or equal to the portal server heartbeat interval. HP recommends configuring the interval to be greater than the portal server heartbeat interval configured on the portal server. Configuring portal user information synchronization Once the device loses communication with a portal server, the portal user information on the device and that on the portal server may be inconsistent after the communication resumes. To solve this problem, the device provides the portal user information synchronization function. This function is implemented by sending and detecting the portal synchronization packet. The process is as follows: 1. The portal server sends the online user information to the access device in a user synchronization packet at the user heartbeat interval, which is set on the portal server. 2. Upon receiving the user synchronization packet, the access device checks the user information carried in the packet with its own. If the device finds a nonexistent user in the packet, it informs the portal server of the information, and the portal server deletes the user. If the device finds that one of its users does not appear in the user synchronization packets within N consecutive synchronization probe intervals (N is equal to the value of retries configured in the portal server user-sync command), it considers that the user does not exist on the portal server and logs the user off. To configure the portal user information synchronization function: Step Command Remarks 1. Enter system view. system-view N/A 168

181 Step Command Remarks 2. Configure the portal user information synchronization function. portal server server-name user-sync [ interval interval ] [ retry retries ] Not configured by default. The portal server specified in the command must exist and must be an IPv4 portal server. This function can take effect only when the specified portal server is referenced on the interface connecting the users. The user information synchronization function requires that a portal server supports the portal user heartbeat function. Only the IMC portal server supports the portal user heartbeat function. To implement the portal user synchronization function, you also need to configure the user heartbeat function on the portal server and make sure that the product of interval and retry is greater than or equal to the portal user heartbeat interval. HP recommends configuring the interval to be greater than the portal user heartbeat interval configured on the portal server. For redundant user information on the device information for users who are considered nonexistent on the portal server, the device deletes the information during the (N+1)th interval, where N is equal to the value of retries configured in the portal server user-sync command. 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 portal users: 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 } Enabling forced logoff for user SSID switching This function logs off a wireless portal user after the user switches SSIDs. To enable forced logoff for user SSID switching: Step Command Remarks 1. Enter system view. system-view N/A 2. Enable forced logoff for user SSID switching. portal wlan ssid-switch logoff By default, a wireless portal user is not logged off after switching SSIDs. Enabling logging for portal packets You can enable logging for portal packets for maintenance purposes, or disable this feature to avoid impact on the system performance. 169

182 Step Command Remarks 1. Enter system view. system-view N/A 2. Enable logging for portal packets. portal log packet By default, portal packet logging is disabled to avoid impacting system performances. Specifying the parameters to be carried in the redirection URL You can specify the following parameters that the redirection URL carries, and customize the parameter names: nas-id Carries the NAS ID parameter. nas-ip Carries the NAS IP parameter. user-mac Carries the user MAC parameter. des-encrypt Specifies DES to encrypt user MAC address in the redirection URL. If you do not specify this keyword, the redirection URL contains plaintext user MAC address. To specify the parameters to be carried in the redirection URL: Step Command Remarks 1. Enter system view. system-view N/A 2. Configure carrying parameters in the redirection URL. portal url-param include { nas-id nas-ip user-mac [ des-encrypt ] } [ param-name param-name ] By default, no parameters are carried in the redirection URL. Enabling host identity check through DHCP snooping When the device serves as a Layer 2 device, it might be unable to learn ARP entries. Therefore, the device cannot perform host identity check through ARP entries. In this scenario, you can enable host identity check through DHCP snooping entries. Only the portal users whose host information exists in the DHCP snooping entries are allowed to continue portal authentication. For more information about DHCP snooping entries, see Layer 3 Configuration Guide. To enable host identity check for portal users: Step Command Remarks 1. Enter system view. system-view N/A 2. Enable host identity check through DHCP snooping. portal host-check dhcp-snooping By default, the device performs host identity check through ARP entries. 170

183 Configuring mandatory webpage pushing With the mandatory webpage pushing function configured on an interface, a user's first Web request is redirected to a specific webpage. Then, the user can access network resources normally. After a specific period of time, if the user sends a Web access request again, the system will push the specified webpage to the user again. This function can be used, for example, by a hotel or a network carrier to push advertisement pages to customers periodically. Like portal, the mandatory webpage pushing function uses the Web request redirection mechanism to push a webpage to users, but it does not authenticate users and therefore no authentication related configuration is needed. You cannot configure both the portal function and the mandatory webpage pushing function on an interface. To configure the mandatory webpage pushing function: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Configure the mandatory webpage pushing function on the interface. interface interface-type interface-number web-redirect url url-string [ interval interval ] N/A By default, mandatory webpage pushing is disabled. After you modify the redirection URL address, online users will not be redirected to the new URL until the current redirection interval expires. Users who access Web for the first time after the modification are redirected to the new URL. Displaying and maintaining portal Task Command Remarks Display the ACLs on a specific interface. Display portal connection statistics on a specific interface or all interfaces. Display information about a portal-free rule or all portal-free rules. display portal acl { all dynamic static } interface interface-type interface-number [ { begin exclude include } regular-expression ] display portal connection statistics { all interface interface-type interface-number } [ { begin exclude include } regular-expression ] display portal free-rule [ rule-number ] [ { begin exclude include } regular-expression ] Available in any view. Available in any view. Available in any view. 171

184 Task Command Remarks Display the portal configuration of a specific interface. Display configuration information about the local portal server. Display information about a specific portal server or all portal servers. Display portal server statistics on a specific interface or all interfaces. Display TCP spoofing statistics. Display information about portal users on a specific interface or all interfaces. Clear portal connection statistics on a specific interface or all interfaces. Clear portal server statistics on a specific interface or all interfaces. display portal interface interface-type interface-number [ { begin exclude include } regular-expression ] display portal local-server [ { begin exclude include } regular-expression ] display portal server [ server-name ] [ { begin exclude include } regular-expression ] display portal server statistics { all interface interface-type interface-number } [ { begin exclude include } regular-expression ] display portal tcp-cheat statistics [ { begin exclude include } regular-expression ] display portal user { all interface interface-type interface-number } [ { begin exclude include } regular-expression ] reset portal connection statistics {all interface interface-type interface-number } reset portal server statistics { all interface interface-type interface-number } Available in any view. Available in any view. Available in any view. Available in any view. Available in any view. Available in any view. Available in user view. Available in user view. Clear TCP spoofing statistics. reset portal tcp-cheat statistics Available in user view. Portal configuration examples The configuration examples were created on the 11900/10500/ G unified wired-wlan module and might vary with device models. When configuring the 11900/10500/ G unified wired-wlan module, make sure the settings are correct (including VLAN settings) on the internal Ethernet interface that connects the module to the switch. For more information, see HP 11900/10500/ G Unified Wired-WLAN Module Basic Configuration Guide. By default, the aggregate interfaces between the access controller engine and the switching engine on an 830 switch or an 870 appliance are Access interfaces in VLAN 1. When configuring the two aggregate interfaces, make sure their permitted VLANs are the same. HP also recommends that you set their link type to be the same. 172

185 Configuring direct portal authentication Network requirements As shown in Figure 58, the wireless user (Client) belongs to VLAN 1 and the AP belongs to VLAN 3. The AC performs direct portal authentication for wireless users. Before portal authentication, the wireless user can access only the portal server. After passing portal authentication, the user can access Internet resources. Use a RADIUS server as the authentication/authorization server. Figure 58 Network diagram Portal server /24 Client /24 Gateway : /24 AP L2 switch Vlan-int /24 Vlan-int /24 RADIUS server /24 AC Configuration prerequisites and guidelines Configure IP addresses for the client, AC, and servers as shown in Figure 58, and make sure they have IP connectivity between each other. Configure the RADIUS server properly to provide authentication/authorization services for users. Configuring the portal server This section uses IMC PLAT 5.1 SP1 (E0202P05) and IMC UAM 5.1 (E0301). 1. Configure the portal server: a. Log in to IMC and click the Service tab. b. From the navigation tree, select User Access Manager > Portal Service > Server to enter the portal server configuration page, as shown in Figure 59. c. Configure the portal server parameters as needed. This example uses the default settings. d. Click OK. 173

186 Figure 59 Portal server configuration 2. Configure the IP address group: a. From the navigation tree, select User Access Manager > Portal Service > IP Group to enter the portal IP address group configuration page. b. Click Add to enter the page shown in Figure 60. c. Enter the IP group name. d. Enter the start IP address and end IP address of the IP group. Make sure that the client's IP address is in the IP group. e. Select a service group. By default, the group Ungrouped is used. f. Select the IP group type Normal. g. Click OK. Figure 60 Adding an IP address group 3. Add a portal device: a. From the navigation tree, select User Access Manager > Portal Service > Device to enter the portal device configuration page. b. Click Add to enter the page shown in Figure 61. c. Enter the device name AC. 174

187 d. Enter the IP address of the router's interface connected to the user. e. Enter the key, which must be the same as that configured on the access device (AC). f. Set whether to enable IP address reallocation. This example uses direct portal authentication. Therefore, select No from the Reallocate IP list. g. Select whether to support sever heartbeat and user heartbeat functions. In this example, select No for both Support Server Heartbeat and Support User Heartbeat. h. Click OK. Figure 61 Adding a portal device 4. Associate the portal device with the IP address group: a. As shown in Figure 62, click the icon in the Port Group column of device AC to enter the port group configuration page. Figure 62 Device list b. On the port group configuration page, click Add to enter the page shown in Figure 63. c. Enter the port group name. d. Select the configured IP address group. The client's IP address must be within this IP address group. e. Use the default settings for other parameters. f. Click OK. 175

188 Figure 63 Adding a port group 5. From the navigation tree, select User Access Manager > Service Parameters > Validate System Configuration to validate the configurations. Configuring the AC 1. Configure a RADIUS scheme: # Create a RADIUS scheme named rs1 and enter its view. <AC> system-view [AC] radius scheme rs1 # Configure the server type for the RADIUS scheme. When using the IMC server, you must configure the RADIUS server type as extended. [AC-radius-rs1] server-type extended # Specify the primary authentication/authorization server, and configure the shared key for secure communication with the server. [AC-radius-rs1] primary authentication [AC-radius-rs1] key authentication simple radius # Specify that the ISP domain name should not be included in the username sent to the RADIUS server. [AC-radius-rs1] user-name-format without-domain [AC-radius-rs1] quit 2. Configure an authentication domain: # Create an ISP domain named dm1 and enter its view. [AC] domain dm1 # Configure the ISP domain to use RADIUS scheme rs1. [AC-isp-dm1] authentication portal radius-scheme rs1 [AC-isp-dm1] authorization portal radius-scheme rs1 [AC-isp-dm1] quit 3. Configure portal authentication: # Configure the portal server as follows: Name: newpt IP address: Key: portal (in plaintext) Port number: URL: 176

189 [AC] portal server newpt ip key simple portal port url # On the interface connected to the client, specify the authentication domain dm1 for portal users and enable portal authentication. [AC] interface vlan-interface 1 [AC Vlan-interface1] portal domain dm1 [AC Vlan-interface1] portal server newpt method direct [AC Vlan-interface1] quit Configuring re-dhcp portal authentication Network requirements As shown in Figure 64, the wireless user (Client) belongs to VLAN 10 and AP belongs to VLAN 3. The AC performs re-dhcp authentication for wireless users. The client obtains an IP address from the DHCP server. Before portal authentication, the DHCP server assigns a private IP address to the client. After the client passes portal authentication, it gets a public IP address from the DHCP server and can access Internet resources. Use a RADIUS server as the authentication/authorization server. On the IMC, specify the internal subnet as the authentication subnet. Figure 64 Network diagram Configuration prerequisites and guidelines Configure IP addresses for the AC and servers as shown in Figure 64, and make sure that the client, AC, and servers have IP connectivity between each other. Configure the RADIUS server to provide authentication/authorization services for users. Configure a public address pool ( /24, in this example) and a private address pool ( /24, in this example) on the DHCP server. The configuration steps are omitted. For more information about DHCP configuration information, see Layer 3 Configuration Guide. Configure the AC as a DHCP relay agent and configure a primary IP address (a public IP address) and a secondary IP address (a private IP address) for the portal-enabled interface. Configuration procedure 1. Configure a RADIUS scheme on the AC: 177

190 # Create a RADIUS scheme named rs1, and enter its view. <AC> system-view [AC] radius scheme rs1 # Set the server type for the RADIUS scheme. When using the IMC server, you must set the server type to extended. [AC-radius-rs1] server-type extended # Specify the primary authentication/authorization server, and configure the shared key for secure communication with the server. [AC-radius-rs1] primary authentication [AC-radius-rs1] key authentication simple radius # Specify that the ISP domain name should not be included in the username sent to the RADIUS server. [AC-radius-rs1] user-name-format without-domain [AC-radius-rs1] quit 2. Configure an authentication domain on the AC: # Create an ISP domain named dm1 and enter its view. [AC] domain dm1 # Configure the ISP domain to use RADIUS scheme rs1. [AC-isp-dm1] authentication portal radius-scheme rs1 [AC-isp-dm1] authorization portal radius-scheme rs1 [AC-isp-dm1] quit 3. Configure portal authentication on the AC: # Configure the portal server as follows: Name: newpt IP address: Key: portal (in plaintext) Port number: URL: [AC] portal server newpt ip key simple portal port url # Configure the AC as a DHCP relay agent, and enable the invalid address check function. [AC] dhcp enable [AC] dhcp relay server-group 0 ip [AC] interface vlan-interface 10 [AC Vlan-interface10] ip address [AC Vlan-interface10] ip address sub [AC-Vlan-interface10] dhcp select relay [AC-Vlan-interface10] dhcp relay server-select 0 [AC-Vlan-interface10] dhcp relay address-check enable # On the interface connected to the client, specify the authentication domain dm1 for portal users, and enable re-dhcp portal authentication. [AC-Vlan-interface10] portal domain dm1 [AC Vlan-interface10] portal server newpt method redhcp [AC Vlan-interface10] quit 178

191 Configuring direct portal authentication with extended functions Network requirements As shown in Figure 65, the wireless user (Client) belongs to VLAN 10 and the AP belongs to VLAN 3. The AC performs direct portal authentication for wireless users. If the client fails security check after it passes identity authentication, the client can access only subnet /24. After the client passes security check, the client can access Internet resources. Use a RADIUS server as the authentication/authorization server. Figure 65 Network diagram Configuration prerequisites Configure IP addresses for the client, AC, and servers as shown in Figure 65 and make sure they have IP connectivity between each other. Configure the RADIUS server to provide authentication/authorization services for users. Configuration procedure 1. Configure a RADIUS scheme on the AC: # Create a RADIUS scheme named rs1 and enter its view. <AC> system-view [AC] radius scheme rs1 # Set the server type for the RADIUS scheme. When using the IMC server, you must set the server type to extended. [AC-radius-rs1] server-type extended # Specify the primary authentication/authorization server, and configure the shared key for secure communication with the server. [AC-radius-rs1] primary authentication [AC-radius-rs1] key authentication simple radius [AC-radius-rs1] user-name-format without-domain # Configure the IP address of the security policy server. [AC-radius-rs1] security-policy-server [AC-radius-rs1] quit 179

192 2. Configure an authentication domain on the AC: # Create an ISP domain named dm1 and enter its view. [AC] domain dm1 # Configure the ISP domain to use RADIUS scheme rs1. [AC-isp-dm1] authentication portal radius-scheme rs1 [AC-isp-dm1] authorization portal radius-scheme rs1 [AC-isp-dm1] quit 3. On the AC, configure the ACL (ACL 3000) for resources on subnet /24 and the ACL (ACL 3001) for Internet resources. [AC] acl number 3000 [AC-acl-adv-3000] rule permit ip destination [AC-acl-adv-3000] quit [AC] acl number 3001 [AC-acl-adv-3001] rule permit ip [AC-acl-adv-3001] quit Make sure you specify ACL 3000 as the isolation ACL and ACL 3001 as the security ACL on the security policy server. 4. Configure extended portal authentication on the AC: # Configure the portal server as follows: Name: newpt IP address: Key: portal (in plaintext) Port number: URL: [AC] portal server newpt ip key simple portal port url # On the interface connected to the client, specify the authentication domain dm1 for portal users and enable extended portal authentication. [AC] interface vlan-interface 10 [AC Vlan-interface10] portal domain dm1 [AC Vlan-interface10] portal server newpt method direct [AC] quit Configuring re-dhcp portal authentication with extended functions Network requirements As shown in Figure 66, the wireless user (Client) belongs to VLAN 100 and AP belongs to VLAN 3. The AC performs extended re-dhcp portal authentication for users. The client obtains an IP address from the DHCP server. Before extended portal authentication, the DHCP server assigns a private IP address to the client. After passing the authentication, the client gets a public IP address. If the client fails security check after it passes identity authentication, the client can access only subnet /24. After the client passes security check, the client can access Internet resources. Use a RADIUS server as the authentication/authorization server. 180

193 Figure 66 Network diagram Portal server /24 DHCP server /24 Client AP automatically obtains an IP address L2 switch Vlan-int / /24 sub Vlan-int /24 RADIUS server /24 AC Security policy server /24 Configuration prerequisites and guidelines Configure IP addresses for the AC and servers as shown in Figure 66, and make sure the client, AC, and servers have IP connectivity between each other. Configure the RADIUS server to provide authentication and authorization services for users. Configure a public address pool ( /24, in this example) and a private address pool ( /24, in this example) on the DHCP server. (Details not shown.) Configure the AC as a DHCP relay agent and configure a primary IP address (a public IP address) and a secondary IP address (a private IP address) for the portal-enabled interface. For DHCP relay configuration information, see Layer 3 IP Services Configuration Guide. Configuration procedure 1. Configure a RADIUS scheme on the AC: # Create a RADIUS scheme named rs1 and enter its view. <AC> system-view [AC] radius scheme rs1 # Set the server type for the RADIUS scheme. When using the IMC server, set the server type to extended. [AC-radius-rs1] server-type extended # Specify the primary authentication/authorization server, and configure the shared key for secure communication with the server. [AC-radius-rs1] primary authentication [AC-radius-rs1] key authentication simple radius [AC-radius-rs1] user-name-format without-domain # Configure the IP address of the security policy server. [AC-radius-rs1] security-policy-server [AC-radius-rs1] quit 2. Configure an authentication domain on the AC: 181

194 # Create an ISP domain named dm1 and enter its view. [AC] domain dm1 # Configure the ISP domain to use RADIUS scheme rs1. [AC-isp-dm1] authentication portal radius-scheme rs1 [AC-isp-dm1] authorization portal radius-scheme rs1 [AC-isp-dm1] quit 3. On the AC, configure the ACL (ACL 3000) for resources on subnet /24 and the ACL (ACL 3001) for Internet resources. [AC] acl number 3000 [AC-acl-adv-3000] rule permit ip destination [AC-acl-adv-3000] quit [AC] acl number 3001 [AC-acl-adv-3001] rule permit ip [AC-acl-adv-3001] quit Make sure you specify ACL 3000 as the isolation ACL and ACL 3001 as the security ACL on the security policy server. 4. Configure extended portal authentication on the AC: # Configure the portal server as follows: Name: newpt IP address: Key: portal (in plaintext) Port number: URL: [AC] portal server newpt ip key simple portal port url # Configure the AC as a DHCP relay agent, and enable the invalid address check function. [AC] dhcp enable [AC] dhcp relay server-group 0 ip [AC] interface vlan-interface 100 [AC Vlan-interface100] ip address [AC Vlan-interface100] ip address sub [AC-Vlan-interface100] dhcp select relay [AC-Vlan-interface100] dhcp relay server-select 0 [AC-Vlan-interface100] dhcp relay address-check enable # On the interface connected to the client, specify the authentication domain dm1 for portal users and enable portal authentication. [AC Vlan-interface100] portal domain dm1 [AC Vlan-interface100] portal server newpt method redhcp [AC Vlan-interface100] quit 182

195 Configuring portal stateful failover Network requirements As shown in Figure 67, a failover link is present between AC 1 and AC 2. Both AC 1 and AC 2 support portal authentication. Configure stateful failover between AC 1 and AC 2 to support portal service backup and use VRRP to implement traffic switchover between the ACs. When AC 1 operates normally, Host accesses AC 1 for portal authentication before accessing the Internet. When AC 1 fails, Host accesses the Internet through AC 2. The VRRP uplink/downlink detection mechanism is used to ensure non-stop traffic forwarding. Use the RADIUS server as the authentication/authorization server. In this example, Server takes the responsibilities of the portal server and the RADIUS server. AC 1 and AC 2 use the failover link to transmit stateful failover related packets and specify VLAN 8 on the ACs as the VLAN dedicated for stateful failover related packets. Figure 67 Network diagram Server /24 L3 switch Gateway: / 24 Master Virtual IP address : /24 Backup AC 1 Vlan-int /24 Vlan-int /24 Failover link Vlan-int /24 Vlan-int / 24 AC 2 L 2 switch Client IP : /24 Gateway: /24 AP /24 Configuration prerequisites and guidelines Configure IP addresses for the client, server, and ACs as shown in Figure 67 and make sure they have IP connectivity between each other. On the authentications server, specify the access device's IP address as the virtual IP address of the VRRP group. For more information about VRRP, see High Availability Configuration Guide. You must use consistent device roles for AC stateful failover and VRRP. If you use an AC as the master for stateful failover, use the AC as the master in a VRRP group, too. Otherwise, in local portal authentication, the access device cannot push authentication pages according to the SSID. If your network cannot meet the requirement, for example, the two ACs are configured for load balancing, related portal-free rules should be configured. 183

196 For information about stateful failover configuration, see High Availability Configuration Guide. Configuring the portal server This section uses IMC PLAT 5.1 SP1 (E0202P05) and IMC UAM 5.1 (E0301). 1. Configure the portal server: a. Log in to IMC and click the Service tab. b. From the navigation tree, select User Access Manager > Portal Service > Server to enter the portal server configuration page, as shown in Figure 68. c. Configure the portal server parameters as needed. This example uses the default settings. d. Click OK. Figure 68 Portal server configuration 2. Configure the IP address group: a. From the navigation tree, select User Access Manager > Portal Service > IP Group to enter the portal IP address group configuration page. b. Click Add to enter the page shown in Figure 69. c. Enter the IP group name. d. Enter the start IP address and end IP address of the IP group. Make sure that the client's IP address is in the IP group. e. Select a service group. By default, the group Ungrouped is used. f. Select the IP group type Normal. g. Click OK. 184

197 Figure 69 Adding an IP address group 3. Add a portal device: a. From the navigation tree, select User Access Manager > Portal Service > Device to enter the portal device configuration page. b. Click Add to enter the page shown in Figure 70. c. Enter the device name AC. d. Enter the virtual IP address of the VRRP group that holds the portal-enabled interface. e. Enter the key, which must be the same as that configured on the ACs. f. Set whether to enable IP address reallocation. This example uses direct portal authentication. Therefore, select No from the Reallocate IP list. g. Set whether to support the portal server heartbeat and user heartbeat functions. In this example, select No for both Support Server Heartbeat and Support User Heartbeat. h. Click OK. Figure 70 Adding a portal device 4. Associate the portal device with the IP address group: a. As shown in Figure 71, click the icon in the Port Group column of device AC to enter the port group configuration page. Figure 71 Device list 185

198 b. On the port group configuration page, click Add to enter the page shown in Figure 72. Perform the following configurations. c. Enter the port group name. d. Select the configured IP address group. The client's IP address must be within this IP address group. e. Use the default settings for other parameters. f. Click OK. Figure 72 Adding a port group Configuring AC 1 5. From the navigation tree, select User Access Manager > User Access Manager > Service Parameters > Validate System Configuration to validate the configurations. 1. Configure VRRP: # Create a VRRP group, and configure the virtual IP address of the VRRP group as <AC1> system-view [AC1] interface vlan-interface 20 [AC1 Vlan-interface20] vrrp vrid 1 virtual-ip # Set the priority of VLAN-interface 20 in the VRRP group to 200. [AC1 Vlan-interface20] vrrp vrid 1 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 the VRRP group by 150 when the interface state of VLAN-interface 10 becomes Down or Removed. [AC1 Vlan-interface20] vrrp vrid 1 track interface vlan-interface10 reduced 150 [AC1 Vlan-interface20] quit 2. Configure a RADIUS scheme: # Create RADIUS scheme rs1 and enter its view. [AC1] radius scheme rs1 # Configure the server type for the RADIUS scheme. When using the IMC server, you must configure the RADIUS server type as extended. [AC1-radius-rs1] server-type extended # Specify the primary authentication/authorization server, and configure the shared key for secure communication with the server. [AC1-radius-rs1] primary authentication

199 [AC1-radius-rs1] key authentication 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.) [AC1-radius-rs1] user-name-format without-domain [AC1-radius-rs1] quit 3. Configure an authentication domain: # Create ISP domain dm1 and enter its view. [AC1] domain dm1 # Configure AAA methods for the ISP domain. [AC1-isp-dm1] authentication portal radius-scheme rs1 [AC1-isp-dm1] authorization portal radius-scheme rs1 [AC1-isp-dm1] quit 4. Enable portal authentication on the interface connecting the host: # Configure a portal server on AC 1. Make sure the IP address, port number and URL match those of the actual portal server. [AC1] portal server newpt ip key simple portal port url # Configure a portal-free rule on AC 1, allowing packets from AC 2 to pass through without portal authentication. This configuration is required only when the roles (master/backup) of the ACs for stateful failover are different from those for VRRP. [AC1] portal free-rule 0 source interface bridge-aggregation 1 destination any # On the interface connected to the client, specify the authentication domain dm1 for portal users and enable portal authentication. [AC1] interface vlan-interface 10 [AC1 Vlan-interface10] portal domain dm1 [AC1 Vlan-interface10] portal server newpt method direct # Specify the source IP address of outgoing portal packets as , the virtual IP address of the VRRP group. [AC1 Vlan-interface10] portal nas-ip Configure portal stateful failover: # Assign interface VLAN-interface 10 to portal group 1. [AC1 Vlan-interface10] portal backup-group 1 [AC1 Vlan-interface10] quit # Set the device ID for AC 1 in stateful failover mode to 1. [AC1] nas device-id 1 # Specify the source IP address of outgoing RADIUS packets as , the virtual IP address of the VRRP group. [AC1] radius nas-ip NOTE: Make sure you add the access device with IP address on the RADIUS server. 6. Configure the WLAN service: # Specify the backup AC address. [AC1] wlan backup-ac ip # Enable hot backup. 187

200 Configuring AC 2 [AC1] hot-backup enable # Configure VLAN 8 as the VLAN for AC hot backup. [AC1] hot-backup vlan 8 [AC1] quit # Create interface WLAN-ESS 1, and add it to VLAN 10. [AC1] interface wlan-ess 1 [AC1-WLAN-ESS1] port link-type hybrid [AC1-WLAN-ESS1] port hybrid vlan 10 untagged [AC1-WLAN-ESS1] port hybrid pvid vlan 10 [AC1-WLAN-ESS1] quit # Configure a WLAN service template, and bind the WLAN service template with interface WLAN-ESS 1. [AC1] wlan service-template 1 clear [AC1-wlan-st-1] ssid abc [AC1-wlan-st-1] bind wlan-ess 1 [AC1-wlan-st-1] service-template enable [AC1-wlan-st-1] quit # Configure AP on AC 1. (Set the access priority of AP to 7. A higher value represents a higher priority. The default priority value is 4.) [AC1] wlan ap ap1 model MSM460-WW [AC1-wlan-ap-ap1] serial-id CN2AD330S8 [AC1-wlan-ap-ap1] priority level 7 [AC1-wlan-ap-ap1] radio 1 [AC1-wlan-ap-ap1-radio-1] service-template 1 [AC1-wlan-ap-ap1-radio-1] radio enable [AC1-wlan-ap-ap1-radio-1] quit [AC1-wlan-ap-ap1] quit 7. Configure the stateful failover function: # Configure the VLAN for stateful failover as VLAN 8. [AC1] dhbk vlan 8 # Enable stateful failover and configure it to support the symmetric path. [AC1] dhbk enable backup-type symmetric-path 1. Configure VRRP: # Create a VRRP group, and configure the virtual IP address of the VRRP group as [AC2] system-view [AC2] interface vlan-interface 20 [AC2 Vlan-interface20] vrrp vrid 1 virtual-ip # Set the priority of VLAN-interface 20 in the VRRP group to 150. [AC2 Vlan-interface20] vrrp vrid 1 priority 150 [AC2 Vlan-interface20] quit 2. Configure a RADIUS scheme: # Create RADIUS scheme rs1 and enter its view. [AC2] radius scheme rs1 188

201 # Configure the server type for the RADIUS scheme. When using the IMC server, you must configure the RADIUS server type as extended. [AC2-radius-rs1] server-type extended # Specify the primary authentication/authorization server, and configure the shared key for secure communication with the server. [AC2-radius-rs1] primary authentication [AC2-radius-rs1] key authentication simple expert # Configure the access device to not carry the ISP domain name in the username sent to the RADIUS server. ( Configure the username format as needed.) [AC2-radius-rs1] user-name-format without-domain [AC2-radius-rs1] quit 3. Configure an authentication domain: # Create ISP domain dm1 and enter its view. [AC2] domain dm1 # Configure AAA methods for the ISP domain. [AC2-isp-dm1] authentication portal radius-scheme rs1 [AC2-isp-dm1] authorization portal radius-scheme rs1 [AC2-isp-dm1] quit 4. Enable portal authentication on the interface connecting the host: # Configure the portal server as needed. [AC2] portal server newpt ip key simple portal port url # Configure a portal-free rule on AC 2, allowing packets from AC 1 to pass through without portal authentication. This configuration is required only when the roles (master/backup) of the ACs for stateful failover are different from those for VRRP. [AC2] portal free-rule 0 source interface bridge-aggregation 1 destination any # On the interface connected to the client, specify the authentication domain dm1 for portal users and enable portal authentication. [AC2] interface vlan-interface 10 [AC2-Vlan-interface10] portal domain dm1 [AC2 Vlan-interface10] portal server newpt method direct # Specify the source IP address of outgoing portal packets as , the virtual IP address of the VRRP group. [AC2 Vlan-interface10] portal nas-ip Configure portal stateful failover: # Assign interface VLAN-interface 10 to portal group 1. [AC2 Vlan-interface10] portal backup-group 1 [AC2 Vlan-interface10] quit # Set the ID of the device in the stateful failover mode to 2. [AC2] nas device-id 2 # Specify the source IP address of outgoing RADIUS packets as , the virtual IP address of the VRRP group. [AC2] radius nas-backup-ip

202 NOTE: Make sure that you have added the access device with IP address on the RADIUS server. 6. Configure the WLAN service: # Specify the backup AC address. [AC2] wlan backup-ac ip # Enable hot backup. [AC2] hot-backup enable # Configure VLAN 8 as the VLAN for AC hot backup. [AC2] hot-backup vlan 8 [AC2] quit # Create interface WLAN-ESS 1, and add it to VLAN 10. [AC2] interface wlan-ess 1 [AC2-WLAN-ESS1] port link-type hybrid [AC2-WLAN-ESS1] port hybrid vlan 10 untagged [AC2-WLAN-ESS1] port hybrid pvid vlan 10 [AC2-WLAN-ESS1] quit # Configure a WLAN service template, and bind the WLAN service template with interface WLAN-ESS 1. [AC2] wlan service-template 1 clear [AC2-wlan-st-1] ssid abc [AC2-wlan-st-1] bind wlan-ess 1 [AC2-wlan-st-1] service-template enable [AC2-wlan-st-1] quit # Configure AP on AC 2, using the default access priority of 4 for the AP. [AC2] wlan ap ap1 model MSM460-WW [AC2-wlan-ap-ap1] serial-id CN2AD330S8 [AC2-wlan-ap-ap1] radio 1 [AC2-wlan-ap-ap1-radio-1] service-template 1 [AC2-wlan-ap-ap1-radio-1] radio enable [AC2-wlan-ap-ap1-radio-1] quit [AC2-wlan-ap-ap1] quit 7. Configure stateful failover: # Configure the VLAN for stateful failover as VLAN 8. [AC2] dhbk vlan 8 # Enable stateful failover and configure it to support the symmetric path. [AC2] dhbk enable backup-type symmetric-path Verifying the configuration # After the client logs in through AC 1, display the user authentication information by using the display portal user command on AC 1 and AC 2, respectively. [AC1] display portal user all Index:3 State:ONLINE SubState:NONE ACL:NONE 190

203 Work-mode: primary MAC IP Vlan Interface d-88f8-0eac Vlan-interface10 Total 1 user(s) matched, 1 listed. [AC2] display portal user all Index:2 State:ONLINE SubState:NONE ACL:NONE Work-mode: secondary MAC IP Vlan Interface d-88f8-0eac Vlan-interface10 Total 1 user(s) matched, 1 listed. The output shows that the portal information of the client is stored on both AC 1 and AC 2. The user mode is primary on AC 1 and secondary on AC 2, indicating that the client logged in from AC 1 and the client's authentication information has been synchronized to AC 2. Configuring portal server detection and portal user information synchronization Network requirements As shown in Figure 73, a wireless client (in VLAN 10) is connected to the access device (AC) and must pass portal authentication to access the Internet. Use a RADIUS server as the authentication/authorization server. Detailed requirements are as follows: Configure a public IP address for the client or configure the client to obtain a public IP address from the DHCP server. Before passing portal authentication, the client can access only the portal server. After passing portal authentication, the client can access the Internet. The access device (AC) can detect whether the portal server is reachable and send trap messages upon state changes. When the portal server is unreachable due to, for example, a connection failure, network device failure, or portal server failure, the access device can disable portal authentication, allowing users to access the Internet without authentication. The access device can synchronize portal user information with the portal server periodically. 191

204 Figure 73 Network diagram Configuration considerations Configure the portal server and enable portal server heartbeat function and the portal user heartbeat function. Configure the RADIUS server to implement authentication and authorization. Configure direct portal authentication on interface VLAN-interface 10, which is connected to the client. 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. 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. Configuration prerequisites Configure IP addresses for the client, AP, AC, and servers as shown in Figure 73, and make sure they have IP connectivity between each other. Configure the RADIUS server to provide authentication and authorization services for users. Configuring the portal server This section uses IMC PLAT 5.1 SP1 (E0202P05) and IMC UAM 5.1 (E0301). 1. Configure the portal server: a. Log in to the IMC management platform and click the Service tab. b. From the navigation tree, select User Access Manager > Portal Service > Server to enter the portal server configuration page, as shown in Figure 74. c. Configure the portal server heartbeat interval and user heartbeat interval. d. Use default values for other parameters. e. Click OK. 192

205 Figure 74 Portal server configuration 2. Configure the IP address group: a. From the navigation tree, select User Access Manager > Portal Service > IP Group to enter the portal IP address group configuration page. b. Click Add to enter the page shown in Figure 75. c. Enter the IP group name. d. Enter the start IP address and end IP address of the IP group. Make sure the client's IP address is in the IP group. e. Select a service group. By default, the group Ungrouped is used. f. Select the IP group type Normal. g. Click OK. Figure 75 Adding an IP address group 3. Add a portal device: a. From the navigation tree, select User Access Manager > Portal Service > Device to enter the portal device configuration page. b. Click Add to enter the page shown in Figure 76. c. Enter the device name AC. 193

206 d. Enter the IP address of the AC's interface connected to the user. e. Enter the key, which must be the same as that configured on the AC. f. Set whether to enable IP address reallocation. This example uses direct portal authentication. Therefore, select No from the Reallocate IP list. g. Select Yes for both Support Server Heartbeat and Support User Heartbeat. h. Click OK. Figure 76 Adding a portal device 4. Associate the portal device with the IP address group: a. As shown in Figure 77, click the icon in the Port Group column of device AC to enter the port group configuration page. Figure 77 Device list b. On the port group configuration page, click Add to enter the page shown in Figure 78. Perform the following configurations: c. Enter the port group name. d. Select the configured IP address group. The IP address used by the user to access the network must be within this IP address group. e. Use the default settings for other parameters. f. Click OK. 194

207 Figure 78 Adding a port group 5. From the navigation tree, select User Access Manager > Service Parameters > Validate System Configuration to validate the configurations. Configuring the AC 1. Configure a RADIUS scheme: # Create RADIUS scheme rs1 and enter its view. <AC> system-view [AC] radius scheme rs1 # Configure the server type for the RADIUS scheme. When using the IMC server, you must configure the RADIUS server type as extended. [AC-radius-rs1] server-type extended # Specify the primary authentication/authorization server, and configure the shared key for secure communication with the server. [AC-radius-rs1] primary authentication [AC-radius-rs1] key authentication simple radius # Configure the access device to not carry the ISP domain name in the username sent to the RADIUS server. [AC-radius-rs1] user-name-format without-domain [AC-radius-rs1] quit 2. Configure an authentication domain: # Create ISP domain dm1 and enter its view. [AC] domain dm1 # Configure AAA methods for the ISP domain. [AC-isp-dm1] authentication portal radius-scheme rs1 [AC-isp-dm1] authorization portal radius-scheme rs1 [AC-isp-dm1] quit 3. Configure portal authentication: # Configure a portal server on the AC, making sure the IP address, port number and URL match those of the actual portal server. [AC] portal server newpt ip key simple portal port url # On the interface connected to the client, specify the authentication domain dm1 for portal users and enable portal authentication. 195

208 [AC] interface vlan-interface 10 [AC Vlan-interface10] portal domain dm1 [AC Vlan-interface10] portal server newpt method direct [AC Vlan-interface10] 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 100 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. [AC] portal server newpt server-detect method portal-heartbeat action trap permit-all interval 100 retry 2 NOTE: 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. [AC] portal server newpt user-sync interval 600 retry 2 NOTE: 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. <AC> display portal server newpt Portal server: 1)newpt: IP : Port : Key : ****** URL : Status : Up The Up state of the portal server indicates that the portal server is reachable. If the AC detects that the portal server is unreachable, you can see the portal server status is Down in the output, and the AC generates a server unreachable trap "portal server newpt lost," and disables portal authentication on the access interface, so the client can access the external network without authentication. 196

209 Configuring direct portal authentication using local portal server Network requirements As shown in Figure 79, a wireless client is connected to the network through the AP. The client belongs to VLAN 2 and the AP belongs to VLAN 3. The client must pass direct portal authentication to access Internet resources. Before authentication, the client can access only the local portal server. The AC (access device) uses the local portal server that runs HTTPS to perform direct portal authentication for users. The local portal server can push customized pages according to the SSID of the user logon interface. Use a RADIUS server as the authentication/authorization server. Figure 79 Network diagram Configuration prerequisites and guidelines Configure IP addresses for the client, AC, and server as shown in Figure 79, and make sure they have IP connectivity between each other. Configure the RADIUS server properly to provide authentication and authorization services for users. Complete the PKI domain configuration, and get the local certificate and the CA certificate. For more configuration information, see "Configuring PKI." Configure the SSL server policy access-policy. For more configuration information, see "Configuring SSL." Edit the authentication page files to be bound with the client SSID. Do not configure the wireless client and the AP to be in the same subnet. Otherwise, after portal authentication is enabled for the subnet, the AP cannot establish a connection with the AC. Configuration procedure 1. Configure a RADIUS scheme on the AC: # Create a RADIUS scheme named rs1 and enter its view. <AC> system-view [AC] radius scheme rs1 # Set the server type for the RADIUS scheme. When using the IMC server, set the server type to extended. 197

210 [AC-radius-rs1] server-type extended # Specify the primary authentication/authorization server, and configure the shared key for secure communication with the server. [AC-radius-rs1] primary authentication [AC-radius-rs1] key authentication simple radius # Specify that the ISP domain name should not be included in the username sent to the RADIUS server. [AC-radius-rs1] user-name-format without-domain [AC-radius-rs1] quit 2. Configure an authentication domain on the AC: # Create an ISP domain named dm1 and enter its view. [AC] domain dm1 # Configure the ISP domain to use RADIUS scheme rs1. [AC-isp-dm1] authentication portal radius-scheme rs1 [AC-isp-dm1] authorization portal radius-scheme rs1 [AC-isp-dm1] quit 3. Configure the WLAN service on the AC: # Create interface WLAN-ESS 1 and add it to VLAN 2. [AC] interface wlan-ess 1 [AC-WLAN-ESS1] port link-type hybrid [AC-WLAN-ESS1] port hybrid vlan 2 untagged [AC-WLAN-ESS1] port hybrid pvid vlan 2 [AC-WLAN-ESS1] quit # Configure a WLAN service template, and bind the WLAN service template with the WLAN-ESS interface. [AC] wlan service-template 1 clear [AC-wlan-st-1] ssid abc [AC-wlan-st-1] bind wlan-ess 1 [AC-wlan-st-1] authentication-method open-system [AC-wlan-st-1] service-template enable [AC-wlan-st-1] quit # Configure AP on the AC. [AC] wlan ap ap1 model MSM460-WW [AC-wlan-ap-ap1] serial-id CN2AD330S8 [AC-wlan-ap-ap1] radio 1 type dot11an [AC-wlan-ap-ap1-radio-1] service-template 1 [AC-wlan-ap-ap1-radio-1] radio enable [AC-wlan-ap-ap1-radio-1] quit [AC-wlan-ap-ap1] quit 4. Configure portal authentication on the AC: # Configure the local portal server to support HTTPS and reference the configured SSL server policy access-policy. [AC] portal local-server https server-policy access-policy # Bind client SSID abc with the customized authentication page file ssid1.zip, which is saved in directory flash:/portal/ of the AC. This configuration is optional. If you do not configure the binding, the AC pushes the system default authentication pages for users. 198

211 Verifying the configuration [AC] portal local-server bind ssid abc file ssid1.zip # Configure the local portal server name as newpt and IP address as Other parameters do not need to be configured. [AC] portal server newpt ip # On VLAN-interface 2, the interface connected to the client, specify the authentication domain dm1 and portal server newpt for portal users and enable direct portal authentication. [AC] interface vlan-interface 2 [AC Vlan-interface2] portal domain dm1 [AC Vlan-interface2] portal server newpt method direct [AC Vlan-interface2] quit After the wireless client is connected to the wireless network whose SSID is abc, when the user accesses subnet /24 by using a web browser, the user is redirected to page This page is the authentication page that is bound with SSID abc. After entering the correct username and password on the web page, the user passes the authentication. You can view information about the user by using the display portal user command on the AC. Configuring portal stateful failover with local portal servers Network requirements As shown in Figure 80, a failover link is present between AC 1 and AC 2. Both AC 1 and AC 2 support portal authentication. Configure stateful failover between AC 1 and AC 2 to support portal service backup and use VRRP to implement traffic switchover between the ACs. When AC 1 operates normally, Client accesses AC 1 for portal authentication before accessing the Internet. When AC 1 fails, Client accesses the Internet through AC 2. Use VRRP uplink/downlink detection mechanism to ensure non-stop traffic forwarding. Use the RADIUS server as the authentication/authorization server. Use local portal servers on the ACs. AC 1 and AC 2 use the failover link to transmit stateful failover related packets. Specify VLAN 10 on the ACs as the VLAN dedicated for stateful failover related packets. 199

212 Figure 80 Network diagram Configuration prerequisites and guidelines Configuring AC 1 Configure IP addresses for the server, client, switches, and ACs and make sure they have IP connectivity between each other. Make sure the client can access the authentication server through AC 1 and AC 2. 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. On the RADIUS server, specify the access device's IP address as the virtual IP address of VRRP group 2. You must use consistent device roles for AC stateful failover and VRRP. If you use an AC as the master for stateful failover, use the AC as the master in a VRRP group, too. Otherwise, in local portal authentication, the access device cannot push the authentication page according to the SSID. If your network cannot meet the requirement, for example, the two ACs are configured for load balancing, related portal-free rules should be configured. For more information about stateful failover, see High Availability Configuration Guide. 1. Configure VRRP: # Create VRRP group 1, and configure the virtual IP address of VRRP group 1 as <AC1> system-view [AC1] interface vlan-interface 100 [AC1 Vlan-interface100] vrrp vrid 1 virtual-ip # Set the priority of VLAN-interface 100 in VRRP group 1 to 200. [AC1 Vlan-interface100] vrrp vrid 1 priority

213 # On VLAN-interface 100, configure the interface to be tracked as VLAN-interface 8 and reduce the priority of VLAN-interface 100 in VRRP group 1 by 120 when the interface state of VLAN-interface 8 becomes Down or Removed. [AC1 Vlan-interface100] vrrp vrid 1 track interface vlan-interface8 reduced 120 [AC1 Vlan-interface100] quit # Create VRRP group 2, and configure the virtual IP address of VRRP group 2 as [AC1] interface vlan-interface 8 [AC1 Vlan-interface8] vrrp vrid 2 virtual-ip # Set the priority of VLAN-interface 8 in VRRP group 2 to 200. [AC1 Vlan-interface8] vrrp vrid 2 priority 200 # On VLAN-interface 8, configure the interface to be tracked as VLAN-interface 100 and reduce the priority of VLAN-interface 8 in VRRP group 2 by 120 when the interface state of VLAN-interface 100 becomes Down or Removed. [AC1 Vlan-interface8] vrrp vrid 2 track interface vlan-interface100 reduced 120 [AC1 Vlan-interface8] quit 2. Configure a RADIUS scheme: # Create RADIUS scheme rs1 and enter its view. [AC1] radius scheme rs1 # Configure the server type for the RADIUS scheme. When using the IMC server, configure the RADIUS server type as extended. [AC1-radius-rs1] server-type extended # Specify the primary authentication/authorization server, and configure the shared key for secure communication with the server. [AC1-radius-rs1] primary authentication [AC1-radius-rs1] key authentication simple expert # Configure the scheme to remove the ISP domain name in the username sent to the RADIUS server. (By default, the ISP domain name is carried in the username. Configure the username format as needed.) [AC1-radius-rs1] user-name-format without-domain [AC1-radius-rs1] quit 3. Configure an authentication domain: # Create ISP domain dm1 and enter its view. [AC1] domain dm1 # Configure AAA methods for the ISP domain. [AC1-isp-dm1] authentication portal radius-scheme rs1 [AC1-isp-dm1] authorization portal radius-scheme rs1 [AC1-isp-dm1] quit 4. Enable portal authentication on the interface connected to the client: # Configure the portal server, with name configured as local, IP address as (the virtual IP address of VRRP group 1), and URL as [AC1] portal server local ip url # Configure a portal-free rule on AC 1, allowing packets from AC 2 to pass through without portal authentication. This configuration is required only when the roles (master/backup) of the ACs for stateful failover are different from those for VRRP. [AC1] portal free-rule 0 source interface bridge-aggregation 1 destination any # Configure the local portal server to support HTTP. 201

214 [AC1] portal local-server http # On the interface connected to the client, specify the authentication domain dm1 for portal users and enable portal authentication. [AC1] interface vlan-interface 100 [AC1 Vlan-interface100] portal domain dm1 [AC1 Vlan-interface100] portal server local method direct # Specify the source IP address for outgoing portal packets as , the virtual IP address of VRRP group 1. [AC1 Vlan-interface100] portal nas-ip Configure portal stateful failover: # Assign interface VLAN-interface 100 to portal group 1. [AC1] interface vlan-interface 100 [AC1 Vlan-interface100] portal backup-group 1 [AC1 Vlan-interface100] quit # Set the device ID of AC 1 in the stateful failover mode to 1. [AC1] nas device-id 1 # Configure the source IP address of RADIUS packets to be sent as , the virtual IP address of VRRP group 2. [AC1] radius nas-ip Configure the WLAN service: # Specify the backup AC address. [AC1] wlan backup-ac ip # Enable hot backup. [AC1] hot-backup enable # Configure VLAN 10 as the VLAN for AC hot backup. [AC1] hot-backup vlan 10 [AC1] quit # Create interface WLAN-ESS 1, and add it to VLAN 100. [AC1] interface wlan-ess 1 [AC1-WLAN-ESS1] port link-type hybrid [AC1-WLAN-ESS1] port hybrid vlan 100 untagged [AC1-WLAN-ESS1] port hybrid pvid vlan 100 [AC1-WLAN-ESS1] quit # Configure a WLAN service template, and bind the WLAN service template with interface WLAN-ESS 1. [AC1] wlan service-template 1 clear [AC1-wlan-st-1] ssid abc [AC1-wlan-st-1] bind wlan-ess 1 [AC1-wlan-st-1] service-template enable [AC1-wlan-st-1] quit # Configure AP on AC 1. [AC1] wlan ap ap1 model MSM460-WW [AC1-wlan-ap-ap1] serial-id CN2AD330S8 [AC1-wlan-ap-ap1] radio 1 [AC1-wlan-ap-ap1-radio-1] service-template 1 [AC1-wlan-ap-ap1-radio-1] radio enable 202

215 Configuring AC 2 [AC1-wlan-ap-ap1-radio-1] quit [AC1-wlan-ap-ap1] quit 7. Configure the stateful failover function: # Configure VLAN 10 as the backup VLAN for stateful failover. [AC1] dhbk vlan 10 # Enable symmetric-path mode stateful failover. [AC1] dhbk enable backup-type symmetric-path 1. Configure VRRP: # Create VRRP group 1, and configure the virtual IP address of VRRP group 1 as <AC2> system-view [AC2] interface vlan-interface 100 [AC2 Vlan-interface100] vrrp vrid 1 virtual-ip [AC2 Vlan-interface100] quit # Create VRRP group 2, and configure the virtual IP address of VRRP group 2 as [AC2] interface vlan-interface 8 [AC2 Vlan-interface8] vrrp vrid 2 virtual-ip [AC2 Vlan-interface8] quit 2. Configure a RADIUS scheme: # Create RADIUS scheme rs1 and enter its view. [AC2] radius scheme rs1 # Configure the server type for the RADIUS scheme. When using the IMC server, configure the RADIUS server type as extended. [AC2-radius-rs1] server-type extended # Specify the primary authentication/authorization server, and configure the shared key for secure communication with the server. [AC2-radius-rs1] primary authentication [AC2-radius-rs1] key authentication simple expert # Configure the scheme to remove the ISP domain name in the username sent to the RADIUS server. (By default, the ISP domain name is carried in the username. Configure the username format as needed.) [AC2-radius-rs1] user-name-format without-domain [AC2-radius-rs1] quit 3. Configure an authentication domain: # Create ISP domain dm1 and enter its view. [AC2] domain dm1 # Configure AAA methods for the ISP domain. [AC2-isp-dm1] authentication portal radius-scheme rs1 [AC2-isp-dm1] authorization portal radius-scheme rs1 [AC2-isp-dm1] quit 4. Enable portal authentication on the interface connected to the client: # Configure the portal server, with name configured as local, IP address as (the virtual IP address of VRRP group 1), and URL as [AC2] portal server local ip url 203

216 # Configure a portal-free rule on AC 2, allowing packets from AC 1 to pass through without portal authentication. This configuration is required only when the roles (master/backup) of the ACs for stateful failover are different from those for VRRP. [AC2]portal free-rule 0 source interface bridge-aggregation 1 destination any # Configure the local portal server to support HTTP. [AC2]portal local-server http # On the interface connected to the client, specify the authentication domain dm1 for portal users and enable portal authentication. [AC2] interface vlan-interface 100 [AC2 Vlan-interface100] portal domain dm1 [AC2 Vlan-interface100] portal server local method direct # Specify the source IP address for outgoing portal packets as , the virtual IP address of VRRP group 1. [AC2 Vlan-interface100] portal nas-ip Configure portal stateful failover: # Assign interface VLAN-interface 100 to portal group 1. [AC2] interface vlan-interface 100 [AC2 Vlan-interface100] portal backup-group 1 [AC2 Vlan-interface100] quit # Set the device ID of AC 2 in the stateful failover mode to 2. [AC2] nas device-id 2 # Configure the source IP address for outgoing RADIUS packets as , the virtual IP address of VRRP group 2. [AC2] radius nas-ip Configure the WLAN service: # Specify the backup AC IP address. [AC2] wlan backup-ac ip # Enable hot backup. [AC2] hot-backup enable # Configure VLAN 10 as the VLAN for AC hot backup. [AC2] hot-backup vlan 10 [AC2] quit # Create interface WLAN-ESS 1, and add it to VLAN 100. [AC2] interface wlan-ess 1 [AC2-WLAN-ESS1] port link-type hybrid [AC2-WLAN-ESS1] port hybrid vlan 100 untagged [AC2-WLAN-ESS1] port hybrid pvid vlan 100 [AC2-WLAN-ESS1] quit # Configure a WLAN service template, and bind the WLAN service template with interface WLAN-ESS 1. [AC2] wlan service-template 1 clear [AC2-wlan-st-1] ssid abc [AC2-wlan-st-1] bind wlan-ess 1 [AC2-wlan-st-1] service-template enable [AC2-wlan-st-1] quit # Configure AP on AC 2, using the default access priority of 4 for the AP. 204

217 [AC2] wlan ap ap1 model MSM460-WW [AC2-wlan-ap-ap1] serial-id CN2AD330S8 [AC2-wlan-ap-ap1] radio 1 [AC2-wlan-ap-ap1-radio-1] service-template 1 [AC2-wlan-ap-ap1-radio-1] radio enable [AC2-wlan-ap-ap1-radio-1] quit [AC2-wlan-ap-ap1] quit 7. Configure the stateful failover function: # Configure VLAN 10 as the backup VLAN for stateful failover. [AC2] dhbk vlan 10 # Enable symmetric-path mode stateful failover. [AC2] dhbk enable backup-type symmetric-path Verifying the configuration # After the user client logs in to AC 1, use the display portal user command on AC 1 and AC 2 to view the authentication information of the user. [AC1] display portal user all Index:3 State:ONLINE SubState:NONE ACL:NONE Work-mode: primary MAC IP Vlan Interface d-88f8-0eac Vlan-interface100 Total 1 user(s) matched, 1 listed. [AC2] display portal user all Index:2 State:ONLINE SubState:NONE ACL:NONE Work-mode: secondary MAC IP Vlan Interface d-88f8-0eac Vlan-interface100 Total 1 user(s) matched, 1 listed. The output shows that the portal information of the user is stored on both AC 1 and AC 2. The user mode is primary on AC 1 and secondary on AC 2, indicating that the user logged in from AC 1 and the user's authentication information has been synchronized to AC 2. Configuring MAC-based quick portal authentication Network requirements As shown in Figure 81, the wireless user client belongs to VLAN 3, and the AP belongs to VLAN 5. Detailed requirements are as follows: Enable direct portal authentication on the AC. 205

218 The client can access only the portal server before authentication and can access the external network after passing portal authentication. When reconnecting to the external network, the authenticated client can pass portal authentication without the username and password. Use the RADIUS server as the authentication/authorization server. Figure 81 Network diagram Configuring the AC 1. Configure a RADIUS scheme on the AC: # Create a RADIUS scheme named rs1, and enter its view. <AC> system-view [AC] radius scheme rs1 # Set the server type for the RADIUS scheme. When you use the IMC server, set the server type to extended. [AC-radius-rs1] server-type extended # Specify the primary authentication/authorization server, and configure the shared key for secure communication with the server. [AC-radius-rs1] primary authentication [AC-radius-rs1] key authentication simple # Specify that the ISP domain name should not be included in the username sent to the RADIUS server. [AC-radius-rs1] user-name-format without-domain [AC-radius-rs1] quit # Specify the NAS IP of the AC. [AC-radius-rs1] nas-ip [AC-radius-rs1] quit 2. Configure an authentication domain on the AC: # Configure an ISP domain named dm1, and enter its view. [AC] domain dm1 # Configure the ISP domain to use RADIUS scheme rs1. [AC-isp-dm1] authentication portal radius-scheme rs1 [AC-isp-dm1] authorization portal radius-scheme rs1 [AC-isp-dm1] quit 3. Configure portal authentication on the AC: # Configure the portal server as follows: Name: 5 IP address: Key: (in plaintext) 206

219 Port number: URL: [AC] portal server 5 ip key simple port url # Create VLAN 5 and configure the IP address of VLAN-interface 5 as /16. [AC] vlan 5 [AC-vlan5] quit [AC] interface vlan 5 [AC-Vlan-interface5] ip address [AC-Vlan-interface5] quit # Create VLAN 3 and configure the IP address of VLAN-interface 3 as /16. [AC] vlan 3 [AC-vlan3] quit [AC] interface vlan 3 [AC-Vlan-interface3] ip address # On the interface connected to the client, specify the authentication domain as dm1 for portal users, and enable direct portal authentication. [AC Vlan-interface3] portal domain dm1 [AC Vlan-interface3] portal server 5 method direct # Configure the NAS IP of the AC as [AC-Vlan-interface3] portal nas-ip [AC Vlan-interface3] quit # Specify the IP address of the MAC binding server as [AC] portal mac-trigger server ip # On the portal authentication-enabled interface, enable MAC-based quick portal authentication. [AC] interface vlan-interface 3 [AC-Vlan-interface3] portal mac-trigger enable [AC-Vlan-interface3] quit Configuring the portal server This section uses IMC PLAT 5.2 (E0401) and IMC UAM 5.2 (E0402). 1. Configure the portal server: a. Log in to IMC and click the Service tab. b. From the navigation tree, select User Access Manager > Portal Service > Server to enter the portal server configuration page, as shown in Figure 82. The Portal Page field displays which is the URL of the portal server. c. Use default values for other parameters. d. Click OK. 207

220 Figure 82 Configuring the portal server 2. Configure the IP address group: a. From the navigation tree, select User Access Manager > Portal Service > IP Group. b. Click Add to enter the page shown in Figure 83. c. Enter the IP group name IP_group. d. Enter the start IP address and the end IP address Make sure the client's IP address is in the IP group. e. Select the service group Ungrouped. f. Select Normal for Action. g. Click OK. Figure 83 Adding an IP address group 3. Add a portal device: a. From the navigation tree, select User Access Manager > Portal Service > Device. b. Click Add to enter the page shown in Figure 84. c. Enter the device name Portal. 208

221 d. Select the IP address , which is the IP address of the AC interface that connects to the client. e. Enter the key , which must be the same as that configured on the AC. f. Select No for both Support Server Heartbeat and Support User Heartbeat. g. Click OK. Figure 84 Adding a portal device 4. Associate the portal device with the IP address group: a. From the navigation tree, select User Access Manager > Portal Service > Device. b. As shown in Figure 85, click the icon in the Operation column for device Portal and select Configure Port Group. Figure 85 Device list c. On the port group configuration page, click Add to enter the page shown in Figure 86. d. Enter the port group name hp_portal. e. Select the configured IP address group IP_group. The client's IP address must be within this IP address group. f. Select Supported for Fast Authentication on Smart Terminals. g. Use default values for other parameters. 209

222 h. Click OK. Figure 86 Adding a port group 5. Configure an access rule: a. From the navigation tree, select User Access Manager > Access Rule Management. b. Click Add to enter the page shown in Figure 87. c. Enter the access rule name mac-trigger. d. Use default values for other parameters. e. Click OK. 210

223 Figure 87 Adding an access rule 6. Configure fast authentication on smart terminals: a. From the navigation tree, select User Access Manager > Service Configuration. b. Click Add to enter the page shown in Figure 88. c. Enter the service name dot1x. d. Select mac-trigger for Default Access Rule. e. Select Portal Fast Authentication on Endpoints. f. Click OK. Figure 88 Adding a service configuration 211

224 7. Configure the access device: a. From the navigation tree, select User Access Manager > Access Device Management > Access Device. b. On the access device configuration page, click Add. c. Enter and confirm the shared key d. Click Add Manually on the device list. e. On the Add Access Device Manually window, enter the access device IP address in the Start IP field, and click OK. Figure 89 Adding an access device 8. Configure the access user: a. Click the User tab. b. From the navigation tree, select All Access Users > Ungrouped. c. Click Add to enter the access user configuration page shown in Figure 90. d. Enter the user name Portal, the account name dot1x, and the password e. Select 5 for Max. Smart Terminal Bindings for Portal. You can set this parameter according to actual requirements. f. Select dot1x in the access service list. 212

225 Figure 90 Adding an access user 9. Configure HTTP user agent feature identification: a. Click the Service tab. b. From the navigation tree, select User Access Manager > Endpoint Identification Management. c. Click the HTTP User Agent Feature Identification Configuration tab. The page displays smart terminals in the HTTP User Agent Feature Identification Configuration List. If the list contains no smart terminals, click Add to add devices. Figure 91 Configuring HTTP user agent feature identification 10. Enable BYOD fast authentication: a. Click the Service tab. b. From the navigation tree, select User Access Manager > Service Parameters > System Settings. c. Click BYOD System Settings. d. Select Yes for Enable Fast Authentication. e. Use default values for other parameters. f. Click OK. 213

226 Figure 92 Configuring BYOD system settings 11. From the navigation tree, select User Access Manager > Service Parameters > Validate to validate the configurations. Verifying the configuration # Use the client to access an external network, the portal authentication page appears. Enter the username Portal and password to log in. # On the AC, display portal user information. [AC] display portal user all Index:2 State:ONLINE SubState:NONE ACL:NONE Work-mode:stand-alone MAC IP Vlan Interface ca9-f414-4c Vlan-interface3 Total 1 user(s) matched, 1 listed. # Disconnect from the external network and then access the network again. The portal authentication page does not appear. On the AC, display portal user information. The output shows that the client has logged in. [AC] display portal user all Index:3 State:ONLINE SubState:NONE ACL:NONE Work-mode:stand-alone MAC IP Vlan Interface ca9-f414-4c Vlan-interface3 Total 1 user(s) matched, 1 listed. 214

227 Troubleshooting portal Inconsistent keys on the access device and the portal server Symptom Analysis Solution When a user is forced to access the portal server, the portal server displays a blank webpage, rather than the portal authentication page or an error message. The keys on the access device and those on the portal server are not configured consistently, causing CHAP message exchange failure. As a result, the portal server does not display the authentication page. 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 Analysis Solution 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. 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 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 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. 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. 215

228 Configuring port security Port security is available on Ethernet and WLAN ports. Supported port types depend on the command. For more information, see Security Command Reference. Overview Port security combines and extends 802.1X and MAC authentication to provide MAC-based network access control. HP recommends that you configure port security in a WLAN network. Port security prevents unauthorized access to a network by checking the source MAC address of inbound traffic and prevents access to unauthorized devices by checking the destination MAC address of outbound traffic. Port security can control MAC address learning and authentication on a port to make sure the port learns only source trusted MAC addresses. A frame is illegal if its source MAC address cannot be learned in a port security mode, or if it is from a client that has failed 802.1X or MAC authentication. The port security feature automatically takes a pre-defined action on illegal frames. This automatic mechanism enhances network security and reduces human intervention. For more information about 802.1X and MAC authentication, see "Configuring 802.1X" and "Configuring MAC authentication." Port security features NTK Port security supports the need to know (NTK) feature, intrusion protection, and port security traps. NTK prevents traffic interception by checking the destination MAC address in outbound frames. The feature ensures that frames are sent only to hosts that have passed authentication or whose MAC addresses have been learned or configured on the access device. Intrusion protection The intrusion protection feature checks the source MAC address in inbound frames for illegal frames and takes a pre-defined action on each detected illegal frame. The action can be disabling the port temporarily, disabling the port permanently, or blocking frames from the illegal MAC address for three minutes (not user configurable). Port security traps To monitor user behavior, configure the port security module to send traps for port security events such as login, logoff, and MAC authentication. Port security modes Port security supports the following categories of security mode: MAC learning control MAC address learning is disabled on ports in secure mode. 216

229 Authentication Implements MAC authentication, 802.1X authentication, or a combination of the 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 10 describes the port security modes and the security features. Table 10 Port security modes Purpose Turning off the port security feature Controlling MAC address learning Performing 802.1X authentication Performing MAC authentication Security mode norestrictions (the default mode). In this mode, port security is disabled on the port and access to the port is not restricted. secure userlogin userloginsecure userloginsecureext userloginwithoui macaddresswithradius Features that can be triggered N/A NTK/intrusion protection N/A NTK/intrusion protection NTK/intrusion protection Performing a combination of MAC authentication and 802.1X authentication Or Else macaddressoruserloginsecure macaddressoruserloginsecureext macaddresselseuserloginsecure macaddresselseuserloginsecureext NTK/intrusion protection 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. For wireless users, the network access device always use 802.1X authentication first. 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. 217

230 Controlling MAC address learning secure: MAC address learning is disabled on a port in this 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 Configuration Guide. A port in secure mode allows only frames sourced from the manually configured MAC addresses to pass. Performing 802.1X authentication userlogin A port in this mode performs 802.1X authentication and implements port-based access control. The port can service multiple 802.1X users. Once an 802.1X user passes authentication on the port, any subsequent 802.1X users can access the network through the port without authentication. userloginsecure A port in this mode performs 802.1X authentication and implements MAC-based access control. The port services only one user passing 802.1X authentication. userloginsecureext This mode is similar to the userloginsecure mode except that this mode supports multiple online 802.1X users. userloginwithoui This mode is similar to the userloginsecure mode. The difference is that a port in this mode also permits frames from one user whose MAC address contains a specific OUI. For wired users, the port performs 802.1X authentication upon receiving 802.1X frames, and performs OUI check upon receiving non-802.1x frames. For wireless users, the port performs OUI check at first. If the OUI check fails, the port performs 802.1X authentication. NOTE: An OUI is a 24-bit number that uniquely identifies a vendor, manufacturer, or organization. In MAC addresses, the first three octets are the OUI. 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 30 seconds after receiving non-802.1x frames and performs 802.1X authentication upon receiving 802.1X frames. For wireless users, the port performs 802.1X authentication first. If 802.1X authentication fails, MAC authentication is performed. macaddressoruserloginsecureext This mode is similar to the macaddressoruserloginsecure mode except that this mode supports multiple 802.1X and MAC authentication users. macaddresselseuserloginsecure 218

231 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 30 seconds after receiving non-802.1x frames. For wireless users, the port performs MAC authentication upon receiving non-802.1x frames. Upon receiving 802.1X frames, the port performs MAC authentication, and if the MAC authentication fails, it performs 802.1X authentication. macaddresselseuserloginsecureext This mode is similar to the macaddresselseuserloginsecure mode except that this mode supports multiple 802.1X and MAC authentication users as the keyword Ext implies. Support for WLAN CAUTION: Do not configure static MAC address entries for wireless users that use the 802.1X or MAC authentication service. If the source MAC address and the VLAN of a wireless user match a static MAC address entry in the MAC address table, the user cannot pass 802.1X authentication or MAC authentication. Table 11 describes the port security modes that implement wireless access security at the link layer. Table 11 Port security modes for WLAN ports Security mode presharedkey macaddressandpr esharedkey userloginsecureext OrPresharedKey Description A user must use a pre-configured static key, also called "the pre-shared key (PSK)," to negotiate the session key with the device and can access the network only after the negotiation succeeds. A user must pass MAC authentication and then use the pre-configured PSK to negotiate with the device. Only when the negotiation succeeds, can the user access the network. A user interacts with the device, choosing the UserLoginSecure mode or using the PSK to negotiate with the device. Features that can be triggered NTK/intrusion protection PSK users refer to users that have passed authentication in presharedkey mode. The maximum number of PSK users on a port varies with security modes. presharedkey mode The maximum number of PSK users on the port is the port specification limit on the number of wireless users or port security's limit on the number of MAC addresses, whichever is smaller. The actual maximum number of PSK users on the port also depends on the total number of PSK users that the system can support. For more information, see About the Configuration Guides for HP Unified Wired-WLAN Products. macaddressandpresharedkey mode The maximum number of PSK users on the port is the MAC authentication feature's limit on the number of concurrent users or port security's limit on the number of MAC addresses, whichever is smaller. The actual maximum number of PSK users on the port also depends on the total number of PSK users that the system can support. 219

232 userloginsecureextorpresharedkey mode The number of PSK users on the port cannot exceed the port limit on the number of wireless users, the number of 802.1X users cannot exceed the 802.1X feature's limit on the number of concurrent users, and the total number of PSK and 802.1X users cannot exceed port security's limit on the number of MAC addresses on the port. The maximum number of PSK or 802.1X users also depends on the system specification. 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. Port security stateful failover In a dual-ac network, the ACs can provide client information stateful failover to avoid client logoff during primary/backup AC switchovers. When a client logs in or logs off, the primary AC synchronizes the client information (authentication and authorization information, client data, and client status) to the backup AC through the IACTP tunnel in real time. Therefore, when a primary/backup AC switchover occurs, the backup AC can immediately take over to provide normal communication for online clients. For more information about AC backup, see WLAN Configuration Guide. Port security supports stateful failover only for 802.1X client information. The Auth-Fail VLAN and guest VLAN do not support stateful failover. If a client is added to an Auth-Fail VLAN on the primary AC, the VLAN information cannot be synchronized to the backup AC. Stop-Account-Buffer packets, if any, cannot be synchronized from the primary AC to the backup AC. The failover link between two ACs is the basic for client information synchronization on both the ACs. Make sure the failover link operates correctly. If the failover link is disconnected and then reconnected, the client information might change. Configuration task list Task Enabling port security Setting port security's limit on the number of MAC addresses on a port Setting the port security mode Remarks Required. Required. 220

233 Task Configuring port security features: Configuring NTK Configuring intrusion protection Enabling port security traps Configuring port security for WLAN ports: Setting the port security mode of a WLAN port Enabling key negotiation Configuring a PSK Ignoring authorization information from the server Configuring NAS ID profile for port security Configuring port security stateful failover Remarks Configure one or more features as required. Required for WLAN ports. Enabling port security When port security is enabled, you cannot manually enable 802.1X or MAC authentication, or change the access control mode or port authorization state. The port security automatically modifies these settings in different security modes. Before you enable port security, disable 802.1X and MAC authentication globally. To enable port security: Step Command Remarks 1. Enter system view. system-view N/A 2. Enable port security. port-security enable By default, port security is enabled. You can use the undo port-security enable command to disable port security when no online users are present. Enabling or disabling port security resets the following security settings to the default: 802.1X access control mode is MAC-based, and the port authorization state is auto. Port security mode is norestrictions. For more information about Configuring 802.1X, see "Configuring 802.1X." For more information about MAC authentication configuration, see "Configuring MAC authentication." Setting port security's limit on the number of MAC addresses on a port You can set the maximum number of MAC addresses that port security allows on a port to control 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. 221

234 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 Configuration Guide. To set the maximum number of secure MAC addresses allowed on a port: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. interface interface-type interface-number N/A 3. Set the limit of port security on the number of MAC addresses. port-security max-mac-count count-value Not limited by default. Setting the port security mode After enabling port security, you can change the port security mode of a port only when the port is operating in norestrictions (the default) mode. To change the port security mode for a port in any other mode, first use the undo port-security port-mode command to restore the default port security mode. You can specify a port security mode when port security is disabled, but your configuration cannot take effect. You cannot change the port security mode of a port when online users are present. Before you set a port security mode for a port, complete the following tasks: Disable 802.1X and MAC authentication. Check that the port does not belong to any aggregation group. To enable a port security mode: Step Command Remarks 1. Enter system view. system-view N/A 2. Set an OUI value for user authentication. 3. Enter interface view. 4. Set the port security mode. port-security oui oui-value index index-value interface interface-type interface-number port-security port-mode { mac-authentication mac-else-userlogin-secure mac-else-userlogin-secure-e xt secure userlogin userlogin-secure userlogin-secure-ext userlogin-secure-or-mac userlogin-secure-or-mac-ext userlogin-withoui } Required for the userlogin-withoui mode. Not configured by default. To set multiple OUI values, repeat this step. To specify the userloginwithoui mode, you must enter Layer 2 Ethernet interface view or WLAN-ESS interface view. By default, a port operates in norestrictions mode. If you configure the MAC authentication quiet timer after you have configured the port-security port-mode { mac-authentication userlogin-secure-or-mac userlogin-secure-or-mac-ext } command, the quiet timer does not take effect. For more information about the MAC authentication quiet timer, see "Configuring MAC authentication." 222

235 Configuring port security features Configuring NTK The NTK feature checks destination MAC addresses in outbound frames to make sure frames are forwarded only to authenticated devices. Any unicast frame with an unknown destination MAC address is discarded. Not all port security modes support triggering the NTK feature. For more information, see Table 10. The NTK feature supports the following modes: ntkonly Forwards only unicast frames with authenticated destination MAC addresses. ntk-withbroadcasts Forwards only broadcast frames and unicast frames with authenticated destination MAC addresses. ntk-withmulticasts Forwards only broadcast frames, multicast frames, and unicast frames with authenticated destination MAC addresses. To configure the NTK feature: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Configure the NTK feature. interface interface-type interface-number port-security ntk-mode { ntk-withbroadcasts ntk-withmulticasts ntkonly } N/A 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 fail for the same frame. To configure the intrusion protection feature: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. interface interface-type interface-number N/A 223

236 Step Command Remarks 3. Configure the intrusion protection feature. port-security intrusion-mode { blockmac disableport disableport-temporarily } By default, intrusion protection is disabled. The disableport keyword is not supported on a WLAN-ESS interface. 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 20 seconds by default. Enabling port security traps You can configure the port security module to send traps for the following categories of events: addresslearned Learning of new MAC addresses. dot1xlogfailure/dot1xlogon/dot1xlogoff 802.1X authentication failure, success, and 802.1X user logoff. ralmlogfailure/ralmlogon/ralmlogoff MAC authentication failure, MAC authentication user logon, and MAC authentication user logoff. intrusion Detection of illegal frames. To enable port security traps: Step Command Remarks 1. Enter system view. system-view N/A 2. Enable port security traps. port-security trap { addresslearned dot1xlogfailure dot1xlogoff dot1xlogon intrusion ralmlogfailure ralmlogoff ralmlogon } By default, port security traps are disabled. Configuring port security for WLAN ports Table 12 describes the key negotiation and PSK requirements for different port security modes on WLAN ports. Table 12 Port security configuration for WLAN ports Port security mode presharedkey, userloginsecureext, userloginsecureextorpresharedkey, and macaddressandpresharedkey Description On WPA or RSN networks using any of these modes, key negotiation must be enabled. In presharedkey and macaddressandpresharedkey modes, you need to configure the PSK. In userloginsecureext mode, you do not need to configure the PSK. In userloginsecureextorpresharedkey mode, you can determine whether to configure any PSK. 224

237 Port security mode Port security modes other than presharedkey, userloginsecureextorpresharedkey, and macaddressandpresharedkey Description No key negotiation is performed and you do not need to enable key negotiation. For more information about WLAN service templates, see WLAN Configuration Guide. By default, an 802.1X-enabled access device periodically multicasts Identity EAP-Request packets out of ports to detect 802.1X clients and trigger authentication. To save the bandwidth of WLAN ports, HP recommends you disable the multicast trigger function (see "Configuring 802.1X"). Setting the port security mode of a WLAN port Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Set a port security mode for the WLAN port. interface interface-type interface-number port-security port-mode { mac-and-psk mac-authentication mac-else-userlogin-secure mac-else-userlogin-secure-ext psk userlogin-secure userlogin-secure-ext userlogin-secure-ext-or-psk userlogin-secure-or-mac userlogin-secure-or-mac-ext userlogin-withoui } N/A By default, a port operates in norestrictions mode. Enabling key negotiation After a user passes 802.1X authentication, a WLAN port uses EAPOL-Key frames to negotiate the link-layer session key with the user if the key negotiation function is enabled. If key negotiation is enabled, an authenticated user is allowed to access to the port only after the key negotiation succeeds. If key negotiation is disabled, a user can directly access the port after passing authentication. To enable key negotiation: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Enable key negotiation of the 11key t yp e. interface interface-type interface-number port-security tx-key-type 11key N/A Disabled by default. 225

238 Configuring a PSK A PSK pre-configured on the device is used to negotiate the session key between the user and the device. To configure a PSK: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Configure a PSK. interface interface-type interface-number port-security preshared-key { pass-phrase raw-key } [ cipher simple ] key N/A By default, no PSK is configured. Ignoring authorization information from the server You can configure a port to ignore the authorization information received from the server (an RADIUS server or the local device) after an 802.1X user or MAC authentication user passes authentication. To configure a port to ignore authorization information from the server: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Ignore the authorization information received from the authentication server. interface interface-type interface-number port-security authorization ignore N/A By default, a port uses the authorization information received from the authentication server. Configuring NAS ID profile for port security Perform this task to specify a NAS ID profile for interface-specific or global port security. When a user logs in from an interface by passing port security authentication, the device searches the NAS ID to be sent to the RADIUS server in the following order: 1. NAS ID configured in the AP template 2. NAS ID configured in radio view 3. NAS ID profile specified for port security on the interface 4. NAS ID profile specified for port security in system view 5. Device name To specify a NAS ID profile for port security in system view: Step Command Remarks 1. Enter system view. system-view N/A 226

239 Step Command Remarks 2. Specify a NAS ID profile. port-security nas-id-profile profile-name By default, no NAS ID profile is specified in system view. To specify a NAS ID profile for port security on an interface: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Specify a NAS ID profile. interface interface-type interface-number port-security nas-id-profile profile-name N/A By default, no NAS ID profile is specified on an interface. Configuring port security stateful failover Perform this task to provide client information stateful failover on two ACs that support stateful failover. After you configure stateful failover for the two ACs and on the WLAN-ESS interfaces (with the same interface number) of the two ACs, the primary AC synchronizes the online client information on the WLAN-ESS interface and the corresponding WLAN-DBSS interface to the backup AC. When a primary/backup AC switchover occurs, the backup AC takes over to provide access services for the online clients without re-authenticating the clients. Port security supports stateful failover only for 802.1X client information. To implement port security stateful failover, complete the following tasks: Configure AC hot backup (stateful failover). For more information, see WLAN Configuration Guide. Configure WLAN client information backup. For more information, see WLAN Configuration Guide. Configure VRRP. You need to configure a VRRP group on the interface connected to the authentication server. For more information, see High Availability Configuration Guide. Configure stateful failover. You need to configure a backup VLAN for the stateful failover function. For more information, see High Availability Configuration Guide. Configure different device IDs for the ACs that back up each other. For more information, see "Configuring AAA." Specify the virtual IP address of the VRRP group as the source address of outgoing RADIUS packets. For more information, see "Configuring AAA." To configure port security stateful failover: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter WLAN-ESS interface view. interface wlan-ess interface-number N/A 227

240 Step Command Remarks 3. Enable stateful failover for port security. port-security synchronization enable By default, stateful failover is disabled for port security. Displaying and maintaining port security Task Command Remarks Display port security configuration information, operation information, and statistics about one or more ports or all ports. Display information about blocked MAC addresses. Display information about PSK users. display port-security [ interface interface-list ] [ { begin exclude include } regular-expression ] display port-security mac-address block [ interface interface-type interface-number ] [ vlan vlan-id ] [ count ] [ { begin exclude include } regular-expression ] display port-security preshared-key user [ interface interface-type interface-number ] [ { begin exclude include } regular-expression ] Available in any view. Available in any view. Available in any view. Port security configuration examples The configuration examples were created on the 11900/10500/ G unified wired-wlan module and might vary with device models. When configuring the 11900/10500/ G unified wired-wlan module, make sure the settings are correct (including VLAN settings) on the internal Ethernet interface that connects the module to the switch. For more information, see HP 11900/10500/ G Unified Wired-WLAN Module Basic Configuration Guide. By default, the aggregate interfaces between the access controller engine and the switching engine on an 830 switch or an 870 appliance are Access interfaces in VLAN 1. When configuring the two aggregate interfaces, make sure their permitted VLANs are the same. HP also recommends that you set their link type to be the same. Configuring the userloginwithoui mode Network requirements As shown in Figure 93, a client is connected to the AC through port WLAN-ESS 1. The AC authenticates the client with a RADIUS server. If the authentication succeeds, the client is authorized to access the Internet. The RADIUS server at /24 functions as the primary authentication server and the secondary accounting server. The RADIUS server at /24 functions as the secondary authentication server and the primary accounting server. The shared key for authentication is name, and the shared key for accounting is money. 228

241 All users use the default authentication, authorization, and accounting methods of ISP domain sun, which can accommodate up to 30 users. The RADIUS server response timeout time is 5 seconds. The maximum number of RADIUS packet retransmission attempts is five. The AC sends real-time accounting packets to the RADIUS server at an interval of 15 minutes, and sends user names without domain names to the RADIUS server. Configure port WLAN-ESS 1 of the AC to: Allow only one 802.1X user to be authenticated. Allow up to five OUI values to be configured and allow one terminal that uses any of the OUI values to access the port in addition to an 802.1X user. Figure 93 Network diagram Configuration procedure The following configuration steps cover some AAA/RADIUS configuration commands. For more information about the commands, see Security Command Reference. Configuration procedures for the client and RADIUS servers are not shown. 1. Configure the RADIUS protocol: # Configure a RADIUS scheme named radsun. <AC> system-view [AC] radius scheme radsun # Specify the IP address of the primary authentication RADIUS server as /24, and that of the primary accounting RADIUS server as /24. [AC-radius-radsun] primary authentication [AC-radius-radsun] primary accounting # Specify the IP address of the secondary authentication RADIUS server as /24, and that of the secondary accounting RADIUS server as /24. [AC-radius-radsun] secondary authentication [AC-radius-radsun] secondary accounting # Set the shared key for authenticating RADIUS authentication/authorization packets as name. [AC-radius-radsun] key authentication name # Set the shared key for authenticating RADIUS accounting packets as money. [AC-radius-radsun] key accounting money # Set the RADIUS server response timeout to 5 seconds, and set the maximum transmission attempts of RADIUS packets to 5. [AC-radius-radsun] timer response-timeout 5 [AC-radius-radsun] retry 5 229

242 # Set the interval between sending real time accounting packets to the RADIUS server to 15 minutes. [AC-radius-radsun] timer realtime-accounting 15 # Exclude the ISP domain name in the username sent to the RADIUS server. [AC-radius-radsun] user-name-format without-domain [AC-radius-radsun] quit # Configure ISP domain sun to use RADIUS scheme radsun for authentication, authorization, and accounting of all types of users. [AC] domain sun [AC-isp-sun] authentication default radius-scheme radsun [AC-isp-sun] authorization default radius-scheme radsun [AC-isp-sun] accounting default radius-scheme radsun # Specify that the ISP domain can contain up to 30 users. [AC-isp-sun] access-limit enable 30 [AC-isp-sun] quit 2. Set the 802.1X authentication method to CHAP. By default, the authentication method is CHAP for 802.1X. [AC] dot1x authentication-method chap 3. Configure port security: # Enable port security. [AC] port-security enable # Add five OUI values. [AC] port-security oui index 1 [AC] port-security oui index 2 [AC] port-security oui index 3 [AC] port-security oui index 4 [AC] port-security oui index 5 # Configure the mandatory authentication domain sun for 802.1X users on WLAN-ESS 1. Set the port security mode to userloginwithoui. [AC] interface wlan-ess 1 [AC-WLAN-ESS1] dot1x mandatory-domain sun [AC-WLAN-ESS1] port-security port-mode userlogin-withoui [AC-WLAN-ESS1] quit # Create service template 2, set its template type to clear and SSID to mactest, bind interface WLAN-ESS 1 to it, and enable open system authentication. [AC] wlan service-template 2 clear [AC-wlan-st-2] ssid mactest [AC-wlan-st-2] bind wlan-ess 1 [AC-wlan-st-2] authentication-method open-system [AC-wlan-st-2] service-template enable [AC-wlan-st-2] quit # Create an AP template named ap1, and set its model to MSM460-WW and serial ID to CN2AD330S8. [AC] wlan ap ap1 model MSM460-WW [AC-wlan-ap-ap1] serial-id CN2AD330S8 [AC-wlan-ap-ap1] radio 1 type dot11an 230

243 # Map service template 2 to radio 1, and enable the radio. [AC-wlan-ap-ap1-radio-1] service-template 2 [AC-wlan-ap-ap1-radio-1] radio enable [AC-wlan-ap-ap1-radio-1] return Verifying the configuration # Display the configuration of the RADIUS scheme named radsun. <AC> display radius scheme radsun SchemeName : radsun Index = 1 Type : standard Primary Auth Server: IP: Port: 1812 State: active Encryption Key : N/A Probe username : N/A Probe interval : N/A Primary Acct Server: IP: Port: 1813 State: active Encryption Key : N/A Probe username : N/A Probe interval : N/A Second Auth Server: IP: Port: 1812 State: active Encryption Key : N/A Probe username : N/A Probe interval : N/A Second Acct Server: IP: Port: 1813 State: active Encryption Key : N/A Probe username : N/A Probe interval : N/A Auth Server Encryption Key : ****** Acct Server Encryption Key : ****** Accounting-On packet disable, send times = 5, interval : 3s Interval for timeout(second) : 5 Retransmission times for timeout : 5 Interval for realtime accounting(minute) : 15 Retransmission times of realtime-accounting packet : 5 Retransmission times of stop-accounting packet : 500 Quiet-interval(min) : 5 Username format : without-domain Data flow unit : Byte Packet unit : one # Display the configuration of the ISP domain named sun. <AC> display domain sun Domain = sun State = Active Access-limit = 30 Accounting method = Required 231

244 Default authentication scheme : radius=radsun Default authorization scheme : radius=radsun Default accounting scheme : radius=radsun Domain User Template: Idle-cut = Disable Session-time : exclude-idle-time Self-service = Disable Authorization attributes: # Display the port security configuration. <AC> display port-security interface wlan-ess 1 Equipment port-security is enabled Trap is disabled Disableport Timeout: 20s OUI value: Index is 1, OUI value is Index is 2, OUI value is Index is 3, OUI value is Index is 4, OUI value is Index is 5, OUI value is WLAN-ESS1 is link-up Port mode is userloginwithoui NeedToKnow mode is disabled Intrusion Protection mode is NoAction Max MAC address number is not configured Stored MAC address number is 0 Authorization is permitted Synchronization is disabled After an 802.1X user gets online, you can see that the number of MAC addresses stored is 1. # Display the 802.1X user connection. <AC> display connection Index=1,Username= test@sun MAC= IP= IPv6=N/A Online=00h00m53s Total 1 connection(s) matched. <AC> display connection ucibinedx 1 Index=2054, Username= test@sun MAC= IP= IPv6=N/A Access=8021X,AuthMethod=CHAP Port Type=Wireless ,Port Name=WLAN-DBSS1:1 Initial VLAN=1, Authorization VLAN= N/A ACL Group=Disable 232

245 User Profile=N/A CAR=Disable Traffic Statistic: InputOctets = OutputOctets =12120 InputGigawords=1 OutputGigawords=0 Priority=Disable SessionTimeout=86236(s), Terminate-Action=Default Start= :39:49,Current= :50:07,Online=00h10m18s Total 1 connection matched. Configuring the userloginsecureext mode on a WLAN port Network requirements Clients are wirelessly connected to the AC through port WLAN-ESS 1. The AC uses the RADIUS server to authenticate its clients. If the authentication for a client succeeds, key negotiation is performed. If key negotiation succeeds, the client can access the network resources. The RADIUS server at /24 is the primary authentication server and the backup accounting server. The RADIUS server at /24 is the backup authentication server and the primary accounting server. Both the authentication and accounting shared keys are name. All users use the default authentication, authorization, and accounting methods of the ISP domain sun. Figure 94 Network diagram RADIUS server SSID 1 AP Client A IP network AC Client B Configuration procedure This example covers only some of the required AAA and RADIUS configuration commands. For more information, see Security Command Reference. The client-side and RADIUS server-side configuration procedures are not shown in this example. For more information about WLAN configuration, see WLAN Configuration Guide. 1. Enable port security. <AC> system-view [AC] port-security enable 2. Configure RADIUS: # Configure RADIUS scheme [AC] radius scheme

246 # Specify the IP address of the primary authentication RADIUS server as /24, and that of the primary accounting RADIUS server as /24. [AC-radius-2000] primary authentication [AC-radius-2000] primary accounting # Specify the IP address of the secondary authentication RADIUS server as /24, and that of the secondary accounting RADIUS server as /24. [AC-radius-2000] secondary authentication [AC-radius-2000] secondary accounting # Set the shared keys for authenticating RADIUS authentication and accounting packets as name. [AC-radius-2000] key authentication name [AC-radius-2000] key accounting name # Exclude the ISP domain name in the username sent to the RADIUS server. [AC-radius-2000] user-name-format without-domain [AC-radius-2000] quit # Configure ISP domain sun, and configure the domain to use RADIUS scheme 2000 for authentication, authorization, and accounting of all types of users. [AC] domain sun [AC-isp-sun] authentication default radius-scheme 2000 [AC-isp-sun] authorization default radius-scheme 2000 [AC-isp-sun] accounting default radius-scheme 2000 [AC-isp-sun] quit # Create interface WLAN-ESS 1. [AC] interface wlan-ess 1 # Set the port security mode to userloginsecureext. [AC-WLAN-ESS1] port-security port-mode userlogin-secure-ext # Enable key negotiation of the 11key type. [AC-WLAN-ESS1] port-security tx-key-type 11key # Disable the 802.1X multicast trigger and online user handshake functions. [AC-WLAN-ESS1] undo dot1x multicast-trigger [AC-WLAN-ESS1] undo dot1x handshake [AC-WLAN-ESS1] quit # Specify the default authentication domain as the domain sun. [AC] domain default sun # Set the 802.1X authentication mode to EAP. [AC] dot1x authentication-method eap 3. Configure the WLAN service template, and the AP: # Create a WLAN service template of the crypto type, enter its view, and set an SSID. [AC] wlan service-template 1 crypto [AC-wlan-st-1] ssid SSID1 # Bind the interface to the service template. [AC-wlan-st-1] bind wlan-ess 1 # Enable open system authentication, the AES-CCMP cipher suite, and the RSN-IE in the beacon and probe responses. [AC-wlan-st-1] authentication-method open-system [AC-wlan-st-1] cipher-suite ccmp 234

247 [AC-wlan-st-1] security-ie rsn # Enable the service template function. [AC-wlan-st-1] service-template enable [AC-wlan-st-1] quit # Create an AP template named ap1, and set its model to MSM460-WW and serial ID to CN2AD330S8. [AC] wlan ap ap1 model MSM460-WW [AC-wlan-ap-ap1] serial-id CN2AD330S8 # Bind the service template 1 to the port radio 1, and enable the radio. [AC-wlan-ap-ap1] radio 1 type dot11an [AC-wlan-ap-ap1-radio-1] service-template 1 [AC-wlan-ap-ap1-radio-1] radio enable [AC-wlan-ap-ap1-radio-1] return Verifying the configuration # Display the port security configuration. <AC> display port-security interface wlan-ess 1 Equipment port-security is enabled Trap is disabled Disableport Timeout: 20s OUI value: WLAN-ESS1 is link-up Port mode is userloginsecureext NeedToKnow mode is disabled Intrusion Protection mode is NoAction Max MAC address number is not configured Stored MAC address number is 0 Authorization is permitted Synchronization is disabled # If a user comes online, you can use the display connection and display wlan client commands to display information about the user. <AC> display connection ucibindex 315 Index=315, Username=test@sectest.com MAC= A-00-7B-2F IP=N/A IPv6=N/A Access=8021X,AuthMethod=EAP Port Type=Wireless ,Port Name=WLAN-DBSS1:0 Initial VLAN=1, Authorization VLAN=N/A ACL Group=Disable User Profile=N/A CAR=Disable Traffic Statistic: InputOctets = OutputOctets =12120 InputGigawords=1 OutputGigawords=0 Priority=Disable SessionTimeout=86236(s), Terminate-Action=Default 235

248 Start= :58:51,Current= :59:29,Online=00h00m38s Total 1 connection matched. <AC> display wlan client verbose Total Number of Clients: 1 Total Number of Clients Connected : 1 Client Information MAC Address : a00-7b2f AID : 1 AP Name : AP1 Radio Id : 1 SSID : sectest BSSID : 000f-e Port : WLAN-DBSS1:0 VLAN : 1 State : Running Power Save Mode : Active Wireless Mode : 11g QoS Mode : WMM Listen Interval (Beacon Interval) : 10 RSSI : 37 Rx/Tx Rate : 5.5/18 Client Type : WPA Authentication Method : Open System AKM Method : 802.1X 4-Way Handshake State : PTKINITDONE Group Key State : IDLE Encryption Cipher : TKIP Roam Status : Normal Roam Count : 0 Up Time (hh:mm:ss) : 00:43:19 Configuring an 802.1X guest VLAN for a port security-enabled port Network requirements As shown in Figure 95, an AP connects to an AC through a switch. The AC performs 802.1X authentication for the wireless users, implements MAC-based access control on the ingress port, and accepts concurrent 802.1X users. Configure a guest VLAN on the ingress port of the AC, so any user that has failed authentication can access VLAN

249 Figure 95 Network diagram Configuration procedure This example covers only some of the required AAA and RADIUS configuration commands. For more information, see Security Command Reference. The client-side and RADIUS server-side configuration procedures are not shown in this example. For more information about WLAN configuration, see WLAN Configuration Guide. 1. Perform RADIUS-related configurations. See steps in "Configuring the userloginwithoui mode." 2. Configure the AC: # Create VLAN 2. <AC> system-view [AC] vlan 2 [AC-vlan2] quit # Enable port security. [AC] port-security enable # Set the 802.1X authentication method to EAP. [AC] dot1x authentication-method eap # Set the port security mode of WLAN-ESS 1 to userloginsecureext. In this mode, the port performs 802.1X authentication, implements MAC-based access control, and allows more than one 802.1X user. [AC] interface wlan-ess 1 [AC-WLAN-ESS1] port-security port-mode userlogin-secure-ext # Enable the MAC-based VLAN function and configure VLAN 1 as the guest VLAN. [AC-WLAN-ESS1] port link-type hybrid [AC-WLAN-ESS1] port hybrid vlan 1 to 2 untagged [AC-WLAN-ESS1] port hybrid pvid vlan 2 [AC-WLAN-ESS1] mac-vlan enable [AC-WLAN-ESS1] dot1x guest-vlan 1 # Disable the 802.1X multicast trigger and online user handshake functions. [AC-WLAN-ESS1] undo dot1x handshake [AC-WLAN-ESS1] undo dot1x multicast-trigger [AC-WLAN-ESS1] quit # Configure the WLAN service template. [AC] wlan service-template 1 clear [AC-wlan-st-1] ssid SSID1 237

250 Verifying the configuration [AC-wlan-st-1] bind wlan-ess 1 [AC-wlan-st-1] authentication-method open-system [AC-wlan-st-1] service-template enable [AC-wlan-st-1] quit # Configure the service template of the AP. [AC] wlan ap 1 model MSM460-WW [AC-wlan-ap-1] serial-id CN2AD330S8 [AC-wlan-ap-1] radio 1 [AC-wlan-ap-1-radio-1] service-template 1 [AC-wlan-ap-1-radio-1] radio enable [AC-wlan-ap-1-radio-1] return # Before Client 1 is authenticated (using the username of mac and MAC address of 000f-e2cc-6a21), the guest VLAN function takes effect. You can use the display mac-vlan all command to display the MAC-to-VLAN mapping. <AC> display mac-vlan all The following MAC VLAN addresses exist: S:Static D:Dynamic MAC ADDR MASK VLAN ID PRIO STATE f-e2cc-6a21 ffff-ffff-ffff 1 0 D Total MAC VLAN address count:1 # If Client 1 initiates authentication and passes the authentication, you can use the display connection command to display the user information, and use the display mac-vlan all command to verify that the MAC-to-VLAN mapping entry has been removed. <AC> display connection user-name mac@sun Index=18, Username=mac@sun MAC=000f-e2cc-6a21 IP= IPv6=N/A Online=00h00m31s Total 1 connection matched. Configuring port security with guest VLAN and VLAN assignment Network requirements Clients connect to the AC through the AP. he AC uses the RADIUS server to authenticate its clients. The access port WLAN-ESS 1 of the AC is in VLAN 1, the RADIUS server is in VLAN 2, and the update server for client software download and upgrade is in VLAN 10. Clients can access the Internet after passing authentication. 238

251 Figure 96 Network diagram AC Authentication server Client AP VLAN 2 VLAN 10 VLAN 5 Client IP network Update server As shown in Figure 97, enable 802.1X and set VLAN 10 as the guest VLAN on port WLAN-ESS 1. If the AC sends an EAP-Request/Identity packet from the port for the maximum number of times but still receives no response, the AC adds the MAC address of the client to its guest VLAN. In this case, the client and the update server are both in VLAN 10, and therefore the host can access the update server and download the 802.1X client. Figure 97 Network diagram As shown in Figure 98, after the host passes the authentication and logs in, the client is added to VLAN 5. In this case, the client and WLAN-ESS 1 are both in VLAN 5, and therefore the client can access the Internet. 239

252 Figure 98 Network diagram Configuration procedure Use the inode client in this example. The client that comes with Windows does not support the function. This example covers only some of the required AAA and RADIUS configuration commands. For more information, see Security Command Reference. # Configure RADIUS scheme <AC> system-view [AC] radius scheme 2000 [AC-radius-2000] primary authentication [AC-radius-2000] primary accounting [AC-radius-2000] key authentication abc [AC-radius-2000] key accounting abc [AC-radius-2000] user-name-format without-domain [AC-radius-2000] quit # Create ISP domain test, and set it as the default ISP domain. By default, the system default ISP domain is system. [AC] domain test [AC-isp-test] quit [AC] domain default enable test # Create ISP domain test, and configure the domain to use RADIUS scheme 2000 for authentication, authorization, and accounting of LAN users. [AC] domain test [AC-isp-test] authentication lan-access radius-scheme 2000 [AC-isp-test] authorization lan-access radius-scheme 2000 [AC-isp-test] accounting lan-access radius-scheme 2000 [AC-isp-test] quit # Enable port security in system view. [AC] port-security enable # Set the 802.1X authentication method to EAP. [AC] dot1x authentication-method eap 240

253 # Configure wireless port WLAN-ESS 1. [AC] interface wlan-ess 1 [AC-WLAN-ESS1] port link-type hybrid [AC-WLAN-ESS1] port hybrid vlan 1 to untagged [AC-WLAN-ESS1] port-security port-mode userlogin-secure-ext [AC-WLAN-ESS1] mac-vlan enable [AC-WLAN-ESS1] dot1x guest-vlan 10 [AC-WLAN-ESS1] dot1x mandatory-domain test [AC-WLAN-ESS1] quit # Configure service template 1. The template must be in clear text mode. [AC] wlan service-template 1 clear [AC-wlan-st-1] ssid dot1x [AC-wlan-st-1] bind wlan-ess 1 [AC-wlan-st-1] authentication-method open-system [AC-wlan-st-1] service-template enable [AC-wlan-st-1] quit # Configure an AP template named 1. [AC] wlan ap 1 model MSM460-WW [AC-wlan-ap-1] serial-id CN2AD330S8 [AC-wlan-ap-1] radio 1 [AC-wlan-ap-1-radio-1] service-template 1 [AC-wlan-ap-1-radio-1] radio enable [AC-wlan-ap-1-radio-1] return Verifying the configuration # Before Client 1 is authenticated (using the username of mac and MAC address of 000f-e2cc-6a21), the guest VLAN function takes effect. You can use the display mac-vlan all command to display the MAC-to-VLAN mapping. <AC> display mac-vlan all The following MAC VLAN addresses exist: S:Static D:Dynamic MAC ADDR MASK VLAN ID PRIO STATE f-e2cc-6a21 ffff-ffff-ffff 10 0 D Total MAC VLAN address count:1 # If Client 1 initiates authentication and passes the authentication, you can use the display connection command to display the user information, and use the display mac-vlan all command to verify that the MAC-to-VLAN mapping entry has been removed. <AC> display connection user-name mac@test Index=18, Username=mac@test MAC=000f-e2cc-6a21 IP= IPv6=N/A Online=00h00m31s Total 1 connection matched. 241

254 Configuring 802.1X stateful failover for port security Network requirements AC 1 and AC 2 support stateful failover. To avoid 802.1X client re-authentication and traffic interruption in case of a primary/backup AC switchover, configure AC 1 and AC 2 to support stateful failover for 802.1X client information and use VRRP to implement traffic switchover between the ACs. When AC 1 operates normally, the client passes 802.1X authentication on AC 1 to access the external network. When AC 1 fails, the client accesses the external network through AC 2. A RADIUS server is used as the AAA server. The NAS IP of the access device configured on the RADIUS server is /24. AC 1 and AC 2 use a failover link to transmit the stateful failover packets and the backup VLAN for stateful failover is VLAN 10. Figure 99 Network diagram Configuration considerations Complete the following tasks: Configure IP addresses for interfaces. Create VLAN 8 and VLAN 10. Configure the RADIUS server. (Details not shown.) Create the WLAN-ESS interface, set a port security mode for 802.1X authentication on the interface, and enable stateful failover for port security. Enable global port security. Enable stateful failover and specify the backup VLAN. Configure a VRRP group on the interface connected to the RADIUS server. Configure an AAA authentication domain and a RADIUS scheme. 242

255 Configure AC backup and the client information backup. Enable the AC hot backup function Configuring AC 1 1. Configure port security: # Specify the 802.1X authentication method as EAP. <AC1> system-view [AC1] dot1x authentication-method eap # Create interface WLAN-ESS 1 and enter its view. [AC1] interface wlan-ess 1 # Set the port security mode to userlogin-secure-ext. [AC1-WLAN-ESS1] port-security port-mode userlogin-secure-ext # Enable stateful failover for port security. [AC1-WLAN-ESS1] port-security synchronization enable # Enable key negotiation. [AC1-WLAN-ESS1] port-security tx-key-type 11key # Specify the authentication domain for 802.1X users as domain [AC1-WLAN-ESS1] dot1x mandatory-domain 2003 # Disable the 802.1X multicast trigger and online user handshake functions. [AC1-WLAN-ESS1] undo dot1x multicast-trigger [AC1-WLAN-ESS1] undo dot1x handshake [AC1-WLAN-ESS1] quit # Enable global port security. [AC1] port-security enable 2. Configure stateful failover: # Specify VLAN 10 as the backup VLAN for stateful failover. [AC1] dhbk vlan 10 # Enable symmetric-path mode stateful failover. [AC1] dhbk enable backup-type symmetric-path 3. Create VRRP group 1 on interface VLAN-interface 8. [AC1] interface vlan 8 [AC1-Vlan-interface8] ip address [AC1-Vlan-interface8] vrrp vrid 1 virtual-ip [AC1-Vlan-interface8] quit 4. Configure AAA: # Specify the device ID to be used in stateful failover mode as 1. [AC1] nas device-id 1 # Configure RADIUS scheme [AC1] radius scheme 2003 [AC1-radius-2003] primary authentication [AC1-radius-2003] primary accounting [AC1-radius-2003] key authentication simple aabbcc [AC1-radius-2003] key accounting simple aabbcc [AC1-radius-2003] user-name-format without-domain [AC1-radius-2003] nas-ip

256 Configuring AC 2 [AC1-radius-2003] quit # Create authentication domain 2003, and specify the AAA methods. [AC1] domain 2003 [AC1-isp-2003] authentication lan-access radius-scheme 2003 [AC1-isp-2003] authorization lan-access radius-scheme 2003 [AC1-isp-2003] accounting lan-access radius-scheme 2003 [AC1-isp-2003] quit 5. Configure AC backup and client information backup: # Specify AC 2 as the backup AC of AC 1. [AC1] wlan backup-ac ip # Configure a WLAN service template, configure the SSID as abc, encryption mode as AES-CCMP, and bind interface WLAN-ESS 1 to the service template. [AC1] wlan service-template 1 crypto [AC1-wlan-st-1] ssid abc [AC1-wlan-st-1] bind wlan-ess 1 [AC1-wlan-st-1] authentication-method open-system [AC1-wlan-st-1] cipher-suite ccmp [AC1-wlan-st-1] security-ie rsn [AC1-wlan-st-1] service-template enable [AC1-wlan-st-1] quit # Configure the AP information. [AC1] wlan ap ap1 model MSM460-WW [AC1-wlan-ap-ap1] serial-id CN2AD330S8 [AC1-wlan-ap-ap1] radio 1 type dot11an [AC1-wlan-ap-ap1-radio-1] service-template 1 [AC1-wlan-ap-ap1-radio-1] radio enable [AC1-wlan-ap-ap1-radio-1] quit [AC1-wlan-ap-ap1] quit # Configure the source IP address of the IACTP tunnel as (the address of AC 1) and the IP address of the IACTP tunnel member (AC 2) as [AC1] wlan mobility-group roam [AC1-wlan-mg-roam] source ip [AC1-wlan-mg-roam] member ip # Enable the IACTP tunnel. [AC1-wlan-mg-roam] mobility-group enable [AC1-wlan-mg-roam] quit # Enable client information backup. [AC1] wlan backup-client enable # Enable the AC hot backup function. [AC1] hot-backup enable # Set VLAN 10 as the VLAN for AC hot backup. [AC1] hot-backup vlan Configure port security: # Specify the 802.1X authentication method as EAP. 244

257 <AC2> system-view [AC2] dot1x authentication-method eap # Create interface WLAN-ESS 1 and enter its view. [AC2] interface wlan-ess 1 # Set the port security mode to userlogin-secure-ext. [AC2-WLAN-ESS1] port-security port-mode userlogin-secure-ext # Enable stateful failover for port security. [AC2-WLAN-ESS1] port-security synchronization enable # Enable key negotiation. [AC2-WLAN-ESS1] port-security tx-key-type 11key # Specify the authentication domain for 802.1X users as domain [AC2-WLAN-ESS1] dot1x mandatory-domain 2003 # Disable the 802.1X multicast trigger and online user handshake functions. [AC2-WLAN-ESS1] undo dot1x multicast-trigger [AC2-WLAN-ESS1] undo dot1x handshake [AC2-WLAN-ESS1] quit # Enable global port security. [AC2] port-security enable 2. Configure stateful failover: # Specify VLAN 10 as the backup VLAN for stateful failover. [AC2] dhbk vlan 10 # Enable symmetric-path mode stateful failover. [AC2] dhbk enable backup-type symmetric-path 3. Create VRRP group 1 on interface VLAN-interface 8. [AC2] interface vlan 8 [AC2-Vlan-interface8] ip address [AC2-Vlan-interface8] vrrp vrid 1 virtual-ip [AC2-Vlan-interface8] quit 4. Configure AAA: # Specify the device ID to be used in stateful failover mode as 2. [AC2] nas device-id 2 # Configure RADIUS scheme [AC2] radius scheme 2003 [AC2-radius-2003] primary authentication [AC2-radius-2003] primary accounting [AC2-radius-2003] key authentication simple aabbcc [AC2-radius-2003] key accounting simple aabbcc [AC2-radius-2003] user-name-format without-domain [AC2-radius-2003] nas-ip [AC2-radius-2003] quit # Create authentication domain 2003, and specify the AAA methods. [AC2] domain 2003 [AC2-isp-2003] authentication lan-access radius-scheme 2003 [AC2-isp-2003] authorization lan-access radius-scheme 2003 [AC2-isp-2003] accounting lan-access radius-scheme

258 [AC2-isp-2003] quit 5. Configure AC backup and client information backup: # Specify AC 1 as the backup AC of AC 2. [AC2] wlan backup-ac ip # Configure a WLAN service template, configure the SSID as abc, encryption mode as AES-CCMP, and bind interface WLAN-ESS 1 to the service template. [AC2] wlan service-template 1 crypto [AC2-wlan-st-1] ssid abc [AC2-wlan-st-1] bind wlan-ess 1 [AC2-wlan-st-1] authentication-method open-system [AC2-wlan-st-1] cipher-suite ccmp [AC2-wlan-st-1] security-ie rsn [AC2-wlan-st-1] service-template enable [AC2-wlan-st-1] quit # Configure the AP information. [AC2] wlan ap ap1 model MSM460-WW [AC2-wlan-ap-ap1] serial-id CN2AD330S8 [AC2-wlan-ap-ap1] radio 1 type dot11an [AC2-wlan-ap-ap1-radio-1] service-template 1 [AC2-wlan-ap-ap1-radio-1] radio enable [AC2-wlan-ap-ap1-radio-1] quit [AC2-wlan-ap-ap1] quit # Configure the source IP address of the IACTP tunnel as (the address of AC 2) and the IP address of the IACTP tunnel member (AC 1) as [AC2] wlan mobility-group roam [AC2-wlan-mg-roam] source ip [AC2-wlan-mg-roam] member ip # Enable the IACTP tunnel. [AC2-wlan-mg-roam] mobility-group enable [AC2-wlan-mg-roam] quit # Enable client information backup. [AC2] wlan backup-client enable # Enable the AC hot backup function. [AC2] hot-backup enable # Set VLAN 10 as the VLAN for AC hot backup. [AC2] hot-backup vlan 10 Verifying the configuration After you complete the configurations, use the display dot1x synchronization status command to display the 802.1X stateful failover status on AC 1 and AC 2. After the client passes 802.1X authentication, execute the display wlan client verbose command on AC 1 (the primary AC) to display detailed information about the client. Execute the display wlan client verbose command on AC 2 (the backup AC), and you can see the same client information as that on AC 1. Execute the display dot1x synchronization connection command on AC 1 and AC 2 to display the 802.1X synchronization information. You can see that the client information is the same on the ACs and 246

259 the primary and backup link states are different, indicating that the ACs have synchronized the client information. When AC 1 fails, AC 2 becomes active. In case of a primary/backup AC switchover, the client can access the network through AC 2 without being re-authenticated. Troubleshooting port security Cannot change port security mode when a user is online Symptom Analysis Solution Port security mode cannot be changed when an 802.1X authenticated or MAC authenticated user is online. [AC-WLAN-ESS1] undo port-security port-mode Error:Cannot configure port-security for there is 802.1X user(s) on line on port WLAN-ESS1. Changing port security mode is not allowed when an 802.1X authenticated or MAC authenticated user is online. 1. Unbind the interface from the service template. 2. Use the cut connection command to disconnect the user connection. 3. Use the undo port-security port-mode command to set the port security mode to norestrictions. 4. Set the port to operate in the desired port security mode. 247

260 Configuring a user profile Overview A user profile provides a configuration template to save predefined configurations, such as a Committed Access Rate (CAR) policy or a Quality of Service (QoS) policy. The user profile implements service applications on a per-user basis. Every time a user accesses the device, the device automatically applies the configurations in the user profile that are associated only with this user. User-based traffic policing is more flexible than interface-based traffic policing. In interface-based traffic policing, if a user moves between ports to access a device, you must remove the policy from the previous port, and then configure the same policy on the port being used to restrict user behaviors. The configuration task is tedious and error prone. The user profile supports working with PPPoE, 802.1X authentication, MAC authentication, and portal authentication, and restricts authenticated users' behaviors as follows: 1. After the authentication server verifies a user, the server sends the device the name of the user profile associated with the user. If the profile is enabled, the device applies the configurations in the user profile, and allows user access based on all valid configurations. If the user profile is disabled, the device denies the user access. 2. After the user logs out, the device automatically disables the configurations in the user profile, and the restrictions on the user access are removed. User profile configuration task list Task Creating a user profile Performing configurations in user profile view Enabling a user profile Remarks Required. Required. Required. Creating a user profile Before you create a user profile, complete the following tasks: Configure authentication parameters on the device. Perform configurations on the client, the device, and the authentication server. For example, configure the username, password, authentication scheme, domain, and bind the user profile with a user. To create a user profile: 248

261 Step Command Remarks 1. Enter system view. system-view N/A 2. Create a user profile, and enter its view. user-profile profile-name You can use the command to enter the view of an existing user profile. Performing configurations in user profile view After a user profile is created, perform configurations in user profile view. The configuration made in user profile view takes effect when the user profile is enabled and a user using the user profile goes online. Supported configurations include QoS policies, WLAN configurations, and firewall configurations. The QoS policies applied in user profile view support only the remark, car, and filter actions. For more information about QoS policies, see ACL and QoS Configuration Guide. For more information about WLAN configuration, see WLAN Configuration Guide. For more information about firewall configuration, see "Configuring firewall." Enabling a user profile Enable a user profile so that configurations in the profile can be applied by the device to restrict user behaviors. If the device detects that the user profile is disabled, the device denies the associated user, even if the user has been verified by the authentication server. You can only edit or remove the configurations in a disabled user profile. Disabling a user profile logs out the users that are using the user profile. To enable a user profile: Step Command Remarks 1. Enter system view. system-view N/A 2. Enable a user profile. user-profile profile-name enable A user profile is disabled by default. Displaying and maintaining user profile Task Command Remarks Display information about all the created user profiles. display user-profile [ { begin exclude include } regular-expression ] Available in any view. 249

262 Configuring password control Overview Password control refers to a set of functions provided by the local authentication server to control user login passwords, super passwords, and user login status based on predefined policies. The rest of this section describes password control functions in detail. Minimum password length By setting a minimum password length, you can enforce users to use passwords long enough for system security. If a user specifies a shorter password, the system rejects the setting and prompts the user to re-specify a password. Minimum password update interval This function allows you to set the minimum interval at which users can change their passwords. If a non-manage level user logs in to change the password but the time elapsed since the last change is less than this interval, the system denies the request. For example, if you set this interval to 48 hours, a non-manage level user cannot change the password twice within 48 hours. This prevents users from changing their passwords frequently. This function is not effective on users of the manage level. For information about user levels, see Fundamentals Configuration Guide. This function is not effective on a user who is prompted to change the password at the first login or a user whose password has just been aged out. Password aging Password aging imposes a lifecycle on a user password. After the password aging time expires, the user needs to change the password. If a user enters an expired password when logging in, the system displays an error message and prompts the user to provide a new password and to confirm it by entering it again. The new password must be a valid one and the user must enter exactly the same password when confirming it. Early notice on pending password expiration When a user logs in, the system checks whether the password will expire in a time equal to or less than the specified notification period. If so, the system notifies the user when the password will expire and provides a choice for the user to change the password. If the user sets a new password that is complexity-compliant, the system records the new password and the setup time. If the user chooses not to change the password or the user fails to change it, the system allows the user to log in using the current password. Telnet, SSH, and terminal users (log in to the device through console or AUX interfaces) can change their passwords by themselves, but FTP users can only have their passwords changed by the administrator. Login with an expired password You can allow a user to log in a certain number of times within a specific period of time after the password expires, so that the user does not need to change the password immediately. For example, if you set the maximum number of logins with an expired password to 3 and the time period to 15 days, a user can log in three times within 15 days after the password expires. 250

263 Password history With this feature enabled, the system maintains certain entries of passwords that a user has used. When a user changes the password, the system checks the new password against the used ones. The new password must be different from the used ones by at least four characters and the four characters must not be the same. Otherwise, the user will fail to change the password and the system displays an error message. You can set the maximum number of history password records for the system to maintain for each user. When the number of history password records exceeds your setting, the latest record overwrites the earliest one. Login attempt limit Limiting the number of consecutive failed login attempts can effectively prevent password guessing. If an FTP or VTY user fails authentication due to a password error, the system adds the user to a password control blacklist. If a user fails to provide the correct password after the specified number of consecutive attempts, the system takes action as configured: Prohibiting the user from logging in until the user is removed from the password control blacklist manually. Allowing the user to try continuously and removing the user from the password control blacklist when the user logs in to the system successfully or the blacklist entry times out (a blacklist entry times out after 1 minute). Prohibiting the user from logging in within a configurable period of time, and allowing the user to log in again after the period of time elapses or the user is removed from the password control blacklist. A password control blacklist can contain up to 1024 entries. A login attempt using a wrong username will undoubtedly fail, but the username will not be added into the password control blacklist. Users accessing the system through the console or AUX interface are not blacklisted, because the system is unable to obtain the IP addresses of these users and these users are privileged and therefore relatively secure to the system. Password composition policy A password can be a combination of characters from the following four types: Uppercase letters A to Z. Lowercase letters a to z. Digits 0 to 9. Special characters. For information about special characters, see the password command in Security Command Reference. Depending on the system's security requirements, you can set the minimum number of character types a password must contain and the minimum number of characters for each type, as shown in Table 13. Table 13 Password composition policy Password combination level Minimum number of character types Level 1 One One Level 2 Two One Minimum number of characters for each type 251

264 Password combination level Minimum number of character types Level 3 Three One Level 4 Four One Minimum number of characters for each type In non-fips mode, all the combination levels are available for a password. In FIPS mode, only the level 4 combination is available for a password. When a user sets or changes a password, the system checks if the password meets the composition requirement. If not, the system displays an error message. Password complexity checking policy A less complicated password such as a password containing the username or repeated characters is more likely to be cracked. For higher security, you can configure a password complexity checking policy to make sure all user passwords are relatively complicated. With such a policy configured, when a user configures a password, the system checks the complexity of the password. If the password is complexity-incompliant, the system refuses the password and displays a password configuration failure message. You can impose the following password complexity requirements: A password cannot contain the username or the reverse of the username. For example, if the username is abc, a password such as abc982 or 2cba is not complex enough. No character of the password appears three or more times consecutively. For example, password a111 is not complex enough. Password display in the form of a string of asterisks (*) For the sake of security, the password a user enters is displayed in the form of a string of asterisks (*). Authentication timeout management Authentication timeout management is only for Telnet and Terminal users. The authentication period is from when the server obtains the username to when the server finishes authenticating the user's password. If a user fails to log in within the configured period of time, the system tears down the connection. Maximum account idle time You can set the maximum account idle time so that accounts staying idle for this period of time become invalid. For example, if you set the maximum account idle time to 60 days and the user of the account test has not logged in successfully within 60 days after the last successful login, the account becomes invalid and the user is unable to log in again. Logging The system logs all successful password changing events and the events of adding users to the password control blacklist. FIPS compliance The device supports the FIPS mode that complies with NIST FIPS requirements. Support for features, commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and non-fips mode. 252

265 Password control configuration task list The password control functions can be configured in several views, and different views support different functions. The settings configured in different views or for different objects have different application ranges and different priorities: Global settings in system view apply to all local user passwords and super passwords. Settings in user group view apply to the passwords of all local users in the user group. Settings in local user view apply to only the password of the local user. Settings for super passwords apply to only super passwords. The previous four types of settings have the following priorities: For local user passwords, the settings with a smaller application scope have a higher priority. For super passwords, the settings configured specifically for super passwords, if any, override those configured in system view. To configure password control: Task at a glance (Required.) Enabling password control () Setting global password control parameters () Setting user group password control parameters () Setting local user password control parameters () Setting super password control parameters () Setting a local user password in interactive mode Enabling password control 1. Enable the global password control feature in system view. Password control configurations take effect only after the password control feature is enabled globally. 2. Enable password control functions individually. The following password control functions need to be enabled individually after the password control feature is enabled globally: Password aging Minimum password length Password history Password composition checking To enable password control: Step Command Remarks 1. Enter system view. system-view N/A 253

266 Step Command Remarks 2. Enable the global password control feature. 3. Enable a specific password control function. password-control enable password-control { aging composition history length } enable In non-fips mode, the global password control feature is disabled by default. In FIPS mode, the global password control feature is enabled and cannot be disabled by default. By default, all of the four password control functions are enabled. After global password control is enabled, local user passwords configured on the device are not displayed when you use the corresponding display command. Setting global password control parameters The password-control login-attempt command takes effect immediately and can affect the users already in the password control blacklist. Other password control configurations do not take effect on users that have been logged in or passwords that have been configured. To set global password control parameters: Step Command Remarks 1. Enter system view. system-view N/A 2. Set the password aging time. password-control aging aging-time 90 days by default. 3. Set the minimum password update interval. 4. Set the minimum password length. 5. Configure the password composition policy. 6. Configure the password complexity checking policy. password-control password update interval interval password-control length length password-control composition type-number type-number [ type-length type-length ] password-control complexity { same-character user-name } check 24 hours by default. 10 characters by default. In non-fips mode, a default password must contain at least one character type and at least one character for each type. In FIPS mode, a default password must contain at least four character types and at least one character for each type. By default, the system does not perform password complexity checking. 254

267 Step Command Remarks 7. Set the maximum number of history password records for each user. password-control history max-record-num 4 by default. 8. Specify the maximum number of login attempts and the action to be taken when a user fails to log in after the specified number of attempts. 9. Set the number of days during which the user is notified of the pending password expiration. 10. Set the maximum number of days and maximum number of times that a user can log in after the password expires. 11. Set the authentication timeout time. 12. Set the maximum account idle time. password-control login-attempt login-times [ exceed { lock lock-time time unlock } ] password-control alert-before-expire alert-time password-control expired-user-login delay delay times times password-control authentication-timeout authentication-timeout password-control login idle-time idle-time By default, the maximum number of login attempts is 3 and a user failing to log in after the specified number of attempts must wait for 1 minute before trying again. 7 days by default. By default, a user can log in three times within 30 days after the password expires. 60 seconds by default. 90 days by default. Setting user group password control parameters Step Command Remarks 1. Enter system view. system-view N/A 2. Create a user group and enter user group view. 3. Configure the password aging time for the user group. 4. Configure the minimum password length for the user group. 5. Configure the password composition policy for the user group. user-group group-name password-control aging aging-time password-control length length password-control composition type-number type-number [ type-length type-length ] N/A By default, the aging time of the user group is the same as the global password aging time. By default, the minimum password length of the user group is the same as the global minimum password length. By default, the password composition policy of the user group is the same as the global password composition policy. 255

268 Setting local user password control parameters Step Command Remarks 1. Enter system view. system-view N/A 2. Create a local user and enter local user view. 3. Configure the password aging time for the local user. 4. Configure the minimum password length for the local user. 5. Configure the password composition policy for the local user. local-user user-name password-control aging aging-time password-control length length password-control composition type-number type-number [ type-length type-length ] N/A By default, the setting equals that for the user group to which the local user belongs. If no aging time is configured for the user group, the global setting applies to the local user. By default, the setting equals that for the user group to which the local user belongs. If no minimum password length is configured for the user group, the global setting applies to the local user. By default, the settings equal those for the user group to which the local user belongs. If no password composition policy is configured for the user group, the global settings apply to the local user. Setting super password control parameters CLI commands include four levels: visit, monitor, system, and manage, in ascending order. Accordingly, login users include four levels, each corresponding to a command level. A user of a certain level can only use the commands at that level or lower levels. To switch from a lower user level to a higher one, a user needs to enter a password for authentication. This password is called a super password. For more information on super passwords, see Fundamentals Configuration Guide. To set super password control parameters: Step Command Remarks 1. Enter system view. system-view N/A 2. Set the password aging time for super passwords. password-control super aging aging-time By default, the super password aging time is the same as the global password aging time. 256

269 Step Command Remarks 3. Configure the minimum length for super passwords. 4. Configure the password composition policy for super passwords. password-control super length length password-control super composition type-number type-number [ type-length type-length ] By default, the minimum super password length is the same as the global minimum password length. By default, the super password composition policy is the same as the global password composition policy. Setting a local user password in interactive mode You can set a password for a local user in interactive mode. When doing so, you need to confirm the password. To set a password for a local user in interactive mode: Step Command 1. Enter system view. system-view 2. Create a local user and enter local user view. local-user user-name 3. Set the password for the local user in interactive mode. password Displaying and maintaining password control Task Command Remarks Display password control configuration information. Display information about users in the password control blacklist. Delete users from the password control blacklist. Clear history password records. display password-control [ super ] [ { begin exclude include } regular-expression ] display password-control blacklist [ user-name name ip ipv4-address ipv6 ipv6-address ] [ { begin exclude include } regular-expression ] reset password-control blacklist { all user-name name } reset password-control history-record [ user-name name super [ level level ] ] Available in any view. Available in any view. Available in user view. Available in user view. This command can delete the history password records of one or all users even when the password history function is disabled. 257

270 Password control configuration example The configuration example was created on the 11900/10500/ G unified wired-wlan module and might vary with device models. When configuring the 11900/10500/ G unified wired-wlan module, make sure the settings are correct (including VLAN settings) on the internal Ethernet interface that connects the module to the switch. For more information, see HP 11900/10500/ G Unified Wired-WLAN Module Basic Configuration Guide. By default, the aggregate interfaces between the access controller engine and the switching engine on an 830 switch or an 870 appliance are Access interfaces in VLAN 1. When configuring the two aggregate interfaces, make sure their permitted VLANs are the same. HP also recommends that you set their link type to be the same. Network requirements Configure a global password control policy to meet the following requirements: An FTP or VTY user failing to provide the correct password in two successive login attempts is permanently prohibited from logging in. A user can log in five times within 60 days after the password expires. The password expires after 30 days. The minimum password update interval is 36 hours. An account becomes invalid if it has been idle for 30 days. A password cannot contain the username or the reverse of the username. No character occurs consecutively three or more times in a password. Configure a super password control policy to meet the following requirements: A super password must contain at least three character types and at least five characters for each type. Configure a password control policy for the local Telnet user test to meet the following requirements: The password must contain at least 12 characters. The password must contain at least two character types and at least five characters for each type. The password for the local user expires after 20 days. Configuration procedure # Enable the password control feature globally. <AC> system-view [AC] password-control enable # Prohibit the user from logging in forever after two successive login failures. [AC] password-control login-attempt 2 exceed lock # Globally set all passwords to expire after 30 days. [AC] password-control aging 30 # Set the minimum password update interval to 36 hours. [AC] password-control password update interval 36 # Specify that a user can log in five times within 60 days after the password expires. [AC] password-control expired-user-login delay 60 times 5 # Set the maximum account idle time to 30 days. 258

271 [AC] password-control login idle-time 30 # Refuse any password that contains the username or the reverse of the username. [AC] password-control complexity user-name check # Specify that no character can appear three or more times consecutively in a password. [AC] password-control complexity same-character check # Specify that a super password must contain at least three character types and at least five characters for each type. [AC] password-control super composition type-number 3 type-length 5 # Configure a super password. [AC] super password level 3 simple 12345ABGFTweuix # Create a local user named test. [AC] local-user test # Set the service type of the user to Telnet. [AC-luser-test] service-type telnet # Set the minimum password length to 12 for the local user. [AC-luser-test] password-control length 12 # Specify that the password of the local user must contain at least two character types and at least five characters for each type. [AC-luser-test] password-control composition type-number 2 type-length 5 # Set the password for the local user to expire after 20 days. [AC-luser-test] password-control aging 20 # Configure the password of the local user in interactive mode. [AC-luser-test] password Password:*********** Confirm :*********** Updating user(s) information, please wait... [AC-luser-test] quit Verifying the configuration # Display the global password control configuration. <AC> display password-control Global password control configurations: Password control: Enabled Password aging: Enabled (30 days) Password length: Enabled (10 characters) Password composition: Enabled (1 types, 1 characters per type) Password history: Enabled (max history record:4) Early notice on password expiration: 7 days User authentication timeout: 60 seconds Maximum failed login attempts: 2 times Login attempt-failed action: Lock Minimum password update time: 36 hours User account idle-time: 30 days Login with aged password: 5 times in 60 day(s) Password complexity: Enabled (username checking) 259

272 Enabled (repeated characters checking) # Display the password control configuration for super passwords. <AC> display password-control super Super password control configurations: Password aging: Enabled (30 days) Password length: Enabled (10 characters) Password composition: Enabled (3 types, 5 characters per type) # Display the password control configuration for local user test. <AC> display local-user user-name test The contents of local user test: State: Active ServiceType: telnet Access-limit: Disable Current AccessNum: 0 User-group: system Bind attributes: Authorization attributes: Password aging: Enabled (20 days) Password length: Enabled (12 characters) Password composition: Enabled (2 types, 5 characters per type) Total 1 local user(s) matched. 260

273 Managing public keys To protect data confidentiality during transmission, the data sender uses an algorithm and a key to encrypt the plain text data before sending the data out. The receiver uses the same algorithm with the help of a key to decrypt the data, as shown in Figure 100. Figure 100 Encryption and decryption The keys that participate in the conversion between plain text and cipher text can be the same or different, dividing the encryption and decryption algorithms into the following types: Symmetric key algorithm The keys for encryption and decryption are the same. Asymmetric key algorithm The keys for encryption and decryption are different. One is the public key, and the other is the private key. The information encrypted with the public key can only be decrypted with the corresponding private key, and vice versa. The private key is kept secret, and the public key may be distributed widely. The private key cannot be practically derived from the public key. The device supports RSA and DSA asymmetric key algorithms. The asymmetric key algorithms can be used for the following purposes: To encrypt and decrypt data Any public key receiver can use the public key to encrypt information, but only the private key owner can decrypt the information. This mechanism ensures confidentiality. To authenticate a sender Also called "digital signature." The key owner uses the private key to "sign" information to be sent, and the receiver decrypts the information with the sender's public key to verify information authenticity. Asymmetric key algorithms are widely used in various applications. For example, SSH, SSL, and PKI use the algorithms for digital signature. For information about SSH, SSL, and PKI, see "Configuring SSH," "Configuring SSL," and "Configuring PKI." Configuration task list Public key configuration tasks enable you to manage the local asymmetric key pairs and configure the peer host public keys on the local device. By completing these tasks, the local device is ready to work with applications such as SSH and SSL to implement data encryption/decryption, or digital signature. Complete these tasks to configure public keys: Task Configuring a local asymmetric key pair on the local device Creating a local asymmetric key pair Displaying or exporting the local host public key Destroying a local asymmetric key pair Remarks Choose one or more tasks. 261

274 Task Remarks Specifying the peer public key on the local device Creating a local asymmetric key pair When you create a local asymmetric key pair, follow these guidelines: The key algorithm must be the same as required by the security application. The key modulus length must be appropriate (see Table 14). Table 14 A comparison of different types of asymmetric key algorithms Type Number of key pairs Modulus length Remarks RSA Two key pairs, one server key pair and one host key pair. Each key pair contains a public key and a private key In non-fips mode: 512 to 2048 bits and defaults to 1024 bits. In FIPS mode: 2048 bits. To achieve high security, specify at least 768 bits in non-fips mode. DSA One key pair, the host key pair. In non-fips mode: 512 to 2048 bits and defaults to 1024 bits. In FIPS mode: 2048 bits. To achieve high security, specify at least 768 bits in non-fips mode. IMPORTANT: Only SSH1.5 uses the RSA server key pair. To create a local asymmetric key pair: Step Command Remarks 1. Enter system view. system-view N/A By default, no asymmetric key pair exists. 2. Create a local asymmetric key pair. public-key local create { dsa rsa } If the type of the key pair to be created already exists, the system asks you whether you want to overwrite the existing key pair. The created key pairs are automatically saved and can survive system reboots. Displaying or exporting the local host public key In some applications, such as SSH, to allow your local device to be authenticated by a peer device through digital signature, you must display or export the local host public key, which will then be specified on the peer device. To display or export the local host public key, choose one of the following methods: Displaying and recording the host public key information Displaying the host public key in a specific format and saving it to a file Exporting the host public key in a specific format to a file 262

275 If your local device functions to authenticate the peer device, you must specify the peer public key on the local device. For more information, see "Specifying the peer public key on the local device." Displaying and recording the host public key information Task Command Remarks Display the local RSA public keys. Display the local DSA public keys. display public-key local rsa public [ { begin exclude include } regular-expression ] display public-key local dsa public [ { begin exclude include } regular-expression ] Available in any view. Use at least one command. The display public-key local rsa public command displays both the RSA server and host public keys. Recording the RSA host public key is enough. After you display the host public key, record the key information for manual configuration of the key on the peer device. Displaying the host public key in a specific format and saving it to a file After you display the host public key in a specific format, save the key to a file, and transfer the file to the peer device. To display a local host public key in a specific format: Step Command Remarks 1. Enter system view. system-view N/A 2. Display the local host public key in a specific format. Display the local RSA host public key in a specific format: In non-fips mode: public-key local export rsa { openssh ssh1 ssh2 } In FIPS mode: public-key local export rsa { openssh ssh2 } Display the local DSA host public key in a specific format: public-key local export dsa { openssh ssh2 } Use at least one command. Exporting the host public key in a specific format to a file After you export a host public key in a specific format to a file, transfer the file to the peer device. 263

276 To export a local host public key in a specific format to a file: Step Command Remarks 1. Enter system view. system-view N/A 2. Export a local host public key in a specific format to a file. Export a local RSA host public key in a specific format to a file: In non-fips mode: public-key local export rsa { openssh ssh1 ssh2 } filename In FIPS mode: public-key local export rsa { openssh ssh2 } filename Export a local DSA host public key in a specific format to a file: public-key local export dsa { openssh ssh2 } filename Use at least one command. Destroying a local asymmetric key pair You might have to destroy a local asymmetric key pair and generate a new pair when an intrusion event has occurred, the storage media of the device is replaced, the asymmetric key has been used for a long time, or the local certificate expires. For more information about the local certificate, see "Configuring PKI." To destroy a local asymmetric key pair: Step Command 1. Enter system view. system-view 2. Destroy a local asymmetric key pair. public-key local destroy { dsa rsa } Specifying the peer public key on the local device In SSH, to enable the local device to authenticate a peer device, specify the peer public key on the local device. The device supports up to 20 peer public keys. For information about displaying or exporting the host public key, see "Displaying or exporting the local host public key." 264

277 To specify the peer public key on the local device: Method Prerequisites Remarks Import the public key from a public key file (recommended) Manually configure the public key input or copy the key data 1. Save the host public key of the intended asymmetric key pair in a file. 2. Transfer a copy of the file through FTP or TFTP in binary mode to the local device. Display and record the public key of the intended asymmetric key pair. If the peer device is an H3C device, use the display public-key local public command to view and record its public key. A public key displayed by other methods for the H3C device might not be in a correct format. During the import process, the system automatically converts the public key to a string in Public Key Cryptography Standards (PKCS) format. The recorded public key must be in the correct format. Otherwise, the manual configuration of a format-incompliant public key will fail. Always use the first method if you are not sure about the format of the recorded public key. To import the host public key from a public key file to the local device: Step Command 1. Enter system view. system-view 2. Import the host public key from the public key file. public-key peer keyname import sshkey filename To manually configure the peer public key on the local device: Step Command Remarks 1. Enter system view. system-view N/A 2. Specify a name for the public key and enter public key view. public-key peer keyname N/A 3. Enter public key code view. public-key-code begin N/A 4. Configure the peer public key. Type or copy the key 5. Return to public key view. public-key-code end Spaces and carriage returns are allowed between characters. When you exit public key code view, the system automatically saves the public key. 6. Return to system view. peer-public-key end N/A Displaying public keys Task Command Remarks Display the local public keys Display the specified or all peer public keys on the local device. display public-key local { dsa rsa } public [ { begin exclude include } regular-expression ] display public-key peer [ brief name publickey-name ] [ { begin exclude include } regular-expression ] Available in any view. Available in any view. 265

278 Public key configuration examples The configuration examples were created on the 11900/10500/ G unified wired-wlan module and might vary with device models. When configuring the 11900/10500/ G unified wired-wlan module, make sure the settings are correct (including VLAN settings) on the internal Ethernet interface that connects the module to the switch. For more information, see HP 11900/10500/ G Unified Wired-WLAN Module Basic Configuration Guide. By default, the aggregate interfaces between the access controller engine and the switching engine on an 830 switch or an 870 appliance are Access interfaces in VLAN 1. When configuring the two aggregate interfaces, make sure their permitted VLANs are the same. HP also recommends that you set their link type to be the same. Manually specifying the peer public key on the local device Network requirements As shown in Figure 101, to prevent illegal access, the AC authenticates the device (the peer device) through a digital signature. Before configuring authentication parameters on the device, configure the public key of the device on the AC. Configure the AC to use the asymmetric key algorithm of RSA to authenticate the device. Manually specify the host public key of the device's public key pair on the AC. Figure 101 Network diagram Configuration procedure 1. Configure the device: # Create local RSA key pairs on the device, setting the modulus length to the default, 1024 bits. <Device> system-view [Device] public-key local create rsa The range of public key size is (512 ~ 2048). NOTES: If the key modulus is greater than 512, It will take a few minutes. Press CTRL+C to abort. Input the bits of the modulus[default = 1024]: Generating Keys # Display the public keys of the local RSA key pairs. [Device] display public-key local rsa public 266

279 ===================================================== Time of Key pair created: 09:50: /08/07 Key name: HOST_KEY Key type: RSA Encryption Key ===================================================== Key code: 30819F300D06092A864886F70D D D90003FA95F5A44A2A2CD3F 814F9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E7 66BD995C669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA DC078B2BAA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A ===================================================== Time of Key pair created: 09:50: /08/07 Key name: SERVER_KEY Key type: RSA Encryption Key ===================================================== Key code: 307C300D06092A864886F70D B E7AEE D9EB2D0433B87 BB6158E35000AFB3FF310E42F109829D65BF70F BE1A3E0BC5C2C03FAAF00DFDDC63D004B44 90DACBA3CFA9E84B9151BDC7EECE1C8770D961557D192DE2B36CAF9974B7B293363BB372771C2C1F Configure the AC: # Configure the host public key of the device's RSA key pairs on the AC. In public key code view, enter the host public key of the device. The host public key is the content of HOST_KEY displayed on the device by using the display public-key local rsa public command. <AC> system-view [AC] public-key peer device Public key view: return to System View with "peer-public-key end". [AC-pkey-public-key] public-key-code begin Public key code view: return to last view with "public-key-code end". [AC-pkey-key-code]30819F300D06092A864886F70D D D9000 3FA95F5A44A2A2CD3F814F9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51 E5E353B3A9AB16C9E766BD995C669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14AB C62DB125035EA DC078B2BAA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B 2BF9C4A [AC-pkey-key-code] public-key-code end [AC-pkey-public-key] peer-public-key end # Display the host public key of the device saved on the AC. [AC] display public-key peer name device ===================================== Key Name : device Key Type : RSA Key Module: 1024 ===================================== Key Code: 30819F300D06092A864886F70D D D90003FA95F5A44A2A2CD3F 814F9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E7 66BD995C669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA DC078B2BAA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A

280 The output shows that the host public key of the device saved on the AC is consistent with the one created on the device. Importing a public key from a public key file Network requirements As shown in Figure 102, to prevent illegal access, the AC (the local device) authenticates the device (the peer device) through a digital signature. Before configuring authentication parameters on the device, configure the public key of the device on the AC Configure the AC to use the asymmetric key algorithm of RSA to authenticate Device A. Import the host public key of the device from the public key file to the AC. Figure 102 Network diagram Configuration procedure 1. Create key pairs on the device and export the host public key: # Create local RSA key pairs on the device, setting the modulus length to the default, 1024 bits. <Device> system-view [Device] public-key local create rsa The range of public key size is (512 ~ 2048). NOTES: If the key modulus is greater than 512, It will take a few minutes. Press CTRL+C to abort. Input the bits of the modulus[default = 1024]: Generating Keys # Display the public keys of the local RSA key pairs. [Device] display public-key local rsa public ===================================================== Time of Key pair created: 09:50: /08/07 Key name: HOST_KEY Key type: RSA Encryption Key ===================================================== Key code: 30819F300D06092A864886F70D D D90003FA95F5A44A2A2CD3F 814F9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E7 66BD995C669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA DC078B2BAA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A ===================================================== 268

281 Time of Key pair created: 09:50: /08/07 Key name: SERVER_KEY Key type: RSA Encryption Key ===================================================== Key code: 307C300D06092A864886F70D B E7AEE D9EB2D0433B87 BB6158E35000AFB3FF310E42F109829D65BF70F BE1A3E0BC5C2C03FAAF00DFDDC63D004B44 90DACBA3CFA9E84B9151BDC7EECE1C8770D961557D192DE2B36CAF9974B7B293363BB372771C2C1F # Export the RSA host public key HOST_KEY to a file named device.pub. [Device] public-key local export rsa ssh2 device.pub 2. Enable the FTP server function on the device: # Enable the FTP server function, and create an FTP user with the username ftp, password 123, and user level 3. This user level makes sure the user has the permission to perform FTP operations. [Device] ftp server enable [Device] local-user ftp [Device-luser-ftp] password simple 123 [Device-luser-ftp] service-type ftp [Device-luser-ftp] authorization-attribute level 3 [Device-luser-ftp] quit 3. On the AC, get the public key file of the device: # From the AC, use FTP to log in to the device, and get the public key file device.pub with the file transfer mode of binary. <AC> ftp Trying Press CTRL+K to abort Connected to FTP service ready. User( :(none)):ftp 331 Password required for ftp. Password: 230 User logged in. [ftp] binary 200 Type set to I. [ftp] get device.pub 227 Entering Passive Mode (10,1,1,1,5,148). 125 BINARY mode data connection already open, transfer starting for /device.pub. 226 Transfer complete. FTP: 299 byte(s) received in second(s), 1.00Kbyte(s)/sec. [ftp] quit 221 Server closing. 4. Import the host public key of the device to the AC: # Import the host public key of the device from the key file device.pub to the AC. <AC> system-view [AC] public-key peer device import sshkey device.pub # Display the host public key of the device on the AC. 269

282 [AC] display public-key peer name device ===================================== Key Name : device Key Type : RSA Key Module: 1024 ===================================== Key Code: 30819F300D06092A864886F70D D D90003FA95F5A44A2A2CD3F 814F9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E7 66BD995C669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA DC078B2BAA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A The output shows that the host public key of the device saved on the AC is consistent with the one created on the device. 270

283 Configuring PKI Overview PKI terms Digital certificate CRL The PKI uses a general security infrastructure to provide information security through public key technologies. PKI, also called asymmetric key infrastructure, uses a key pair to encrypt and decrypt the data. The key pair consists of a private key and a public key. The private key must be kept secret, but the public key needs to be distributed. Data encrypted by one of the two keys can only be decrypted by the other. A key problem with PKI is how to manage the public keys. PKI employs the digital certificate mechanism to solve this problem. The digital certificate mechanism binds public keys to their owners, helping distribute public keys in large networks securely. With digital certificates, the PKI system provides network communication and e-commerce with security services such as user authentication, data non-repudiation, data confidentiality, and data integrity. HP's PKI system provides certificate management for IPsec and SSL. A digital certificate is a file signed by a certificate authority (CA) for an entity. It includes mainly the identity information of the entity, the public key of the entity, the name and signature of the CA, and the validity period of the certificate, where the signature of the CA ensures the validity and authority of the certificate. A digital certificate must comply with the international standard of ITU-T X.509. The most common standard is X.509 v3. This document involves local certificate and CA certificate. A local certificate is a digital certificate signed by a CA for an entity, and a CA certificate is the certificate of a CA. If multiple CAs are trusted by different users in a PKI system, the CAs will form a CA tree with the root CA at the top level. The root CA has a CA certificate signed by itself and each lower level CA has a CA certificate signed by the CA at the next higher level. An existing certificate might need to be revoked when, for example, the username changes, the private key leaks, or the user stops the business. Revoking a certificate will remove the binding of the public key with the user identity information. In PKI, the revocation is made through certificate revocation lists (CRLs). Whenever a certificate is revoked, the CA publishes one or more CRLs to show all certificates that have been revoked. The CRLs contain the serial numbers of all revoked certificates and provide an effective way for checking the validity of certificates. A CA might publish multiple CRLs when the number of revoked certificates is so large that publishing them in a single CRL might degrade network performance, and it uses CRL distribution points to indicate the URLs of these CRLs. 271

284 CA policy A CA policy is a set of criteria that a CA follows in processing certificate requests, issuing and revoking certificates, and publishing CRLs. Usually, a CA advertises its policy in the form of certification practice statement (CPS). A CA policy can be acquired through out-of-band means such as phone, disk, and . Because different CAs might use different methods to examine the binding of a public key with an entity, make sure you understand the CA policy before selecting a trusted CA for certificate request. PKI architecture A PKI system consists of entities, a CA, a registration authority (RA) and a PKI repository, as shown in Figure 103. Figure 103 PKI architecture Entity CA RA PKI repository An entity is an end user of PKI products or services, such as a person, an organization, a device like a router or a switch, or a process running on a computer. A CA is a trusted authority responsible for issuing and managing digital certificates. A CA issues certificates, specifies the validity periods of certificates, and revokes certificates as needed by publishing CRLs. A registration authority (RA) is an extended part of a CA or an independent authority. An RA can implement functions including identity authentication, CRL management, key pair generation and key pair backup. The PKI standard recommends that an independent RA be used for registration management to achieve higher security of application systems. A PKI repository can be a Lightweight Directory Access Protocol (LDAP) server or a common database. It stores and manages information like certificate requests, certificates, keys, CRLs and logs when it provides a simple query function. LDAP is a protocol for accessing and managing PKI information. An LDAP server stores user information and digital certificates from the RA server and provides directory navigation service. From an LDAP server, an entity can obtain local and CA certificates of its own as well as certificates of other entities. 272

285 PKI operation In a PKI-enabled network, an entity can request a local certificate from the CA, and the device can check the validity of certificates. Here is how it works: 1. An entity submits a certificate request to the RA. 2. The RA reviews the identity of the entity, and then sends the identity information and the public key with a digital signature to the CA. 3. The CA verifies the digital signature, approves the application, and issues a certificate. 4. The RA receives the certificate from the CA, sends it to the LDAP server or other distribution points to provide directory navigation service, and notifies the entity that the certificate is successfully issued. 5. The entity retrieves the certificate. With the certificate, the entity can communicate with other entities safely through encryption and digital signature. 6. The entity makes a request to the CA when it needs to revoke its certificate. The CA approves the request, updates the CRLs and publishes the CRLs on the LDAP server or other distribution points. PKI applications The PKI technology can satisfy the security requirements of online transactions. As an infrastructure, PKI has a wide range of applications. The following lists some common application examples: VPN A VPN is a private data communication network built on the public communication infrastructure. A VPN can leverage network layer security protocols (for instance, IPsec) in conjunction with PKI-based encryption and digital signature technologies for confidentiality. Secure s require confidentiality, integrity, authentication, and non-repudiation. PKI can address these needs. The secure protocol that is developing rapidly is S/MIME, which is based on PKI and allows for transfer of encrypted mails with signature. Web security For web security, two peers can establish an SSL connection first for transparent and secure communications at the application layer. With PKI, SSL enables encrypted communications between a browser and a server. Both of the communication parties can verify each other's identity through digital certificates. PKI configuration task list Task Configuring a PKI entity Configuring a PKI domain Requesting a certificate Obtaining certificates Verifying PKI certificates Destroying the local RSA key pair Removing a certificate Configuring automatic certificate request Manually requesting a certificate Remarks Required. Required. Required. Use either method. 273

286 Task Configuring a certificate access control policy Remarks Configuring a PKI entity A certificate is the binding of a public key and the identity information of an entity, where the identity information is identified by an entity distinguished name (DN). A CA identifies a certificate applicant uniquely by entity DN. An entity DN is defined by these parameters: Common name of the entity. Country code of the entity, a standard 2-character code. For example, CN represents China and US represents the United States. FQDN of the entity, a unique identifier of an entity on the network. It consists of a host name and a domain name and can be resolved to an IP address. For example, is an FQDN, where www is a host name and whatever.com a domain name. IP address of the entity. Locality where the entity resides. Organization to which the entity belongs. Unit of the entity in the organization. State where the entity resides. The configuration of an entity DN must comply with the CA certificate issue policy. You need to determine, for example, which entity DN parameters are mandatory and which are optional. Otherwise, certificate requests might be rejected. To configure a PKI entity: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an entity and enter its view. 3. Configure the common name for the entity. 4. Configure the country code for the entity. 5. Configure the FQDN for the entity. 6. Configure the IP address for the entity. 7. Configure the locality for the entity. pki entity entity-name common-name name country country-code-str fqdn name-str ip ip-address locality locality-name No entity exists by default. You can create up to two entities on a device. No common name is specified by default. No country code is specified by default. No FQDN is specified by default. No IP address is specified by default. No locality is specified by default. 274

287 Step Command Remarks 8. Configure the organization name for the entity. 9. Configure the unit name for the entity. 10. Configure the state or province for the entity. organization org-name organization-unit org-unit-name state state-name No organization is specified by default. No unit is specified by default. No state or province is specified by default. NOTE: The Windows 2000 CA server has some restrictions on the data length of a certificate request. If the entity DN in a certificate request goes beyond a certain limit, the server will not respond to the certificate request. Configuring a PKI domain Before requesting a PKI certificate, an entity needs to be configured with some enrollment information, which is referred to as a PKI domain. A PKI domain is intended only for convenience of reference by other applications like IKE and SSL, and has only local significance. The PKI domain configured on a device is invisible to the CA and other devices, and each PKI domain has its own parameters. A PKI domain is defined by these parameters: Trusted CA An entity requests a certificate from a trusted CA. Entity A certificate applicant uses an entity to provide its identity information to a CA. RA Generally, an independent RA is in charge of certificate request management. It receives the registration request from an entity, examines its qualification, and determines whether to ask the CA to sign a digital certificate. The RA only examines the application qualification of an entity. It does not issue any certificate. Sometimes, the registration management function is provided by the CA, in which case no independent RA is required. HP recommends you to deploy an independent RA. URL of the registration server An entity sends a certificate request to the registration server through SCEP, a dedicated protocol for an entity to communicate with a CA. Polling interval and count After an applicant makes a certificate request, the CA might need a long period of time if it verifies the certificate request manually. During this period, the applicant needs to query the status of the request periodically to get the certificate as soon as possible after the certificate is signed. You can configure the polling interval and count to query the request status. IP address of the LDAP server An LDAP server is usually deployed to store certificates and CRLs. If this is the case, you need to configure the IP address of the LDAP server. Fingerprint for root certificate verification After receiving the root certificate of the CA, an entity needs to verify the fingerprint of the root certificate, namely, the hash value of the root certificate content. This hash value is unique to every certificate. If the fingerprint of the root certificate does not match the one configured for the PKI domain, the entity will reject the root certificate. To configure a PKI domain: Step Command Remarks 1. Enter system view. system-view N/A 275

288 Step Command Remarks 2. Create a PKI domain and enter its view. pki domain domain-name No PKI domain exists by default. You can configure up to 32 PKI domains on a device. 3. Specify the trusted CA. ca identifier name No trusted CA is specified by default. The CA name is required only when you obtain a CA certificate. It is not used for local certificate request. 4. Specify the entity for certificate request. 5. Specify the authority for certificate request. 6. Configure the URL of the server for certificate request. 7. Configure the polling interval and attempt limit for querying the certificate request status. 8. Specify the LDAP server. 9. Configure the fingerprint for root certificate verification. certificate request entity entity-name certificate request from { ca ra } certificate request url url-string certificate request polling { count count interval minutes } ldap-server ip ip-address [ port port-number ] [ version version-number ] root-certificate fingerprint { md5 sha1 } string No entity is specified by default. The specified entity must exist. No authority is specified by default. No URL is configured by default. The URL does not support domain name resolution. By default, the polling interval is 20 minutes, and the maximum number of attempts is 50. No LDP server is specified by default. Required when the certificate request mode is auto and optional when the certificate request mode is manual. In the latter case, if you do not configure this command, the fingerprint of the root certificate must be verified manually. No fingerprint is configured by default. Requesting a certificate When you request a certificate for an entity, the entity introduces itself to the CA by providing its identity information and public key, which will be the major components of the certificate. A certificate request can be submitted to a CA in offline mode or online mode. In offline mode, a certificate request is submitted to a CA by an out-of-band means such as phone, disk, or . Online certificate request falls into manual mode and auto mode. Configuring automatic certificate request In auto mode, an entity automatically requests a certificate from the CA server if it has no local certificate for an application working with PKI. The entity requests the certificate through SCEP, and saves the local certificate after retrieving it from the CA. If the PKI domain has no CA certificate before the entity submits the certificate request, the entity automatically retrieves the CA certificate first. 276

289 If an automatically requested certificate will expire or has expired, the entity does not initiate a re-request to the CA automatically, and the services using the certificate might be interrupted. To configure automatic certificate request: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter PKI domain view. pki domain domain-name N/A 3. Set the certificate request mode to auto. certificate request mode auto [ key-length key-length password { cipher simple } password ] * Manual by default. Manually requesting a certificate In manual mode, you must submit a local certificate request for an entity. Before the request, you must obtain a CA certificate and generate a key pair for the PKI domain. The CA certificate in the PKI domain is used to verify the authenticity and validity of a local certificate. Generating a key pair is an important step in certificate request. The key pair includes a public key and a private key. The private key is kept by the user. The public key is transferred to the CA along with some other information. For more information about RSA key pair configuration, see "Managing public keys." Configuration guidelines If a PKI domain already has a local certificate, creating an RSA key pair might result in inconsistency between the key pair and the certificate. To generate a new RSA key pair, delete the local certificate, and then execute the public-key local create command. For more information about the public-key local create command, see Security Command Reference. A newly created key pair overwrites the existing one. If you perform the public-key local create command in the presence of a local RSA key pair, the system asks you whether you want to overwrite the existing one. If a PKI domain already has a local certificate, you cannot request another certificate for it. This helps avoid inconsistency between the certificate and the registration information resulting from configuration changes. Before requesting a new certificate, use the pki delete-certificate command to delete the existing local certificate and the CA certificate stored locally. When it is impossible to request a certificate from the CA through SCEP, you can print the request information or save the request information to a local file, and then send the printed information or saved file to the CA by an out-of-band means. To print the request information, use the pki request-certificate domain command with the pkcs10 keyword. To save the request information to a local file, use the pki request-certificate domain command with the pkcs10 filename filename option. Make sure the clocks of the entity and the CA are synchronous. Otherwise, the validity period of the certificate is abnormal. In FIPS mode, you cannot import MD5 certificates. Configuration procedure To manually request a certificate: 277

290 Step Command Remarks 1. Enter system view. system-view N/A 2. Enter PKI domain view. pki domain domain-name N/A 3. Set the certificate request mode to manual. certificate request mode manual Manual by default. 4. Return to system view. quit N/A 5. Retrieve a CA certificate manually. 6. Generate a local RSA key pair. 7. Submit a local certificate request manually. See "Obtaining certificates" public-key local create rsa pki request-certificate domain domain-name [ password ] [ pkcs10 [ filename filename ] ] N/A By default, no local RSA key pair exists. In FIPS mode, the RSA key modulus length must be 2048 bits. This command is not saved in the configuration file. Obtaining certificates You can download CA certificates or local certificates from the CA server and save them locally. To do so, use either the offline mode or the online mode. In offline mode, you must obtain a certificate by an out-of-band means such as FTP, disk, or , and then import it into the local PKI system. Certificate retrieval serves the following purposes: Locally store the certificates associated with the local security domain for improved query efficiency and reduced query count. Prepare for certificate verification. Before retrieving a local certificate in online mode, make sure to complete LDAP server configuration. If a PKI domain already has a CA certificate, you cannot obtain another CA certificate for it. This restriction helps avoid inconsistency between the certificate and registration information resulting from configuration changes. To obtain a new CA certificate, use the pki delete-certificate command to delete the existing CA certificate and the local certificate first. Be sure that the device system time falls in the validity period of the certificate so that the certificate is valid. To obtain certificates: Step Command Remarks 1. Enter system view. system-view N/A 2. Retrieve a certificate manually In online mode: pki retrieval-certificate { ca local } domain domain-name In offline mode: pki import-certificate { ca local } domain domain-name { der p12 pem } [ filename filename ] Use either command. The pki retrieval-certificate configuration is not saved in the configuration file. 278

291 Verifying PKI certificates A certificate needs to be verified before you use it. Verifying a certificate examines that the certificate is signed by the CA and that the certificate has neither expired nor been revoked. You can specify whether CRL checking is required in certificate verification. If you enable CRL checking, CRLs are used in verification of a certificate. In this case, make sure to obtain the CA certificate and CRLs to the local device before the certificate verification. If you disable CRL checking, you only need to obtain the CA certificate. The CRL update period defines the interval at which the entity downloads CRLs from the CRL server. The CRL update period setting manually configured on the device takes precedence over that carried in the CRLs. Verifying certificates with CRL checking Step Command Remarks 1. Enter system view. system-view N/A 2. Enter PKI domain view. pki domain domain-name N/A 3. Specify the URL of the CRL distribution point. crl url url-string No CRL distribution point URL is specified by default. The CRL distribution point URL does not support DNS. Do not include domain names in the URL. 4. Set the CRL update period. crl update-period hours 5. Enable CRL checking. crl check enable By default, the CRL update period depends on the next update field in the CRL file. Enabled by default. 6. Return to system view. quit N/A 7. Retrieve the CA certificate. See "Obtaining certificates" N/A 8. Retrieve the CRLs. 9. Verify the validity of a certificate. pki retrieval-crl domain domain-name pki validate-certificate { ca local } domain domain-name This command is not saved in the configuration file. N/A Verifying certificates without CRL checking Step Command Remarks 1. Enter system view. system-view N/A 2. Enter PKI domain view. pki domain domain-name N/A 3. Disable CRL checking. crl check disable Enabled by default. 279

292 Step Command Remarks 4. Return to system view. quit N/A 5. Retrieve the CA certificate. See "Obtaining certificates" N/A 6. Verify the validity of the certificate. pki validate-certificate { ca local } domain domain-name N/A Destroying the local RSA key pair A certificate has a lifetime, which is determined by the CA. When the private key leaks or the certificate is about to expire, you can destroy the old RSA key pair, and then create a pair to request a new certificate. To destroy the local RSA key pair: Step Command 1. Enter system view. system-view 2. Destroy a local RSA key pair. public-key local destroy rsa Removing a certificate When a certificate requested manually is about to expire or you want to request a new certificate, you can delete the current local certificate or CA certificate. To remove a certificate: Step Command 1. Enter system view. system-view 2. Delete certificates. pki delete-certificate { ca local } domain domain-name Configuring a certificate access control policy By configuring a certificate access control policy, you can further control access to the server, providing additional security for the server. To configure a certificate access control policy: Step Command Remarks 1. Enter system view. system-view N/A 2. Create a certificate attribute group and enter its view. pki certificate attribute-group group-name No certificate attribute group exists by default. 280

293 Step Command Remarks 3. Configure an attribute rule for the certificate issuer name, certificate subject name, or alternative subject name. attribute id { alt-subject-name { fqdn ip } { issuer-name subject-name } { dn fqdn ip } } { ctn equ nctn nequ } attribute-value No restriction exists on the issuer name, certificate subject name and alternative subject name by default. 4. Return to system view. quit N/A 5. Create a certificate access control policy and enter its view. 6. Configure a certificate access control rule. pki certificate access-control-policy policy-name rule [ id ] { deny permit } group-name No access control policy exists by default. No access control rule exists by default. A certificate attribute group must exist to be associated with a rule. Displaying and maintaining PKI Task Command Remarks Display the contents or request status of a certificate. Display CRLs. Display information about one or all certificate attribute groups. Display information about one or all certificate access control policies. display pki certificate { { ca local } domain domain-name request-status } [ { begin exclude include } regular-expression ] display pki crl domain domain-name [ { begin exclude include } regular-expression ] display pki certificate attribute-group { group-name all } [ { begin exclude include } regular-expression ] display pki certificate access-control-policy { policy-name all } [ { begin exclude include } regular-expression ] Available in any view. Available in any view. Available in any view. Available in any view. PKI configuration examples IMPORTANT: When the CA uses Windows Server, the SCEP add-on is required. You must use the certificate request from ra command to specify that the entity requests a certificate from an RA. When the CA uses RSA Keon, the SCEP add-on is not required. You must use the certificate request from ca command to specify that the entity requests a certificate from a CA. The configuration examples were created on the 11900/10500/ G unified wired-wlan module and might vary with device models. 281

294 When configuring the 11900/10500/ G unified wired-wlan module, make sure the settings are correct (including VLAN settings) on the internal Ethernet interface that connects the module to the switch. For more information, see HP 11900/10500/ G Unified Wired-WLAN Module Basic Configuration Guide. By default, the aggregate interfaces between the access controller engine and the switching engine on an 830 switch or an 870 appliance are Access interfaces in VLAN 1. When configuring the two aggregate interfaces, make sure their permitted VLANs are the same. HP also recommends that you set their link type to be the same. Certificate request from an RSA Keon CA server Network requirements As shown in Figure 104, the AC submits a local certificate request to the CA server. The AC acquires the CRLs for certificate verification. Figure 104 Network diagram Configure the CA server 1. Create a CA server named myca: In this example, configure these basic attributes on the CA server: Nickname Name of the trusted CA. Subject DN DN information of the CA, including the Common Name (CN), Organization Unit (OU), Organization (O), and Country (C). You can use the default values for the other attributes. 2. Configure extended attributes: Enter the management interface for the CA server, and do the following for the jurisdiction configuration: Select the proper extension profiles. Enable the SCEP autovetting function. Specify the IP address list for SCEP autovetting. 3. Configure the CRL distribution behavior. After completing the previous configuration, you must perform CRL related configurations. In this example, select the local CRL distribution mode of HTTP and set the HTTP URL to 282

295 Configure the AC 1. Synchronize the system time of the AC with the CA server, so that the AC can correctly request a certificate. 2. Configure the entity name as aaa and the common name as name. <AC> system-view [AC] pki entity aaa [AC-pki-entity-aaa] common-name name [AC-pki-entity-aaa] quit 3. Configure the PKI domain: # Create PKI domain torsa and enter its view. [AC] pki domain torsa # Configure the name of the trusted CA as myca. [AC-pki-domain-torsa] ca identifier myca # Configure the URL of the registration server in the format of [AC-pki-domain-torsa] certificate request url # Set the registration authority to CA. [AC-pki-domain-torsa] certificate request from ca # Specify the entity for certificate request as aaa. [AC-pki-domain-torsa] certificate request entity aaa # Configure the URL for the CRL distribution point. [AC-pki-domain-torsa] crl url [AC-pki-domain-torsa] quit 4. Generate a local host key pair using RSA: [AC] public-key local create rsa The range of public key size is (512 ~ 2048). NOTES: If the key modulus is greater than 512, It will take a few minutes. Press CTRL+C to abort. Input the bits in the modulus [default = 1024]: Generating Keys Apply for certificates: # Retrieve the CA certificate and save it locally. [AC] pki retrieval-certificate ca domain torsa Retrieving CA/RA certificates. Please wait a while... The trusted CA's finger print is: MD5 fingerprint:ede A273 B61A F1B A0B1 F9AB SHA1 fingerprint: 77F9 A077 2FB8 088C 550B A33C 2410 D354 23B2 73A8 Is the finger print correct?(y/n):y Saving CA/RA certificates chain, please wait a moment... CA certificates retrieval success. 283

296 # Retrieve CRLs and save them locally. [AC] pki retrieval-crl domain torsa Connecting to server for retrieving CRL. Please wait a while... CRL retrieval success! # Request a local certificate manually. [AC]pki request-certificate domain torsa Certificate is being requested, please wait... Enrolling the local certificate,please wait a while... [AC] Certificate request Successfully! Saving the local certificate to device... Done! Verifying the configuration # Use the following command to view information about the local certificate acquired. <AC> display pki certificate local domain torsa Certificate: Data: Version: 3 (0x2) Serial Number: 9A96A48F 9A509FD7 05FFF4DF 104AD094 Signature Algorithm: sha1withrsaencryption Issuer: C=cn O=org OU=test CN=myca Validity Not Before: Jan 8 09:26: GMT Not After : Jan 8 09:26: GMT Subject: CN=aaa Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00D67D F6A CA6C4B11 F8F89138 E4E905BD 43953BA2 623A54C0 EA3CB6E0 B04649CE C9CDDD E96D9 FF4F7B73 A E583AC61 D3A5C849 CBDE350D 2A1926B7 0AE5EF5E D1D8B08A DBF C2A F EB0549 A65D9E74 0F2953F2 D4F0042F D4F FB59F3 8D4B2F6C 2B Exponent: (0x10001) X509v3 extensions: X509v3 CRL Distribution Points: 284

297 URI: Signature Algorithm: sha1withrsaencryption A4 F2F74C1A 50F4100D B764D6CE B30C0133 C4363F2F 73454D51 E9F95962 EDE9E590 E7458FA6 765A0D3F C4047BC2 9C391FF0 7383C4DF 9A0CCFA AF 987B029C C857AD96 E4C E798 8FCC1E4A 3E598D E2F86C33 75B51661 B6556C5E 8F546E B C8C29AC7 E427C8E4 B9AAF5AA 80A75B3C You can also use some other display commands to view detailed information about the CA certificate and CRLs. For more information about the display pki certificate ca domain and display pki crl domain commands, see Security Command Reference. Certificate request from a Windows 2003 CA server Network requirements As shown in Figure 105, configure PKI entity AC to request a local certificate from the CA server. Figure 105 Network diagram Configure the CA server 1. Install the certificate server suites: a. From the start menu, select Control Panel > Add or Remove Programs. b. Select Add/Remove Windows Components > Certificate Services. c. Click Next to begin the installation. 2. Install the SCEP add-on: The Windows 2003 server does not support SCEP by default. Install the SCEP add-on so that the AC can register and obtain its certificate automatically. After the SCEP add-on installation completes, a URL is displayed, which you must configure on the AC as the URL of the server for certificate registration. 3. Modify the certificate service attributes: a. From the start menu, select Control Panel > Administrative Tools > Certificate Authority. If you install the certificate service component and SCEP add-on successfully, there should be two certificates issued by the CA to the RA. b. In the navigation tree, right-click the CA server and select Properties > Policy Module. 285

298 Configure the AC c. Click Properties, and then select Follow the settings in the certificate template, if applicable. Otherwise, automatically issue the certificate. 4. Modify the Internet Information Services (IIS) attributes: a. From the start menu, select Control Panel > Administrative Tools > Internet Information Services (IIS) Manager. b. From the navigation tree, select Web Sites. c. Right-click Default Web Site and select Properties > Home Directory. d. In the Local path box, specify the path for certificate service. e. Specify an available port number as the TCP port number for the default website to avoid conflict with existing services. In this example, port 8080 is used. 1. Synchronize the system time of the AC with the CA server, so that the AC can properly request a certificate. 2. Configure the entity DN: # Configure the entity name as aaa and the common name as AC. <AC> system-view [AC] pki entity aaa [AC-pki-entity-aaa] common-name AC [AC-pki-entity-aaa] quit 3. Configure the PKI domain: # Create PKI domain torsa and enter its view. [AC] pki domain torsa # Configure the name of the trusted CA as myca. [AC-pki-domain-torsa] ca identifier myca # Configure the URL of the registration server in the format of certsrv/mscep/mscep.dll, where host:port indicates the IP address and port number of the CA server. [AC-pki-domain-torsa] certificate request url # Set the registration authority to RA. [AC-pki-domain-torsa] certificate request from ra # Specify the entity for certificate request as aaa. [AC-pki-domain-torsa] certificate request entity aaa 4. Generate a local key pair using RSA: [AC] public-key local create rsa The range of public key size is (512 ~ 2048). NOTES: If the key modulus is greater than 512, It will take a few minutes. Press CTRL+C to abort. Input the bits in the modulus [default = 1024]: Generating Keys

299 Apply for certificates: # Retrieve the CA certificate and save it locally. [AC] pki retrieval-certificate ca domain torsa Retrieving CA/RA certificates. Please wait a while... The trusted CA's finger print is: MD5 fingerprint:766c D2C8 9E46 845B 4DCE 439C 1C1F 83AB SHA1 fingerprint:97e5 DDED AB FB DB5C E7F8 D7D7 7C9B 97B4 Is the finger print correct?(y/n):y Saving CA/RA certificates chain, please wait a moment... CA certificates retrieval success. # Request a local certificate manually. [AC] pki request-certificate domain torsa challenge-word Certificate is being requested, please wait... [AC] Enrolling the local certificate,please wait a while... Certificate request Successfully! Saving the local certificate to device... Done! Verifying the configuration # Use the following command to view information about the local certificate acquired. <AC> display pki certificate local domain torsa Certificate: Data: Version: 3 (0x2) Serial Number: 48FA0FD C Signature Algorithm: sha1withrsaencryption Issuer: CN=CA server Validity Not Before: Nov 21 12:32: GMT Not After : Nov 21 12:42: GMT Subject: CN=AC Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00A6637A 8CDEA1AC B2E04A59 F7F6A9FE 5AEE52AE 14A392E4 E0E5D458 0D BF91E57 FA8C67AC 6CE8FEBB B 10242FDD D3947F5E 2DA70BD9 1FAF07E5 1D167CE1 FC20394F 476F5C08 C5067DF9 287

300 CB4D05E6 55DC11B6 9F4C014D EA D403CF 2D93BC5A 8AF3224D 1125E439 78ECEFE1 7FA9AE7B 877B50B F 6B Exponent: (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: B68E D7C44C 7ABCE3BA 9BF385F8 A448F4E1 X509v3 Authority Key Identifier: keyid:9d EADFEFA2 4A663E75 F416B6F6 D41EE4FE X509v3 CRL Distribution Points: URI: URI:file://\\l00192b\CertEnroll\CA server.crl Authority Information Access: CA Issuers - URI: CA Issuers - URI:file://\\l00192b\CertEnroll\l00192b_CA server.crt :.0.I.P.S.E.C.I.n.t.e.r.m.e.d.i.a.t.e.O.f.f.l.i.n.e Signature Algorithm: sha1withrsaencryption BFA1CBD B068840B (Omitted) You can also use some other display commands to view detailed information about the CA certificate. For more information about the display pki certificate ca domain command, see Security Command Reference. Certificate access control policy configuration example Network requirements As shown in Figure 106, the client accesses the remote HTTP Secure (HTTPS) server through the HTTPS protocol. SSL is configured to make sure that only legal clients log into the HTTPS server. Create a certificate access control policy to control access to the HTTPS server. Figure 106 Network diagram 288

301 Configuration procedure For more information about SSL configuration, see "Configuring SSL." The PKI domain to be referenced by the SSL policy must be created in advance. For more information about PKI domain configuration, see "Configure the PKI domain" in Configure the AC. 1. Configure the SSL policy for the HTTPS server to use: <AC> system-view [AC] ssl server-policy myssl [AC-ssl-server-policy-myssl] pki-domain 1 [AC-ssl-server-policy-myssl] client-verify enable [AC-ssl-server-policy-myssl] quit 2. Configure the certificate attribute group: # Create certificate attribute group mygroup1 and add two attribute rules. The first rule specifies that the DN of the subject name includes the string aabbcc, and the second rule specifies that the IP address of the certificate issuer is [AC] pki certificate attribute-group mygroup1 [AC-pki-cert-attribute-group-mygroup1] attribute 1 subject-name dn ctn aabbcc [AC-pki-cert-attribute-group-mygroup1] attribute 2 issuer-name ip equ [AC-pki-cert-attribute-group-mygroup1] quit # Create certificate attribute group mygroup2 and add two attribute rules. The first rule specifies that the FQDN of the alternative subject name does not include the string of apple, and the second rule specifies that the DN of the certificate issuer name includes the string aabbcc. [AC] pki certificate attribute-group mygroup2 [AC-pki-cert-attribute-group-mygroup2] attribute 1 alt-subject-name fqdn nctn apple [AC-pki-cert-attribute-group-mygroup2] attribute 2 issuer-name dn ctn aabbcc [AC-pki-cert-attribute-group-mygroup2] quit 3. Configure the certificate access control policy # Create the certificate access control policy of myacp and add two access control rules. [AC] pki certificate access-control-policy myacp [AC-pki-cert-acp-myacp] rule 1 deny mygroup1 [AC-pki-cert-acp-myacp] rule 2 permit mygroup2 [AC-pki-cert-acp-myacp] quit 4. Apply the SSL server policy and certificate access control policy to HTTPS service and enable HTTPS service. # Apply SSL server policy myssl to HTTPS service. [AC] ip https ssl-server-policy myssl # Apply the certificate access control policy of myacp to HTTPS service. [AC] ip https certificate access-control-policy myacp # Enable HTTPS service. [AC] ip https enable 289

302 Troubleshooting PKI Failed to obtain the CA certificate Symptom Failed to obtain a CA certificate. Analysis Solution Possible reasons include: The network connection is not proper. For example, the network cable might be damaged or loose. No trusted CA is specified. The URL of the registration server for certificate request is not correct or not configured. No authority is specified for certificate request. The system clock of the device is not synchronized with that of the CA. 1. Make sure the network connection is physically proper. 2. Check that the required commands are configured properly. 3. Use the ping command to verify that the RA server is reachable. 4. Specify the authority for certificate request. 5. Synchronize the system clock of the device with that of the CA. Failed to request local certificates Symptom Failed to request a local certificate. Analysis Possible reasons include: The network connection is not proper. For example, the network cable might be damaged or loose. No CA certificate has been obtained. The current key pair has been bound to a certificate. No trusted CA is specified. The URL of the registration server for certificate request is not correct or not configured. No authority is specified for certificate request. Some required parameters of the entity DN are not configured. Solution 1. Make sure the network connection is physically proper. 2. Retrieve a CA certificate. 3. Regenerate a key pair. 4. Specify a trusted CA. 290

303 5. Use the ping command to verify that the RA server is reachable. 6. Specify the authority for certificate request. 7. Configure the required entity DN parameters. Failed to obtain CRLs Symptom Failed to obtain CRLs. Analysis Possible reasons include: The network connection is not proper. For example, the network cable might be damaged or loose. No CA certificate has been obtained before you try to obtain CRLs. The IP address of LDAP server is not configured. The CRL distribution URL is not configured. The LDAP server version is wrong. Solution 1. Make sure the network connection is physically proper. 2. Retrieve a CA certificate. 3. Specify the IP address of the LDAP server. 4. Specify the CRL distribution URL. 5. Re-configure the LDAP version. 291

304 Configuring SSH Overview Secure Shell (SSH) is a network security protocol. Using encryption and authentication, SSH implements remote login and file transfer securely over an insecure network. SSH uses the typical client-server model to establish a channel for secure data transfer based on TCP. SSH includes two versions: SSH1.x and SSH2.0 (hereinafter referred to as SSH1 and SSH2), which are not compatible. SSH2 is better than SSH1 in performance and security. The device can work as an SSH server or as an SSH client. When acting as an SSH server, the device provides services to SSH clients and supports the following SSH versions: SSH2 and SSH1 in non-fips mode. SSH2 in FIPS mode. When acting as an SSH client, the device supports SSH2 only. It allows users to establish SSH connections with an SSH server. The device supports the following SSH applications: Stelnet Provides secure and reliable network terminal access services. Through Stelnet, a user can log in to a remote server securely. Stelnet protects devices against attacks such as IP spoofing and plain text password interception. The device can act as both the Stelnet server and Stelnet client. SFTP Based on SSH2, it uses the SSH connection to provide secure file transfer. The device can serve as the SFTP server, allowing a remote user to log in to the SFTP server for secure file management and transfer. The device can also serve as an SFTP client, enabling a user to log in from the device to a remote device for secure file transfer. SCP Based on SSH2, it offers a secure approach to copying files. The device can act as the SCP server, allowing a user to log in to the device for file upload and download. The device can also act as an SCP client, enabling a user to log in from the device to a remote server for secure file transfer. How SSH works This section uses SSH2 as an example to describe the stages to establish an SSH session. For more information about these stages, see SSH Technology White Paper. Table 15 Stages to establish an SSH session Stages Connection establishment Version negotiation Description The SSH server listens to the connection requests on port 22. After a client initiates a connection request, the server and the client establish a TCP connection. The two parties determine a version to use. 292

305 Stages Algorithm negotiation Key exchange Authentication Session request Description SSH supports multiple algorithms. Based on the local algorithms, the two parties determine to use the following algorithms: Key exchange algorithm for generating session keys. Encryption algorithm for encrypting data. Public key algorithm for digital signature and authentication. HMAC algorithm for protecting data integrity. The two parties use the Diffie-Hellman (DH) exchange algorithm to dynamically generate the session keys and session ID: The session keys are used for protecting data transfer. The session ID is used for identifying the SSH connection. In this stage, the client also authenticates the server. The SSH server authenticates the client in response to the client's authentication request. After passing authentication, the client sends a session request to the server to request the establishment of a session (Stelnet, SFTP, or SCP). After the server grants the request, the client and the server start to communicate with each other in the session. Interaction In this stage, you can execute commands from the client by pasting the commands in text format. The text must be within 2000 bytes. To execute the commands successfully, HP recommends that you paste the commands that are in the same view. If you want to execute commands of more than 2000 bytes, you can save the commands in a configuration file, upload it to the server through SFTP, and use it to restart the server. SSH authentication When the device acts as an SSH server, it supports the following authentication methods: Password authentication The SSH server uses AAA to authenticate the client. During password authentication, the SSH client performs the following operations: a. Encrypts its username and password. b. Encapsulates the encrypted information into an authentication request. c. Sends the request to the server. After receiving the request, the SSH server performs the following operations: a. Decrypts the request to get the username and password in plain text. b. Checks the validity of the username and password locally or through remote AAA authentication. c. Informs the client of the authentication result. If the AAA server requires the user for a secondary password authentication, it sends the SSH server an authentication response with a prompt. The prompt is transparently transmitted to the client to notify the user to enter a specific password. When the user enters the correct password, the AAA sever examines the password validity. If the password is valid, an authentication success message is sent to the client. 293

306 NOTE: Only clients that run SSH2 or a later version support secondary password authentication that is initiated by the AAA server. Publickey authentication The server authenticates the client through the digital signature. During publickey authentication, the client sends the server a publickey authentication request that contains the following information: Username. Public key of the client. Publickey algorithm information (or the digital certificate that carries the public key information). The server examines the validity of the public key. If the public key is invalid, the authentication fails. If the public key is valid, the server authenticates the client by using the digital signature. Finally, it informs the client of the authentication result. The device supports using the publickey algorithms RSA and DSA for digital signature. A client can send public key information to the SSH server for validity check by using one of the following methods: The client directly sends the user's public key information to the server. The server checks the validity of the user's public key. The client sends the user's public key information to the server through a digital certificate. The server checks the validity of the digital certificate. When acting as a client, the device does not support this method. Password-publickey authentication The server requires SSH2 clients to pass both password authentication and publickey authentication. However, SSH1 clients only need to pass either authentication. Any authentication The server requires the client to pass password authentication or publickey authentication. FIPS compliance The device supports the FIPS mode that complies with NIST FIPS requirements. Support for features, commands, and parameters might differ in FIPS mode and non-fips mode. For more information about FIPS mode, see "Configuring FIPS." Configuring the device as an SSH server You can configure the device as an Stelnet, SFTP or SCP server. Because the configuration procedures are similar, the SSH server represents the Stelnet, SFTP, and SCP server unless otherwise specified. SSH server configuration task list Task Generating local DSA and RSA key pairs Enabling the SSH server function Enabling the SFTP server function Remarks Required. Required for Stelnet, SFTP, and SCP servers. Required only for the SFTP server. 294

307 Task Configuring the user interfaces for SSH clients Configuring a client's host public key Remarks Required. Required if the following conditions exist: Publickey authentication is configured for users. The clients directly send the public keys to the server for validity check. See "Configuring PKI." Configuring the PKI domain for verifying the client certificate Required if the following conditions exist: Publickey authentication is configured for users. The clients send the public keys to the server through digital certificates for validity check. The PKI domain must have the CA certificate to verify the client certificate. Configuring an SSH user Setting the SSH management parameters Required for publickey authentication users and optional for other authentication users. Generating local DSA and RSA key pairs DSA and RSA key pairs are required for generating session keys and the session ID in the key exchange stage. The key pairs can also be used by a client to authenticate the server. When a client authenticates the server, it compares the public key received from the server with the server's public key that it saved locally. If the keys are consistent, the client uses the public key to authenticate the digital signature received from the server. If the digital signatures are consistent, the authentication succeeds. Configuration guidelines When you generate local DSA and RSA key pairs, follow these restrictions and guidelines: To support SSH clients that use different types of key pairs, generate both DSA and RSA key pairs on the SSH server. The public-key local create rsa command generates a server RSA key pair and a host RSA key pair. Each of the key pairs consists of a public key and a private key. In SSH1, the public key in the server key pair is used to encrypt the session key for secure transmission of the session key. Because SSH2 uses the DH algorithm to generate each session key on the SSH server and the client, no session key transmission is required. The server key pair is not used in SSH2. The public-key local create dsa command generates only a host key pair. SSH1 does not support the DSA algorithm. DSA algorithm is not supported in FIPS mode. Configuration procedure To generate local RSA and DSA key pairs on the SSH server: Step Command Remarks 1. Enter system view. system-view N/A 2. Generate RSA and DSA key pairs. public-key local create { dsa rsa } By default, both RSA and DSA key pairs do not exist. 295

308 Enabling the SSH server function The SSH server function allows clients to communicate with the device through SSH. When the device acts as an SCP server, only one SCP user is allowed to access to the SCP server at one time. To enable the SSH server function: Step Command Remarks 1. Enter system view. system-view N/A 2. Enable the SSH server function. ssh server enable Disabled by default. Enabling the SFTP server function This SFTP server function enables clients to log in to the SFTP server through SFTP. When the device functions as the SFTP server, only one client can access the SFTP server at a time. To enable the SFTP server function: Step Command Remarks 1. Enter system view. system-view N/A 2. Enable the SFTP server function. sftp server enable Disabled by default. Configuring the user interfaces for SSH clients SSH clients access the device through VTY user interfaces. You must configure the user interfaces for SSH clients to allow SSH login. The configuration takes effect on the clients only at the next login. IMPORTANT: Before you configure a user interface to support SSH, you must configure its authentication mode to scheme. Otherwise, the protocol inbound command does not take effect. To configure the user interfaces for SSH clients: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter VTY user interface view. 3. Set the login authentication mode to scheme. 4. Configure the user interface to support SSH login. user-interface vty number [ ending-number ] authentication-mode scheme protocol inbound { all ssh } N/A By default, the authentication mode is password. By default, Telnet and SSH are supported. 296

309 For more information about the authentication-mode and protocol inbound commands, see Fundamentals Command Reference. Configuring a client's host public key This configuration task is only necessary for the clients that directly send the public key to the server in publickey authentication. In publickey authentication, the server first compares the SSH username and client's host public key received from the client with those saved locally. If they are consistent, the server examines the digital signature that the client sends. The digital signature is calculated by the client according to the private key that is associated with the host public key. For successful authentication, you must perform the following tasks: 1. Configure the client's DSA and RSA host public key on the server. You can configure up to 20 SSH client's public keys on an SSH server. 2. Specify the associated host private key on the client to generate the digital signature. If the device serves as an SSH client, specify the public key algorithm on the client. The algorithm determines the associated host private key for generating the digital signature. You can enter the content of a client's host public key or import the client's host public key from the public key file. HP recommends that you import the client's host public key. For more information about client public key configuration, see "Managing public keys." Entering a client's host public key Before you enter the client's host public key, you must use the display public-key local public command on the client to obtain the client's host public key. To enter a client's host public key: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter public key view. public-key peer keyname N/A 3. Enter public key code view. public-key-code begin N/A 4. Configure a client's host public key. 5. Return to public key view and save the configured host public key. Enter the content of the host public key public-key-code end The host public key must be in the DER encoding format without being converted. Spaces and carriage returns are allowed between characters. When you exit public key code view, the system automatically saves the public key. 6. Return to system view. peer-public-key end N/A Importing the client's host public key from the public key file Before you import the host public key, upload the client's public key file (in binary) to the server, for example, through FTP or TFTP. During the import process, the server automatically converts the host public key in the public key file to a string in PKCS format. 297

310 To import a client's host public key from the public key file: Step Command 1. Enter system view. system-view 2. Import the client's public key from the public key file. public-key peer keyname import sshkey filename Configuring an SSH user To configure an SSH user that uses publickey authentication, you must perform the procedure in this section. If the authentication method is password or password-publickey, you must perform one of the following tasks: For local authentication, configure a local user account by using the local-user command. For remote authentication, configure an SSH user account on an authentication server, for example, a RADIUS server. If the authentication method is password, you do not need to create an SSH user. However, if you want to display all SSH users, including the password-only SSH users, for centralized management, you can use this command to create them. If such an SSH user has been created, make sure you have specified the correct service type and authentication method. Configuration restrictions and guidelines When you configure an SSH user, follow these restrictions and guidelines: You can set the service type to Stelnet, SFTP, or SCP. You can specify one of the following authentication methods for the SSH user: Password The user must pass password authentication. Publickey authentication The user must pass publickey authentication. Password-publickey authentication As an SSH2.0 user, the user must pass both password and publickey authentication. As an SSH1 user, the user must pass either password or publickey authentication. Any The user can use either password authentication or publickey authentication. For all authentication methods except password authentication, you must specify a client's host public key or digital certificate. For a client that directly sends the user's public key information to the server, you must specify the client's host public key on the server. The specified client's host public key must already exist. For more information about public keys, see "Configuring a client's host public key." For a client that sends the user's public key information to the server through a digital certificate, you must specify the PKI domain on the server. This PKI domain verifies the client certificate. To make sure the authorized SSH users can pass the authentication, the specified PKI domain must have the correct CA certificate. For more information about configuring a PKI domain, see "Configuring PKI." The command level accessible to an SSH user depends on the authentication method: If the authentication method is publickey or password-publickey, the command level accessible to the SSH user is set by using the user privilege level command on the user interface. 298

311 If the authentication method is password, the command level accessible to the SSH user is authorized by AAA. SSH1 does not support SFTP or SCP. For an SSH1 client, you must set the service type to stelnet or all. For an SFTP SSH user, the working folder depends on the authentication method: If the authentication method is password, the working folder is authorized by AAA. If the authentication method is publickey or password-publickey, the working folder is set by using the ssh user command. If you change the authentication method or public key for a logged-in SSH user, the change takes effect on the user at the next login. Configuration procedure To configure an SSH user and specify the service type and authentication method: Step Command 1. Enter system view. system-view 2. Create an SSH user, and specify the service type and authentication method. Create an SSH user, and specify the service type and authentication method for Stelnet users: ssh user username service-type stelnet authentication-type { password { any password-publickey publickey } assign { pki-domain pkiname publickey keyname } } Create an SSH user, and specify the service type and authentication method for all users, SCP or SFTP users: ssh user username service-type { all scp sftp } authentication-type { password { any password-publickey publickey } assign { pki-domain pkiname publickey keyname } work-directory directory-name } Setting the SSH management parameters Step Command Remarks 1. Enter system view. system-view N/A 2. Enable the SSH server to support SSH1 clients. 3. Set the RSA server key pair update interval. 4. Set the SSH user authentication timeout timer. ssh server compatible-ssh1x enable ssh server rekey-interval hours ssh server authentication-timeout time-out-value By default, the SSH server supports SSH1 clients. By default, the interval is 0, and the RSA server key pair is not updated. This command takes effect only on SSH1 users. The default setting is 60 seconds. If a user does not finish the authentication when the timeout timer expires, the connection cannot be established. 299

312 Step Command Remarks 5. Set the maximum number of SSH authentication attempts. 6. Configure the SFTP connection idle timeout period. ssh server authentication-retries times sftp server idle-timeout time-out-value The default setting is 3. Authentication fails if the number of authentication attempts (including both publickey and password authentication) exceeds the upper limit. The default setting is 10 minutes. When the idle timeout timer expires, the system automatically tears the connection down. Configuring the device as an Stelnet client This section describes how to configure the device as an Stelnet client. Stelnet client configuration task list Task Specifying a source IP address or source interface for SSH packets Enabling and disabling first-time authentication Establishing a connection to an Stelnet server Remarks Required. Specifying a source IP address or source interface for SSH packets HP recommends that you specify a loopback interface or dialer interface as the source interface for SSH packets for the following purposes: Ensuring the communication between the Stelnet client and the Stelnet server. Improving the manageability of Stelnet clients in authentication service. To specify a source IP address or source interface for SSH packets: Step Command Remarks 1. Enter system view. system-view N/A 300

313 Step Command Remarks 2. Specify a source IP address or source interface for SSH packets. Specify a source IPv4 address or source interface for SSH packets: ssh client source { interface interface-type interface-number ip ip-address } Specify a source IPv6 address or source interface for SSH packets: ssh client ipv6 source { interface interface-type interface-number ipv6 ipv6-address } By default, the source IP address or source interface for SSH packets is not configured. The SSH packets use the IP address of the output interface specified in the routing entry as their source address. Enabling and disabling first-time authentication When the device works as an SSH client, you can enable or disable first-time authentication for the client. When a client not configured with the server's host public key accesses the server for the first time, one of the following conditions exists: If first-time authentication is disabled, the client cannot access the server. To enable the client to access the server, you must complete the following tasks in advance: a. Configure the server's host public key locally. b. Specify the public key name for authentication on the client. If first-time authentication is enabled, the client accesses the server, and saves the server's host public key on the client. When accessing the server next time, the client uses the locally saved server's host public key to authenticate the server. In a secure network, enabling first-time authentication simplifies client configuration, but it also brings potential security risks. Enabling first-time authentication Step Command Remarks 1. Enter system view. system-view N/A 2. Enable first-time authentication. ssh client first-time enable Enabled by default. Disabling first-time authentication Step Command Remarks 1. Enter system view. system-view N/A 2. Disable first-time authentication. 3. Configure the server host public key. 4. Specify the host public key name of the server. undo ssh client first-time See "Configuring a client's host public key" ssh client authentication server server assign publickey keyname Enabled by default. The method for configuring the server host public key on the client is similar to that for configuring client public key on the server. N/A 301

314 Establishing a connection to an Stelnet server You can launch the Stelnet client to establish a connection to an Stelnet server, and specify the following algorithms for SSH connection establishment: Public key algorithm. Preferred encryption algorithm. Preferred HMAC algorithm. Preferred key exchange algorithm. To establish a connection to an Stelnet server: Task Command Remarks Establish a connection to an Stelnet server. Establish a connection to an IPv4 server: In non-fips mode: ssh2 server [ port-number ] [ identity-key { dsa rsa } prefer-compress { zlib zlib-openssh } prefer-ctos-cipher { 3des aes128 des } prefer-ctos-hmac { md5 md5-96 sha1 sha1-96 } prefer-kex { dh-group-exchange dh-group1 dh-group14 } prefer-stoc-cipher { 3des aes128 des } prefer-stoc-hmac { md5 md5-96 sha1 sha1-96 } ] * In non-fips mode: ssh2 server [ port-number ] [ identity-key rsa prefer-ctos-cipher { aes128 aes256 } prefer-ctos-hmac { sha1 sha1-96 } prefer-kex dh-group14 prefer-stoc-cipher { aes128 aes256 } prefer-stoc-hmac { sha1 sha1-96 } ] * Establish a connection to an IPv6 server: In FIPS mode: ssh2 ipv6 server [ port-number ] [ identity-key { dsa rsa } prefer-compress { zlib zlib-openssh } prefer-ctos-cipher { 3des aes128 des } prefer-ctos-hmac { md5 md5-96 sha1 sha1-96 } prefer-kex { dh-group-exchange dh-group1 dh-group14 } prefer-stoc-cipher { 3des aes128 des } prefer-stoc-hmac { md5 md5-96 sha1 sha1-96 } ] * In non-fips mode: ssh2 ipv6 server [ port-number ] [ identity-key rsa prefer-ctos-cipher { aes128 aes256 } prefer-ctos-hmac { sha1 sha1-96 } prefer-kex dh-group14 prefer-stoc-cipher { aes128 aes256 } prefer-stoc-hmac { sha1 sha1-96 } ] * Use one of the commands in user view. Configuring the device as an SFTP client This section describes how to configure the device as an SFTP client. 302

315 SFTP client configuration task list Task Specifying a source IP address or source interface for SFTP packets Enabling and disabling first-time authentication Establishing a connection to an SFTP server Working with SFTP directories Working with SFTP files Displaying help information Terminating the connection with the SFTP server Remarks Required. Specifying a source IP address or source interface for SFTP packets HP recommends that you specify a loopback interface or dialer interface as the source interface for SFTP packets for the following purposes: Ensuring the communication between the SFTP client and the SFTP server. Improving the manageability of SFTP clients in the authentication service. To specify a source IP address or interface for SFTP packets: Step Command Remarks 1. Enter system view. 2. Specify a source IP address or interface for SFTP packets. system-view Specify a source IPv4 address or interface for SFTP packets: sftp client source { interface interface-type interface-number ip ip-address } Specify a source IPv6 address or interface for SFTP packets: sftp client ipv6 source { interface interface-type interface-number ipv6 ipv6-address } N/A By default, the source IP address or source interface for SFTP packets is not configured. The SFTP packets use the IP address of the output interface specified in the routing entry as their source address. Establishing a connection to an SFTP server You can launch the SFTP client to establish a connection to an SFTP server, and specify the following algorithms for SFTP connection establishment: Public key algorithm. Preferred encryption algorithm. Preferred HMAC algorithm. Preferred key exchange algorithm. 303

316 After the connection is established, you can directly enter SFTP client view on the server to perform directory and file operations. To establish a connection to an SFTP server: Task Command Remarks Establish a connection to an SFTP server and enter SFTP client view. Establish a connection to an IPv4 SFTP server: In non-fips mode: sftp server [ port-number ] [ identity-key { dsa rsa } prefer-compress { zlib zlib-openssh } prefer-ctos-cipher { 3des aes128 des } prefer-ctos-hmac { md5 md5-96 sha1 sha1-96 } prefer-kex { dh-group-exchange dh-group1 dh-group14 } prefer-stoc-cipher { 3des aes128 des } prefer-stoc-hmac { md5 md5-96 sha1 sha1-96 } ] * In FIPS mode: sftp server [ port-number ] [ identity-key rsa prefer-ctos-cipher { aes128 aes256 } prefer-ctos-hmac { sha1 sha1-96 } prefer-kex dh-group14 prefer-stoc-cipher { aes128 aes256 } prefer-stoc-hmac { sha1 sha1-96 } ] * Establish a connection to an IPv6 SFTP server: In non-fips mode: sftp ipv6 server [ port-number ] [ identity-key { dsa rsa } prefer-compress { zlib zlib-openssh } prefer-ctos-cipher { 3des aes128 des } prefer-ctos-hmac { md5 md5-96 sha1 sha1-96 } prefer-kex { dh-group-exchange dh-group1 dh-group14 } prefer-stoc-cipher { 3des aes128 des } prefer-stoc-hmac { md5 md5-96 sha1 sha1-96 } ] * In FIPS mode: sftp ipv6 server [ port-number ] [ identity-key rsa prefer-ctos-cipher { aes128 aes256 } prefer-ctos-hmac { sha1 sha1-96 } prefer-kex dh-group14 prefer-stoc-cipher { aes128 aes256 } prefer-stoc-hmac { sha1 sha1-96 } ] * Use one of the commands in user view. Working with SFTP directories Step Command Remarks 1. Enter SFTP client view. 2. Change the working directory of the remote SFTP server. 3. Return to the upper-level directory. For more information, see "Establishing a connection to an SFTP server." cd [ remote-path ] cdup N/A 304

317 Step Command Remarks 4. Display the current working directory on the SFTP server. 5. Display files under a directory. 6. Change the name of a directory on the SFTP server. 7. Create a new directory on the SFTP server. 8. Delete one or more directories from the SFTP server. pwd dir [ -a -l ] [ remote-path ] ls [ -a -l ] [ remote-path ] rename oldname newname mkdir remote-path rmdir remote-path&<1-10> The dir command functions as the ls command. Working with SFTP files Step Command Remarks 1. Enter SFTP client view. 2. Change the name of a file on the SFTP server. 3. Download a file from the remote server and save it locally. 4. Upload a local file to the SFTP server. 5. Display the files under a directory. 6. Delete one or more directories from the SFTP server. For more information, see "Establishing a connection to an SFTP server." rename old-name new-name get remote-file [ local-file ] put local-file [ remote-file ] dir [ -a -l ] [ remote-path ] ls [ -a -l ] [ remote-path ] delete remote-file&<1-10> remove remote-file&<1-10> N/A The dir command functions as the ls command. The delete command functions as the remove command. Displaying help information Use the help command to display all commands or the help information of an SFTP client command, including the command format and parameters. To display all commands or the help information of an SFTP client command: Step 1. Enter SFTP client view. 2. Display all commands or the help information of an SFTP client command. Command For more information, see "Establishing a connection to an SFTP server." help [ all command-name ] 305

318 Terminating the connection with the SFTP server Step Command Remarks 1. Enter SFTP client view. 2. Terminate the connection with the SFTP server and return to user view. For more information, see "Establishing a connection to an SFTP server." bye exit quit N/A These commands function in the same way. Configuring the device as an SCP client This section describes how to configure the device as an SCP client. SCP client configuration task list Task Enabling and disabling first-time authentication Transferring files with an SCP server Remarks Required. 306

319 Transferring files with an SCP server Task Connect to the SCP server, and transfer files with the server. Command Upload a file to the SCP server: In non-fips mode: scp [ ipv6 ] server [ port-number ] put source-file-path [ destination-file-path ] identity-key { dsa rsa } [ prefer-compress { zlib zlib-openssh } prefer-ctos-cipher { 3des aes128 des } prefer-ctos-hmac { md5 md5-96 sha1 sha1-96 } prefer-kex { dh-group-exchange dh-group1 dh-group14 } prefer-stoc-cipher { 3des aes128 des } prefer-stoc-hmac { md5 md5-96 sha1 sha1-96 } ] * In FIPS mode: scp [ ipv6 ] server [ port-number ] put source-file-path [ destination-file-path ] [ identity-key rsa prefer-compress { zlib zlib-openssh } prefer-ctos-cipher { aes128 aes256 } prefer-ctos-hmac { sha1 sha1-96 } prefer-kex dh-group14 prefer-stoc-cipher { aes128 aes256 } prefer-stoc-hmac { sha1 sha1-96 } ] * Download a file from the SCP server: In non-fips mode: scp [ ipv6 ] server [ port-number ] get source-file-path [ destination-file-path ] [ identity-key { dsa rsa } prefer-compress { zlib zlib-openssh } prefer-ctos-cipher { 3des aes128 des } prefer-ctos-hmac { md5 md5-96 sha1 sha1-96 } prefer-kex { dh-group-exchange dh-group1 dh-group14 } prefer-stoc-cipher { 3des aes128 des } prefer-stoc-hmac { md5 md5-96 sha1 sha1-96 } ] * In FIPS mode: scp [ ipv6 ] server [ port-number ] get source-file-path [ destination-file-path ] [ identity-key rsa prefer-compress { zlib zlib-openssh } prefer-ctos-cipher { aes128 aes256 } prefer-ctos-hmac { sha1 sha1-96 } prefer-kex dh-group14 prefer-stoc-cipher { aes128 aes256 } prefer-stoc-hmac { sha1 sha1-96 } ] * Displaying and maintaining SSH Task Command Remarks Display the source IP address or interface configured for the SFTP client. Display the source IP address or interface information configured for the Stelnet client. Display SSH server status information or session information on an SSH server. Display the mappings between SSH servers and their host public keys on an SSH client. display sftp client source [ { begin exclude include } regular-expression ] display ssh client source [ { begin exclude include } regular-expression ] display ssh server { status session } [ { begin exclude include } regular-expression ] display ssh server-info [ { begin exclude include } regular-expression ] Available in any view. Available in any view. Available in any view. Available in any view. 307

320 Task Command Remarks Display information about one or all SSH users on an SSH server. Display the public keys of the local key pairs. Display the public keys of the SSH peers. display ssh user-information [ username ] [ { begin exclude include } regular-expression ] display public-key local { dsa rsa } public [ { begin exclude include } regular-expression ] display public-key peer [ brief name publickey-name ] [ { begin exclude include } regular-expression ] Available in any view. Available in any view. Available in any view. Stelnet configuration examples This section provides examples of configuring Stelnet. The configuration examples were created on the 11900/10500/ G unified wired-wlan module and might vary with device models. When configuring the 11900/10500/ G unified wired-wlan module, make sure the settings are correct (including VLAN settings) on the internal Ethernet interface that connects the module to the switch. For more information, see HP 11900/10500/ G Unified Wired-WLAN Module Basic Configuration Guide. By default, the aggregate interfaces between the access controller engine and the switching engine on an 830 switch or an 870 appliance are Access interfaces in VLAN 1. When configuring the two aggregate interfaces, make sure their permitted VLANs are the same. HP also recommends that you set their link type to be the same. Password authentication enabled Stelnet server configuration example Network requirements As shown in Figure 107: You can log in to the AC through the Stelnet client (SSH2) that runs on the client. The AC acts as the Stelnet server and uses password authentication. The username and password of the client are saved on the AC. The client and the AC can reach each other. Figure 107 Network diagram 308

321 Configuration procedure 1. Generate an RSA key pair on the Stelnet client: a. Launch PuTTYGen.exe, select SSH-2 RSA, and click Generate. Figure 108 Generating an RSA key pair on the client b. Continuously move the mouse and do not place the mouse over the green progress bar shown in Figure 109. Otherwise, the progress bar stops moving and the key pair generating progress stops. 309

322 Figure 109 Generating process c. After the key pair is generated, click Save public key to save the public key. A file saving window appears. Figure 110 Saving the RSA key pair on the client 310

323 d. Enter a file name (key.pub in this example), and click Save. e. On the page as shown in Figure 110, click Save private key to save the private key. A confirmation dialog box appears. f. Click Yes. A file saving window appears. g. Enter a file name (private.ppk, in this example), and click Save. h. Transmit the public key file to the server through FTP or TFTP. (Details not shown.) 2. Configure the Stelnet server AC: # Generate the RSA key pairs. <AC> system-view [AC] public-key local create rsa # Enable the SSH server function. [AC] ssh server enable # Configure an IP address for VLAN-interface 2. The Stelnet client uses this address as the destination address for SSH connection. [AC] interface vlan-interface 2 [AC-Vlan-interface2] ip address [AC-Vlan-interface2] quit # Set the authentication mode to AAA for the user interfaces. [AC] user-interface vty 0 4 [AC-ui-vty0-4] authentication-mode scheme # Enable the user interfaces to support SSH. [AC-ui-vty0-4] protocol inbound ssh [AC-ui-vty0-4] quit # Create a local user client001. [AC] local-user client001 # Specify the password as aabbcc for the local user. [AC-luser-client001] password simple aabbcc # Set the user privilege level to 3 for the local user. [AC-luser-client001] authorization-attribute level 3 # Specify the service type as ssh for the local user. [AC-luser-client001] service-type ssh [AC-luser-client001] quit # Create an SSH user client001. Specify the service type as stelnet and the authentication method as password for the user. By default, password authentication is used if no SSH user is created. [AC] ssh user client001 service-type stelnet authentication-type password 3. Establish a connection to the Stelnet server: The device supports different types of Stelnet client software, such as PuTTY and OpenSSH. The following example uses PuTTY version 0.58 on the Stelnet client. To establish a connection to the Stelnet server: a. Launch PuTTY.exe on the Stelnet client. 311

324 Figure 111 Specifying the host name (or IP address) b. In the Host Name (or IP address) filed, enter the IP address of the Stelnet server. c. Click Open to connect to the server. If the connection is successfully established, the system notifies you to enter the username and password. After entering the username (client001) and password (aabbcc), you can enter the CLI of the server. Publickey authentication enabled Stelnet server configuration example Network requirements As shown in Figure 112: You can log in to the AC through the Stelnet client (SSH2) that runs on the client. The AC acts as the Stelnet server, and uses publickey authentication and the RSA public key algorithm. 312

325 Figure 112 Network diagram Configuration considerations In the server configuration, the client public key is required. Use the client software to generate the RSA key pair on the client before configuring the Stelnet server. The device supports different types of Stelnet client software, such as PuTTY and OpenSSH. The following example uses PuTTY version 0.58 on the Stelnet client. Configuration procedure 1. Generate an RSA key pair on the Stelnet client: a. Launch PuTTYGen.exe, select SSH-2 RSA, and click Generate. Figure 113 Generating an RSA key pair on the client b. Continuously move the mouse and do not place the mouse over the green progress bar shown in Figure 114. Otherwise, the progress bar stops moving and the key pair generating progress stops. 313

326 Figure 114 Generating process c. After the key pair is generated, click Save public key to save the public key. A file saving window appears. Figure 115 Saving the RSA key pair on the client 314

327 d. Enter a file name (key.pub in this example), and click Save. e. On the page as shown in Figure 115, click Save private key to save the private key. A confirmation dialog box appears. f. Click Yes. A file saving window appears. g. Enter a file name (private.ppk, in this example), and click Save. h. Transmit the public key file to the server through FTP or TFTP. (Details not shown.) 2. Configure the Stelnet server AC: # Generate the RSA key pairs. <AC> system-view [AC] public-key local create rsa # Enable the SSH server function. [AC] ssh server enable # Configure an IP address for VLAN-interface 2. The Stelnet client uses this address as the destination address for SSH connection. [AC] interface vlan-interface 2 [AC-Vlan-interface2] ip address [AC-Vlan-interface2] quit # Set the authentication mode to AAA for the user interfaces. [AC] user-interface vty 0 4 [AC-ui-vty0-4] authentication-mode scheme # Enable the user interfaces to support SSH. [AC-ui-vty0-4] protocol inbound ssh # Set the user command privilege level to 3. [AC-ui-vty0-4] user privilege level 3 [AC-ui-vty0-4] quit # Import the client's public key from file key.pub and name it Key001. [AC] public-key peer Key001 import sshkey key.pub # Create an SSH user client002. Specify the authentication method as publickey for the user, and assign the public key Key001 to the user. [AC] ssh user client002 service-type stelnet authentication-type publickey assign publickey Key Establish a connection to the Stelnet server: a. Launch PuTTY.exe on the Stelnet client. 315

328 Figure 116 Specifying the host name (or IP address) b. In the Host Name (or IP address) field, enter the IP address of the Stelnet server. c. Select Connection > SSH > Auth from the navigation tree. d. Click Browse to bring up the file selection window, navigate to the private key file (private in this example) and click OK. 316

329 Figure 117 Specifying the private key file e. Click Open to connect to the server. If the connection is successfully established, the system notifies you to enter the username and password. After entering the username (client002), you can enter the CLI of the server. Password authentication enabled Stelnet client configuration example Network requirements As shown in Figure 118: You can log in to the switch through the Stelnet client that runs on AC. The switch acts as the Stelnet server and uses password authentication. The username and password of AC are saved on the switch. Figure 118 Network diagram 317