No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

CX11x, CX31x, CX710 (Earlier Than V6.03), and CX91x Series Switch Modules V100R001C10 Configuration Guide 12

The documents describe the configuration of various services supported by the CX11x&CX31x&CX91x series switch modules The description covers configuration examples and function configurations.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Principles

Principles

This section describes the implementation of AAA.

Concepts

AAA Architecture

AAA uses the client/server structure. AAA architecture features good scalability and facilitates centralized user information management. Figure 12-1 shows the AAA architecture.

Figure 12-1 AAA architecture

Authentication

AAA supports the following authentication modes:

  • Non-authentication: Users are completely trusted without validity check. This mode is rarely used.

  • Local authentication: User information is configured on the network access server (NAS). This mode features fast processing and low operation cost. The major limitation of local authentication is that information storage is subject to the device hardware capacity.

  • Remote authentication: User information is configured on the authentication server. AAA can remotely authenticate users through the Remote Authentication Dial In User Service (RADIUS) or Huawei Terminal Access Controller Access Control System (HWTACACS) protocol.

Authorization

AAA supports the following authorization modes:

  • Non-authorization: Users are not authorized.

  • Local authorization: authorizes users according to the attributes configured on the NAS for the local user accounts.

  • HWTACACS authorization: authorizes users through the HWTACACS server.

  • RADIUS authorization: Users pass the RADIUS authorization upon passing the RADIUS authentication. RADIUS integrates authentication and authorization. Therefore, RADIUS authorization cannot be performed separately.

  • If-authenticated authorization: applies to scenarios where users must be authenticated and the authentication process is separated from the authorization process. That is, this mode is available for only local authentication and HWTACACS authentication, and is unavailable for RADIUS authentication.
    • After local authentication is successful, local authorization is used.
    • After HWTACACS authentication is successful, all rights are enabled. That is, HWTACACS authorization is not required.
Accounting

AAA supports the following accounting modes:

  • Non-accounting: Users are not charged.

  • Remote accounting: supports remote accounting through the RADIUS or HWTACACS server.

RADIUS Protocol

RADIUS Protocol Overview

RADIUS uses the client/server model in distributed mode and protects a network from unauthorized access. It is often used in network environments that require high security and control remote user access. It defines the User Datagram Protocol (UDP)-based RADIUS packet format and message transmission mechanism, and specifies UDP ports 1812 and 1813 as the authentication and accounting ports respectively.

At the beginning, RADIUS was only the AAA protocol used for dial-up users. When diversified user access modes are used, RADIUS can also be applied to these access modes such as Ethernet access. RADIUS provides the access service through authentication and authorization and records the network resources used by users through accounting.

RADIUS has the following characteristics:

  • Client/Server model

    • RADIUS client: RADIUS clients run on the network access servers (NAS) to transmit user information to the specified RADIUS server and process requests (for example, accept or reject user access) based on the responses from the servers. RADIUS clients can locate at any node on a network.

      As the RADIUS client, the device supports:

      • Standard RADIUS protocol and its extensions, including Request For Comments (RFC) 2865 and RFC 2866

      • Huawei-developed private attributes

      • Active detection on the RADIUS server status

      • Retransmission for Accounting Stop packets in the local buffer

      • Automatic switching function of the RADIUS server

  • RADIUS server: RADIUS servers run on central computers and workstations to maintain user authentication and network service access information. The servers receive connection requests from users, authenticate the users, and send the responses (indicating that the requests are accepted or rejected) to the clients. RADIUS servers need to maintain three databases, as shown in Figure 12-2.

    Figure 12-2 Databases maintained by the RADIUS servers

    • Users: stores user information such as user names, passwords, protocols, and IP addresses.
    • Clients: stores RADIUS client information such as the shared key and IP address of an access device.
    • Dictionary: stores the attributes in the RADIUS protocol and their value descriptions.
  • Security mechanism

    RADIUS clients and servers exchange authentication messages using shared keys that cannot be transmitted through networks, which enhances information exchange security. In addition, passwords are encrypted using shared keys before being transmitted to avoid theft on an insecure network.

  • Fine scalability

    RADIUS packets consist of the packet header and a certain number of attributes. After new attributes are added to RADIUS packets, its implementation remains unchanged.

RADIUS Packet Overview
RADIUS Packet Format

