HP A 5120 Manual

							 
111 
Authentication page customization support 
The  local  portal  server  function  allows  you  to  customize  authentication  pages.  You  can  customize 
authentication pages by editing the corresponding HTML files and then compress and save the files to the 
storage  medium  of  the  device.  A  set  of  customized  authentication  pages  consists of  six  authentication 
pages—the  logon  page,  the  logon  success  page,  the  online  page,  the  logoff  success  page,  the  logon 
failure  page,  and  the  system  busy  page.  A  local  portal  server  will  push  a  corresponding  authentication 
page  at  each  authentication  phase.  If  you  do  not  customize  the  authentication  pages, the local  portal 
server will push the default authentication pages.  
 NOTE: 
For the rules of customizing authentication pages, see “Customizing authentication pages.”  
Portal authentication modes 
Portal  authentication may  work  at Layer  2 or Layer  3 of  the  OSI  model. The A5120  EI Switch Series 
supports only Layer 2 authentication mode. 
In Layer  2  authentication  mode,  portal  authentication  is  enabled  on  an  access  device’s  Layer  2  port  that 
connects authentication clients, and allows only clients whose source MAC addresses pass authentication 
to  access  the  external  network.  Now,  only  local  portal  authentication  supports  Layer  2  mode,  where  the 
access device serves as the local portal server to perform web authentication on clients. 
In addition, Layer 2 authentication allows the authentication server to assign different VLANs according to 
user authentication  results  so  that access  devices  can  control  user  access  to  resources.  After  a  client 
passes authentication,  the authentication server  can  assign  an  authorized  VLAN  to  allow  the user  to 
access  the  resources  in  the  VLAN.  If  a  client fails authentication,  the authentication server  can  assign  an 
Auth-Fail VLAN.  
Layer 2 portal authentication process 
Only  local  portal  authentication supports Layer  2 mode. Figure  42 illustrates  the  process of local Layer-2 
portal authentication: 
Figure 42 Local Layer-2 portal authentication process 
 
 
As shown in Figure 42, the local Layer-2 portal authentication process includes the following steps. 
1. The portal authentication client sends an HTTP or HTTPS request. Upon receiving the HTTP request, 
the access device redirects it to the listening IP address of the local portal server, which then pushes 
a web authentication page to the authentication client. The user types the username and password 
on web authentication page. The listening IP address of the local portal server is the IP address of a 
Layer 3 interface on the access device which is routable to the portal client. Usually, it is a 
loopback interface’s IP address. Authentication/accounting server
1) Initiate a connection
2) RADIUS authentication
3) Notify the user of login success
Access deviceAuthentication client  
						

							 
112 
2. The access device and the RADIUS server exchange RADIUS packets to authenticate the user. 
3. If the user passes RADIUS authentication, the local portal server pushes a logon success page to the 
authentication client. 
Authorized VLAN 
Layer 2 portal authentication supports VLAN assignment by the authentication server. After a user passes 
portal  authentication, if  the  authentication  server  is  configured  with an authorized  VLAN for  the  user,  the 
authentication  server  assigns the authorized  VLAN  to  the  access  device,  which  will  then add  the  user  to 
the authorized VLAN and generate a MAC VLAN entry. If this VLAN does not exist, the access device will 
first create the VLAN and then add the user to the VLAN. 
By  deploying  the  authorized  VLAN  assignment function, you  can  control  which  network  resources users 
passing portal authentication can access. 
Auth-Fail VLAN 
The Auth-Fail  VLAN feature allows  users  failing authentication to  access a  VLAN that  accommodates 
network resources such as the patches server, virus definitions server, client software server, and anti-virus 
software  server, so  that  the  users  can upgrade their client software or  other  programs.  Such  a  VLAN  is 
called an ―Auth-Fail VLAN‖. 
Layer  2  portal  authentication  supports  MAC-based  Auth-Fail  VLAN  (MAFV).  With an  Auth-Fail  VLAN 
configured  on  a  port,  if  a  user  on  the  port  fails  authentication, the  access  devices  creates  a MAC  VLAN 
entry based on the MAC address of the user and adds the user to the Auth-Fail VLAN. Then, the user can 
access the non-HTTP resources in the Auth-Fail VLAN, and all HTTP requests of the user will be redirected 
to  the  authentication page. If the  user passes  authentication,  the  access  device  adds  the  user  to  the 
assigned VLAN  or  return  the  user  to the initial VLAN of  the  port,  depending  on whether  the 
authentication server assigns a VLAN. If the user fails the authentication, the access device keeps the user 
in  the  Auth-Fail  VLAN. If  an  access  port  receives  no  traffic  from  a  user in  the  Auth-Fail  VLAN  during  a 
specified  period  of  time (90  seconds  by  default), it removes the user from  the  Auth-Fail  VLAN and  adds 
the user to the initial VLAN of the port.  
 NOTE: 
