Loading ...
Loading ...
Loading ...
105
8. Appendix
Configuring RADIUS Authentication in
PowerAlert
PowerAlert supports RADIUS authentication, authorization and
accounting. In addition to configuring PowerAlert to use RADIUS, one
or more RADIUS servers must be configured to provide the appropriate
exchange of information. This document assumes the following:
• The user understands the steps necessary to configure one or
more RADIUS hosts in PowerAlert
• The user understands the steps necessary to configure PowerAlert
to use RADIUS for authentication and/or accounting, either as
a sole option or in relationship to local authentication and/or
accounting
• Some flavor of RADIUS server has been installed and configured
and is accessible by PowerAlert
For the rest of this document, when we reference a specific RADIUS
server type, we will be using FreeRadius (www.freeradius.org) as our
default. Your specific configuration may vary.
Configuring the Dictionary
This refers to the definition of the attributes that can be exchanged
between a RADIUS server and a RADIUS client, in this case PowerAlert.
Sample A of this document shows a sample 'dictionary.tripplite'
configuration for use with a FreeRadius server.
The first thing that needs to be configured is a Vendor ID for TrippLite;
the assigned code is 850. This is necessary so that the vendor-
specific attributes that PowerAlert will send to the RADIUS server are
understood and accepted. Likewise, it allows the server to respond
with vendor-specific information. The configuration requires and defines
three string attributes.
TrippLite-Authorization
This string contains the authorization definition for a defined user. It
is how PowerAlert determines what facilities within PowerAlert may be
accessed or modified by a given user.
TrippLite-Outlet-Realms
This string contains the individual outlet realms for which a user
is granted access. This is how PowerAlert has implemented user-
controlled outlets.
TrippLite-Message
This is a simple string containing a textual message that will be sent
from PowerAlert to the RADIUS server during the accounting process.
Once the dictionary has been configured, the RADIUS server should
now understand how to handle information exchange with PowerAlert.
Configuring the Users
Each user requires a unique configuration. For the sample FreeRadius
server, those entries go into a single file called “users.” A sample of the
configuration file is given in Sample B.
Sample Administrative User
This entry in the user table defines a sample administrative user for
PowerAlert:
radiusadmin Cleartext-Password := "radiusadmin"
Reply-Message = "Hello, %{User-Name}",
TrippLite-Authorization = "default=rw",
Session-Timeout = 2400,
Idle-Timeout = 1200
This entry defines a user with the name of 'radiusadmin' and a
password of 'radiusadmin'. It is important to note that PowerAlert will
only generate authentication requests with a Cleartext-Password; no
other exchange mechanism is supported at this time.
The Reply-Message line simply indicates a textual response sent back
if the user authenticates successfully. It is not required by PowerAlert,
but is a standard component of a response to an authentication request.
The TrippLite-Authorization string is required in all successful
authentication responses. Failure to return said string will default the user
to no authorization. In this case, as described in the dictionary, this user
has default Read-Write access to all of the facilities within PowerAlert.
The Session-Timeout and Idle-Timeout strings are not defined in the
dictionary. They are not vendor-specific attributes, but are instead part
of the standard RADIUS configuration defined by RFC 2865.
Session-Timeout “sets the maximum number of seconds of
service to be provided to the user before termination of the
session or prompt. This Attribute is available to be sent by the
server to the client in an Access-Accept or Access-Challenge.” In
the case of PowerAlert, if this value is not sent, a user’s session
will never timeout.
Idle-Timeout “sets the maximum number of consecutive seconds
of idle connection allowed to the user before termination of the
session or prompt. This Attribute is available to be sent by the
server to the client in an Access-Accept or Access-Challenge.” In
the cause of PowerAlert, if this value is not sent, a user’s session
will never expire due to inactivity.
Sample Managerial User
This entry in the user table defines a sample managerial user for
PowerAlert:
radiusmanager Cleartext-Password := "radiusmanager"
Reply-Message = "Hello, %{User-Name}",
TrippLite-Authorization =
"default=rw,security=ro",
Session-Timeout = 1200,
Idle-Timeout = 600
For the most part, this is identical to the administrative account above:
A user name and password on the first line, a Reply-Message on the
second line, and a Tripplite-Authorization string on the third line. We
end the entry with slightly shorter Session-Timeout and Idle-Timeout
entries. The only major difference between the default manager
and the default administrator is that the manager is explicitly denied
Write access to the security facility, meaning they can view security
resources, such as user accounts and authentication schemes, but not
change them.
Loading ...
Loading ...
Loading ...