RADIUS uses UDP packets to transmit information. Figure 12-3 shows the RADIUS packet format.

Figure 12-3 RADIUS packet format

Fields in a RADIUS packet include:
  • Code: 1 byte. It describes the RADIUS packet type. The Code value varies in different types of RADIUS packets. For example, the value 1 indicates an Access-Request packet, and the value 2 indicates an Access-Accept packet.
  • Identifier: 1 byte. It is used to match request packets and reply packets, and detect the request packets retransmitted within a certain period. After a client sends a request packet, the server sends a reply packet with the same Identifier value as the request packet.
  • Length: 2 bytes. It specifies the RADIUS packet length. Bytes out of the specified length value are treated as padding and ignored on the receiver. If the length of a received packet is smaller than the Length value, the packet is discarded.
  • Authenticator: 16 bytes. It is used to verify the reply packets sent by the RADIUS server and encrypt user password.
  • Attribute: variable length. It is the content of a packet carrying authentication, authorization, and accounting information and providing configuration details of request and reply packets. An Attribute field may contain multiple attributes, each of which consists of Type, Length, and Value.

    • Type: 1 byte. It indicates the attribute type. The value ranges from 1 to 255.
    • Length: It indicates the length of an attribute (including type, length, and attribute). The unit is byte.
    • Value: It indicates the attribute information. The format and content are dependent on Type and Length. The maximum length is 253 bytes.
RADIUS Packet Type

RADIUS defines 16 tytes of packets. Table 12-1 describes the authentication packets, Table 12-2 describes the accounting packets, and Table 12-3 describes the authorization packets.

Table 12-1 RADIUS authentication packet

Packet Name

Description

Access-Request

This is the first packet transmitted in a RADIUS interaction process. This packet carries user authentication information, such as user name and password. The Access-Request packet is from the RADIUS client to the RADIUS server. The RADIUS server determines whether a user is allowed to access the network according to the user information carried in this packet.

Access-Accept

This packet is sent by the RADIUS server to respond to the Access-Request packet sent by the client. If all attributes in the Access-Request packet are acceptable, the server considers that the user passes the authentication and sends this packet. After receiving this packet, the client grants the network access rights to the user.

Access-Reject

This packet is sent by the RADIUS server to respond to the Access-Request packet sent by the client. If any attribute in the Access-Request packet is unacceptable, the RADIUS server considers that the user fails the authentication and sends this packet.

Access-Challenge

During an EAP authentication, when the RADIUS server receives an Access-Request packet carrying the user name, it generates a random MD5 challenge and sends the MD5 challenge to the client through this packet. After the client encrypts the user password using the MD5 challenge, the client sends the encrypted password in an Access-Request packet to the RADIUS server. The RADIUS server compares the encrypted password received from the client with the locally encrypted password. If they are the same, the server considers the user valid.

Table 12-2 RADIUS accounting packet

Packet Name

Description

Accounting-Request (Start)

If the client uses RADIUS accounting, the client sends this packet to the server before accessing network resources.

Accounting-Response (Start)

After receiving and recording the Accounting-Request (Start) packet, the server returns this packet to the client.

Accounting-Request (Interim-update)

If the accounting server fails to receive the Accounting-Request (Stop) packet, the server cannot stop accounting for the user. To address this problem, configure interim accounting on the client. The client then periodically sends accounting packets to the server.

Accounting-Response (Interim-update)

After receiving an Accounting-Request (Interim-update) packet, the server returns this packet to the client.

Accounting-Request (Stop)

When a user goes offline voluntarily or is forcibly disconnected, the client sends this packet carrying the network resource usage information (including online duration and number of incoming/outgoing bytes) to the server, requesting the server to stop accounting.

Accounting-Response (Stop)

After receiving an Accounting-Request (Stop) packet, the server sends this packet to the client.

Table 12-3 RADIUS authorization packet

Packet Name

Description

CoA-Request

When the administrator needs to modify the rights of an online user (for example, prohibit the user from accessing a website), the server sends this packet to the client, requesting the client to modify the user rights.

CoA-ACK

If the client successfully modifies the user rights, the client sends this packet to the server.

CoA-NAK

If the client cannot modify the user rights, the client sends this packet to the server.

DM-Request

