HP 5500 Ei 5500 Si Switch Series Configuration Guide
Have a look at the manual HP 5500 Ei 5500 Si Switch Series Configuration Guide online for free. It’s possible to download the document as PDF or print. UserManuals.tech offer 1114 HP manuals and user’s guides for free. Share the user manual or guide on Facebook, Twitter or Google+.
136 3. The portal server assembles the username and pa ssword into an authentication request message and sends it to the access device. Meanwhile, the portal server starts a timer to wait for an authentication acknow ledgment message. 4. The access device and the RADIUS server exchan ge 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 mess age to the authentication client to notify it of logon success. 7. The portal server sends an authentication repl y acknowledgment message to the access device. With extended portal functions, the process includes additional steps: 8. The security policy server exchanges security check information with the authentication client to check whether the authentication client meets the security requirements. 9. Based on the security check result, the security policy server authorizes the user to access certain resources, and sends the authorization information to the access device. The access device then controls access of the user based on the authorization information. Re-DHCP authentication process (with CHAP/PAP authentication) Figure 56 Re-DHCP authentication process The re-DHCP authentication takes the following procedure: The first steps are the same as those in the direct authentication/cross-subnet authentication process. 7. After receiving the authentication success message, the authentication client obtains a new public IP address through DHCP and notifies the portal se rver that it has obtained a public IP address. 8. The portal server notifies the acce ss device that the authentication client has obtained a new public IP address. 9. Detecting the change of the IP address by exam ining ARP packets received, the access device notifies the portal server of the change.
137 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. Portal support for EAP authentication process Figure 57 Portal support for EAP authentication process All portal authentication modes share the same EAP authentication steps. The following takes the direct portal authentication as an example to show the EAP authentication process: 1. The authentication client sends an EAP Request/Identi ty message to the portal server to initiate an EAP authentication process. 2. The portal server sends a portal authentication re quest 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 ce rtificate information of the client. 3. After the access device receives the portal authentication request, it constructs a RADIUS authentication request and sends it to the RADI US 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 certificat e 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. Authentication/ Accounting serverAuthentication clientPortal serverAccess device 1) EAP request 2) Authentication request 4) Certificate request 3) RADIUS authentication 10) Authentication reply ACK Authorization Timer Security check 5) EAP response … 6) EAP authentication … 7) Authentication success 8) Authentication reply 9) Login success Security policy server
138 5. After receiving the certificate requ est, the portal server sends an EAP authentication reply to the authentication client, carrying th e EAP-Message attribute values. 6. The authentication client sends another EAP reques t 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 initia ted 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 acce ss 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 authenticati on client of the authentication success. 10. The portal server sends an authentication reply acknowledgment to the access device. The remaining steps are for extended portal authentication. For more information about the steps, see the portal authentication process with CHAP/PAP authentication. Portal stateful failover (availabl e only on the HP 5500 EI series) Overview The stateful failover feature supports hot backup of ser vices on two devices. It can be configured on key devices to avoid service interruptions caused by single point failures. When working normally, the two devices synchronize the service information of each other. If one device fails, the other device takes over the services. To implement stateful failover, specify a dedicated VL AN (called the backup VLAN) on each device for stateful failover packets. If both a failover link and a backup VLAN are configured, add the physical ports at the two ends of the failover link to the backup VL AN. For more information about the stateful failover feature, see High Availability Configuration Guide .
139 Figure 58 Network diagram for portal stat eful failover configuration As shown in Figure 58, u sers have to pass portal authentication to access the Internet. To avoid portal service interruption caused by single point failures, you can deploy two access devices (Gateway A and Gateway B) and configure the portal stateful failover function on them, so that they back up the portal online user information of each other through the failover link. When one of them (Gateway A or Gateway B) fails, the other can guarantee the normal data communication of the online portal users and perform portal authentication for new portal users. Basic concepts 1. Device states • Independence: A stable running status of a device when it does not establish the failover link with the other device. • Synchronization: A stable running status of a device when it establishes the failover link with the other device successfully and is ready for data backup. 2. User modes • Stand-alone: Indicates that the user data is stored on the local device only. Currently, the local device is in independence state or it is in synchronization state but has not synchronized the user data to the peer device yet. • Primary: Indicates that the user logs in from the local device, and the user data is generated on the local device. The local device is in synchronization state and ready for receiving and processing packets from the server.
140 • Secondary: Indicates that the user logs in from the peer device, and the user data is synchronized from the peer device to the local device. The local device is in synchronization state. It only receives and processes the synchronization messages and does not process packets from the server. Portal authentication across VPNs (available only on the HP 5500 EI series) This feature is not applicable to VPNs with overlapping address spaces. In a scenario where the branches belong to differen t VPNs that are isolated from each other and all portal users in the branches need to be authenticate d by the server at the headquarters, you can deploy portal authentication across MPLS VPNs. As shown in Figure 59, the PE connecting the authentication clients serves as the NAS. The NAS is configured with portal authentication and AAA authentication, both of which support authentication across VPNs. Th e NAS can transmit a client’s portal authentication packets in a VPN transparently through the MPLS backbone to the servers in another VPN. This feature implements centralized client authentication across different VPNs while ensuring the separation of packets of the different VPNs. Figure 59 Network diagram for portal authentication across VPNs Portal authentication configured on MCE devices can also support authentication across VPNs. For information about MCE, see Layer 3—IP Routing Configuration Guid. For information about AAA implementation across VPNs, see Configuring AAA. Portal configuration task list The HP 5500 SI switch series supports only Layer 2 portal configuration. Complete these tasks to configure Layer 2 portal authentication: Task Remarks Specifying the local portal server for Layer 2 portal authentication Required Configuring the local portal server Customizing authentication pages Optional Configuring the local portal server Required Enabling Layer 2 portal authentication Required Controlling access of portal Configuring a portal-free rule Optional P MPLS backbone PE PE CE CE CE VPN 1 VPN 2 VPN 3 AAA server Portal server Host Host NAS
141 Task Remarks users Setting the maximum number of online portal users Specifying an authentication domain for portal users Configuring Layer 2 portal authentication to support web proxy Enabling support for portal user moving Specifying an Auth-Fail VLAN for portal authentication Optional Specifying an auto redirection URL for authenticated portal users Optional Configuring online Layer 2 portal user detection Optional Logging off portal users Optional Complete these tasks to configure Layer 3 portal authentication: Task Remarks Specifying a portal server for Layer 3 portal authentication Required Enabling Layer 3 portal authentication Required Controlling access of portal users Configuring a portal-free rule Optional Configuring an authentication source subnet Setting the maximum number of online portal users Specifying an authentication domain for portal users Configuring RADIUS related attributes Specifying NAS-Port-Type for an interface Optional Specifying a NAS ID profile for an interface Specifying a source IP address for outgoing portal packets Optional Configuring portal stateful failover (available only on the HP 5500 EI series) Optional Specifying an auto redirection URL for authenticated portal users Optional Configuring portal detection functions Configuring the portal server detection function Optional Configuring portal user information synchronization Logging off portal users Optional Configuration prerequisites The portal feature provides a solution for user identity authentication and security check. However, the portal feature cannot implement this solution by itself. RADIUS authentication needs to be configured on the access device to cooperate with the portal feature to complete user authentication. The prerequisites for portal authentication configuration are as follows: • The portal server and the RADIUS server have been installed and configured properly. Local portal authentication requires no independ ent portal server be installed.
142 • 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 installe d and configured properly. (Available only on the HP 5500 EI series) • 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. • T o 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. F or installation and configuration about the security policy server, see IMC EAD Security Policy Help. The ACL for resources in the quarantined area and that for restricted resources correspond to isolation ACL and security ACL, respectively, on the security policy server. You can modify the authorized ACLs on the access device. However, your changes take effect only for portal users logging on after the modification. For portal authentication to work normally, make sure that the system name of the access device is no more than 16 characters. Specifying the portal server Specifying the local portal server for Layer 2 portal authentication L ayer 2 portal authentication uses the local portal server. Specify the IP address of a Layer 3 interface on the device that is routable to the portal client as the listening IP address of the local portal server. HP recommends using the IP address of a loopback interface rather than a physical Layer 3 interface, because: • The status of a loopback interface is stable. Ther e will be no authentication page access failures caused by interface failures. • A loopback interface does not forward received packe ts to any network, avoiding impact on system performance when there are many network access requests. To specify the local portal server for Layer 2 portal authentication: Step Command Remarks 1. Enter system view. system-view N/A 2. Specify the listening IP address of the local portal server for Layer 2 portal authentication. portal local-server ip ip-address By default, no listening IP address is specified. NOTE: The specified listening IP address can be changed or deleted only if Layer 2 portal authentication is not enabled on any port.
143 Specifying a portal server for Layer 3 portal authentication (available only on the HP 5500 EI series) This task allows you to specify the portal server parameters for Layer 3 portal authentication, including the portal server IP address, shared encryption key, server port, and the URL address for web authentication. According to the networking environmen t, 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. When you specify a portal server for Layer 3 portal authentication, follow these guidelines: • If the portal server is in an MPLS VPN, specify the VPN instance when specifying the portal server on the device, so the device can send packets to the portal server. To specify a portal server for Layer 3 authentication: Step Command Remarks 1. Enter system view. system-view N/A 2. Specify a portal server and configure related parameters. portal server server-name ip ip-address [ key [ cipher | simple ] key-string | port port-id | url url-string | vpn-instance vpn-instance-name ] * | ipv6 ipv6-address [ key [ cipher | simple ] key-string | port port-id | url url-string ] * } By default, no portal server is specified. NOTE: The specified parameters of a portal server can be modified or deleted only if the portal server is not referenced on any interface. Configuring the local portal server Configuring a local portal server is required only for local portal authentication. During local portal authentication, the local portal server pushes authentication pages to users. You can define the authentication pages for users; otherwise, the default authentication pages will be used during the authentication process. Customizing authentication pages Customized authentication pages exist in the form of HTML files. You can compress them and then save them in the storage medium of the access device. A set of authentication pages includes six main authentication pages and their page elements. The six main authentication pages are the logon page, th e logon success page, the logon failure page, the online page, the system busy page, and the logoff succ ess page. The page elements refer to the files that the authentication pages reference, for example, back.jpg for page Logon.htm. Each main authentication page can reference multiple page elements. If you define only some of the main authentication pages, the system will use the default authentication pages for the undefined ones.
144
For the local portal server to operate normally and steadily, follow the following rules when customizing
authentication pages:
Rules on file names
The main authentication pages have predefin ed file names, which cannot be changed.
Table 10 Main authentication page file names
Main authentication
page File name
Logon page logon.htm
Logon success page logonSuccess.htm
Logon failure page logonFail.htm
Online page
Pushed after the user gets on line for online notification
online.htm
System busy page
Pushed when the system is busy or the user is in the
logon process busy.htm
Logoff success page logoffSuccess.htm
NOTE:
You can define the names of the files other than the main authentication page files. The file names and
directory names are case-insensitive.
Rules on page requests
The local portal server supports only Post and Get requests.
• Get requests are used to get the static files in the authentication pages and allow no recursion. For
example, if file Logon.htm includes contents that perform Get action on file ca.htm, file ca.htm
cannot include any reference to file Logon.htm.
• Post requests are used when users submit username and password pairs, log on the system, and log
off the system.
Rules on Post request attributes
1. Observe the following requirements when editing a form of an authentication page:
{ An authentication page can have multiple forms, but there must be one and only one form
whose action is logon.cgi . Otherwise, user information cannot be sent to the local portal server.
{ The username attribute is fixed as PtUser, and the password attribute is fixed as PtPwd.
{ Attribute PtButton is required to indicate the action that the user requests, which can be Logon
or Logoff .
{ A logon Post request must contain PtUser, PtPwd , and PtButton attributes.
{ A logoff Post request must contain the PtButton attribute.
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.
User name:
145 Password : 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. Rules on page file compression and saving • A set of authentication page files must be compressed into a standard zip file. The name of a zip file can contain only letters, numerals, and unders cores. The zip file of the default authentication pages must be saved with name defaultfile.zip. • The set of authentication pages must be loca ted in the root directory of the zip file. • Zip files can be transferred to the device through FTP or TFTP. The default authentication pages file must be saved in the root directory of the device, and other authentication files can be saved in the root directory or the portal directory under the root directory of the device. Examples of zip files on the device: dir Directory of flash:/portal/ 0 -rw- 1405 Feb 28 2011 15:53:31 ssid2.zip 1 -rw- 1405 Feb 28 2011 15:53:20 ssid1.zip 2 -rw- 1405 Feb 28 2011 15:53:39 ssid3.zip 3 -rw- 1405 Feb 28 2011 15:53:44 ssid4.zip 2540 KB total (1319 KB free) Rules on file size and contents For the system to push customized authentication pages smoothly, you need comply with the following size and content requirements on authentication pages. • The size of the zip file of each set of authentication pages, including the main authentication pages and the page elements, must be no more than 500 KB. • The size of a single page, including the main au thentication 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 co ntents 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: