Table of Contents Table of Contents... 1-1 1.1 AAA/RADIUS/HWTACACS Over... 1-1 1.1.1 Introduction to AAA... 1-1 1.1.2 Introduction to RADIUS... 1-3 1.1.3 Introduction to HWTACACS... 1-9 1.1.4 Protocols and Standards... 1-12 1.2 AAA/RADIUS/HWTACACS Task List... 1-12 1.3 Configuring AAA... 1-14 1.3.1 Prerequisites... 1-14 1.3.2 Creating an ISP Domain... 1-14 1.3.3 Configuring ISP Domain Attributes... 1-15 1.3.4 Configuring an AAA Authentication Scheme for an ISP Domain... 1-16 1.3.5 Configuring an AAA Authorization Scheme for an ISP Domain... 1-17 1.3.6 Configuring an AAA Accounting Scheme for an ISP Domain... 1-19 1.3.7 Configuring Local User Attributes... 1-21 1.3.8 Tearing down User Connections Forcibly... 1-23 1.4 Configuring RADIUS... 1-24 1.4.1 Creating a RADIUS Scheme... 1-24 1.4.2 Specifying the RADIUS Authentication/Authorization Servers... 1-24 1.4.3 Configuring the RADIUS Accounting Servers and Relevant Parameters... 1-25 1.4.4 Setting the Shared Key for RADIUS Packets... 1-27 1.4.5 Setting the Maximum Number of RADIUS Request Retransmission Attempts... 1-27 1.4.6 Setting the Supported RADIUS Server Type... 1-28 1.4.7 Setting the Status of RADIUS Servers... 1-28 1.4.8 Configuring Attributes Related to the Data Sent to the RADIUS Server... 1-29 1.4.9 Setting Timers Regarding RADIUS Servers... 1-31 1.4.10 Configuring RADIUS Accounting-on... 1-32 1.4.11 Configuring an IP Address for the Security Policy Server... 1-33 1.4.12 Enabling the Listening Port of the RADIUS Client... 1-33 1.5 Configuring HWTACACS... 1-34 1.5.1 Creating a HWTACAS scheme... 1-34 1.5.2 Specifying the HWTACACS Authentication Servers... 1-34 1.5.3 Specifying the HWTACACS Authorization Servers... 1-35 1.5.4 Specifying the HWTACACS Accounting Servers... 1-35 1.5.5 Setting the Shared Key for HWTACACS Packets... 1-36 1.5.6 Configuring Attributes Related to the Data Sent to the TACACS Server... 1-37 1.5.7 Setting Timers Regarding HWTACACS Servers... 1-38 1.6 Displaying and Maintaining AAA/RADIUS/HWTACACS... 1-39 i
Table of Contents 1.6.1 Displaying and Maintaining AAA... 1-39 1.6.2 Displaying and Maintaining RADIUS... 1-39 1.6.3 Displaying and Maintaining HWTACACS... 1-40 1.7 AAA/RADIUS/HWTACACS Examples... 1-40 1.7.1 AAA for Telnet Users by a HWTACACS Server... 1-40 1.7.2 AAA for Telnet Users by Separate Servers... 1-42 1.8 Troubleshooting AAA/RADIUS/HWTACACS... 1-44 1.8.1 Troubleshooting RADIUS... 1-44 1.8.2 Troubleshooting HWTACACS... 1-45 ii
When configuring AAA/RADIUS/HWTACACS, go to these sections for information you are interested in: AAA/RADIUS/HWTACACS Over AAA/RADIUS/HWTACACS Task List Configuring AAA Configuring RADIUS Configuring HWTACACS Displaying and Maintaining AAA/RADIUS/HWTACACS AAA/RADIUS/HWTACACS Examples Troubleshooting AAA/RADIUS/HWTACACS 1.1 AAA/RADIUS/HWTACACS Over This section covers these topics: Introduction to AAA Introduction to RADIUS Introduction to HWTACACS 1.1.1 Introduction to AAA Authentication, Authorization, and Accounting (AAA) provides a uniform framework for configuring these three security functions to implement network security management. AAA usually uses a client/server model, where the client runs on the network access server (NAS) and the server maintains user information centrally. In an AAA network, a NAS is a server for users but a client for the AAA servers, as shown in Figure 1-1. 1-1
Internet User NAS RADIUS server Figure 1-1 AAA networking diagram HWTACACS server When a user tries to establish a connection to the NAS and obtain the rights to access other networks or some network resources, the NAS authenticates the user or the corresponding connection. The NAS can also transparently pass the user authentication, authorization and accounting information to the server (RADIUS server or HWTACACS server). The RADIUS/HWTACACS protocol defines how to exchange user information between a NAS and a server. In the AAA network shown in Figure 1-1, there is a RADIUS server and a HWTACACS server. You can determine the authentication, authorization and accounting scheme according to the actual requirements. For example, you can use the RADIUS server for authentication and authorization, and the HWTACACS server for accounting. The three security functions are described as follows: Authentication: Identifies remote users and judges whether a user is legal. Authorization: Grants different users different rights. For example, a user logging into the server can be granted the permission to access and print the files in the server. Accounting: Records all network service usage information of users, including the service type, start and end time, and traffic. In this way, accounting can be used for not only accounting itself, but also network security surveillance. You can use AAA to provide only one or two security functions, if desired. For example, if your company only wants employees to be authenticated before they access specific resources, you can configure only an authentication server. If the network usage information is expected to be recorded, you also need to configure an accounting server. As mentioned above, AAA provides a uniform framework to implement network security management. It is a security mechanism that enables authenticated and authorized entities to access specific resources and records operations by the entities. The AAA framework thus allows for excellent scalability and centralized user information management. 1-2
AAA can be implemented through multiple protocols. Currently, the device supports using RADIUS and HWTACACS for AAA, and RADIUS is often used in practice. 1.1.2 Introduction to RADIUS Remote Authentication Dial-In User Service (RADIUS) is a distributed information interaction protocol in the client/server model. RADIUS can protect networks against unauthorized access and is often used in network environments where both high security and remote user access are required. Based on UDP, RADIUS defines the RADIUS packet format and the message transfer mechanism, and uses UDP port 1812 as the authentication port and 1813 as the accounting port. RADIUS was originally designed for dial-in user access. With the diversification of access methods, RADIUS has been extended to support more access methods, for example, Ethernet access and ADSL access. It uses authentication and authorization to provide access service and uses accounting to collect and record usage of network resources by users. I. Client/server model Client: The RADIUS client runs on the NASs located throughout the network. It passes user information to designated RADIUS servers and acts on the response (for example, rejects or accepts user access requests). Server: The RADIUS server runs on the computer or workstation at the network center and maintains information related to user authentication and network service access. It authenticates a user after receiving a connection request and returns the processing result (for example, rejecting or accepting user access requests) to the client. In general, the RADIUS server maintains three databases, namely, Users, Clients, and Dictionary, as shown in Figure 1-2: Figure 1-2 RADIUS server components Users: Stores user information such as the username, password, applied protocols, and IP address. Clients: Stores information about RADIUS clients such as the shared keys and IP addresses. Dictionary: Stores the information for interpreting RADIUS protocol attributes and their values. 1-3
II. Security authentication mechanism Information exchanged between the RADIUS client and the RADIUS server is authenticated with a shared key, which is never transmitted over the network, thus enhancing the security of information exchange. To prevent user passwords from being intercepted in non-secure networks, the passwords are encrypted during transmission. A RADIUS server supports multiple user authentication methods, such as the Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP) of Point-to-Point Protocol (PPP). In addition, a RADIUS server can act as the client of another AAA server to provide proxy authentication or accounting service. III. Basic message exchange process of RADIUS For the interaction among the host, the RADIUS client, and the RADIUS server, see Figure 1-3. Figure 1-3 Basic message exchange process of RADIUS The following is how RADIUS operates: 1) The host initiates a connection request carrying the username and password to the RADIUS client. 2) Having received the username and password, the RADIUS client sends an authentication request (Access-Request) to the RADIUS server, where the user password is encrypted by the Message-Digest 5 (MD5) algorithm with the shared key. 1-4
3) The RADIUS server authenticates the username and password. If the authentication succeeds, it sends back an Access-Accept message containing the information of user s right. If the authentication fails, it returns an Access-Reject message. 4) The RADIUS client accepts or denies the user according to the returned authentication result. If it accepts the user, it sends a start-accounting request (Accounting-Request) to the RADIUS server. 5) The RADIUS server returns a start-accounting response (Accounting-Response) and starts accounting. 6) The subscriber accesses the network resources. 7) The host requests the RADIUS client to tear down the connection and the RADIUS client sends a stop-accounting request (Accounting-Request) to the RADIUS server. 8) The RADIUS server returns a stop-accounting response (Accounting-Response) and stops accounting. 9) The subscriber stops network resource accessing. IV. RADIUS packet structure RADIUS uses UDP to transmit messages. It ensures the smooth message exchange between the RADIUS server and the client through a series of mechanisms, including the timer management mechanism, retransmission mechanism, and slave server mechanism. Figure 1-4 shows the RADIUS packet structure. Figure 1-4 RADIUS packet structure Descriptions of fields are as follows: 1) The Code field (1-byte long) is for indicating the type of the RADIUS packet. Table 1-1 gives the possible values and their meanings. 1-5
Table 1-1 Main values of the Code field Code Packet type Description 1 Access-Request 2 Access-Accept 3 Access-Reject 4 Accounting-Request 5 Accounting-Response From the client to the server. A packet of this type carries user information for the server to authenticate the user. It must contain the User-Name attribute and can optionally contain the attributes of NAS-IP-Address, User-Password, and NAS-Port. From the server to the client. If all the attribute values carried in the Access-Request are acceptable, that is, the authentication succeeds, the server sends an Access-Accept response. From the server to the client. If any attribute value carried in the Access-Request is unacceptable, the server rejects the user and sends an Access-Reject response. From the client to the server. A packet of this type carries user information for the server to start/stop accounting on the user. It contains the Acct-Status-Type attribute, which indicates whether the server is requested to start the accounting or to end the accounting. From the server to the client. The server sends to the client a packet of this type to notify that it has received the Accounting-Request and has correctly recorded the accounting information. 2) The Identifier field (1-byte long) is for matching request packets and response packets and detecting retransmitted request packets. The request and response packets of the same type have the same identifier. 3) The Length field (2-byte long) indicates the length of the entire packet, including the Code, Identifier, Length, Authenticator, and Attribute fields. The value of the field is in the range 20 to 4096. Bytes beyond the length are considered the padding and are neglected after being received. If the length of a received packet is less than that indicated by the Length field, the packet is dropped. 4) The Authenticator field (16-byte long) is used to authenticate the reply from the RADIUS server, and is also used in the password hiding algorithm. There are two kinds of authenticators: Request authenticator and Response authenticator. 5) The Attribute field carries information about the configuration details of a request or response. This field is represented in triplets of Type, Length, and Value. 1-6
Type: One byte, in the range 1 to 255. It indicates the type of the attribute. Commonly used attributes for RADIUS authentication and authorization are listed in Table 1-2. Length: One byte for indicating the length of the attribute in bytes, including the Type, Length, and Value fields. Value: Value of the attribute, up to 253 bytes. Its format and content depend on the Type and Length fields. Table 1-2 RADIUS attributes No. Attribute type No. Attribute type 1 User-Name 45 Acct-Authentic 2 User-Password 46 Acct-Session-Time 3 CHAP-Password 47 Acct-Input-Packets 4 NAS-IP-Address 48 Acct-Output-Packets 5 NAS-Port 49 Acct-Terminate-Cause 6 Service-Type 50 Acct-Multi-Session-Id 7 Framed-Protocol 51 Acct-Link-Count 8 Framed-IP-Address 52 Acct-Input-Gigawords 9 Framed-IP-Netmask 53 Acct-Output-Gigawords 10 Framed-Routing 54 (unassigned) 11 Filter-ID 55 Event-Timestamp 12 Framed-MTU 56-59 (unassigned) 13 Framed-Compression 60 CHAP-Challenge 14 Login-IP-Host 61 NAS-Port-Type 15 Login-Service 62 Port-Limit 16 Login-TCP-Port 63 Login-LAT-Port 17 (unassigned) 64 Tunnel-Type 18 Reply_Message 65 Tunnel-Medium-Type 19 Callback-Number 66 Tunnel-Client-Endpoint 20 Callback-ID 67 Tunnel-Server-Endpoint 21 (unassigned) 68 Acct-Tunnel-Connection 22 Framed-Route 69 Tunnel-Password 23 Framed-IPX-Network 70 ARAP-Password 24 State 71 ARAP-Features 25 Class 72 ARAP-Zone-Access 1-7
No. Attribute type No. Attribute type 26 Vendor-Specific 73 ARAP-Security 27 Session-Timeout 74 ARAP-Security-Data 28 Idle-Timeout 75 Password-Retry 29 Termination-Action 76 Prompt 30 Called-Station-Id 77 Connect-Info 31 Calling-Station-Id 78 -Token 32 NAS-Identifier 79 EAP-Message 33 Proxy-State 80 Message-Authenticator 34 Login-LAT-Service 81 Tunnel-Private-Group-id 35 Login-LAT-Node 82 Tunnel-Assignment-id 36 Login-LAT-Group 83 Tunnel-Preference 37 Framed-AppleTalk-Link 84 ARAP-Challenge-Response 38 Framed-AppleTalk-Network 85 Acct-Interim-Interval 39 Framed-AppleTalk-Zone 86 Acct-Tunnel-Packets-Lost 40 Acct-Status-Type 87 NAS-Port-Id 41 Acct-Delay-Time 88 Framed-Pool 42 Acct-Input-Octets 89 (unassigned) 43 Acct-Output-Octets 90 Tunnel-Client-Auth-id 44 Acct-Session-Id 91 Tunnel-Server-Auth-id The attribute types listed in Table 1-2 are defined by RFC 2865, RFC 2866, RFC 2867, and RFC 2568. V. RADIUS extended attributes The RADIUS protocol features excellent extensibility. Attribute 26 (Vender-Specific) defined by RFC 2865 allows a vender to define extended attributes to implement functions that the standard RADIUS protocol does not provide. A vendor can encapsulate multiple type-length-value (TLV) sub-attributes in RADIUS packets for extension in applications. As shown in Figure 1-5, a sub-attribute that can be encapsulated in Attribute 26 consists of the following four parts: 1-8
Vendor-ID (four bytes): Indicates the ID of the vendor. Its most significant byte is 0 and the other three bytes contain a code complying with RFC 1700. The vendor ID of H3C is 2011. Vendor-Type: Indicates the type of the sub-attribute. Vendor-Length: Indicates the length of the sub-attribute. Vendor-Data: Indicates the contents of the sub-attribute. Figure 1-5 Segment of a RADIUS packet containing an extended attribute 1.1.3 Introduction to HWTACACS Huawei Terminal Access Controller Access Control System (HWTACACS) is an enhanced security protocol based on TACACS (RFC 1492). Similar to RADIUS, it uses the server/client model for information exchange between NAS and HWTACACS server. HWTACACS implements AAA mainly for such users as Point-to-Point Protocol (PPP) users, Virtual Private Dial-up Network (VPDN) users, and terminal users. In a typical HWTACACS application, a terminal user needs to log onto the device for operations. Working as the HWTACACS client, the device sends the username and password to the HWTACACS sever for authentication. After passing authentication and being authorized, the user can log into the device to perform operations. I. Differences between HWTACACS and RADIUS HWTACACS and RADIUS have many common features, like implementing AAA, using a client/server model, using shared keys for user information security and having good flexibility and extensibility. Meanwhile, they also have differences, as listed in Table 1-3. Table 1-3 Primary differences between HWTACACS and RADIUS HWTACACS Uses TCP, providing more reliable network transmission Encrypts the entire packet except for the HWTACACS header RADIUS Uses UDP, providing higher transport efficiency Encrypts only the password field in an authentication packet 1-9
HWTACACS Protocol packets are complicated and authorization is independent of authentication. Authentication and authorization can be deployed on different HWTACACS servers. Supports authorized use of configuration commands. For example, an authenticated login user can be authorized to configure the device. RADIUS Protocol packets are simple and authorization is combined with authentication. Does not support authorized use of configuration commands. II. Basic message exchange process of HWTACACS The following takes Telnet user as an example to describe how HWTACACS performs user authentication, authorization, and accounting. Figure 1-6 illustrates the basic message exchange process of HWTACACS. 1-10
User HWTACACS client HWTACACS server 1) The user logs in 2) Start-authentication packet 3) Authentication response requesting the username 4) Request for username 5) The user enters the username 6) Authentication continuance packet with the username 7) Authentication response requesting the login password 8) Request for password 9) The user enters the password 10) Authentication continuance packet with the login password 11) Authentication response indicating successful authentication 12) User authorization request packet 14) The user logs in successfully 13) Authorization response indicating successful authorization 15) Start-accounting request 16) Accounting response indicating the start of accounting 17) The user logs off 18) Stop-accounting request 19) Stop-accounting response Figure 1-6 Basic message exchange process of HWTACACS for a Telnet user 1) A Telnet user applies to access the NAS. 2) Upon receiving the request, the HWTACACS client sends a start-authentication packet to the HWTACACS server. 3) The HWTACACS server sends back an authentication response requesting the username. 4) Upon receiving the request, the HWTACACS client asks the user for the username. 5) The user enters the username. 6) After receiving the username from the user, the HWTACACS client sends to the server a continue-authentication packet carrying the username. 1-11
7) The HWTACACS server sends back an authentication response, requesting the login password. 8) Upon receipt of the response, the HWTACACS client requests of the user the login password. 9) The user enters the password. 10) After receiving the login password, the HWTACACS client sends to the HWTACACS server a continue-authentication packet carrying the login password. 11) The HWTACACS server sends back an authentication response indicating that the user has passed authentication. 12) The HWTACACS client sends the user authorization request packet to the HWTACACS server. 13) The HWTACACS server sends back the authorization response, indicating that the user is authorized now. 14) Knowing that the user is now authorized, the HWTACACS client pushes the configuration interface of the NAS to the user. 15) The HWTACACS client sends a start-accounting request to the HWTACACS server. 16) The HWTACACS server sends back an accounting response, indicating that it has received the start-accounting request. 17) The user logs off. 18) The HWTACACS client sends a stop-accounting request to the HWTACACS server. 19) The HWTACACS server sends back a stop-accounting packet, indicating that the stop-accounting request has been received. 1.1.4 Protocols and Standards The protocols and standards related to AAA, RADIUS, and HWTACACS include: RFC 2865: Remote Authentication Dial In User Service (RADIUS) RFC 2866: RADIUS Accounting RFC 2867: RADIUS Accounting Modifications for Tunnel Protocol Support RFC 2868: RADIUS Attributes for Tunnel Protocol Support RFC 2869: RADIUS Extensions RFC 1492: An Access Control Protocol, Sometimes Called TACACS 1.2 AAA/RADIUS/HWTACACS Task List I. AAA configuration task list Task Remarks Creating an ISP Domain Configuring ISP Domain Attributes 1-12
Task Configuring an AAA Authentication Scheme for an ISP Domain Configuring an AAA Authorization Scheme for an ISP Domain Configuring an AAA Accounting Scheme for an ISP Domain Configuring Local User Attributes Tearing down User Connections Forcibly Remarks For local authentication, refer to Configuring Local User Attributes. For RADIUS authentication, refer to Configuring RADIUS. For HWTACACS authentication, refer to Configuring HWTACACS. II. RADIUS configuration task list Creating a RADIUS Scheme Task Specifying the RADIUS Authentication/Authorization Servers Configuring the RADIUS Accounting Servers and Relevant Parameters Setting the Shared Key for RADIUS Packets Setting the Maximum Number of RADIUS Request Retransmission Attempts Setting the Supported RADIUS Server Type Setting the Status of RADIUS Servers Configuring Attributes Related to the Data Sent to the RADIUS Server Setting Timers Regarding RADIUS Servers Configuring RADIUS Accounting-on Configuring an IP Address for the Security Policy Server Enabling the Listening Port of the RADIUS Client Remarks 1-13
III. HWTACACS configuration task list Task Creating a HWTACAS scheme Specifying the HWTACACS Authentication Servers Specifying the HWTACACS Authorization Servers Specifying the HWTACACS Accounting Servers Setting the Shared Key for HWTACACS Packets Configuring Attributes Related to the Data Sent to the TACACS Server Setting Timers Regarding HWTACACS Servers Remarks 1.3 Configuring AAA By configuring AAA, you can provide network access service for legal users, protect the networking devices, and avoid unauthorized access and bilking. In addition, you can configure ISP domains to perform AAA on accessing users. In AAA, users are divided into lan-access users(such as 802.1x users and MAC authentication users), login users(such as SSH, Telnet, FTP, and terminal access users), and command line users(that is, command line authentication users). Except for command line users, you can configure separate authentication/authorization/accounting policies for all the other type of users. Command line users can be configured with authorization policy independently. 1.3.1 Prerequisites For remote authentication, authorization, or accounting, you must create the RADIUS or HWTACACS scheme first. RADIUS scheme: Reference a configured RADIUS scheme to implement authentication/authorization and accounting. For RADIUS scheme configuration, refer to Configuring RADIUS. HWTACACS scheme: Reference a configured HWTACACS scheme to implement authentication/authorization and accounting. For HWTACACS scheme configuration, refer to Configuring HWTACACS. 1.3.2 Creating an ISP Domain For the NAS, each accessing user belongs to an ISP domain. Up to 16 ISP domains can be configured on a NAS. If a user does not provide the ISP domain name, the system considers that the user belongs to the default ISP domain. 1-14
Follow these steps to create an ISP domain: Enter system system- Create an ISP domain and enter ISP domain domain isp-name Return to system quit Specify the default ISP domain domain default { disable enable isp-name } The system-default ISP domain named system by default You cannot delete the default ISP domain unless you change it to a non-default ISP domain (with the domain default disable command) first. If a user enters a username without an ISP domain name, the device uses the authentication scheme for the default ISP domain to authenticate the user. 1.3.3 Configuring ISP Domain Attributes Follow these steps to configure ISP domain attributes: Enter system system- Create an ISP domain and enter ISP domain Place the ISP domain to the state of active or blocked Specify the maximum number of users in the ISP domain Configure the idle cut function domain isp-name state { active block } access-limit { disable enable max-user-number } idle-cut { disable enable minute } When created, an ISP is in the state of active by default, and users in the domain can request network services. No limit by default Disabled by default 1-15
Enable the self-service server localization function and specify the URL of the self-service server for changing user password self-service-url { disable enable url-string } Disabled by default A self-service RADIUS server, for example, CAMS, is required for the self-service server localization function. With the self-service function, a user can manage and control his or her accounting information or card number. A server with self-service software is a self-service server. 1.3.4 Configuring an AAA Authentication Scheme for an ISP Domain In AAA, authentication, authorization, and accounting are three separate processes. Authentication refers to the interactive authentication process of username/password/user information during access or service request. The authentication process neither sends authorization information to a supplicant nor triggers any accounting. You can configure AAA to use only authentication. If you do not perform any authentication configuration, the system-default ISP domain uses the local authentication scheme. Before configuring an authentication scheme, complete these three tasks: For RADIUS or HWTACACS authentication, configure the RADIUS or HWTACACS scheme to be referenced first. The local and none authentication modes do not require any scheme. Determine the access mode or service type to be configured. With AAA, you can configure an authentication scheme specifically for each access mode and service type, limiting the authentication protocols that can be used for access. Determine whether to configure an authentication scheme for all access modes or service types. Follow these steps to configure an AAA authentication scheme for an ISP domain: Enter system system- Create an ISP domain and enter ISP domain domain isp-name 1-16
Specify the default authentication scheme for all types of users Specify the authentication scheme for LAN access users Specify the authentication scheme for login users authentication default { hwtacacs-scheme hwtacacs-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] authentication lan-access { local none radius-scheme radius-scheme-name [ local ] } authentication login { hwtacacs-scheme hwtacacs-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] } local by default The default authentication scheme is used by default. The default authentication scheme is used by default. The authentication scheme specified with the authentication default command is for all types of users and has a priority lower than that for a specific access mode. With a RADIUS authentication scheme configured, AAA accepts only the authentication result from the RADIUS server. The response from the RADIUS server does include the authorization information when the authentication is successful, but the authentication process ignores the information. With the radius-scheme radius-scheme-name local or hwtacacs-scheme hwtacacs-scheme-name local keyword and argument combination configured, the local scheme is the backup scheme and is used only when the RADIUS server or TACACS server is not available. If the primary authentication scheme is local or none, the system performs local authentication or does not perform any authentication, rather than uses the RADIUS or HWTACACS scheme. 1.3.5 Configuring an AAA Authorization Scheme for an ISP Domain In AAA, authorization is a separate process at the same level as authentication and accounting. Its responsibility is to send authorization requests to the specified authorization server and to send authorization information to users authorized. Authorization scheme configuration is optional in AAA configuration. 1-17
If you do not perform any authorization configuration, the system-default domain uses the local authorization scheme. With the authorization scheme of none, the users are not required to be authorized, in which case an authenticated user has the default right. The default right is visiting (the lowest one) for EXEC users(that is, console users who use the console, AUX, or Telnet or SSH to connect to the device, such as Telnet or SSH users. Each connection of these types is called an EXEC user). The default right for FTP users is to use the root directory of the device. Before configuring an authorization scheme, complete these three tasks: 1) For HWTACACS authorization, configure the HWTACACS scheme to be referenced first. For RADIUS authorization, the RADIUS authorization scheme must be same as the RADIUS authentication scheme; otherwise, it does not take effect. 2) Determine the access mode or service type to be configured. With AAA, you can configure an authorization scheme specifically for each access mode and service type, limiting the authorization protocols that can be used for access. 3) Determine whether to configure an authorization scheme for all access modes or service types. Follow these steps to configure an AAA authorization scheme for an ISP domain: Enter system system- Create an ISP domain and enter ISP domain Specify the default authorization scheme for all types of users Specify the authorization scheme for command line users Specify the authorization scheme for LAN access users domain isp-name authorization default { hwtacacs-scheme hwtacacs-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] } authorization command hwtacacs-scheme hwtacacs-scheme-name authorization lan-access { local none radius-scheme radius-scheme-name [ local ] } local by default The default authorization scheme is used by default. The default authorization scheme is used by default. 1-18
Specify the authorization scheme for login users authorization login { hwtacacs-scheme hwtacacs-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] } The default authorization scheme is used by default. The authorization scheme specified with the authorization default command is for all types of users and has a priority lower than that for a specific access mode. RADIUS authorization is special in that it takes effect only when the RADIUS authorization scheme is the same as the RADIUS authentication scheme. In addition, if a RADIUS authorization fails, the error message returned to the NAS says that the server is not responding. With the radius-scheme radius-scheme-name local or hwtacacs-scheme hwtacacs-scheme-name local keyword and argument combination configured, the local scheme is the backup scheme and is used only when the RADIUS server or TACACS server is not available. If the primary authentication scheme is local or none, the system performs local authorization or does not perform any authorization, rather than uses the RADIUS or HWTACACS scheme. Authorization information of the RADIUS server is sent to the RADIUS client along with the authorization response message; therefore, you cannot specify a separate RADIUS server. If you use RADIUS for authorization and authentication, you must use the same scheme setting for authorization and authentication; otherwise, the system will prompt you with an error message. 1.3.6 Configuring an AAA Accounting Scheme for an ISP Domain In AAA, accounting is a separate process at the same level as authentication and authorization. Its responsibility is to send accounting start/update/end requests to the specified accounting server. Accounting is not required, and therefore accounting scheme configuration is optional. If you do not perform any accounting configuration, the system-default domain uses the local accounting scheme. Before configuring an authorization scheme, complete these three tasks: 1) For RADIUS or HWTACACS accounting, configure the RADIUS or HWTACACS scheme to be referenced first. The local and none authentication modes do not require any scheme. 1-19
2) Determine the access mode or service type to be configured. With AAA, you can configure an accounting scheme specifically for each access mode and service type, limiting the accounting protocols that can be used for access. 3) Determine whether to configure an accounting scheme for all access modes or service types. Follow these steps to configure an AAA accounting scheme for an ISP domain: Enter system system- Create an ISP domain and enter ISP domain Enable the accounting optional feature Specify the default accounting scheme for all types of users Specify the accounting scheme for LAN access users Specify the accounting scheme for login users domain isp-name accounting optional accounting default { hwtacacs-scheme hwtacacs-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] } accounting lan-access { local none radius-scheme radius-scheme-name [ local ] } accounting login { hwtacacs-scheme hwtacacs-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] } Disabled by default Local by default The default accounting scheme is used by default. The default accounting scheme is used by default. 1-20
With the accounting optional command configured, a user that will be disconnected otherwise can use the network resources even when there is no available accounting server or the communication with the current accounting server fails. The accounting scheme specified with the accounting default command is for all types of users and has a priority lower than that for a specific access mode. With the radius-scheme radius-scheme-name local or hwtacacs-scheme hwtacacs-scheme-name local keyword and argument combination configured, the local scheme is the backup scheme and is used only when the RADIUS server or HWTACACS server is not available. If the primary accounting scheme is local or none, the system performs local accounting or does not perform any accounting, rather than uses the RADIUS or HWTACACS scheme. With the access mode of login, accounting is not supported for FTP services. 1.3.7 Configuring Local User Attributes For local authentication, you must create a local user and configure the attributes. A local user represents a set of users configured on a device, which are uniquely identified by the username. For a user requesting network service to pass local authentication, you must add an entry as required in the local user database of the device. Follow these steps to configure the attributes for a local user: Enter system system- Set the password display mode for all local users Add a local user and enter local user Configure a password for the local user Place the local user to the state of active or blocked local-user password-display-mode { auto cipher-force } local-user user-name password { cipher simple } password state { active block } auto by default No local user is configured by default When created, a local user is in the state of active by default, and the user can request network services. 1-21
Specify the service types for the user service-type { lan-access { ssh telnet terminal } * [ level level ] } No service is authorized to a user by default By default, no service is authorized to a user and anonymous access to FTP service is not allowed. If you authorize a user to use the FTP service but do not specify a directory that the user can access, the user can access the root directory of the device by default. Specify the service types for the user Authorize the user to use the FTP service and specify a directory for the user to access service-type ftp [ ftp-directory directory] Set the directory accessible to FTP/SFTP users Set the priority level of the user Set attributes for a LAN access user work-directory directory-name level level attribute { access-limit max-user-number idle-cut minute ip ip-address location { nas-ip ip-address port slot-number subslot-number port-number port slot-number subslot-number port-number } mac mac-address vlan vlan-id } * By default, FTP/SFTP users can access the root directory. 0 by default If the user is bound to a remote port, the nas-ip parameter must be specified. If the user is bound to a local port, the nas-ip parameter does not need to be specified. The default value of nas-ip is 127.0.0.1, meaning the current host. 1-22
With the local-user password-display-mode cipher-force command configured, a local user password is always displayed in cipher text, regardless of the configuration of the password command. In this case, if you use the save command to save the configuration, all existing local user passwords will still be displayed in cipher text after the device restarts, even if you restore the display mode to auto. Local authentication checks the service types of a local user. If the service types are not available, the user cannot pass authentication. During authorization, a user with no service type configured is authorized with no service by default. If you specify an authentication method that requires the username and password, including local authentication, RADIUS authentication and HWTACACS authentication, the level of the commands that a user can use after logging in depends on the priority of the user, or the priority of user interface level as with other authentication methods. For an SSH user using RSA public key authentication, the commands that can be used depend on the level configured on the user interface. For details regarding authentication method and command level, refer to Login and System Maintaining and Debugging respectively. Both the service-type and level commands can be used to specify user priority. The one used later has the final effect. The attribute ip command only applies to authentications that support IP address passing, such as 802.1x. If you configure the command to authentications that do not support IP address passing, such as MAC address authentication, the local authentication will fail. The attribute port command binds a port by its number only, regardless of the port type. The idle-cut command configured under ISP applies to lan-access users only. 1.3.8 Tearing down User Connections Forcibly Follow these steps to tear down user connections forcibly: Enter system system- Tear down AAA user connections forcibly cut connection { access-type { dot1x mac-authentication portal } all domain isp-name interface interface-type interface-number ip ip-address mac mac-address ucibindex ucib-index user-name user-name vlan vlan-id } [ slot slot-number ] Applies to only LAN access user connections at present. 1-23
1.4 Configuring RADIUS The RADIUS protocol is configured scheme by scheme. After creating a RADIUS scheme, you need to configure the IP addresses and UDP ports of the RADIUS servers for the scheme. The servers include authentication/authorization servers and accounting servers, or from another point of, primary servers and secondary servers. In another words, the attributes of a RADIUS scheme mainly include IP addresses of primary and secondary servers, shared key, and RADIUS server type. Actually, the RADIUS protocol configurations only set the parameters necessary for the information interaction between a NAS and a RADIUS server. For these settings to take effect, you must reference the RADIUS scheme containing those settings in ISP domain. For information about the commands for referencing a scheme, refer to Configuring AAA. 1.4.1 Creating a RADIUS Scheme Before performing other RADIUS configurations, follow these steps to create a RADIUS scheme and enter RADIUS scheme : Enter system system- Create a RADIUS scheme and enter RADIUS scheme radius scheme radius-scheme-name Not defined by default A RADIUS scheme can be referenced by more than one ISP domain at the same time. 1.4.2 Specifying the RADIUS Authentication/Authorization Servers Follow these steps to specify the RADIUS authentication/authorization servers: Enter system system- Create a RADIUS scheme and enter RADIUS scheme radius scheme radius-scheme-name Not defined by default 1-24
Configure the IP address and UDP port of the primary RADIUS authentication/authorizati on server Configure the IP address and UDP port of the secondary RADIUS authentication/authorizati on server primary authentication ip-address [ port-number ] secondary authentication ip-address [ port-number ] The defaults are as follows: 0.0.0.0 for the IP address, and 1812 for the port. The defaults are as follows: 0.0.0.0 for the IP address, and 1812 for the port. In practice, you may specify two RADIUS servers as the primary and secondary authentication/authorization servers respectively. At a moment, a server can be the primary authentication/authorization server for a scheme and the secondary authentication/authorization servers for another scheme. The IP addresses of the primary and secondary authentication/authorization servers for a scheme cannot be the same. Otherwise, the configuration fails. 1.4.3 Configuring the RADIUS Accounting Servers and Relevant Parameters Follow these steps to specify the RADIUS accounting servers and perform related configurations: Enter system system- Create a RADIUS scheme and enter RADIUS scheme Configure the IP address and UDP port of the primary RADIUS accounting server radius scheme radius-scheme-name primary accounting ip-address [ port-number ] Not defined by default The defaults are as follows: 0.0.0.0 for the IP address, and 1813 for the port. 1-25
Configure the IP address and UDP port of the secondary RADIUS accounting server Enable the device to buffer stop-accounting requests getting no responses Set the maximum number of stop-accounting request transmission attempts Set the maximum number of accounting request transmission attempts secondary accounting ip-address [ port-number ] stop-accounting-buffer enable retry stop-accounting retry-times retry realtime-accounting retry-times The defaults are as follows: 0.0.0.0 for the IP address, and 1813 for the port. Enabled by default 500 by default 5 by default In practice, you can specify two RADIUS servers as the primary and secondary accounting servers respectively; or specify one server to function as both. Besides, because RADIUS uses different UDP ports to receive authentication/authorization and accounting packets, the port for authentication/authorization must be different from that for accounting. You can set the maximum number of stop-accounting request transmission buffer, allowing the device to buffer and resend a stop-accounting request until it receives a response or the number of transmission retries reaches the configured limit. In the latter case, the device discards the packet. You can set the maximum number of accounting request transmission attempts on the device, allowing the device to disconnect a user when the number of accounting request transmission attempts for the user reaches the limit but it still receives no response to the accounting request. The IP addresses of the primary and secondary accounting servers cannot be the same. Otherwise, the configuration fails. Currently, RADIUS does not support keeping accounts on FTP users. 1-26
1.4.4 Setting the Shared Key for RADIUS Packets The RADIUS client and RADIUS server use the MD5 algorithm to encrypt packets exchanged between them and a shared key to verify the packets. Only when the same key is used can they properly receive the packets and make responses. Follow these steps to set the shared key for RADIUS packets: Enter system system- Create a RADIUS scheme and enter RADIUS scheme Set the shared key for RADIUS authentication/authorizati on or accounting packets radius scheme radius-scheme-name key { accounting authentication } string Not defined by default No key by default The shared key configured on the device must be the same as that configured on the RADIUS server. 1.4.5 Setting the Maximum Number of RADIUS Request Retransmission Attempts Because RADIUS uses UDP packets to carry data, the communication process is not reliable. If a NAS receives no response from the RADIUS server before the response timeout timer expires, it is required to retransmit the RADIUS request. If the number of transmission attempts exceeds the specified limit but it still receives no response, it considers the authentication a failure. Follow these steps to set the maximum number of RADIUS request retransmission attempts: Enter system system- Create a RADIUS scheme and enter RADIUS scheme Set the number of retransmission attempts of RADIUS packets radius scheme radius-scheme-name retry retry-times Not defined by default 3 by default 1-27
The maximum number of retransmission attempts of RADIUS packets multiplied by the RADIUS server response timeout period cannot be greater than 75. Refer to the timer response-timeout command in the command manual for configuring RADIUS server response timeout period. 1.4.6 Setting the Supported RADIUS Server Type Follow these steps to set the supported RADIUS server type: Enter system system- Create a RADIUS scheme and enter RADIUS scheme Specify the RADIUS server type supported by the device radius scheme radius-scheme-name server-type { extended standard } Not defined by default By default, the RADIUS server type is standard. If you change the type of RADIUS server, the data stream destined to the original RADIUS server will be restored to the default unit. When a third-party RADIUS is used, you can configure the RADIUS server to standard or extended. When CAMS server is used, you must RADIUS server to extended. 1.4.7 Setting the Status of RADIUS Servers When a primary server, authentication/authorization server or accounting server, fails, the device automatically turns to the secondary server. When both the primary and secondary servers are available, the device sends request packets to the primary server. Once the primary server fails, the primary server turns into the state of block, and the device turns to the secondary server. In this case: If the secondary server is available, the device triggers the primary server quiet timer. After the quiet timer times out, the status of the primary server is active again and the status of the secondary server remains the same. 1-28
If the secondary server fails, the device restores the status of the primary server to active immediately. If the primary server has resumed, the device turns to use the primary server and stops communicating with the secondary server. After accounting starts, the communication between the client and the secondary server remains unchanged. Follow these steps to set the status of RADIUS servers: Enter system system- Create a RADIUS scheme and enter RADIUS scheme Set the status of the primary RADIUS authentication/authorizati on server Set the status of the primary RADIUS accounting server Set the status of the secondary RADIUS authentication/authorizati on server Set the status of the secondary RADIUS accounting server radius scheme radius-scheme-name state primary authentication { active block } state primary accounting { active block } state secondary authentication { active block } state secondary accounting { active block } Not defined by default active for every server configured with IP address in the RADIUS scheme If both the primary server and the secondary server are in the blocked state, it is necessary to manually turn the secondary server to the active state so that the secondary server can perform authentication. If the secondary server is still in the blocked state, the primary/secondary switchover cannot take place. If one server is in the active state while the other is blocked, the primary/secondary switchover will not take place even if the active server is not reachable. 1.4.8 Configuring Attributes Related to the Data Sent to the RADIUS Server Follow these steps to configure the attributes related to the data sent to the RADIUS server: 1-29
Enter system system- Enable the RADIUS trap function Create a RADIUS scheme and enter RADIUS scheme Specify the format of the username to be sent to a RADIUS server Specify the unit for data flows or packets to be sent to a RADIUS server radius trap { accounting-server-do wn authentication-server-d own } radius scheme radius-scheme-name user-name-format { with-domain without-domain } data-flow-format { data { byte giga-byte kilo-byte mega-byte } packet { giga-packet kilo-packet mega-packet one-packet } }* Disabled by default Not defined by default By default, the ISP domain name is included in the username. The defaults are as follows: byte for data flows, and one-packet for data packets. Set the source IP address of the device to send RADIUS packets In RADIUS scheme In system nas-ip ip-address quit radius nas-ip ip-address Use either command By default, the outbound port serves as the source IP address to send RADIUS packets Some earlier RADIUS servers cannot recognize usernames that contain an ISP domain name, therefore before sending a username including a domain name to such a RADIUS server, the device must remove the domain name. This command is thus provided for you to decide whether to include a domain name in a username to be sent to a RADIUS server. If a RADIUS scheme defines that the username is sent without the ISP domain name, do not apply the RADIUS scheme to more than one ISP domain, thus avoiding the confused situation where the RADIUS server regards two users in different ISP domains but with the same userid as one. The nas-ip command in RADIUS scheme is only for the current RADIUS scheme, while the radius nas-ip command in system is for all RADIUS schemes. However, the nas-ip command in RADIUS scheme overwrites the configuration of the radius nas-ip command. 1-30