Feature Description - User Access (Nonx1x2) (V600R003C00 - 02)

HUAWEI NetEngine80E/40E Router
V600R003C00
Feature Description - User Access
Issue 02
Date 2011-09-10
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.

Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute the warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.
Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 02 (2011-09-10) Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
i
About This Document
Purpose
This document describes the user access feature in terms of its overview, principle, and
applications.
This document together with other types of document helps intended readers get a deep
understanding of the user access feature.
Related Versions
The following table lists the product versions related to this document.
Product Name Version
HUAWEI NetEngine80E/40E
Router
V600R003C00

Intended Audience
This document is intended for:
l Network planning engineers
l Commissioning engineers
l Data configuration engineers
l System maintenance engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Feature Description - User Access About This Document
ii
Symbol Description
DANGER
Indicates a hazard with a high level of risk, which if not
avoided, will result in death or serious injury.
WARNING
Indicates a hazard with a medium or low level of risk, which
if not avoided, could result in minor or moderate injury.
CAUTION
Indicates a potentially hazardous situation, which if not
avoided, could result in equipment damage, data loss,
performance degradation, or unexpected results.
TIP
Indicates a tip that may help you solve a problem or save
time.
NOTE
Provides additional information to emphasize or supplement
important points of the main text.

Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all updates made in previous issues.
Changes in Issue 02 (2011-09-10)
There is no update compared with the previous issue.
Changes in Issue 01 (2011-06-30)
Initial field commercial release.
Feature Description - User Access About This Document
iii
Contents
About This Document.....................................................................................................................ii
1 AAA and User Management.......................................................................................................1
1.1 Introduction to AAA and User Management.....................................................................................................2
1.2 References..........................................................................................................................................................3
1.3 Enhancement......................................................................................................................................................4
1.4 Principles............................................................................................................................................................4
1.4.1 AAA...........................................................................................................................................................4
1.4.2 RADIUS....................................................................................................................................................7
1.4.3 HWTACACS...........................................................................................................................................10
1.4.4 User Management....................................................................................................................................11
1.5 Applications......................................................................................................................................................16
1.5.1 RADIUS Authentication and Accounting...............................................................................................17
1.5.2 HWTACACS Authentication, Accounting, and Authorization..............................................................17
1.6 Terms and Abbreviations..................................................................................................................................18
Feature Description - User Access Contents
iv
1 AAA and User Management
About This Chapter
1.1 Introduction to AAA and User Management
1.2 References
1.3 Enhancement
1.4 Principles
1.5 Applications
1.6 Terms and Abbreviations
Feature Description - User Access 1 AAA and User Management
1
1.1 Introduction to AAA and User Management
Definition
AAA, short for Authentication, Authorization, and Accounting, provides the following types of
security functions:
l Authentication: determines the users who can access the network.
l Authorization: authorizes users to use specific services.
l Accounting: records the utilization of network resources.
The NE80E/40E implements AAA through the Remote Authentication Dial in User Service
(RADIUS) protocol or the Huawei Terminal Access Controller Access Control System
(HWTACACS) protocol.
l RADIUS
RADIUS is one of the most commonly used protocols to implement AAA. As an
application-layer protocol running between the NE80E/40E and a RADIUS server,
RADIUS defines the procedure for transmitting user information and accounting
information between theNE80E/40E and the RADIUS server and the format of packets
exchanged between them.
l HWTACACS
AAA can also be implemented through HWTACACS. HWTACACS is the enhancement
of TACACS that is an access control protocol defined in RFC 1492. Similar to RADIUS,
HWTACACS adopts the client/server model to communicate with the HWTACACS
server, thus implementing AAA for various users, including Point-to-Point Protocol (PPP)
users, Virtual Private Dial Network (VPDN) users, and login users.
A broadband remote access server (BRAS) is used to manage access users. Currently, the BRAS
manages users in the following modes:
l Domain-based user management
All users belong to a same domain. By default, users are added to a default domain. The
BRAS manages users by configuring service attributes for a domain. Thus, the users in the
same domain have the same service attributes.
l User account-based user management
User accounts and related service attributes are configured on an AAA server such as the
RADIUS server or the HWTACACS server, and are then delivered to users when the users
get online or dynamically delivered to users after the users get online.
In actual applications (except the applications of non-authentication and non-accounting) on the
NE80E/40E, all user accounts must be configured on an AAA server, and all the domains to
which the user accounts belong must be configured on the NE80E/40E. The NE80E/40E
supports the configuration and management of local user accounts.
Commonly, the service attributes configured in a domain have a lower priority than the service
attributes delivered by an AAA server. Therefore, when service attributes are configured in a
domain and are also delivered by an AAA server, the NE80E/40E adopts the service attributes
that are delivered by the AAA server. The service attributes configured in a domain take effect
only when the AAA server does not support or deliver the service attributes.
2
Purpose
The NE80E/40E implements AAA through either RADIUS or HWTACACS.
The NE80E/40E supports domain-based or user account-based user management and supports
multiple authentication and accounting policies.
By authorizing and managing user attributes, the NE80E/40E implements the enhanced the user
management function, including user bandwidth control, access authority control, and QoS
attribute control.
Benefits
This feature brings the following benefits to operators:
l Access users are identified to guarantee legal service access.
l Authorities of access users are controlled through domain-based or user account-based user
management.
l The reliability of access user accounting is ensured through the RADIUS or HWTACACS
accounting protocol and the local accounting function in case of the remote accounting
failure.
1.2 References
Document Description
RFC 2903 Generic AAA Architecture
RFC 2904 AAA Authorization Framework
RFC 2905 AAA Authorization Application Examples
RFC 2906 AAA Authorization Requirements
RFC 2989 Criteria for Evaluating AAA Protocols for Network Access
RFC 3539 Authentication, Authorization and Accounting (AAA)
RFC 2809 Implementation of L2TP Compulsory Tunneling via RADIUS
RFC 2865 Remote Authentication Dial In User Service (RADIUS) (June 2000)
RFC 2866 RADIUS Accounting (June 2000)
RFC 2867 RADIUS Accounting Modifications for Tunnel Protocol Support
RFC 2868 RADIUS Attributes for Tunnel Protocol Support
RFC 2869 RADIUS Extensions (June 2000)
RFC 2882 Network Access Servers Requirements: Extended RADIUS
Practices
RFC 3162 RADIUS and IPv6
3
Document Description
RFC 3575 IANA Considerations for RADIUS (Remote Authentication Dial In
User Service)
RFC 3579 RADIUS (Remote Authentication Dial In User Service) Support For
Extensible Authentication Protocol (EAP)
RFC 3580 IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines
RFC 4014 Remote Authentication Dial-In User Service (RADIUS) Attributes
Suboption for the Dynamic Host Configuration Protocol (DHCP)
Relay Agent Information Option
RFC 0927 TACACS user identification Telnet option
RFC 1492 An Access Control Protocol, Sometimes Called TACACS (July
1993)

1.3 Enhancement
Version Feature Enhancement
V600R003C00 fail-time and interval parameters are added to the
local-user state command to set the maximum times
that a user fails the authentication and the period of
time between two authentication attempts
respectively. If the two parameters are specified, a
user will be blocked for a while if the user fails to log
in N times. This reduces the possibility for invalid
users to obtain a correct login password and improves
security.

1.4 Principles
1.4.1 AAA
Authentication
The NE80E/40E supports the following authentication modes. The three modes can be used in
combination.
l Non-authentication
In this mode, users are completely trusted without the check on their validity. This mode
is rarely used.
l Local authentication
4
In this mode, user information, including the user name, password, and attributes, is
configured on the NE80E/40E. This mode features fast processing speed and low operation
costs. The major limitation is that the information storage capacity is subject to the capacity
of device hardware.
l Remote authentication
In this mode, user information, including the user name, password, and attributes, is
configured on an authentication server. The NE80E/40E supports remote authentication
through RADIUS or HWTACACS. As a client, the NE80E/40E communicates with the
RADIUS or HWTACACS server. The RADIUS protocol can be either a standard RADIUS
protocol or an extended RADIUS protocol of Huawei, that is, RADIUS+V1.0 or RADIUS
+V1.1.
l First local authentication and later remote authentication
It is a local-authentication-preferred policy. That is, remote authentication is performed
only after local authentication fails.
l First remote authentication and later local authentication
It is a remote-authentication-preferred policy. That is, local authentication is performed
only after the AAA server gives no response.
l First remote authentication and later non-authentication
It is also a remote-authentication-preferred policy. That is, non-authentication is performed
only after the AAA server gives no response.
Authorization
The NE80E/40E supports user authorization during user login as well as dynamic authorization
for online users. During user login, the NE80E/40E supports various types of authorization
schemes.
l Authorization during user login
The NE80E/40E supports the following authorization modes during user login:
Direct authorization
In this mode, users are completely trusted and directly authorized.
Local authorization
In this mode, users are authorized based on the attributes of local user accounts
configured on the NE80E/40E.
HWTACACS authorization
In this mode, users are authorized through a HWTACACS server.
If-authenticated authorization
In this mode, users pass the authorization after passing authentication (not in non-
authentication mode).
RADIUS authorization
RADIUS integrates authentication and authorization. Therefore, RADIUS
authorization cannot be performed independently.
l Authorization for online users
The NE80E/40E supports dynamic authorization for online users.
In dynamic authorization, attributes such as the user group, committed access rate (CAR),
and policy name, are re-configured on the AAA server. The AAA server then delivers the
attributes to the AAA module through Change of Authorization (CoA) packets and the
5
AAA module dynamically updates the users' authorization information. For description
about CoA packets, refer to RFC 3576.
NOTE
The NE80E/40E can update the following user information by sending CoA packets.Filter-
Id ,Session-Timeout,Idle-Timeout ,Acct_Interim_Interval,HW-Input-Committed-Information-
Rate,HW-Input-Peak-Information-Rate,HW-Output-Committed-Information-Rate,HW-Output-
Peak-Information-Rate,HW-Remanent-Volume ,HW-Subscriber-QoS-Profile ,HW-Priority.
Accounting
l Accounting mode
AAA supports the following accounting modes:
Non-accounting
Free services are provided.
Remote accounting
The NE80E/40E supports remote accounting through an AAA server.
Local accounting protection
The NE80E/40E supports the local accounting protection function to avoid bill loss or
error bills when a link fault occurs (for example, the AAA server is disconnected). When
the AAA server fails to charge users, user bills are saved locally. Later, when the AAA
server recovers, the NE80E/40E uploads the locally saved bills to the accounting server
through the Trivial File Transfer Protocol (TFTP).
There must be a local bill pool before you can implement the local accounting protection
function on the NE80E/40E. The local accounting protection function does not take
effect in the absence of a local bill pool. You can create or delete a local bill pool through
commands. Note that after the local bill pool is deleted, the locally saved bills are also
deleted correspondingly and the NE80E/40E cannot automatically back up the bills to
a bill server.
Real-time accounting
During real-time accounting for online users, the NE80E/40E periodically generates
accounting packets and then sends them to a remote accounting server. Real-time
accounting is also a bill protection measure. It furthest reduces error bills and ensures
accuracy of accounting information in case of a link failure.
Working together with an AAA server, the NE80E/40E also supports the time-based
pre-paid service and traffic-based pre-paid service. It also supports charge rate switching
and charge discounting functions. Then, users are accounted at different charge rates
based on their access types.
l Accounting failure policy
The NE80E/40E supports the configuration of a remote accounting failure policy. Remote
accounting failure policies include:
Policy for start-accounting failures
When start-accounting fails,
If the policy is set to "offline", the user cannot go online.
If the policy is set to "online", the user remains online but no real-time accounting
packets can be exchanged between the user and the AAA server, even though the
AAA server gives a response again. The user still needs to send an accounting packet
to the AAA server for going offline. If the AAA server fails to charge the user, the
user bill is saved locally.
6
Policy for real-time accounting failures
When real-time accounting fails,
If the policy is set to "offline", the NE80E/40E terminates user access and saves the
offline bills locally.
If the policy is set to "online", the user remains online and sends real-time accounting
packets to the AAA server. If the user needs to go offline, it sends an accounting
packet to the AAA server. When the AAA server fails to charge the user, the user
bill is saved locally.
Policy for remote offline-accounting failures
When a user goes offline and the AAA server fails in accounting, the user bill is saved
locally; if the local bill pool is full, the bill is lost.
l Accounting packet copy
Accounting packet copy indicates that during accounting, accounting packets are sent to
two AAA servers synchronously for separate accounting. This function is used when the
original accounting information need be saved on multiple devices, for example, in the
scenario of the multi-operator networking. In this case, the accounting packets are sent to
two AAA servers and are used as original accounting information in subsequent bill
accounting.
There are the following accounting packet copy modes:
Physical accounting
For physical accounting, an accounting copy server is configured on the BAS interface
for user access. After the user logs in, the NE80E/40E searches for the accounting copy
server based on the user access interface and VLAN information and then copies the
accounting packets to this accounting server.
Two-level accounting
For two-level accounting, a main accounting server and an accounting copy server are
configured for a domain. During accounting, the main accounting server copies the
accounting packets to the accounting copy server.
1.4.2 RADIUS
Format of a RADIUS Message
Figure 1-1 shows the format of a RADIUS message.
Figure 1-1 Format of a RADIUS message
Code Identifier Length
Authenticator
Attribute
1
2
3
4
5
6
0-1- 2- 3- 4- 5- 6-7- 0-1- 2- 3- 4- 5- 6-7- 0-1- 2- 3- 4- 5- 6-7- 0-1- 2- 3- 4- 5- 6-7

