User Access Manager Help >> User Guide

User Guide for User Access Manager

Identity authentication is adopted for the access control on the network. The implementation requires collaboration among the INC User Access Manager Component (UAM), the access device and the client.
The identity authentication can be based on 802.1X or Portal. The following describes configurations for both.

 1.Configuration for 802.1X Authentication

• Add an access device to the UAM.
• Configure a service in the UAM.
• Add an access user to the UAM, and subscribe to the service configured in Step 2 for the user.
• Configure the RADIUS scheme, domain and authentication mode on the access device.
  RADIUS scheme: Configure the authentication/accounting server as the UAM.
  Domain: Configure a domain with a reference to the RADIUS scheme. It is recommended that specify the domain name the same as the service suffix in the UAM.
  Authentication mode: Enable 802.1X authentication globally and on the port connected to the PC.
• On the terminal PC, install the client software and create an 802.1X connection. Initiate the identity authenticate using the username of the access user that has been added to the UAM.
  With the above Steps 1 through 5, a legal access user can get access to the network. The following sections describe the purpose and the key configuration of each step.

       1.1 Adding an Access Device to the UAM

• Purpose:
  Make the UAM trust the access devices. Only those added to the UAM can exchange RADIUS packets with the UAM.
  
  
• To start configuration:
  Select the User tab, and in the User Access Policy navigation tree click Access Device Management and then click Access Device.
  
  
• Key parameters:
  Authentication Shared Key/Accounting Shared Key: Make sure that they are consistent with those in the RADIUS scheme configured on the access device.
  Authentication Port/Accounting Port: Make sure that they are consistent with the ports of the authentication/accounting servers in the RADIUS scheme configured on the access device.
  Access Device Type: The authentication packets exchanged between device and UAM vary with the device model. You must select Intelbras or Huawei here to support the extended RADIUS attributes.
  Select/Add Manually: For either option, make sure that the IP address (configurable with the nas ip command in the RADIUS scheme) of the access device is the one for packet exchange between access device and UAM.
  

       1.2 Configuring a Service in the UAM

• Purpose:
  A service is a collection of access attributes concerning the authorization and binding information of access users.
  
  
• To start configuration:
  Select the User tab, and in the User Access Policy navigation tree click Access Service.
  
  
• Key parameters:
  Basic Information area: It is recommended that the service suffix be consistent with the domain name configured on the access device. The Available check box configures whether the service can be subscribed to by access users.
  Authorization Information area: Enable/Disable certificate authentication for access users, and configure the authorities to be assigned to users that have passed the authentication, including uplink/downlink bandwidth, sending priority, VLAN, and ACL. (Access Period and Do Not Bind Access Device Group are extended functions of the UAM, which will be described later in Extended Services of the UAM.)
  Authentication Binding Information area: Configure the conditions for an access user to be passed for identity authentication. A condition-incompliant user cannot pass identity authentication.
  User Client Configuration area: Configure the requirements for the PC. A logged-in access user is to be kicked out if an unqualified PC is used.
  

       1.3 Adding an Access User with the UAM

• Purpose:
  An access user is an account for identity authentication.
  
  
• To start configuration:
  Select the User tab, in the navigation tree click User Management , and click Add User.
  
  
• Key parameters:
  Add User >> Basic Information: A user name uniquely identifies a user and can be grouped for easy management. The user name cannot be used by an access user to initiate an authentication.
  Access Configuration >> Access Information: Different from the user name configured in Add User >> Basic Information, it is an account name used to initiate an authentication.
  Access Configuration >> User Access Manager: Services configured in the UAM before subscription. Each access user can subscribe to more than one service.
  Access Configuration >> Access Device Binding Information/Terminal Binding Information: Correspond to the Authentication Binding Information area in the Add Service Configuration page. The settings here do not take effect if the service does not include any binding information. If, on the other hand, the service includes binding information but no values are set here, the information used for the first successful login is bound.

       1.4 Configuring RADIUS Scheme, Domain and Authentication Mode on the Access Device