When the administrator needs to disconnect a user, the server sends this packet to the client, requesting the client to disconnect the user.

DM-ACK

If the client successfully disconnects the user, the client sends this packet to the server.

DM-NAK

If the client cannot disconnect the user, the client sends this packet to the server.

RADIUS Interaction Process
RADIUS Authentication, Authorization, and Accounting

The access device functions as a RADIUS client to collect user information, including user name and password, and sends the information to the RADIUS server. The RADIUS server authenticates users according to the information, and performs authorization and accounting for the users after the users are authenticated. Figure 12-4 shows information exchanged between a user, the RADIUS client, and the RADIUS server.

Figure 12-4 RADIUS authentication, authorization, and accounting process
  1. A user sends a connection request carrying the user name and password to the RADIUS client (access device).
  2. The RADIUS client sends an Access-Request packet containing the user identity information to the RADIUS server according to the user name and password.
  3. The RADIUS server verifies the user identity:

    • If the user identity is valid, the RADIUS server returns an Access-Accept packet to the RADIUS client. The Access-Accept packet contains authorization information.
    • If the user identity is invalid, the RADIUS server returns an Access-Reject packet to the RADIUS client to reject access from the user.
  4. The RADIUS client notifies the user whether authentication is successful.
  5. The RADIUS client permits or rejects the user according to the authentication result. If the user is permitted, the RADIUS client sends an Accounting-Request (Start) packet to the RADIUS server.
  6. The RADIUS server sends an Accounting-Response (Start) packet to the RADIUS client and starts accounting.
  7. The user starts to access network resources.
  8. (Optional) If interim accounting is enabled, the RADIUS client periodically sends Accounting-Request (Interim-update) packets to the RADIUS server, preventing incorrect accounting result caused by unexpected user disconnection.
  9. (Optional) The RADIUS server returns Accounting-Response (Interim-update) packets and performs interim accounting.
  10. The user sends a logout request.
  11. The RADIUS client sends an Accounting-Request (Stop) packet to the RADIUS server.
  12. The RADIUS server sends an Accounting-Response (Stop) packet to the RADIUS client and stops accounting.
  13. The RADIUS client notifies the user of the processing result, and the user stops accessing network resources.
CoA

Change of Authorization (CoA) allows the administrator to change the right of an authenticated online user through RADIUS. For example, a VLAN ID can be delivered to some access users through CoA packets, so that they belong to the same VLAN no matter which interfaces they connect to. Figure 12-5 shows the CoA interaction process.

Figure 12-5 CoA interaction process

  1. The RADIUS server sends a CoA-Request packet to the RADIUS client according to service information, requesting the client to modify user authorization information. The CoA-Request packet may contain the policy name (configured on the RADIUS client) or ACL rules.
  2. The RADIUS client modifies user authorization information according to the CoA-Request packet without disconnecting the user.
  3. The RADIUS client returns a CoA-ACK or CoA-NAK packet.
    • If the authorization information is modified (for example, the policy name in the CoA packet is the same as that configured on the client), the RADIUS client returns a CoA-ACK packet to the RADIUS server.
    • If the authorization information cannot be modified, the RADIUS client returns a CoA-NAK packet to the RADIUS server.
DM

When a user needs to be disconnected forcibly, the RADIUS server sends a Disconnect Message (DM) to the RADIUS client. Figure 12-6 shows the DM interaction process.

Figure 12-6 DM interaction process

  1. The administrator forcibly disconnects a user on the RADIUS server. The RADIUS server sends a DM Request packet to the RADIUS client, requesting the client to disconnect the user.
  2. When receiving the DM Request packet, the RADIUS client requests the user to go offline.
  3. The RADIUS client returns a DM ACK or DM NAK packet.

    • If the user successfully goes offline, the RADIUS client returns a DM ACK packet to the RADIUS server.
    • If the user cannot go offline, the RADIUS client returns a DM NAK packet to the RADIUS server.

HWTACACS Protocol

HWTACACS Protocol Overview

HWTACACS is an enhancement to TACACS (RFC 1492). Similar to RADIUS, HWTACACS uses the client/server model to implement communication between NAS and HWTACACS servers.