7
The meaning of each field is described as follows:
l Code: indicates the message type, such as the access request, access permission, and
accounting request.
l Identifier: is a string of numbers in ascending order for matching the request and response
packets.
l Length: indicates the total length of all fields.
l Authenticator: is used for checking the validity of a RADIUS message.
l Attribute: indicates the contents of a message, describing user attributes.
Process of Exchanging RADIUS Messages
The RADIUS server builds a unique database to store user names and passwords that are required
for authentication. To obtain the right to access certain networks or to use certain network
resources, a user needs to set up a connection with the NE80E/40E through a device. In this case,
the NE80E/40E functions in connecting the user and the device.
The NE80E/40E is responsible for sending AAA information about the user to the RADIUS
server. RADIUS prescribes how to transmit AAA information between the NE80E/40E and the
RADIUS server. The RADIUS server receives connection requests from users, authenticates
users, and then sends the required configuration information back to the NE80E/40E.
The authentication information between the NE80E/40E and the RADIUS server is transmitted
with a key. This protects the user password from theft on an insecure network. Figure 1-2 shows
the process of exchanging RADIUS messages between the RADIUS server and client.
Figure 1-2 Process of exchanging RADIUS messages between the RADIUS server and client
1.User name
password
2.Request
3.Response
User RADIUS sever Router