After a user is added to the authorized VLAN or Auth-Fail VLAN, the IP address of the client needs to 
be automatically or manually updated to ensure that the client can communicate with the hosts in the 
VLAN.  
Assignment of authorized ACLs 
The  device  can  use  ACLs  to  control  user  access  to  network  resources  and  limit  user  access  rights.  With 
authorized  ACLs  specified  on  the  authentication  server,  when  a user  passes  authentication,  the 
authentication server assigns an authorized ACL for the user, and the device filters traffic from the user on 
the  access  port  according  to  the  authorized  ACL.  You  must  configure  the  authorized  ACLs  on  the  access 
device  if  you  specify  authorized  ACLs  on  the  authentication  server.  To  change  the  access  right  of  a  user, 
specify  a  different  authorized  ACL  on  the  authentication  server  or  change  the  rules  of  the  corresponding 
authorized ACL on the device. 
Portal configuration task list 
Complete these tasks to configure Layer 2 portal authentication:  
						

							 
113 
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 
Controlling access of portal 
users 
Configuring a portal-free rule 
Optional 
Setting the maximum number of online portal 
users 
Specifying an authentication domain for portal 
users 
Adding a web proxy server port number 
Enabling support for portal user moving 
Specifying the Auth-Fail VLAN for portal authentication Optional 
Specifying the auto redirection URL for authenticated portal users Optional 
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.  
Before you configure portal authentication, complete the following tasks: 
 The  portal  server  and  the  RADIUS  server  have been  installed  and  configured  properly. Local portal 
authentication requires no independent portal server be installed. 
 The portal client, access device, and servers are routable to 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 the chapter ―AAA configuration.‖ 
 To implement extended  portal functions,  install  and  configure iMC  EAD, and ensure  that the  ACLs 
configured on the access device correspond to those specified for resources in the quarantined area 
and restricted resources  on  the  security  policy  server respectively. For information  about  security 
policy server configuration on the access device, see the chapter ―AAA configuration.‖  
 NOTE: 
 For installation and configuration about the security policy server, see iMC EAD Security Policy Help. 
 The ACL for resources in the quarantined area and that for restricted resources correspond to isolation ACL and 
security ACL on the security policy server respectively. 
 You can modify the authorized ACLs on the access device. However, your changes take effect only for portal 
users logging on after the modification.   
						

							 
114 
Specifying the local portal server for Layer 2 portal 
authentication 
Layer 2 portal authentication uses the local portal server. You need to 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 strongly recommends that you use the IP address of a loopback interface rather than a physical 
Layer 3 interface, because: 
 The  status  of  a  loopback  interface  is  stable. There  will  be  no authentication  page  access  failures 
caused by interface failures. 
 A loopback interface does not forward received packets to any network, avoiding impact on system 
performance when there are many network access requests. 
Follow these steps to specify the local portal server for Layer 2 portal authentication: 
To do… Use the command… Remarks 
Enter system view system-view — 
Specify the listening IP address of 
the local portal server for Layer 2 
portal authentication 
portal local-server ip ip-address 
Required 
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.  
Configuring the local portal server 
Configuring  a  local  portal  server  is  required  only  for  local  portal  authentication. During  local  portal 
authentication,  the  local  portal  server  pushes  authentication  pages  to users.  You can define the 
authentication  pages for users;  otherwise,  the  default  authentication  pages  will  be  used  during  the 
authentication process. 
Customizing authentication pages 
Customized authentication  pages exist in the  form  of HTML  files. You  can compress them and  then  save 
them in the storage medium of the access device.  
A set  of  authentication  pages includes six main  authentication pages and their page  elements.  The  six 
main  authentication pages  are the  logon  page,  the  logon  success  page,  the  logon  failure  page,  the 
online page, the system busy page, and the logoff success page. The page elements refer to the files that 
the authentication pages reference, for example, back.jpg for page Logon.htm. Each main authentication 
page  can  reference  multiple  page  elements.  If  you define only some of  the  main  authentication  pages, 
the system will use the default authentication pages for the undefined ones. 
For  the  local  portal  server  to  operate  normally  and  steadily, you  need  to  follow the  following rules  when 
customizing authentication pages: 
Rules on file names 
The  main  authentication  pages have  predefined  file  names,  which  cannot  be  changed.  The  following 
table lists the names.  
						

							 
115 
Table 9 Main authentication page file names 
Main authentication page File name 
Logon page logon.htm 
Logon success page logonSuccess.htm 
Logon failure page logonFail.htm 
Online page 
Pushed after the user gets online for online notification online.htm 
System busy page 
Pushed when the system is busy or the user is in the logon process busy.htm 
Logoff success page logoffSuccess.htm 
 
 NOTE: 