HWTACACS is used to perform authentication, authorization, and accounting for the users accessing the Internet through Point-to-Point Protocol (PPP) or Virtual Private Dial-up Network (VPDN) and the management users. For example, an HWTACACS server can be configured to perform authentication, authorization, and accounting for the management users logging in to the device. The device functions as the HWTACACS client to send the user names and passwords to the HWTACACS server. The authorized users can log in to the device and perform operations.

Both HWTACACS and RADIUS protocols can implement authentication, authorization, and accounting. They are similar in the following aspects:
  • Client/server model
  • Using a public key to encrypt user information
  • Good flexibility and extensibility

Compared with RADIUS, HWTACACS is more reliable in transmission and encryption, and is more suitable for security control. Table 12-4 lists the differences between HWTACACS and RADIUS.

Table 12-4 Comparisons between HWTACACS and RADIUS

HWTACACS

RADIUS

Transmits data through TCP, which is more reliable.

Transmits data through UDP, which is more efficient.

Encrypts the entire packet except for the standard HWTACACS header.

Encrypts only the password field in the packet.

Separates authentication from authorization so that authentication and authorization can be implemented on different security servers. For example, an HWTACACS server can perform authentication and the other one can perform authorization.

Combines authentication and authorization.

Supports command line authorization. The command line use is restricted by command level and AAA. When a user enters a command, the command is executed only after being authorized by the HWTACACS server.

Does not support command line authorization. The commands that a user can use depend on the user level. A user can only use the commands of the same level as or lower level than the user level.

Applies to security control.

Applies to accounting.

HWTACACS Packet Overview

Unlike RADIUS packets which all use the same format, HWTACACS packets use different formats. However, the HWTACACS Authentication Packet, HWTACACS Authorization Packet, and HWTACACS Accounting Packet use different formats except that they all share the same HWTACACS Packet Header.

HWTACACS Packet Header

All HWTACACS packets have a 12-byte packet header, as shown in Figure 12-7.

Figure 12-7 HWTACACS packet header
Table 12-5 Fields in HWTACACS packet header
Field Description
major version Major version of the HWTACACS protocol. The current version is 0xc.
minor version Minor version of the HWTACACS protocol. The current version is 0x0.
type HWTACACS protocol packet type, including authentication (0x01), authorization (0x02), and accounting (0x03).
seq_no Packet sequence number in a session, ranging from 1 to 254.
flags Encryption flag on the packet body. Only the first bit among the 8 bits is supported. The value 0 indicates to encrypt the packet body, and the value 1 indicates not to encrypt the packet body.
session_id Session ID, which is the unique identifier of a session.
length Length of the HWTACACS packet body, excluding the packet header.
HWTACACS Authentication Packet Format
HWTACACS authentication packets include:
  • Authentication Start: When an authentication starts, the client sends this packet carrying the authentication type, user name, and authentication data to the server.
  • Authentication Continue: When receiving the Authentication Response packet from the server, the client returns this packet if the authentication process is not ended.
  • Authentication Reply: When the server receives the Authentication Start or Authentication Continue packet from the client, the server sends this packet to the client to notify the client of the current authentication status.