1. A user initiates authentication and sends a user name and password to the NE80E/40E.
2. After the RADIUS client configured on the NE80E/40E receives the user name and
password, it sends an authentication request to the RADIUS server.
3. If the request is valid, the RADIUS server completes the authentication and sends the
required authorization information back to the RADIUS client.
Authentication information is encrypted before being transmitted between the RADIUS client
and RADIUS server. This prevents theft of information on an insecure network.
The process of exchanging accounting messages is similar to that of exchanging authentication
or authorization messages.
Features of RADIUS
RADIUS adopts the server/client model and has the following characteristics:
8
l RADIUS features excellent real-time performance by using the User Datagram Protocol
(UDP) as the transmission protocol.
l RADIUS possesses high reliability owing to the retransmission mechanism and backup
server mechanism.
l RADIUS is easy to implement and is applicable to the multi-threaded server in the case of
a large number of users.
Versions of RADIUS
The NE80E/40E supports standard RADIUS, RADIUS+V1.0, and RADIUS+V1.1. RADIUS
+V1.1 and RADIUS+V1.0, derived from the standard RADIUS protocol, are private protocols
defined by Huawei. With these protocols, the RADIUS server works more effectively in flow
control, charge rate switching, and control over the BRAS. The two protocols are both applicable
to IPHotel and Portal services though they are different in expansion.
l RADIUS+V1.0
In RADIUS+V1.0, a private attribute set is suffixed to the standard attribute set. That is,
the private attributes are simply added to the standard attribute set. Such an extension may
conflict with the subsequent extension of the standard RADIUS protocol.
l RADIUS+V1.1
In RADIUS+V1.1, all private attributes are considered a subset to be contained in the
vendor-specific attribute defined in RFC 2865. This ensures the interworking and
controllability between extended RADIUS+V1.1 of Huawei and the extended RADIUS
protocols defined by other vendors, and avoids the conflict between extended RADIUS
+v1.1 of Huawei and the subsequent extension of the standard RADIUS protocol.
For Huawei private RADIUS attributes, refer to "Appendix A RADIUS Attributes" in the
HUAWEI NE80E/40E Router Configuration Guide - BRAS Service.
Implementation of RADIUS on the NE80E/40E
As a RADIUS client, the NE80E/40E implements the following functions:
l Actively detects the status of the RADIUS server.
After receiving an AAA authentication or accounting message, the NE80E/40E enables the
server detection process if the server is Down. The NE80E/40E then transforms the message
into a packet and sends the packet to the current server to detect the server. If a response
packet is received from the RADIUS server, the NE80E/40E considers the server available.
l Caches the accounting-stop packets locally and retransmits them.
If the number of retransmission failures exceeds the set value, the accounting-stop packets
are saved to the buffer queue. The system periodically scans the queue, extracts the packets,
sends them to the specific server, and enables the waiting timer. If the transmission fails or
no response packet is received from the server within the timeout period, the packets are
put to the buffer queue again.
l Automatically switches to another RADIUS server in the server group.
If the current server does not work or the number of retransmission events exceeds the set
maximum number, the NE80E/40E selects another server in the server group to transmit
packets.
l Performs load balancing between RADIUS servers.
9
Enabled with load balancing, the NE80E/40E selects the RADIUS server in the Up state
according to the costs of the RADIUS servers. Commonly, the higher the priority, the higher
the possibility that the RADIUS server is selected.
l Switches RADIUS attributes.
The NE80E/40E supports the RADIUS attribute switching function. When the RADIUS
attribute switching function is enabled and then configured, the NE80E/40E encapsulates
or parses the original attribute value in accordance with the post-switching attribute format
during the transmission of RADIUS messages. In this manner, the NE80E/40E can
interwork with other devices.
l Carries CAR in the class attribute
In the standard RADIUS protocol, the client is required to add the class attribute carried in
the authentication message received from the RADIUS server to the accounting packet,
and send the accounting packet to the accounting server without changing the class attribute.
The NE80E/40E extends the standard RADIUS protocol by adding CAR to the class
attribute.
l RADIUS user priority configurable
Users on the NE80E/40E can have different priorities.
l User-name specified in RADIUS to be separated the delimiter.
The delimiter shall be as specified below: "\", "/", ":", "<", ">", "|", "@","'", "%".
If the RADIUS server is configured to resolve user names from left to right, it considers
the left part of a delimiter as a user name and the right part of the delimiter as a domain
name; if the RADIUS server is configured to resolve user names from right to left, it
considers the right part of a delimiter as a user name and the right part of the delimiter as
a domain name.
1.4.3 HWTACACS
Format of an HWTACACS message
The process of transmitting HWTACACS messages is similar to that of transmitting RADIUS
messages.
Features of HWTACACS
Compared with RADIUS, HWTACACS is more reliable in transmission and encryption and
thus is more suitable for security control. Table 1-1 shows comparisons between HWTACACS
and RADIUS.
Table 1-1 Comparisons between HWTACACS and RADIUS
HWTACACS RADIUS
Uses the Transmission Control Protocol
(TCP) to provide reliable transmission.
Uses UDP.
Encrypts the main structure of a packet
except the standard HWTACACS header.
Encrypts only the password field in the
authentication packet.
Separates authorization from
authentication.
Performs authentication together with
authorization.
10
HWTACACS RADIUS
Is suitable for security control. Is suitable for accounting.
Authorizes the commands executed by
administrative users.
Does not authorize the commands executed by
administrative users.

