Enterprise products and services are set forth in the express warranty statements acco mpanying such
products and services. Nothing herein should be construe d as constituting an additional warranty. Hewlett
Packard Enterprise shall not be liable for technical or editorial errors or omissions co ntained herein.
Confidential computer software. V alid license from Hewlett Packard Enterprise required for possession, use, or
copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software
Documentation, and T e chnical Data for Commercial Items are licensed to the U.S. Government under vendor’s
standard commercial license.
Links to third-party websites take you outside the Hewlett Packard Enterprise website. Hewlett Packard
Enterprise has no control over and is not responsible for information outside the Hewlett Packard Enterprise
website.
Acknowledgments
Intel®, Itanium®, Pentium®, Intel Inside®, and the Intel Inside logo are trademarks of Intel Corporation in the
United States and other countries.
Microsoft® and Windows® are trademarks of the Microsoft group of companies.
Adobe® and Acrobat® are trademarks of Adobe Systems In corporated.
Java and Oracle are registered trademarks of Oracle and/or its affiliates.
UNIX® is a registered trademark of The Open Group.
RADIUS ······················································································································································ 2
HWTACACS ··············································································································································· 6
AAA implementation on the device ············································································································ 9
Protocols and standards ·························································································································· 10
RADIUS attributes ···································································································································· 11
FIPS compliance ·············································································································································· 14
AAA configuration considerations and task list ································································································ 14
Configuring AAA schemes ······························································································································· 15
Configuring local users ····························································································································· 15
Creating an ISP domain ··························································································································· 33
Setting the ISP domain status ·················································································································· 34
Configuring authentication methods for an ISP domain ··········································································· 34
Configuring authorization methods for an ISP domain ············································································· 35
Configuring accounting methods for an ISP domain ················································································ 36
Enabling the session-control feature ················································································································ 37
Setting the maximum number of concurrent login users ·················································································· 37
Displaying and maintaining AAA ······················································································································ 37
AAA configuration examples ···························································································································· 38
AAA for SSH users by an HWTACACS server ························································································ 38
Local authentication, HWTACACS authorization, and RADIUS accounting for SSH users ····················· 39
Authentication and authorization for SSH users by a RADIUS server ····················································· 41
Troubleshooting RADIUS ································································································································· 44
Password updating and expiration ··········································································································· 47
User login control ····································································································································· 48
Password not displayed in any form ········································································································ 48
Logging ···················································································································································· 48
FIPS compliance ·············································································································································· 49
Password control configuration task list ··········································································································· 49
Enabling password control ······························································································································· 49
Setting global password control parameters ···································································································· 50
Setting user group password control parameters ···························································································· 51
Setting local user password control parameters ······························································································ 51
Setting super password control parameters ···································································································· 52
Displaying and maintaining password control ·································································································· 53
Password control configuration example ········································································································· 53
Verifying the configuration ························································································································ 55
Managing public keys ··················································································· 57
Overview ·························································································································································· 57
FIPS compliance ·············································································································································· 57
Creating a local key pair ·································································································································· 57
Configuration procedure ··························································································································· 58
Distributing a local host public key ··················································································································· 58
Exporting a host public key in a specific format to a file ··········································································· 59
Displaying a host public key in a specific format and saving it to a file ···················································· 59
Displaying a host public key ····················································································································· 59
Destroying a local key pair ······························································································································· 60
Configuring a peer public key ·························································································································· 60
Importing a peer host public key from a public key file ············································································ 61
Entering a peer public key ························································································································ 61
Displaying and maintaining public keys ··········································································································· 61
Examples of public key management ·············································································································· 61
Example for entering a peer public key ···································································································· 61
Example for importing a public key from a public key file ········································································ 63
Support for MPLS L3VPN ························································································································ 68
Feature and software version compatibility ······································································································ 69
FIPS compliance ·············································································································································· 69
PKI configuration task list ································································································································· 69
Configuring a PKI entity ··································································································································· 69
Configuring a PKI domain ································································································································ 70
Requesting a certificate ··································································································································· 72
Security protocols and encapsulation modes ························································································· 104
Security association ······························································································································· 106
Authentication and encryption ················································································································ 106
Feature restrictions and guidelines ········································································································ 108
ACL-based IPsec configuration task list ································································································· 108
Configuring an ACL ································································································································ 109
Configuring an IPsec transform set ········································································································ 110
Configuring a manual IPsec policy ········································································································· 111
Configuring an IKE-based IPsec policy ·································································································· 112
Applying an IPsec policy to an interface ································································································ 114
Enabling ACL checking for de-encapsulated packets ············································································ 115
Configuring the IPsec anti-replay function ····························································································· 115
Binding a source interface to an IPsec policy ························································································ 116
IKE negotiation process ························································································································· 125
IKE security mechanism ························································································································· 126
Protocols and standards ························································································································ 127
IKE configuration prerequisites ······················································································································ 127
IKE configuration task list ······························································································································· 127
Configuring an IKE profile ······························································································································ 128
Configuring an IKE proposal ·························································································································· 129
Configuring an IKE keychain ·························································································································· 131
Configuring the global identity information ····································································································· 131
Configuring the IKE keepalive function ·········································································································· 132
Configuring the IKE NAT keepalive function ·································································································· 132
Configuring IKE DPD ····································································································································· 133
Enabling invalid SPI recovery ························································································································ 133
Setting the maximum number of IKE SAs ······································································································ 134
Configuring SNMP notifications for IKE ········································································································· 134
Displaying and maintaining IKE ····················································································································· 135
Main mode IKE with pre-shared key authentication configuration example ·················································· 135
Verifying the configuration ······················································································································ 138
Troubleshooting IKE ······································································································································ 138
IKE negotiation failed because no matching IKE proposals were found ················································ 138
IKE negotiation failed because no IKE proposals or IKE keychains are referenced correctly ··············· 138
IPsec SA negotiation failed because no matching IPsec transform sets were found ···························· 139
iii
IPsec SA negotiation failed due to invalid identity information ······························································· 140
How SSH works ····································································································································· 143
SSH authentication methods ·················································································································· 144
FIPS compliance ············································································································································ 145
Configuring the device as an SSH server ······································································································ 145
SSH server configuration task list ·········································································································· 145
Generating local DSA or RSA key pairs ································································································· 146
Enabling the Stelnet server ···················································································································· 147
Enabling the SFTP server ······················································································································ 147
Enabling the SCP server ························································································································ 147
Configuring NETCONF over SSH ·········································································································· 147
Configuring user lines for SSH login ······································································································ 148
Configuring a client's host public key ····································································································· 148
Configuring an SSH user ······················································································································· 149
Configuring the SSH management parameters ····················································································· 150
Configuring the device as an Stelnet client ···································································································· 151
Stelnet client configuration task list ········································································································ 151
Specifying a source IP address for SSH packets··················································································· 151
Establishing a connection to an Stelnet server ······················································································ 152
Configuring the device as an SFTP client ······································································································ 153
SFTP client configuration task list ·········································································································· 153
Specifying the source IP address for SFTP packets ·············································································· 153
Establishing a connection to an SFTP server ························································································ 153
Working with SFTP directories ··············································································································· 154
Working with SFTP files ························································································································· 154
Displaying help information ···················································································································· 155
Terminating the connection with the SFTP server ················································································· 155
Configuring the device as an SCP client ········································································································ 155
Displaying and maintaining SSH ···················································································································· 156
Stelnet configuration examples ······················································································································ 156
Password authentication enabled Stelnet server configuration example ··············································· 157
Publickey authentication enabled Stelnet server configuration example ··············································· 159
Password authentication enabled Stelnet client configuration example ················································ 165
Displaying and maintaining ARP detection ···························································································· 195
User validity check and ARP packet validity check configuration example ············································ 195
Configuring ARP scanning and fixed ARP ····································································································· 196
Configuration restrictions and guidelines ······························································································· 197
Network application ································································································································ 204
Configuring uRPF ·········································································································································· 204
Displaying and maintaining uRPF ·················································································································· 204
uRPF configuration example ·························································································································· 205
Configuring FIPS ························································································· 206
Overview ························································································································································ 206
Configuration restrictions and guidelines ······································································································· 206
Configuring FIPS mode ·································································································································· 207
Entering FIPS mode ······························································································································· 207
Configuration changes in FIPS mode ···································································································· 208
Exiting FIPS mode ································································································································· 208
FIPS self-tests ················································································································································ 209
Triggering self-tests ································································································································ 210
Displaying and maintaining FIPS ··················································································································· 210
FIPS configuration examples ························································································································· 211
Entering FIPS mode through automatic reboot ······················································································ 211
Entering FIPS mode through manual reboot ·························································································· 212
Exiting FIPS mode through automatic reboot ························································································ 213
Exiting FIPS mode through manual reboot ···························································································· 214
Configuring attack detection and prevention ··············································· 215
Remote support ······································································································································ 219
Index ··········································································································· 220
vi
Configuring AAA
Overview
Authentication, Authorization, and Accounting (AAA) provides a uniform framework for implementing
network access management. This feat ure specifies the following security functions:
• Authentication—Identifies users and verifies their validity.
• Authorization—Grants different users different rights, and controls the users' access to
resources and services. For example, you can permit office users to read and print files and
prevent guests from accessing files on the device.
• Accounting—Records network usage details of users, including the service type, start time,
and traffic. This function enables time-based and traffic-based charging and user behavior
auditing.
AAA uses a client/server m odel. The clie nt runs on the access d evice, or the net work access se rver
(NAS), which authenticates user identities and controls user access. The server maintains user
information centrally. See Figure 1.
Figure 1
Remote user
To access networks or resources beyond the NAS, a user sends its identity information to the NAS.
The NAS transparently passes the user information to AAA servers and waits for the authentication,
authorization, and accounting result. Based on the result, the NAS determines whether to permit or
deny the access request.
AAA has vari ous implementations, including RADIUS and HWT ACACS. RADIUS is most ofte n used.
The network in Figure 1 ha
servers to implement different security functions. For example, you can use the HWTACACS server
for authentication and authorization, and use the RADIUS server for accounting.
AAA network diagram
Network
s one RADIUS server and one HWT A CACS server. You can use dif ferent
NAS
RADIUS server
HWTACACS server
Internet
You can choose the security functions provided by AAA as needed. For example, if your company
wants employees to be authenticated before they access specific resources, you would deploy an
authentication server. If network usage information is needed, you would also configure an
accounting server.
The device performs dynamic password authentication.
1
RADIUS
Remote Authentication Dial-In User Service (RADIUS) is a distributed information interaction
protocol that uses a client/server model. The protocol can protect networks against unauthorized
access and is often used in network environments that require both high security and remote user
access.
The RADIUS authorization process is combined with the RADIUS authentication process, and user
authorization information is piggybacked in authentication responses. RADIUS uses UDP port 1812
for authentication and UDP port 1813 for accounting.
RADIUS was originally designed for dial-in user access, and has been extended to support
additional access methods, such as Ethernet and ADSL.
Client/server model
The RADIUS client runs on the NASs located throughout the network. It passes user information to
RADIUS servers and acts on the responses to, for example, reject or accept user access requests.
The RADIUS server runs on the computer or workstation at the network center and maintains
information related to user authentication and network service access.
The RADIUS server operates using the following process:
1. Receives authentication, authorization, and accounting requests from RADIUS clients.
2. Performs user authentication, authorization, or accounting.
3. Returns user access control information (for example, rejecting or accepting the user acce ss
request) to the clients.
The RADIUS server can also act as the client of another RADIUS server to provide authentication
proxy services.
The RADIUS server maintains the following databases:
• Users—Stores user information, such as the usernames, passwords, applied protocols, and IP
addresses.
• Clients—Stores information about RADIUS clients, such as shared keys and IP addresses.
• Dictionary—Stores RADIUS protocol attributes and their values.
Figure 2 RADIUS server databases
Information exchange security mechanism
The RADIUS client and server exchange information between them with the help of shared keys,
which are preconfigured on the client and server. A RADIUS packet has a 16-byte field called
Authenticator. This field includes a signature ge nerated by using the MD5 algorithm, the shared key,
and some other information. The receiver of the packet verifies the si gnature and accepts the packet
only when the signature is correct. This mechanism ensures the security of information exchanged
between the RADIUS client and server.
The shared keys are also used to encrypt user passwords that are included in RADIUS packets.
User authentication methods
The RADIUS server supports multiple user authentication methods, such as PAP, CHAP, and EAP.
2
Basic RADIUS packet exchange process
Figure 3 illustrates the interactions between a user host, the RADIUS client, and the RADIUS server.
Figure 3 Basic RADIUS packet exchange process
RADIUS uses the following workflow:
1. The host sends a connection request that includes the user's username and password to the
RADIUS client.
2. The RADIUS client sends an authentication request (Access-Request) to the RADIUS server.
The request includes the user's password, which has been processed by the MD5 algorithm
and shared key.
3. The RADIUS server authenticates the username and password. If the authenticati on succeeds,
the server sends back an Access-Accept packet that contains the user's authorization
information. If the authentication fails, the server returns an Access-Reject packet.
4. The RADIUS client permits or denies the user according to the authentication result. If the result
permits the user, the RADIUS client sends a start-accounting request (Accounting-Request)
packet to the RADIUS server.
5. The RADIUS server returns an acknowledgment (Accounting-Response) packet and starts
accounting.
6. The user accesses the network resources.
7. The host requests the RADIUS client to tear down the connection.
8. The RADIUS client sends a stop-accounting request (Accounting-Reque st) packet to the
RADIUS server.
9. The RADIUS server returns an acknowledgment (Accounting-Response) and stops accounting
for the user.
10. The RADIUS client notifies the user of the termination.
RADIUS packet format
RADIUS uses UDP to transmit packets. The protocol also uses a series of mechanisms to ensure
smooth packet exchange between the RADIUS server and the client. These mechanisms incl ude the
timer mechanism, the retransmission mechanism, and the backup server mechanism.
3
Figure 4 RADIUS packet format
Descriptions of the fields are as follows:
•The Code field (1 byte long) indicates the type of the RADIUS packet. Table 1 g
values and their meanings.
Table 1 Main values of the Code field
ives the main
Cod
e
1 Access-Request
2 Access-Accept
3 Access-Reject
4 Accounting-Request
5
Packet type Description
From the client to the server. A packet of this type includes 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 attribute values included in the
Access-Request are acceptable, the authentication succeeds, and the
server sends an Access-Accept response.
From the server to the client. If any attribute value included in the
Access-Request is unacceptable, the authentication fails, and the server
sends an Access-Reject response.
From the client to the server. A packet of this type includes user information
for the server to start or stop accounting for the user. The Acct-Status-Type
attribute in the packet indicates whether to start or stop accounting.
Accounting-Respons
e
From the server to the client. The server sends a packet of this type to
notify the client that it has received the Accounting-Request and has
successfully recorded the accounting information.
•The Identifier field (1 byte long) is used to match response packets with request packets and to
detect duplicate request packets. The request and response packets of the same exchange
process for the same purpose (such as authentication or accounting) have the same identifier.
•The Length field (2 bytes long) indicates the length of the entire packet (in bytes), including the
Code, Identifier, Length, Authenticator, and Attributes fields. Bytes beyond this length are
considered padding and are ignored by the receiver. If the length of a received packet is less
than this length, the packet is dropped.
•The Authenticator field (16 bytes long) is used to authenticate responses from the RADIUS
server and to encrypt user passwords. There are two types of authenticators: request
authenticator and response authenticator.
•The Attributes field (variab le in length) includes authentication, authorization, and accounting
information. This field can contain multiple attributes, each with the following subfields:
{Type—Type of the attribute.
4
{ Length—Length of the attribute in bytes, including the Type, Length, and Value subfields.
{ Value—Value of the attribute. Its format and content depend on the Type subfield.
Commonly used RADIUS attributes are defined in RFC 2865, RFC 2866, RFC 2867, and RFC
2868. For more information, see "Commonly used standard RADIUS attributes."
The RADIUS protocol features excellent extensibility. The Vendor-Specific attribute (attribute 26)
allows a vendor to define extended attributes. The extended attributes implement functions that the
standard RADIUS protocol does not provide.
A vendor can encapsulate multiple subattributes in the TL V format in attribute 26 to provide exte nded
functions. As shown in Figure 5, a
subattribute encapsulated in attribute 26 consists of the following
parts:
• Vendor-ID—ID of the vendor. The most significant byte is 0. The other three bytes contains a
code compliant to RFC 1700.
• Vendor-Type—Type of the subattribute.
• Vendor-Length—Length of the subattribute.
• Vendor-Data—Contents of the subattribute.
For more information about the proprietary RADIUS subattributes of HPE, see "HPE proprietary
RADIUS sub
attributes."
Figure 5 Format of attribute 26
HWTACACS
HW Terminal Access Controller Access Control System (HWTACACS) is an enhanced security
protocol based on T ACACS (RFC 1492 ). HWT ACACS is similar to RADIUS, and uses a client/server
model for information exchange between the NAS and the HWTACACS server.
6
HWTACACS typically provides AAA services for PPP, VPDN, and terminal users. In a typical
HWT ACA CS scenario, terminal users need to log in to the NAS. Working as the HWTACACS client,
the NAS sends users' usernames and passwords to the HWTACACS server for authentication. After
passing authentication and obtaining authorized rights, a user logs in to the device and performs
operations. The HWTACACS server records the operations that each user performs.
Differences between HWTACACS and RADIUS
HWTACACS and RADIUS have many features in common, such as using a client/server model,
using shared keys for data encryption, and providing flexibility and scalability. Table 3 lists the
ry differences between HWTACACS and RADIUS.
prima
Table 3 Primary differences between HWTACACS and RADIUS
HWTACACS RADIUS
Uses TCP, which provides reliable network
transmission.
Uses UDP, which provides high transport efficiency.
Encrypts the entire packet except for the
HWTACACS header.
Protocol packets are complicated and authorization
is independent of authentication. Authentication and
authorization can be deployed on different
HWTACACS servers.
Supports authorization of configuration commands.
Access to commands depends on both the user's
roles and authorization. A user can use only
commands that are permitted by the user roles and
authorized by the HWTACACS server.
Basic HWTACACS packet exchange process
Figure 6 describes how HWT ACACS perf orms user authentication, a uthorization, and accounting for
a Telnet user .
Encrypts only the user password field in an
authentication packet.
Protocol packets are simple and the authorization
process is combined with the authentication
process.
Does not support authorization of configuration
commands. Access to commands solely depends on
the user's roles. For more information about user
roles, see Fundamentals Configuration Guide.
7
Figure 6 Basic HWTACACS packet exchange process for a Telnet user
HostHWTACACS clientHWTACACS server
1) The user tries to log in
2) Start-authentication packet
3) Authentication response requesting the username
4) Request for username
5) The user enters the username
6) Continue-authentication packet with the username
7) Authentication response requesting the password
8) Request for password
9) The user enters the password
10) Continue-authentication packet with the password
11) Response indicating successful authentication
12) User authorization request packet
13) Response indicating successful authorization
14) The user logs in successfully
15) Start-accounting request
16) Response indicating the start of accounting
17) The user logs off
18) Stop-accounting request
19) Stop-accounting response
HWTACACS operates using the following workflow:
1. A Telnet user sends an access request to the HWTACACS client.
2. The HWTACACS client sends a start-authentication packet to the HWTACACS server when it
receives the request.
3. The HWTACACS server sends back an authentication response to request the username.
4. Upon receiving the response, 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 the server a
continue-authentication packet that includes the username.
7. The HWTACACS server sends back an authentication response to request the login password.
8. Upon receipt of the response, the HWTACACS client prompts the user for the login password.
9. The user enters the password.
8
10. After receiving the login password, the HWTACACS client sends the HWTACACS serv er a
continue-authentication packet that includes the login password.
11. If the authentication succeeds, the HWTACACS server sends back an authenti cation response
to indicate that the user has passed authentication.
12. The HWTACACS client sends a user authorization request packet to the HWTACACS server.
13. If the authorization succeeds, the HWTACACS server sends back an authorization response,
indicating that the user is now authorized.
14. Knowing that the user is now authorized, the HWTACACS client pushes its CLI to the user and
permits the user to log in.
15. The HWTACACS client sends a start-accounting request to the HWTACACS server.
16. The HWTACACS server sends back an accounting response, indi cating 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 response, indicating that the
stop-accounting request has been received.
AAA implementation on the device
This section describes AAA user mana gement and methods.
User management based on ISP domains and user access types
AAA manages users based on the users' ISP domains and access types.
On a NAS, each user belongs to one ISP domain. The NAS determines the ISP domain to which a
user belongs based on the username entered by the user at login.
Figure 7 Determining the ISP domain for a user by username
AAA manages use rs in the same ISP domain based on the users' access types. The device supports
AAA for login users. Login users include SSH, Telnet, FTP, and terminal users who log in to the
device. Terminal users can access through a console port.
AAA methods
AAA supports configuring different authentication, authorization, and accounting methods for
different types of users in an ISP domain. The N AS determines the ISP domain and access type of a
user, and uses the methods configured for the access type in the domain to control the user's
access.
AAA also supports configuring a set of default methods for an ISP domain. These default methods
are applied to users for whom no AAA method s are configured.
The device supports the following authentication methods:
9
• No authentication—This method trusts all users and does not perform authentication. For
security purposes, do not use this method.
• Local authentication—The NAS authenticates users by itself, based on the locally configured
user information including the usernames, passwords, and attributes. Local authentication
allows high speed and low cost, but the amount of information that can be stored is limited by
the size of the storage space.
• Remote authentication—The NAS works with a RADIUS or HW TACACS server to
authenticate users. The server manages user information in a centralized manner. Remote
authentication provides high capacity, reliable, and centralized authentication services for
multiple NASs. You can configure backup methods to be used when the remote server is not
available.
The device supports the following authorization methods:
• No authorization—The NAS performs no authorization exchange. After passing
authentication, users can access the network, except FTP, SFTP , and SCP u sers. When an FTP,
SFTP, or SCP user passes authentication, the working directory is set to the root directory of the
NAS, but the user cannot access this directory.
• Local authorization—The NAS performs authorization according to the user attributes locally
configured for users.
• Remote authorization—The NAS works with a RADIUS or HWTACACS server to authorize
users. RADIUS authorization is bound with RADIUS authentication. RADIUS a uthorization can
work only after RADIUS authentication is successful, and the authorization information is
included in the Access-Accept packet. HWTACACS authorization is separate from
HWTACACS authentication, and the authorization information is included in the authorizatio n
response after successful authentication. You can configure backup methods to be used when
the remote server is not available.
The device supports the following accounting methods:
• No accounting—The NAS does not perform accounting for the users.
• Local accounting—Local accounting is implemented on the NAS. It counts and controls the
number of concurrent users who use the same local user account, but does not provide
statistics for charging.
• Remote accounting—The NAS works with a RADIUS server or HWTACACS server for
accounting. You can configure ba ckup methods to be used when the remote server is not
available.
In addition, the device provides the following login services to enhance device security:
• Command authorization—Enables the NAS to let the authorization server d etermine whether
a command entered by a login user is permitted. Login users can execute only commands
permitted by the authorization server. Fo r more info rm ation about command auth orization, see
Fundamentals Configuration Guide.
• Command accounting—When command authorization is disabled, command accounting
enables the accounting server to record all valid commands executed on the device. When
command authorization is enabled, command accounting enables the accounting server to
record all authorized commands. For more information about command accounting, see
Fundamentals Configuration Guide.
•User role authentication—Authenticates each user who wants to obtain a temporary user role
without logging out or getting disconnected. For more information about temporary user role
authorization, see Fundamentals Configuration Guide.
Protocols and standards
• RFC 2865, Remote Authentication Dial In User Service (RADIUS)
• RFC 2866, RADIUS Accounting
10
• 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 T ACACS
RADIUS attributes
Commonly used standard RADIUS attributes
No. Attribute Description
1 User-Name Name of the user to be authenticated.
2 User-Password
3 CHAP-Password
4 NAS-IP-Address
5 NAS-Port Physical port of the NAS that the user accesses.
6 Service-Type
7 Framed-Protocol Encapsulation protocol for framed access.
8 Framed-IP-Address IP address assigned to the user.
11 Filter-ID Name of the filter list.
12 Framed-MTU
14 Login-IP-Host IP address of the NAS interface that the user accesses.
15 Login-Service Type of the service that the user uses for login.
18 Reply-Message
User password for PAP authentication, only present in Access-Request
packets when PAP authentication is used.
Digest of the user password for CHAP authentication, only present in
Access-Request packets when CHAP authentication is used.
IP address for the server to use to identify the client. Typically, a client is
identified by the IP address of its access interface. This attribute is only
present in Access-Request packets.
Type of service that the user has requested or type of service to be
provided.
MTU for the data link between the user and NAS. For example, this
attribute can be used to define the maximum size of EAP packets allowed
to be processed in 802.1X EAP authentication.
Text to be displayed to the user, which can be used by the server to
communicate information, for example, the reason of the authentication
failure.
Vendor-specific proprietary attribute. A packet can contain one or more
26 Vendor-Specific
27 Session-Timeout Maximum service duration for the user before termination of the session.
28 Idle-Timeout
31 Calling-Station-Id
32 NAS-Identifier Identification that the NAS uses to identify itself to the RADIUS server.
40 Acct-Status-Type
proprietary attributes, each of which can contain one or more
subattributes.
Maximum idle time permitted for the user before termination of the
session.
User identification that the NAS sends to the server. For the LAN access
service provided by an HPE device, this attribute includes the MAC
address of the user in the format HHHH-HHHH-HHHH.
Type of the Accounting-Request packet. Possible values include:
• 1—Start.
• 2—Stop.
• 3—Interim-Update.
• 4—Reset-Charge.
11
No. Attribute Description
•7—Accounting-On. (Defined in the 3rd Generation Partnership
Project.)
•8—Accounting-Off. (Defined in the 3rd Generation Partnership
Project.)
• 9 to 14—Reserved for tunnel accounting.
• 15—Reserved for failed.
Authentication method used by the user. Possible values include:
45 Acct-Authentic
• 1—RADIUS.
• 2—Local.
• 3—Remote.
60 CHAP-Challenge
61 NAS-Port-Type
79 EAP-Message
80
87 NAS-Port-Id String for describing the port of the NAS that is authenticating the user.
Message-Authenticato
r
CHAP challenge generated by the NAS for MD5 calculation during CHAP
authentication.
Type of the physical port of the NAS that is authenticating the user.
Possible values include:
• 15—Ethernet.
• 16—Any type of ADSL.
• 17—Cable. (With cable for cable TV.)
• 19—WLAN-IEEE 802.11.
• 201—VLAN.
• 202—ATM.
If the port is an ATM or Ethernet one and VLANs are implemented on it,
the value of this attribute is 201.
Used to encapsulate EAP packets to allow RADIUS to support EAP
authentication.
Used for authentication and verification of authentication packets to
prevent spoofing Access-Requests. This attribute is present when EAP
authentication is used.
HPE proprietary RADIUS subattributes
No. Subattribute Description
1 Input-Peak-Rate Peak rate in the direction from the user to the NAS, in bps.
2 Input-Average-Rate Average rate in the direction from the user to the NAS, in bps.
3 Input-Basic-Rate Basic rate in the direction from the user to the NAS, in bps.
4 Output-Peak-Rate Peak rate in the direction from the NAS to the user, in bps.
5 Output-Average-Rate Average rate in the direction from the NAS to the user, in bp s.
6 Output-Basic-Rate Basic rate in the direction from the NAS to the user, in bps.
15 Remanent_Volume
20 Command
Total remaining available traffic for the connection, in different units for
different server types.
Operation for the session, used for session control. Possible values
include:
• 1—Trigger-Request.
• 2—Terminate-Request.
• 3—SetPolicy.
• 4—Result.
• 5—PortalClear.
12
No. Subattribute Description
Identification for retransmitted packets. For retransmitted packets from
the same session, this attribute must be the same value. For
retransmitted packets from different sessions, this attribute does not
24 Control_Identifier
have to be the same value. The client response of a retransmitted
packet must also include this attribute and the value of this attribute
must be the same.
For Accounting-Request packets of the start, stop, and interim update
types, the Control_Identifier attribute does not take effect.
25 Result_Code
Result of the Trigger-Request or SetPolicy operation, zero for success
and any other value for failure.
26 Connect_ID Index of the user connection.
FTP, SFTP, or SCP user working directory.
28 Ftp_Directory
When the RADIUS client acts as the FTP, SFTP, or SCP server, this
attribute is used to set the working directory for an FTP, SFTP, or SCP
user on the RADIUS client.
29 Exec_Privilege EXEC user priority.
59 NAS_Startup_Timestamp
Startup time of the NAS in seconds, which is represented by the time
elapsed after 00:00:00 on Jan. 1, 1970 (UTC).
User IP address and MAC address included in authentication and
60 Ip_Host_Addr
accounting requests, in the format A.B.C.D hh:hh:hh:hh:hh:hh. A
space is required between the IP address and the MAC address.
61 User_Notify
Information that must be sent from the server to the client
transparently.
Hash value assigned after an 802.1X user passes authentication,
which is a 32-byte string. This attribute is stored in the user list on the
62 User_HeartBeat
NAS and verifies the handshake packets from the 802.1X user. This
attribute only exists in Access-Accept and Accounting-Request
packets.
User groups assigned after the SSL VPN user passes authentication.
140 User_Group
A user can belong to multiple user groups that are separated by
semicolons. This attribute is used to work with the SSL VPN device.
141 Security_Level
Security level assigned after the SSL VPN user passes security
authentication.
201 Input-Interval-Octets Number of bytes input within a real-time accounting interval.
202 Output-Interval-Octets Number of bytes output within a real-time accounting interval.
203 Input-Interval-Packets
204 Output-Interval-Packets
205 Input-Interval-Gigawords
206
Output-Interval-Gigawords Amount of bytes output within an accounting interval, in units of 4G
Number of packets input within an accounting interval in the unit set on
the NAS.
Number of packets output within an accounting interval in the unit set
on the NAS.
Amount of bytes input within an accounting interval, in units of 4G
bytes.
bytes.
207 Backup-NAS-IP Backup source IP address for sending RADIUS packets.
255 Product_ID Product name.
13
FIPS compliance
The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for
features, commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and
non-FIPS mode.
AAA configuration considerations and task list
To configure AAA, complete the following tasks on the NAS:
1. Configure the required AAA schemes:
{Local authentication—Configure local users and the related attributes, including the
usernames and passwords, for the users to be authenticated.
{Remote authentication—Configure the required RADIUS and HWTACACS schemes.
2. Configure AAA methods for the users' ISP domains. To use remote AAA methods, you must
specify the configured RADIUS or HWTACACS schemes.
Figure 8 AAA configuration procedure
To configure AAA, perform the following tasks:
Tasks at a glance
(Required.) Perform at least one of the following tasks to configure local users or AAA schemes:
• Configuring local users
• Configuring RADIUS schemes
• Configuring HWTACACS schemes
(Required.) Configure AAA methods for ISP domains:
1. (Required.) Creating an ISP domain
2. (Optiona
3. (Req
and accounting methods for the ISP domain:
{ Configuring authentication methods for an ISP domain
{ Configuring authorization methods for an ISP domain
{ Configuring accounting methods for an ISP domain
(Optional.) Enabling the session-control feature
l.) Setting the ISP domain status
uired.) Perform at least one of the following tasks to configure AAA authentication, authorization,
14
Tasks at a glance
(Optional.) Setting the maximum number of concurrent login users
Configuring AAA schemes
This section includes information on configuring local users, RADIUS schemes, and HWTACACS
schemes.
Configuring local users
To implement local authentication, authorization, and accounting, create local users and configure
user attributes on the device. The local users and attributes are stored in the local user database on
the device. A local user is u niquely identified by the combination of a username and a user type. The
device supports only device management users who log in to the device for device management.
The following local user attributes are configurable:
• Service type—Services that the user can use. Lo cal authentication checks the service types of
a local user. If none of the service types is available, the user cannot pass authentication.
Service types include FTP, SSH, Telnet, and terminal.
• User state—Whether or not a local user can request network services. There are two user
states: active and blocked. A user in active state can request netwo rk services, but a user in
blocked state cannot.
•Upper limit of concurrent logins using the same user name—Maximum number of users
who can concurrently access the device by using the same user name. When the number
reaches the upper limit, no more local users can access the device by using the user name.
• User group—Each local user belongs to a lo cal use r group and h as all attribut es of the g roup.
The attributes include the password control attributes and authorization attributes. For more
information about local user group, see "Configuring user group attributes."
• Authorization attributes—Authorization attributes indicate the user's rights after it passes
local authentication. Authorization attribut es include the ACL, idle cut feature, user role, VLAN,
and FTP/SFTP/SCP working directory. For support information about authori zation attributes,
see "Configuring local user attributes."
ure the authorization attributes based on the service type of local users.
Config
You can configure an authorization attribute in user group view or local user view. The setting of
an authorization attribute in local user view takes precedence over the attribute setting in user
group view.
{ The attribute configured in user group view applies to all local users in the user group.
{ The attribute configured in local user view applies only to the local user.
•Password control attributes—Password control attributes help control password security for
device management users. Password control attributes include password aging time, minimum
password length, password composition checking, password complexity checking, and login
attempt limit.
You can configure a password control attribute in system view, user group view, or local user
view. A password control attribute with a smaller effective range has a higher priority. For more
information about password management and global password configuration, see "Configuring
password control."
15
Local user configuration task list
Tasks at a glance
(Required.) Configuring local user attributes
(Optional.) Configuring user group attributes
(Optional.) Displaying and maintaining local users and local user groups
Configuring local user attributes
When you configure local user attributes, follow these guidelines:
•When you use the password-control enable command to globally enable the password
control feature, local user passwords are not displayed.
•You can configure authorization attributes and password control attributes in local user view or
user group view. The setting in local user view takes precedence over the setting in user group
view.
•Configure authorization attributes according to the application environments and purposes.
Support for authorization attributes depends on the service types of users.
{For Telnet and terminal users, only the authorization attributes idle-cut and user-role are
effective.
{For SSH users, only the authorization attributes idle-cut, user-role, and work-directory
are effective.
{ For FTP users, only the authorization attributes user-role and work-directory are effective.
{ For other types of local users, no authorization attribute takes effect.
To configure local user attributes:
Step Command Remarks
1. Enter system view.
2. Add a local user and enter
local user view.
3. (Optional.) Configure a
password for the local
user.
4. Assign services to the
local user.
5. (Optional.) Place the local
user to the active or
blocked state.
The password is encrypted with the
hash algorithm and saved in
ciphertext.
In non-FIPS mode, a
non-password-protected user
passes authentication if the user
provides the correct username and
passes attribute checks. To
enhance security, configure a
password for each local user.
In FIPS mode, only
password-protected users can pass
authentication.
By default, no service is authorized
to a local user.
By default, a created local user is in
active state and can request
network services.
6. (Optional.) Set the upper
access-limit
max-user-number
16
By default, the number of concurrent
Step Command Remarks
limit of concurrent logins
using the local user
name.
7. (Optional.) Configure
authorization attributes
for the local user.
8. (Optional.) Configure
password control
attributes for the local
user.
9. (Optional.) Assign the
local user to a user group.
authorization-attribute
acl-number |
user-role
work-directory
• Set the password aging time:
password-control aging
aging-time
• Set the minimum password
length:
password-control length
length
• Configure the password
composition policy:
password-control
composition type-number
type-number [ type-length
type-length ]
• Configure the password
complexity checking policy:
This command takes effect only
when local accounting is configured
for the local user. It does not apply to
FTP, SFTP, or SCP users, who do
not support accounting.
The following default settings apply:
• FTP, SFTP, and SCP users have
the root directory of the NAS set
as the working directory.
However, the users do not have
permission to access the root
directory.
• The network-operator user role
is assigned to local users that
are created by a network-admin
or level-15 user on the default
MDC.
• The mdc-operator user role is
assigned to local users that are
created by an mdc-admin or
level-15 user on a non-default
MDC.
Optional.
By default, the local user uses
password control attributes of the
user group to which the local user
belongs.
By default, a local user belongs to
the default user group
system
.
Configuring user group attributes
User groups simplify local user configuration and management. A user group contains a group of
local users and has a set of local user attributes. You can configure local user attributes for a user
group to implement centralized user attributes management for the local users in the group. Local
user attributes that are manageable include authorization attributes.
17
By default, every new local user belongs to the default user group system and has all attributes of
the group. To assign a local user to a different user group, use the group command in local user
view.
To configure user group attributes:
Step Command Remarks
1. Enter system view.
system-view
N/A
2. Create a user group and
enter user group view.
3. Configure authorization
attributes for the user
group.
4. (Optional.) Configure
password control attributes
for the user group.
By default, no authorization
attribute is configured for a user
group.
Optional.
By default, the user group uses
the global password control
settings. For more information,
see "Configuring password
control."
, which is the
Displaying and maintaining local users and local user groups
Execute display commands in any view .
Task Command
Display the local user
configuration and online user
statistics.
Display the user group
configuration.
display local-user
service-type
user-name
display user-group
{
user-name |
class manage
[
ftp
ssh
|
[ group-name ]
telnet
|
vlan
|
vlan-id ]
Configuring RADIUS schemes
A RADIUS scheme specifies the RADIUS serve rs that the device can wo rk with and defin es a set of
parameters. The device uses the parameters to exchange information with the RADIUS servers,
including the IP addresses of the servers, UDP port numbers, shared keys, and server types.
18
idle-cut
|
terminal
} |
disable
{
state
active
{
enable
|
block
|
} |
} |
Configuration task list
Tasks at a glance
(Required.) Creating a RADIUS scheme
(Required.) Specifying the RADIUS authentication servers
(Optional.) Specifying the RADIUS accounting servers and the relevant parameters
(Optional.) Specifying the shared keys for secure RADIUS communication
(Optional.) Specifying a VPN for the scheme
(Optional.) Setting the username format and traffic statistics units
(Optional.) Setting the maximum number of RADIUS request transmission attempts
(Optional.) Setting the status of RADIUS servers
(Optional.) Specifying the source IP address for outgoing RADIUS packets
(Optional.) Setting RADIUS timers
(Optional.) Configuring the accounting-on feature
(Optional.) Configuring the IP addresses of the security policy servers
(Optional.) Configuring the Login-Service attribute check method for SSH, FTP, and terminal us ers
(Optional.) Enabling SNMP notifications for RADIUS
(Optional.) Displaying and maintaining RADIUS
Creating a RADIUS scheme
Create a RADIUS scheme before performing any other RADIUS configurations. You can configure a
maximum of 16 RADIUS schemes. A RADIUS scheme can be used by multiple ISP domains.
To create a RADIUS scheme:
Step Command Remarks
1. Enter system view.
2. Create a RADIUS scheme
and enter RADIUS scheme
view.
system-view
radius scheme
radius-scheme-name
Specifying the RADIUS authentication servers
A RADIUS authentication server completes authentication and authorization together, because
authorization information is piggybacked in authentication responses sent to RADIUS clients.
You can specify one primary authentication server and a maximum of 16 secondary authentication
servers for a RADIUS scheme. When the primary server is not available, the device searches for the
secondary servers in the order they are configured. The first secondary server in active state i s used
for communication.
If redundancy is not required, specify only the primary server. A RADIUS authentication server can
act as the primary authentication server for one scheme and a secondary authentication server for
another scheme at the same time.
N/A
By default, no RADIUS scheme is
defined.
To specify RADIUS authentication servers for a RADIUS scheme:
By default, no authentication
server is specified.
Two authentication servers in a
scheme, primary or secondary,
cannot have the same
combination of hostname, IP
address, port number, and VPN.
Specifying the RADIUS accounting servers and the relevant parameters
Y ou can specify one primary accounting server and a maximum of 16 se condary accountin g servers
for a RADIUS scheme. When the primary server is not available, the device searches for the
secondary servers in the order they are configured. The first secondary server in active state i s used
for communication.
If redundancy is not required, specify only the primary server. A RADIUS accounting server can act
as the primary accounting server for one scheme and a secondary accounting server for another
scheme at the same time.
The device sends a stop-accounting request to the accounting server in the following situations:
• The device receives a connection teardown request from a host.
• The device receives a connection teardown command from an administrator.
When the maximum number of real-time accounting attempts is reached, the device disconnects
users who have no accounting responses.
RADIUS does not support accounting for FTP, SFTP, and SCP users.
To specify RADIUS accounting servers and the relevant parameters for a RADIUS scheme:
Step Command Remarks
1. Enter system view.
2. Enter RADIUS scheme view.
3. Specify RADIUS accounting
servers.
4. (Optional.) Set the maximum
number of real-time
Two accounting servers in a
scheme, primary or
secondary, cannot have the
same combination of
hostname, IP address, port
number, and VPN.
20
Step Command Remarks
accounting attempts.
Specifying the shared keys for secure RADIUS communication
The RADIUS client and server use the MD5 algorithm and shared keys to generate the Authenticator
value for packet authentication and user password encryption. The client and server must use the
same key for each type of communication.
A key configured in this task is for all servers of the same type (accounting or authentication) in the
scheme. The key has a lower priority than a key configured individually for a RADIUS server.
To specify a shared key for secure RADIUS communication:
Step Command Remarks
1. Enter system view.
system-view
N/A
2. Enter RADIUS scheme view.
3. Specify a shared key for
secure RADIUS
communication.
Specifying a VPN for the scheme
The VPN specified for a RADIUS scheme applies to all authentication and acco unting servers in that
scheme. If a VPN is also configured for an individual RADIUS server, the VPN specified for the
RADIUS scheme does not take effect on that server.
To specify a VPN for a scheme:
Step Command Remarks
1. Enter system view.
2. Enter RADIUS scheme view.
3. Specify a VPN for the RADIUS
scheme.
radius scheme
radius-scheme-name
key
accounting
{
authentication
simple
} string
system-view
radius scheme
radius-scheme-name
vpn-instance
|
cipher
} {
vpn-instance-name
N/A
By default, no shared key is
specified.
|
The shared key configured on the
device must be the same as the
shared key configured on the
RADIUS server.
N/A
N/A
By default, a RADIUS
scheme belongs to the public
network.
Setting the username format and traffic statistics units
A username is in the userid@isp-name format, where the isp-name argument represents the user's
ISP domain name. By default, the ISP domain name is included in a username. However, older
RADIUS servers might not recognize usernames that contain the ISP domain names. In this case,
you can configure the device to remove the domain name of each username to be sent.
If two or more ISP domains use the same RADIUS scheme, configure the RA DIUS scheme to keep
the ISP domain name in usernames for domain identification.
The device reports online user traffic statistics in accounting packets. The traf fic measurement units
are configurable, but they must be the same as the traffic measurement units configured on the
RADIUS accounting servers.
To set the username format and the traf fic statistics units for a RADIUS scheme:
21
Step Command Remarks
1. Enter system view.
system-view
N/A
2. Enter RADIUS scheme view.
3. Set the format for usernames
sent to the RADIUS servers.
4. (Optional.) Set the data flow
and packet measurement
units for traffic statistics.
radius scheme
radius-scheme-name
user-name-format
keep-original
{
without-domain
data-flow-format { data
giga-byte | kilo-byte |
mega-byte } | packet
giga-packet | kilo-packet |
{
mega-packet | one-packet
with-domain
|
}
{
|
byte |
} }*
N/A
By default, the ISP domain name
is included in a username.
By default, traffic is counted in
bytes and packets.
Setting the maximum number of RADIUS request transmission attempts
RADIUS uses UDP packets to transfer data. Because UDP communication is not reliable, RADIUS
uses a retransmission mechanism to improve reliability. A RADIUS request is retransmitted if the
NAS does not receive a server response for the request within the response timeout timer. For more
information about the RADIUS server response timeout timer, see "Setting RADIUS timers."
ou can set the maximum number for the NAS to retransmit a RADIUS request to the same server.
Y
When the maximum number is reached, the NAS tries to communicate with other RADIUS servers in
active state. If no other servers are in active state at the time, the NAS considers the authentication
or accounting attempt a failure.
To set the maximum number of RADIUS request tran smission attempts:
Step Command Remarks
1. Enter system view.
system-view
N/A
2. Enter RADIUS scheme view.
3. Set the maximum number of
RADIUS request transmission
attempts.
Setting the status of RADIUS servers
T o control the RADIUS servers with which the device communicates whe n the current servers are no
longer available, set the status of RADIUS servers to blocked or active. You can specify one primary
RADIUS server and multiple secondary RADIUS servers. The secondary servers act as the backup
of the primary server. The device chooses servers based on the following rules:
• When the primary server is in active state, the device communicates with the primary server.
• If the primary server fails, the device performs the following operations:
{ Changes the server status to blocked.
{ Starts a quiet timer for the server.
{ Tries to communicate with a secondary server in active state that has the highest priority.
• If the secondary server is unreachable, the device performs the following operations:
{ Changes the server status to blocked.
{ Starts a quiet timer for the server.
{ Tries to communicate with the next secondary server in active state that has the highest
priority.
radius scheme
radius-scheme-name
retry
retry-timesThe default setting is 3.
N/A
22
Loading...
+ 196 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.