The HWTACACS authentication packets have different formats.
  • Figure 12-8 shows the format of HWTACACS Authentication Start packets.

    Figure 12-8 HWTACACS Authentication Start packet format
    Table 12-6 Fields in HWTACACS Authentication Start packet
    Field Description
    action Authentication action.
    priv_lvl User privilege level.
    authen_type Authentication type, including:
    • CHAP(0x03)
    • PAP(0x02)
    • ASCII(0x01)
    service Type of the service requesting authentication. The PPP(0x03), LOGIN(0x01), and NONE(0x00) types are available, corresponding to PPP users, administrators, and other users.
    user len Length of the user name entered by a login user.
    port len Length of the port field.
    rem_addr len rem_addr field length.
    data len Authentication data length.
    user Name of the user requesting authentication. The maximum length is 129.
    port

    Name of the user interface requesting authentication. The maximum length is 47.

    • For management users, this field indicates the user terminal interface, for example, console0 and vty1. For example, the authen_type of Telnet users is ASCII, service is LOGIN, and port is vtyx.
    • For other users, this field indicates the user access interface.
    rem_addr IP address of the login user.
    data Authentication data. Different data is encapsulated depending on the values of action and authen_type. For example, when PAP authentication is used, the value of this field is PAP plain-text password.
  • Figure 12-9 shows the format of HWTACACS Authentication Continue packets.

    Figure 12-9 HWTACACS Authentication Continue packet format
    Table 12-7 Fields in HWTACACS Authentication Continue packet
    Field Description
    user_msg len Length of the character string entered by a login user.
    data len Authentication data length.
    flags Authentication continue flag. The value 0 indicates that the authentication continues, and the value 1 indicates that the authentication has ended.
    user_msg Character string entered by the login user. This field carries the user login password to respond to the server_msg field in the Authentication Response packet.
    data Authentication data. Different data is encapsulated depending on the values of action and authen_type. For example, when PAP authentication is used, the value of this field is PAP cipher-text password.
  • Figure 12-10 shows the format of HWTACACS Authentication Response packets.

    Figure 12-10 HWTACACS Authentication Response packet format
    Table 12-8 Fields in HWTACACS Authentication Response packet
    Field Description
    status

    Authentication status, including:

    • PASS (0x01): Authentication is successful.
    • FAIL (0x02): Authentication is fail.
    • GETDATA (0x03): Request user information.
    • GETUSER (0x04): Request user name.
    • GETPASS (0x05): Request password.
    • RESTART (0x06): Request reauthentication.
    • ERROR (0x07): An error occurs when the server receives authentication packets.
    • FOLLOW (0x21): The server requests reauthentication.
    flags Whether the client displays the password entered by user in plain text. The value 1 indicates that the password is not displayed in plain text.
    server_msg len Length of the server_msg field.
    data len Authentication data length.
    server_msg Optional field. This field is sent by the server to the user to provide additional information.
    data Authentication data, providing information to client.
HWTACACS Authorization Packet Format
HWTACACS authorization packets include:
  • Authorization Request: HWTACACS separates authentication from authorization. Therefore, a user can be authenticated by HWTACACS, and authorized using another protocol. If a user is authenticated by HWTACACS, the client sends an Authorization Request packet carrying authorization information to the server.
  • Authorization Response: After receiving the Authorization Request packet, the server sends this packet carrying the authorization result to the client.
The HWTACACS authorization packets have different formats.
  • Figure 12-11 shows the format of HWTACACS Authorization Request packets.

    Figure 12-11 HWTACACS Authorization Request packet format
    NOTE:

    The meanings of the priv_lvl, authen_type, authen_service, user len, port len, rem_addr len, port, and rem_addr fields in the Authorization Request packet are the same as those in the Authentication Start packet, and are not provided here.

    Table 12-9 Fields in HWTACACS Authorization Request packet
    Field Description
    authen_method

    Authentication method, including

    • No authentication method configured (0x00)
    • None authentication (0x01)
    • Local authentication (0x05)
    • HWTACACS authentication (0x06)
    • RADIUS authentication (0x10)
    authen_service Type of the service requesting authentication. The PPP(0x03), LOGIN(0x01), and NONE(0x00) types are available, corresponding to PPP users, administrators, and other users.
    arg_cnt Number of attributes carried in Authorization Request packet.
    argN Attribute of the Authorization Request packet.
  • Figure 12-12 shows the format of HWTACACS Authentication Response packets.

    NOTE:

    The meanings of the server_msg len, data len, and server_msg fields are the same as those in HWTACACS Authentication Response packet, and are not provided here.

    Figure 12-12 HWTACACS Authorization Response packet format
    Table 12-10 Fields in HWTACACS Authorization Response packet
    Field Description
    status

    Authorization status, including:

    • Authorization is successful (0x01)
    • The attributes in Authorization Request packets are modified by the TACACS server (0x02)
    • Authorization is fail (0x10)
    • An error occurs on the authorization server (0x11)
    • An authorization server is respecified (0x21)
    arg_cnt

    Number of attributes carried in Authorization Response packet.

    argN Authorization attribute delivered by the HWTACACS authorization server.