In HWTACACS, authentication is separated from authorization. Therefore, you can use
RADIUS for authentication and HWTACACS for authorization. In such a case, though RADIUS
authorization is performed, only HWTACACS authorization takes effects.
Command-Line Authorization in HWTACACS
HWTACACS supports command-line authorization for the users with specific levels in a
specified domain or a specified Secure Shell (SSH) user.
In command-line authorization mode, after a user logs in to the router through Telnet or SSH,
every command input by the user needs to be authorized by the HWTACACS server. The
command can be run only after command-line authorization is passed. Otherwise, the
HWTACACS server displays a message to inform the user that command-line authorization
fails and the command cannot be run.
If the router does not receive any authorization response from the HWTACACS server within
the timeout period set by the user, it considers that the command-line authorization times out,
and thus the command cannot be run.
Figure 1-3 shows the process of command-line authorization in HWTACACS.
Figure 1-3 Process of command-line authorization in HWTACACS
User Router TACACS
Server
1.command
2.author-cmd REQ
3.author-cmd ACK

1. The user enters a command on the NE80E/40E.
2. The NE80E/40E sends a command-line authorization request to the TACACS server.
3. The TACACS server returns the authorization result to the NE80E/40E. If authorization
succeeds, the user can run the command of the corresponding level; otherwise, the user
cannot run the command.
1.4.4 User Management
Overview
The BRAS is used to manage access users. Currently, the BRAS manages users in the following
modes:
11
l Domain-based user management
All users belong to a same domain. By default, users are added to the default domain. The
BRAS manages users by configuring service attributes in a domain. Thus, the users in the
same domain have the same service attributes.
l User account-based user management
User accounts and related service attributes are configured on an AAA server such as the
RADIUS server or the HWTACACS server, and are then delivered to users when the users
get online, or dynamically delivered to users after the users get online.
In practical applications (except in non-authentication and non-accounting modes) on the
NE80E/40E, all user accounts must be configured on an AAA server, and the domain to which
the user accounts belong must be configured on the NE80E/40E. The NE80E/40E supports the
configuration and management of local user accounts.
The service attributes configured for a domain have a lower priority than the service attributes
delivered by an AAA server. Therefore, when service attributes are both configured for a domain
and delivered by an AAA server, the NE80E/40E adopts the service attributes that are delivered
by the AAA server. The service attributes configured for a domain take effect only when the
AAA server does not support or deliver the service attributes.
Overview of a Domain
The NE80E/40E supports a user account in the format of username@domain or
domain@username. Here, @ is a domain name delimiter. The positions of the domain name and
the user name can be exchanged. If the user account that is input when a user accesses the NE80E/
40E does not contain a domain name, it indicates that the user belongs to the default domain of
the system.
l Default domain
A default domain is fixed in the system. The service attributes of the default domain can
be modified rather than deleted.
The NE80E/40E has three default domains: default0, default1, and default_admin, as
shown in Table 1-2.
Table 1-2 Default domains of the NE80E/40E
Name Description Default
Attributes
default0 It is a domain to which a user belongs before
authentication. When a user access the NE80E/40E
and is not authenticated, the NE80E/40E does not
know the domain of the user, and thus by default
considers that the user belongs to default0.
Non-
authentication
Non-accounting
default1 It is a domain to which a user belongs during
authentication. During authentication, if a user inputs
a user account that does not contain a domain name,
the NE80E/40E by default considers that the user
belongs to default1.
RADIUS
authentication
RADIUS
accounting
12
Name Description Default
Attributes
default_admin It is a domain to which an operation user belongs. In
the case that an operation user logs in to the NE80E/
40E through Telnet or SSH, if the operation user inputs
a user account that does not contain a domain name
during authentication, the NE80E/40E by default
considers that the operation user belongs to
default_admin.
First local
authentication and
later RADIUS
authentication
Non-accounting