• Purpose:
  Enable 802.1X and RADIUS on the access device, in which 802.1X for interaction between client and access device, while RADIUS for interaction between access device and UAM.
  
  
• To start configuration:
  Log in to the CLI of the access device through Console or Telnet.
  
  
• Key parameters:
  RADIUS scheme: Set the authentication/accounting servers to the UAM, set the authentication/accounting ports and keys to the ones configured on the access device, set the service type to extended, and set the user name format to with-domain. The following is an example of RADIUS scheme configuration on an access device:
  [Device] radius scheme test
  [Device-radius-test] primary authentication 192.168.4.169 1812
  [Device-radius-test] primary accounting 192.168.4.169 1813
  [Device-radius-test] key authentication testkey
  [Device-radius-test] key accounting testkey
  [Device-radius-test] server-type extended
  [Device-radius-test] user-name-format with-domain
  Domain: Configure a domain with a reference to the configured RADIUS scheme. If the RADIUS scheme specifies the format of user name with domain, the domain name you specify here must be consistent with the suffix of the service configuration in the UAM. The following is an example of domain configuration on an access device:
  [Device] domain testdm
  [Device-isp-testdm] authentication lan-access radius-scheme test
  [Device-isp-testdm] accounting lan-access radius-scheme test
  Authentication mode: Enable 802.1X authentication globally and on the port connected to the PC. Configure the authentication mode to CHAP. The following is an example of 802.1X authentication configuration on an access device:
  [Device] dot1x
  [Device] dot1x authentication-method chap
  [Device] interface Ethernet 1/0/2
  [Device-Ethernet1/0/2] dot1x

       1.5 Installing and Configuring 802.1X Client on a PC

Install the iNode client (or any other 802.1X-capable client), and create an 802.1X authentication connection.
Be sure to type a user name in the format of "access user name@domain name" if you have specified the format of user name with domain on the access device. Otherwise, directly type an access user name.

 2. Configuration for Portal Authentication

• Add an access device to the UAM.
• Configure a service with the UAM.
• Add an access user to the UAM, and subscribe to the service configured in Step 2 for the user.
• Add a Portal Server to the UAM.
• Configure RADIUS scheme, domain and authentication mode on the access device.
  RADIUS scheme: Configure the authentication/accounting server as the UAM.
  Domain: Configure a domain named after the service suffix in the UAM and with a reference to the RADIUS scheme.
  Authentication mode: Set the Portal Server as that in the UAM, and enable Portal authentication on the port connected to the PC (or the VLAN port).
• On the terminal PC, install the client and create a Portal connection. Initiate the identity authenticate using the username of the access user that has been added to the UAM.

       2.1 Adding a Portal Server to the UAM

During the Portal authentication, the UAM acts as the Portal Server as well as authenticating the user name and password. Therefore, besides Steps 1 through 3 as in the case of 802.1X authentication, there is an extra Step 4 to configure Portal authentication.

• Purpose:
  Enable Portal authentication in the UAM.
  
  
• To start configuration:
  Select the User tab, and in the User Access Policy navigation tree select Portal Service > IP Group, Portal Service > Device, or Portal Service > Server.
  
  
• Key parameters:
  1) Portal IP Group
  Configure the IP address range of access users.
  2) Portal Device
  This includes configuration of device and port group.
  Device: Specify a Portal access device. The keys and listening ports configured in the UAM must be consistent with those of the Portal Server configured on the access device.
  Port group: You can manage the port group information of your specified access device. The parameters to be concerned are start/end ports and IP address group (to be selected from those configured with the Portal IP Group function). An access user is allowed to initiate an identity authentication request only when its IP address belongs to the specified IP address group and the access port is in the range specified by the start and end ports.
  3) Portal Server
  The IP address of the Portal Server is automatically set to that of the host on which the Portal module is installed.
  Here you need to pay attention to the service type list. The service type ID must be consistent with the domain name configured on the access device, and the service type description is to be displayed in the Portal connection window of the iNode client for selection by access users. Once an access user selects a service type description, it is automatically associated with the domain on the access device based on the description-ID mapping.

       2.2 Configuring RADIUS Scheme, Domain and Authentication Mode on the Access Device

