 |
» |
|
|
|
When the HP-UX AAA Server receives any RADIUS message, it
calls the FSM, and defines a starting event according to the type
of message. This first event determines the first action. In the
default FSM, the first action for an Access-Request is iaaaUsers. Figure 1-4 “Default Action Sequence” shows how
the FSM actions interact to process the Access-Request for authentication
and authorization:
Authentication to
Verify the Client and User | |
The authentication of an access request has
a number of distinctive steps as shown in Figure 1-5 “Authentication Steps”. The rounded rectangles represent configuration
files that the HP-UX AAA Server uses and the ovals represent one
or more authentication types. Authentication StepsAfter the HP-UX
AAA server receives an Access-Request, it attempts to match the
client making the request to an entry in the clients file. The server attempts to authenticate a request
only if a match can be made. Next, iaaaUsers checks the local users file. In this step, the User-Name attribute value from
the Access-Request is used to find an entry for the user in the
/etc/opt/aaa/users file. If User-Name
matches an entry, the server retrieves that profile, and then authentication
moved to step 5. If User-Name does not match
an entry, authentication moves to the next step.
If the iaaaUsers action does not find a matching user profile in the
users file, the FSM calls the iaaaRealm action. The iaaaRealm action parses the User-Name attribute value for a realm
name, and searches authfile to determine the data store where the
user profiles for the parsed realm are located. A default entry
can be used to handle any realms that are not explicitly configured
in authfile. | | | |  | NOTE: If no realm is specified in the NAI, the server
assigns the value NULL for the realm. You can configure NULL realm
behavior in the same manner as named realms. | | | | |
The iaaaRealm action calls another action that attempts to retrieve
a matching user profile from the data store for the realm, as indicated
by authfile: A realm-specific
AAA users file; An external data store,
such as LDAP or a database; A Unix user profile service
via the getpwent() system call.
If the realm is defined as a proxy, the RADIUS request is
forwarded to the target RADIUS server defined for this realm. The user is authenticated according
to the protocol established by the
Access-Request. If a password based protocol (PAP,CHAP, MSCHAP)
is specified, the user's password is verified. If an EAP method
is used, mutual authentication is carried out according to the EAP
type (PEAP, TLS, TTLS, or LEAP).
If User-Name matches no entry, either in a local text file
or an external data source, the authentication fails. Authorization
to Control Sessions and Access to Services | |
The HP-UX AAA Server can authorize users through
the following methods: Provisioning
on a user-by-user basis with check items and by adding reply items
to an Access-Accept message (simple policy); Through its Local Authorization
Server (LAS) functions based on realms; Through stored
policy decisions based on other logical groups that can add check
and reply items to the request
Like authentication, the authorization of an
access request has a number of distinctive steps as shown in Figure 1-6 “Authorization Steps”. The rounded rectangles
represent configuration files and the ovals represent one or more
actions called by the FSM. The dotted lines and shapes indicate
a step in the process that does not occur with the server's default
FSM configuration, but can be achieved with a customized configuration. The server receives
a request and authenticates the user. If authentication is successful,
the authorization begins. Check Items. After authentication
each check item in the user profile is processed or matched against
the request's corresponding Attribute-Value (A-V) pairs. If all
the check and deny items associated with User-Name are satisfied,
the CHK_DNY action returns an ACK value to the FSM. If any check or deny item,
including the user's password, is not matched correctly, the authentication
module returns a NAK value to the FSM. The request fails, and an Access-Reject
message is returned to the client.
Policy. HP-UX AAA policies
can be simple or complex decisions that control the authentication,
authorization, and accounting process for a user's request. A simple
policy uses lists of check and reply items. A complex policy refers
to checking a logical A-V pair expression associated with a group
of users for a true or false result. An A-V pair expression is represented
by a Boolean logic statement that can include AND, OR, NOT Boolean
operators, and relative operators. A-V pair expressions can use
parentheses to nest statements. According to the result of this complex
policy decision, the HP-UX AAA Server can accept or reject the request,
as well as control how services are delivered or logged. Some policies
that can be implemented include. According to the result of this complex policy decision,
the HP-UX AAA Server can accept or reject the request, as well as
control how services are delivered or logged. Some policies that
can be implemented include: Dialed Number
Identification Service (DNIS)—routing requests according
to the number called from or called; Grouping users by NAS addresses
or ports; Control session duration,
concurrent usage, or delivered services by logical groupings defined
by the contents of specified A-V pairs; Control access according
to any time-based criteria.
Local
Authorization Server (LAS). LAS refers to the routines and code
in the server that handle authorization. LAS and POSTLAS actions
are part of the LAS. Session control with LAS is based on realms.
Local Session tracking must be explicitly enabled for a realm via
the Server Manager or the /etc/opt/aaa/las.conf file. If the realm is not listed, LAS does not enforce
any session control for users from that realm. When the LAS handles
an Access-Request for a user in a local realm configured in the
las.conf file, the LAS module performs the following steps: Checks
the user profile for a Simultaneous-Session attribute-value pair,
which determines the maximum number of active sessions the user
can have. Default value is 1. Authorizes or denies service
based on Service-Class.
The POSTLAS action performs Simultaneous Access Token (SAT) control,
which is used to implement realm-based simultaneous session control. | | | | | NOTE: It is not recommended to enable local session tracking
for any realms utilizing session management via SQL Access. | | | | |
Reply items refers
to the generation of an Access-Accept or Access-Reject message by
the REPLY action. By adding reply items to a user's profile or through
policy decisions, REPLY can provide a NAS with provisioning information
in an Access-Accept data packet. Depending on the capabilities of
the NAS, the reply items can be used to control a user's session.
For example, the following user entry limits the length of the session
and the hosts that can be accessed:
guest@library.org Password = "public"
Filter = "library",
Session-Timeout = 3600 |
Users can authenticate as guest@example.org using password public to connect for one hour (3600 seconds) to the library
hosts that the filter library allows. The REPLY action also checks for a Service-Type value, equates
the value with user entries, and then appends reply items to the
request accordingly. The attribute values for these items specify
the default values to use when configuring the connection specified
by Service-Type. The special user entries are not used for authentication;
the reply items for one of these entries are appended to a request
from any user requesting the corresponding service type. When duplicate
A-V pairs exist, pruning is applied to determine the A-V pair that
should be included in the Access-Accept or Access-Reject message.
|
Printable version