l Domain type
The NE80E/40E supports the following types of domains:
Default-domain pre-authentication
Default-domain authentication
Default-domain authentication force
Default-domain authentication replace
Authentication domain
Roam-domain
Permit-domain
The following describes the functions of each type of domain:
Default-domain pre-authentication
This domain is used for only Web authentication users and fast authentication users to
obtain IP addresses. A user binds the user name to this domain and then obtains an IP
address after passing Web authentication. Then, the user obtains corresponding rights
according to the user group name in this domain. After passing the Web authentication
in this domain, the users can access only the Web authentication server and the DNS.
(The access rights are controlled through the UCL-group and ACLs.)
If the default-domain pre-authentication is not configured on a BAS interface, default0
is adopted as the default-domain pre-authentication.
Default-domain authentication
If a user inputs a user account that does not contain a domain name during authentication,
the user adopts the authentication scheme, accounting scheme, and RADIUS server that
are configured in the default-domain authentication.
If the default-domain authentication is not configured on a BAS interface, default1 is
adopted as the default-domain authentication.
Default-domain authentication force
A user adopts the authentication scheme, accounting scheme, and RADIUS server that
are configured in this domain, regardless of whether a domain name is contained in the
input user account or what the domain name is. If a domain name is contained in the
user account, the domain name remains unchanged during authentication; if no domain
name is contained, the default-domain authentication force is added to the user account.
Default-domain authentication replace
A user adopts the authentication scheme, accounting scheme, and RADIUS server that
are configured in this domain, regardless of whether a domain name is contained in the
13
input user account or what the domain name is. If a domain name is contained in the
user account, the domain name is replaced with the default-domain authentication
replace during authentication; if no domain name is contained, the default-domain
authentication replace is added to the user account.
Authentication domain
It is a domain name that is contained in the user account input by a user. When a user
inputs a normal user account (a domain name is contained and is configured on the
NE80E/40E, and the BAS interface is not configured with the default-domain
authentication force or default-domain authentication replace), the user adopts the
authentication scheme, accounting scheme, and RADIUS server that are configured in
the input domain name.
Roam-domain
A user must input a user account containing a domain name; otherwise, the user cannot
adopt the roam-domain policy. If the domain name is not configured on the NE80E/
40E, the user adopts the authentication scheme, accounting scheme, and RADIUS server
that are configured in the roam-domain. The user account remains unchanged during
authentication.
If the roam-domain is not configured on a BAS interface, default1 is adopted as the
roam domain.
Permit-domain
It is a domain that is allowed to access when users are getting online through a BAS
interface.
l Domain application
Users getting online with a domain name
Assume that a user inputs a user account, namely, user@A.
The BAS interface that accesses the user is not configured with the default-domain
authentication. If domain A is configured on the NE80E/40E, the user adopts the
authentication and accounting schemes that are configured in domain A, and the user
account for authentication is user@A. If domain A is not configured on the NE80E/
40E, and the roam-domain is disabled, the user authentication fails. If the roam-
domain is enabled, the user adopts the authentication and accounting schemes that
are configured in the roam-domain.
The BAS interface that accesses the user is configured with domain B as the default-
domain authentication. If domain A is configured on the NE80E/40E, the user adopts
the authentication and accounting schemes that are configured in domain A, and the
user account for authentication is user@A. If domain A is not configured on the
NE80E/40E, and the roam-domain is disabled, the user authentication fails. If the
roam-domain is enabled, the user adopts the authentication and accounting schemes
that are configured in the roam-domain.
The BAS interface that accesses the user is configured with domain E as the roam-
domain. If domain A is not configured on the NE80E/40E, the user adopts the
authentication and accounting schemes that are configured in domain E. If domain
A is configured on the NE80E/40E, the user adopts the authentication and accounting
schemes that are configured in domain A, and the user account for authentication is
user@A.
The BAS interface that accesses the user is configured with domain F as the default-
domain authentication force. In this case, the user adopts the authentication and
accounting schemes that are configured in domain F (regardless of whether domain
14
A is configured on the NE80E/40E or whether a roam-domain is configured), and
the user account for authentication is still user@A.
The BAS interface that accesses the user is configured with domain G as the default-
domain authentication replace. In this case, the user adopts the authentication and
accounting schemes that are configured in domain G (regardless of whether domain
A is configured on the NE80E/40E or whether a roam-domain is configured), and
the user account for authentication is changed into user@G.
Users getting online without a domain name
Assume that a user inputs a user account, namely, user.
If the BAS interface that accesses the user is not configured with the default-domain
authentication, the user adopts the authentication and accounting schemes that are
configured in default1, and the user account for authentication is user@default1.
If the BAS interface that accesses the user is configured with domain B as the default-
domain authentication, the user adopts the authentication and accounting schemes
that are configured in domain B (domain B here is a default domain), and the user
account for authentication is user@B.
If the BAS interface that accesses the user is configured with domain H as the default-
domain authentication force, the user adopts the authentication and accounting
schemes that are configured in domain H, and the user account for authentication is
user@H.
If the BAS interface that accesses the user is configured with domain J as the default-
domain authentication replace, the user adopts the authentication and accounting
schemes that are configured in domain J, and the user account for authentication is
user@J.
No matter a user gets online with or without a domain name, after confirming the
authentication domain of the user, the NE80E/40E still has to determine whether the
authentication domain is allowed to access the BAS interface on which a permit-domain
is configured.
NOTE
The user account mentioned above is not the one that is sent to an AAA server. Instead, whether the user
account sent to the AAA server contains a domain name depends on whether the device is configured to
send a domain name to the AAA server.
Domain Management
A domain or an AAA server manages users by configuring service attributes for the users.
Domain management includes access management and service management.
l Access management
In a domain, you can configure the authorization, authentication, and accounting schemes
and corresponding server that are used when a user accesses the BAS interface; configure
the authentication mode used in user authentication; specify the IP address pool and the
DNS server that are used to assign an IP address to a user; and control the user access by
setting a limit on access number
The following functions are highlighted:
Time period control
In a specified time period, a domain automatically enters the blocked state. At this time,
the users in the domain cannot get online, and the online users are forced to get offline.
When the time period expires, the domain is activated and users in the domain can get
15
online. Four time periods can be set in a domain, and all of them can take effect
independent of each other.
Mandatory PPP authentication
Generally, the authentication mode (PAP/CHAP/MSCHAP) for PPP users is
determined through the negotiation between the PPP client and the virtual template (VT)
interface. After an authentication mode is configured in a domain for PPP users, the
PPP users are authenticated according to the configured authentication mode.
IP address alarm
After the upper threshold (in percentage) of IP addresses is set, the NE80E/40E sends
a trap to the NMS when the IP address utilization exceeds the upper threshold. If the
threshold of IP addresses is not set, the NE80E/40E does not generate any alarm no
matter how the IP addresses in the domain are used.
Mandatory Web authentication
Mandatory Web authentication: If the user that requires Web authentication or fast
authentication attempts to access an unauthorized address before authentication, the
NE80E/40E redirects the access request to the mandatory Web authentication server for
the user to be authenticated.
l Service management
After a user gets online, the user can be managed through a domain in terms of basic access
services (such as access the Internet) or the right, bandwidth, and QoS of the value-added
services.
The involved service attributes include: QoS profile, user priority, captive portal, multicast
group, time period, traffic statistics, accounting packet copy, and idle-cut. The following
functions are described:
Captive portal
Captive portal means that when a user accesses the external network for the first time
after passing the authentication, the NE80E/40E forcibly redirects the access request to
a certain server, which is usually the portal server of a carrier. In this manner, a service
provided by the carrier is immediately accessed after the user is connected to the
Internet.
Idle-cut
Idle-cut means that when the traffic from a user is smaller than the lower threshold in
a certain time period, the NE80E/40E considers that the user is idle, and thus cut off the
connection with the user. In the configuration of the idle-cut function, you need to
specify two parameters, namely, the time period and the traffic.
Traffic statistics collection
This function can be classified into two categories: function of collecting total traffic
in a domain and function of collecting the upstream and downstream traffic of a user.
QoS control based on the time period
QoS control is implemented for domain users within a specific time period. When the
time period expires, there will be no QoS control for domain users.
1.5 Applications
16
1.5.1 RADIUS Authentication and Accounting
User 1, user 2, and user 3 access the Internet through the NE80E/40E. The users send
authentication packets to the RADIUS server for authentication and authorization. When the
master server goes Down, the packets are switched to the backup server for authentication or
accounting. After the authentication succeeds, the RADIUS server delivers corresponding rights
to the users, and thus the users can access the Internet.
Figure 1-4 Network diagram of RADIUS authentication and accounting
user1@isp1
user2@isp2
user3@isp3
Router
RADIUS
(master)
RADIUS
(backup)
Internet
129.7.66.67 129.7.66.66