To enable Portal authentication, you need also to configure the RADIUS scheme and domain on the access device. This configuration is the same as in the case of 802.1X authentication. Note that if you have configured a service type list for the Portal Server of the UAM, the domain name configured here on the access device must be consistent with the service type ID.
To enable Portal authentication, you need to configure the Portal Server and related parameters, and enable Portal authentication on the VLAN port. The following is an example of Portal authentication configuration on an access device:
[Device] portal server test ip 192.168.4.169 key 123456 port 2000 //test is the server name
[Device] interface Vlan-interface 1000
[Device-Vlan-interface1000] portal test
Note that there are different kinds of Portal authentication: direct Portal authentication, NAT and address reallocation. For detailed configuration of NAT and address reallocation, refer to the related configuration examples or contact the technical support engineers.

       2.3 Installing and Configuring Portal Client on a PC

Install the iNode client and create a Portal authentication connection.
Note that if you have configured a service type list for the Portal Server in the UAM, the description of each type will be options in the service type drop-down list that appears during creating a Portal connection. There is one-to-one mapping between service type ID and service type description in the UAM, and mapping between service type ID and domain name on the access device. Therefore, once an access user selects a service type from the iNode client, it is associated with a domain on the access device.

 3. Framework of Access User + Service

As shown in the above configurations for 802.1X and Portal authentication, the UAM is based on a framework of access user + service. This framework provides flexibility in the following cases.

• Different users, by subscribing to the same service, get identical authentication attributes. This feature applies to users in the same category of positions. For example, the R&D staff can subscribe to the service that denies Internet access, while the marketing staff can subscribe to the service that does not allow access to the R&D internal database.
• A single user, by subscribing to different services, gets different authentication attributes designed for different purposes. This feature applies to mobile users or those working in different time ranges. For example, an employee is on business frequently, working at the R&D center or a branch office. Since these two sites have different access restricts, two services are defined. You can subscribe to the two services for him/her. In addition, authentication binding requirements can be set in the services to ensure that each service is used only at one specified site.

 4. Extended Services of the UAM

In addition to the basic identity authentication function, the UAM also provides two extended services, access period management and unbound access device group management .

       4.1 Access Period Management

• Purpose:
  Set the periods during which user access is allowed.
  Suppose you configured access period policy T and created service S with a reference to policy T. Then policy T applies to all access users that subscribe to service S.
  
  
• To start configuration:
  Select the User tab, and then in the User Access Policy navigation tree click Access Condition and then click Access Period Policy.
  
  
• Key parameters:
  Valid from/Expired from: The duration in which the access period policy takes effect.
  Access Period List: Periods during which user access is allowed. The users have access to the network only during the periods covered by the access period list and the validity period of the access period policy at the same time.

       4.2 Unbound Access Device Group

• Purpose:
  Set the areas from which the access users are free of authentication binding information check.
  As explained previously in the service configuration section, the authentication binding information is set to put additional conditions on the identity authentication. The unbound areas set some special areas from which the access user are free of binding check during identity authentication. Suppose you configured not to bind area A, and created service S with a reference to area A. Then the users accessing from area A (that is, from any device in area A) are not checked of their authentication binding information. This means they get access to the network despite of binding information incompliance.
  
  
• To start configuration:
  Select the User tab, and then in the User Access Policy navigation tree click Access Condition and then click Access Device Group.
  
  

Related Topics

• Access Device
• Access Period Policy
• Access Device Group
• Access Service