 |
» |
|
|
|
User profiles associate
information, like check and reply items, with a user name. The server
configuration must include profiles for all the users that can access
services through the AAA server. Profiles can be stored in flat
text files, or in an external database. If a user profile is not included
in the configuration, the server will reject the user's access request. The default users, realm, or prefix.users files may contain user profiles for authentication.
Each user entry in one of these files can be one or more lines of
information. You do not have to edit the default users file when mapping realms to authentication types in
the authfile, since the user information for each defined realm will
be stored in a realm file or external database. Unless the default installation
of the configuration files has been changed, the users file can be
found in the /etc/opt/aaa directory. | | | |  | IMPORTANT: Configuration files have a maximum input line length
of 255 characters. No checking is done to insure that a configuration
statement has not exceeded this limit. | | | | |
| | | |  | NOTE: The order of the entries is important; the first entry
that matches the request will be used to authenticate the user.
The server will ignore the remaining entries; therefore, you should
list the most specific entries first and the default entry should
be last. | | | | |
Syntax of a User Entry | |
The first line of each entry consists of one or more fields: Users-Name configuration-items check-items
reply-item,
reply-item
. . . |
Syntax
of IPv6 Attributes | |
This section briefly describes the syntax of the IPv6
attributes that the users file contains. For more information on IPv6 Attributes,
refer to RFC 3162. This attribute indicates the identifying IPv6 address of the
NAS which is requesting authentication of the user, and it must
be unique to the NAS within the scope of the RADIUS server. Example 23-1 Examples
of NAS-IPv6-Address Attribute Syntax fedc:ba98:7654:3210:fedc:ba98:7654:3210
12ab::4871
2222::4 |
This attribute indicates an IPv6 prefix to be configured for
the user. Example 23-3 Examples
of Framed-IPv6-Prefix Attribute Syntax 0/64/12ab::cd30:0:0:0:0
0/28/fedc:ba98:7654:3210:fedc:ba98:7654:3210 |
The first field in the above examples is the Reserved field.
If you do not list this field, the default value 0 will be used.
However, HP recommends using 0 in the Reserved field to comply with
RFC 3162. The second field in the above example is the Prefix-Length
field. This field can take any value from 0 to 128. If nothing is
specified in the Prefix-Length field, the default value 64 is used. The last field in the above example is the Prefix field. In
this field, the complete IPv6 address must be listed. This attribute indicates the system that the user will connect
to when Service-Type is defined as Login. You can also specify a
valid hostname to this attribute, if that hostname is configured
in the clients file. Example 23-4 Examples
of Login-IPv6-Host Attribute Syntax fedc:ba98:7654:3210:fedc:ba98:7654:3210
12ab::4871
2222::4
hostname.domain.com |
This attribute is sent by the AAA server to the NAS and contains
the name of an assigned pool that must be used to assign an IPv6
address for the user. The pool is a string attribute sent to the
NAS. This value is returned to the NAS. The NAS then handles the
IPv6 prefix allocation based on the value returned. If a NAS does
not support multiple address pools, the NAS must ignore this attribute. Example 23-6 Example
of a Framed-IPv6-Pool Attribute Syntax With Tunneling | |
When the AAA server receives an Access-Request from
a client that matches the user, fred-eng, it will first
attempt to match the password to the User-Password attribute
value in the request and then will check the request for a tunnel
hint. If the password does not match, or there is no hint for medium
type or the hint does not specify the IP address type, the server
will respond with an Access-Reject; otherwise, the server
will return the listed tunneling attribute values to the client. fred-eng Password = "laser", Tunnel-Medium-Type = IPv4
Tunnel-Type = PPTP,
Tunnel-Medium-Type = IPv4,
Tunnel-Client-Endpoint = 192.168.127.1,
Tunnel-Server-Endpoint = 192.155.111.1,
Tunnel-Password = Michigan,
Tunnel-Private-Group-ID = engineering,
Tunnel-Assignment-ID = management,
Tunnel-Preference = first,
Tunnel-Client-Auth-ID = NET,
Tunnel-Server-Auth-ID = Michigan,
Tunnel-Type = L2TP |
Attribute tags are used in the next example. If the password
does not match, or there is no hint for medium type or the hint
does not specify the IP address type, the server will respond with
an Access-Reject; otherwise, the server will return the
listed tunneling attribute values to the client. Because the tunnels
tagged with 1 are defined first, the client will establish a tunnel
according to those attributes, unless the client cannot use the
PPTP protocol—then the attributes tagged with 2 will be used
instead. |
fred-eng Password="laser", Tunnel-Medium-Type = IPv4
Tunnel-Type =:1:PPTP,
Tunnel-Medium-Type =:1:IPv4,
Tunnel-Client-Endpoint =:1:192.168.127.1,
Tunnel-Server-Endpoint =:1:192.155.111.1,
Tunnel-Password =:1:Michigan,
Tunnel-Private-Group-ID =:1:engineering,
Tunnel-Assignment-ID =:1:management,
Tunnel-Preference =:1:first,
Tunnel-Client-Auth-ID =:1:NET,
Tunnel-Server-Auth-ID =:1:Michigan,
Tunnel-Type =:2:L2TP,
Tunnel-Medium-Type =:2:IPv4,
Tunnel-Client-Endpoint =:2:192.168.127.1,
Tunnel-Server-Endpoint =:2:192.170.130.1,
Tunnel-Password =:2:California,
Tunnel-Private-Group-ID =:2:engineering,
Tunnel-Assignment-ID =:2:management,
Tunnel-Preference =:2:second,
Tunnel-Client-Auth-ID =:2:NET,
Tunnel-Server-Auth-ID =:2:California |
|
Printable version