1.5.2 HWTACACS Authentication, Accounting, and Authorization
User 1, user 2, and user 3 access the Internet through the NE80E/40E. The users send
authentication packets to the HWTACACS server for authentication and authorization. When
the master server goes Down, the packets are switched to the backup server for authentication
or accounting. After the authentication succeeds, the HWTACACS server delivers
corresponding rights to the users, and then the users can access the Internet. The accounting bills
can also be copied to the bill server the same time they are being sent to the HWTACACS server.
Figure 1-5 Networking diagram of HWTACACS authentication, accounting, and authorization
user1@isp1
user2@isp2
user3@isp3
Router
HWTACACS
(master)
HWTACACS
(backup)
Internet
130.7.66.67 130.7.66.66
Bill sever
10.10.10.1
17

1.6 Terms and Abbreviations
Abbreviation Full Spelling
AAA Authentication Authorization Accounting
RADIUS Remote Authentication Dial In User Service
HWTACACS HUAWEI Terminal Access Controller Access Control System

18

Feature Description - User Access (Nonx1x2) (V600R003C00 - 02)

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Feature Description - User Access (Nonx1x2) (V600R003C00 - 02)

Загружено:

Авторское право:

Доступные форматы

HUAWEI NetEngine80E/40E Router

Вам также может понравиться