You can define the names of the files other than the main authentication page files. The file names and 
directory names are case-insensitive.   
Rules on page requests 
The local portal server supports only Post and Get requests. 
 Get  requests  are  used  to  get  the  static  files  in  the  authentication  pages  and  allow  no  recursion.  For 
example, if file  Logon.htm  includes  contents that  perform  Get  action  on file ca.htm, file ca.htm 
cannot include any reference to file Logon.htm. 
 Post requests are used when users submit username and password pairs, log on the system, and log 
off the system. 
Rules on Post request attributes 
1. Observe the following requirements when editing a form of an authentication page: 
 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: 
Password  : 
 
 
3. Authentication pages logonSuccess.htm and online.htm must contain the logoff Post request.  
						

							 
116 
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  underscores.  The  zip  file  of  the  default  authentication 
pages must be saved with name defaultfile.zip. 
 The set of authentication pages must be located in the root directory of the zip file. 
 Zip  files  can  be  transferred  to  the  device  through  FTP  or  TFTP,  and  must  be  saved  in  the  specified 
directory  of  the  device.  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  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: 
     
     
     
      
						

							 
117 
     
    ... ... 
 
    ... ... 
     
     
 
Redirecting authenticated users to a specified web page 
To  make  the  device automatically redirect  users  passing authentication to  a  specified  web  page,  do  the 
following in logon.htm and logonSuccess.htm: 
1. In logon.htm, set the target attribute of Form to blank. 
See the contents in gray: 
     
2. Add the function for page loading pt_init() to logonSucceess.htm. 
See the contents in gray: 
     
     
    LogonSuccessed 
     
     
     
    ... ... 
     
  
 NOTE: 
 HP recommends that you use browser IE 6.0 or above on the authentication clients. 
 Ensure that the browser of an authentication client permits pop-ups or permits pop-ups from the access device. 
Otherwise, the user cannot log off by closing the logon success or online page and can only click Cancel to 
return back to the logon success or online page. 
 If a user refreshes the logon success or online page, or jumps to another web site from either of the pages, the 
device also logs off the user. 
 If a user is using the Chrome browser, the device cannot log off the user when the user closes the logon success 
or online page.  
Configuring the local portal server 
To make the local portal server take effect, you need to specify the protocol to be used for communication 
between the portal client and local portal server. 
Configuration prerequisites 
Before you configure the local portal server to support HTTPS, complete the following tasks: 
 Configure  PKI  policies,  obtain  the  CA  certificate,  and  apply  for  a  local  certificate.  For more 
information, see the chapter ―PKI configuration.‖  
						

							 
118 
 Configure  the  SSL  server  policy,  and  specify  the  PKI  domain  to  be  used,  which  is  configured  in  the 
above step. For more information, see the chapter ―SSL configuration.‖ 
When  you specify the  protocol  for  the  local  portal  server  to  support,  the  local  portal  server  will  load  the 
default  authentication  page  file, which is supposed  to  be  saved  in  the  root  directory  of  the  device.  To 
ensure that  the  local  portal  server  uses  the  user-defined  default  authentication  pages,  you  need  to  edit 
and save them properly. Otherwise, the system default authentication pages will be used. 
Configuration procedure 
Follow these steps to configure the local portal server: 
To do… Use the command… Remarks 
Enter system view system-view — 
Configure the protocol type for 
the local portal server to support 
and load the default 
authentication page file 
portal local-server { http | https 
server-policy policy-name } 
Required 
By default, the local portal server 
does not support any protocol. 
Configure the welcome banner of 
the default authentication pages 
of the local portal server 
portal server banner banner-string Optional 
No welcome banner by default. 
 