HWTACACS Accounting Packet Format
HWTACACS accounting packets include:
The HWTACACS accounting packets have different formats.
  • Figure 12-13 shows the format of HWTACACS Accounting Request packets.

    Figure 12-13 HWTACACS Accounting Request packet format
    NOTE:

    The meanings of the authen_method, priv_lvl, authen_type, user len, port len, rem_addr len, port, and rem_addr fields in the Accounting Request packet are the same as those in the Authorization Request packet, and are not provided here.

    Table 12-11 Fields in HWTACACS Accounting Request packet
    Field Description
    flags Accounting type:
    • Start accounting (0x02)
    • Stop accounting (0x04)
    • Interim accounting (0x08)
    authen_service Type of the service requesting authentication. The PPP(0x03), LOGIN(0x01), and NONE(0x00) types are available, corresponding to PPP users, administrators, and other users.
    arg_cnt Number of attributes carried in Accounting Request packet.
    argN Attribute of the Accounting Request packet.
  • Figure 12-14 shows the format of HWTACACS Accounting Response packets.

    Figure 12-14 HWTACACS Accounting Response packet format
    Table 12-12 Fields in HWTACACS Accounting Request packet
    Field Description
    server_msg len Length of the server_msg field.
    data len Length of the data field.
    status Accounting status:
    • Accounting is successful (0x01)
    • Accounting is fail (0x02)
    server_msg Information sent by the accounting server to the client.
    data Information sent by the accounting server to the administrator.
HWTACACS Interaction Process

This section describes how HWTACACS performs authentication, authorization, and accounting for Telnet users. Figure 12-15 shows the message exchange process.
Figure 12-15 HWTACACS message interaction

The HWTACACS message exchange process is as follows:
  1. A Telnet user sends a request packet.
  2. The HWTACACS client sends an Authentication Start packet to the HWTACACS server after receiving the request packet.
  3. The HWTACACS server sends an Authentication Reply packet to request the user name.
  4. The HWTACACS client sends a packet to query the user name after receiving the Authentication Reply packet.
  5. The user enters the user name.
  6. The HWTACACS client sends an Authentication Continue packet containing the user name to the HWTACACS server.
  7. The HWTACACS server sends an Authentication Reply packet to request the password.
  8. The HWTACACS client queries the password after receiving the Authentication Reply packet.
  9. The user enters the password.
  10. The HWTACACS client sends an Authentication Continue packet containing the password to the HWTACACS server.
  11. The HWTACACS server sends an Authentication Reply packet, indicating that the user has been authenticated.
  12. The HWTACACS client sends an Authorization Request packet to the HWTACACS server.
  13. The HWTACACS server sends an Authorization Response packet, indicating that the user is authorized.
  14. The HWTACACS client receives the Authorization Response packet and displays the login page.
  15. The HWTACACS client sends an Accounting Request (start) packet to the HWTACACS server.
  16. The HWTACACS server sends an Accounting Response packet.
  17. The user requests to go offline.
  18. The HWTACACS client sends an Accounting Request (stop) packet to the HWTACACS server.
  19. The HWTACACS server sends an Accounting Response packet.
NOTE:

Both the HWTACACS protocol and TACACS+ protocol of other vendors can implement authentication, authorization, and accounting. Their authentication procedures and implementations are the same, so the HWTACACS protocol is completely compatible with the TACACS+ protocol.

Domain-based User Management

A domain is a group of users.

A NAS manages users based on domains. Each access user belongs to a domain that is determined by the user name provided for login, as shown in Figure 12-16.

Figure 12-16 Using the user name to determine the domain

The device has two default domains: default and default_admin. The two domains can be modified but cannot be deleted.

The default domain is not used. The default_admin domain is used for administrators such as the administrators who log in using SSH, Telnet, FTP, and terminals. By default, local authentication is performed for users in this domain when the administrator log in without domain.

The preconfigured authentication, authorization, and accounting scheme is used in the corresponding domain view to implement authentication, authorization, and accounting for users. AAA provides the default scheme including local authentication, local authorization, and local accounting. If no authentication, authorization, and accounting scheme is used in the domain of a user, the default scheme is used.

Authorization information configured in a domain has a lower priority than authorization information delivered by an AAA server. That is, the authorization information delivered by an AAA server is used preferentially. When the AAA server does not have or does not support authorization, the authorization attributes configured in a domain take effect. In this manner, you can increase services flexibly by means of domain management, regardless of the authorization attributes provided by the AAA server.

Translation
Download
Updated: 2019-08-09

Document ID: EDOC1000041694

Views: 59812

Downloads: 3623

Average rating:
This Document Applies to these Products
Related Version
Related Documents
Share
Previous Next