Enabling Layer 2 portal authentication 
Only  after  you  enable  portal  authentication  on  an  access  interface  can  the  access interface perform 
portal authentication on connected clients. 
Before  enabling  Layer  2  portal  authentication,  make  sure  that the  listening  IP  address of  the  local  portal 
server is specified. 
Follow these steps to enable Layer 2 portal authentication: 
To do… Use the command… Remarks 
Enter system view system-view — 
Enter Layer 2 Ethernet interface 
view 
interface interface-type interface-
number — 
Enable Layer 2 portal 
authentication on the port portal local-server enable Required 
Not enabled by default. 
 
 NOTE: 
 To ensure normal operation of portal authentication on a Layer 2 port, HP does not recommend you to enable 
port security, guest VLAN of 802.1X, or EAD fast deployment of 802.1X on the port. 
 To support assignment of authorized VLANs, you must enable the MAC-based VLAN function on the port.   
						

							 
119 
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.  
For Layer 2 portal authentication, you can configure only a portal-free rule that is from any source address 
to  any  or  a  specified  destination  address.  If  you  configure  a  portal-free  rule that  is  from  any  source 
address to a specified destination address, users can access the specified address  directly, without being 
redirected  to  the  portal  authentication  page  for  portal  authentication.  Usually,  you  can  configure  the  IP 
address  of  a  server  that  provides  certain  services  (such as  software  upgrading  service)  as  the  destination 
IP address of a portal-free rule, so that Layer 2 portal authentication users can access the services without 
portal authentication. 
Follow these steps to configure a portal-free rule: 
To do… Use the command… Remarks 
Enter system view system-view — 
Configure a portal-free rule portal free-rule rule-number { destination { any | ip { ip-
address mask { mask-length | netmask } | any } } } * Required 
 
 NOTE: 
 You cannot configure two or more portal-free rules with the same filtering criteria. Otherwise, the system prompts 
that the rule already exists.  
 No matter whether portal authentication is enabled or not, you can only add or remove a portal-free rule. You 
cannot modify it.  
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. 
Follow these steps to set the maximum number of online portal users allowed in the system: 
To do… Use the command… Remarks 
Enter system view system-view — 
Set the maximum number of 
online portal users portal max-user max-number Required 
1000 by default. 
 
 NOTE: 
 The maximum number of online portal users that is assigned by the switch depends on the ACL resources of the 
switch. 
 If the maximum number of online portal users specified in the command is less than that of the current online 
portal users, the command can be executed successfully and will not impact the online portal users, but the 
system will not allow new portal users to log on until the number drops down below the limit.   
						

							 
120 
Specifying an authentication domain for portal users 
After  you  specify an authentication  domain  for  portal  users  on  an  interface, the  device  uses the 
authentication domain  for authentication,  authorization,  and  accounting  (AAA) of all portal  users  on  the 
interface,  ignoring  the  domain  names carried  in  the  usernames.  This  allows  you  to  specify  different 
authentication domains for different interfaces as needed. 
Follow these steps to specify an authentication domain for portal users on an interface: 
To do… Use the command… Remarks 
Enter system view system-view — 
Enter interface view interface interface-type 
interface-number — 
Specify an authentication domain 
for portal users on the interface portal domain domain-name 
Required 
By default, no authentication domain 
is specified for portal users. 
 
 NOTE: 
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 the chapter “AAA configuration.”  
Adding a web proxy server port number  
 NOTE: 
Only Layer 2 portal authentication supports this feature.  
By  default,  only  HTTP  requests  from  unauthenticated  users  to  port  80  trigger  portal  authentication.  If  an 
unauthenticated  user  uses  a  web  proxy  server  and  the  port  number  of  the  proxy  server  is  not  80,  the 
user’s  HTTP  requests  cannot  trigger  portal  authentication  and  will  be  dropped.  To  solve  this  problem, 
configure the port numbers of the web proxy servers on the device.  
If  there  are  web  servers  that  use  non-80  port  numbers  on  your  network  and  users  must  pass  portal 
authentication  before  accessing  the  servers,  you  can  also  add  proxy  web  server  port  numbers  on  the 
device for the web servers so that HTTP requests to those web servers trigger portal authentication. 
Follow  these  steps  to  add  a  web  proxy  server  port  number so  that  HTTP  requests destined  for this  port 
number trigger portal authentication: 
To do… Use the command… Remarks 
Enter system view system-view — 
Add a web proxy server port 
number portal web-proxy port port-number 
Required 
By default, no web proxy server port 
number is configured, and only HTTP 
requests to port 80 trigger portal 
authentication.