The PolicyAssistant provides an easy to use interface to configure NavisRadius for the the most common Authentication, Authorization and Accounting (AAA) applications.
The PolicyAssistant supports the following features and capabilities:
The key to the PolicyAssistant decisions is the User Realm. Data retrieval, authentication, and accounting policy are all based on the users realm.
The user realm is usually derived from the user name entered when the user logs into the network. The realm can also be defined by the DNIS (Called-Station-Id) used when the user logs onto the network, regardless of the realm the user enters. A Default Realm can also be designated for instances when no realm is used.
When you select the PolicyAssistant you will be see the Realms panel containing a list of any realms that have already been configured. From this panel you may add, delete and modify the realms that make up your configuration.
Note: The PolicyAssistant includes a special realm of DEFAULT. NavisRadius uses this realm if no realm is specified by the user and one is not specified by DNIS to realm mapping. You may wish to look at and modify the settings for the DEFAULT realm.
To configure an existing realm, double click on the realm or
select the realm and click the
button. This will display
the initial Realm Configuration dialog box with the options
for the selected realm already entered.
To add and configure a new realm, click on the
button. This will display an empty
initial Realm Configuration dialog box which you will use
to enter information about your new realm.
In the Realm Name field, enter the realm users enter when logging
into the network or enter the name of the realm used for
DNIS to realm mapping
Note: You must define the realm first before configuring DNIS
to realm mapping.
For example: If the users log in as user@myisp.com you would enter
myisp.comin this field.
In the User Session Limit field enter the maximum number of concurrent network a user may use.
Note: The default User Session Limit may be overridden on a per-user basis by setting the Connection-Limit Check-Item in the user profile to the appropriate limit for that user.
In the Total Realm Session Limit field, enter the maximum total number of concurrent network available to all users in this realm.
For example: Setting Total Realm Session Limit to 100 will limit the total number of simultaneous sessions for all users in this realm to 100. If 100 users are already logged in, The 101st user will be rejected and will not be allowed to log in until someone else has logged out.
It is important to understand how User Session Limit and Total Realm Session Limit interact. Each limit is looked at independently, and if either limit is exceeded the session will be rejected.
For example: If User Session Limit is set to 1 andTotal Realm Session Limit is set to 3, the users tom@myisp.com, richard@myisp.com, and terry@myisp.com all log in to the network. The session count for each is 1 so none of them would be able to log in and start a second, concurrent session. The session count for the realm myisp.com is 3. If the user mike@myisp.com tried to log in he would be rejected since the realm count would exceed the Connections for this Realm limit of 3. This is the case even though the Connections per Use for limit for mike@myisp.com is 1 and he has no active sessions.
Select a source for your user profiles. The options are:
FileThe users information is stored in a users file. (See User File Panel) The user source can also be retrieved from UNIX password or shadow files, a Windows NT SAM directory, or verified using SecurID or SafeWord. DatabaseThe user information is stored in a database. Also, a template may be specified to define a default profile for this realm. LDAPThe user information is retrieved from an LDAP directory. Also, a template may be specified to define a default profile for individual users or the entire realm. Microsoft Active DirectoryThe user information is validated using Microsoft Active Directory. ProxyThe request is forwarded to another RADIUS server. The user session attributes can be retrieved from the remote server, a default local template, or a template specified by the remote server.
to get a list of all user files in the run directory. Selecting a
file from the list, places the file's name into the User File Name field.
For example: Although user glenn logs in as glenn@myisp.com, the user name used for his profile would be just glenn.
Note: When using the PolicyAssistant, user lookups always use the basic User-Name attribute without realm. This means that you must use a separate user file for each realm so that NavisRadius can distinguish between users with the same name in two different realms. For example: glenn@myisp.com and glenn@homenet.net
When using a database to store user information for your realm you will need to provide data about how to query the database.
Important Notes:Use of the PolicyAssistant with databases requires use of the the schema provided with NavisRadius. Use of any other schema is not supported with the PolicyAssistant.
BP and BP/SE Versions: You should already have a database with the right schema installed. However, if you wish for multiple NavisRadius servers to share a single database you will need to modify the Jdbc method in the PolicyAssistant PolicyFlow. Please contact NavisRadius technical support for assistance.
SP Version: If you are using the NavisRadius SP version you will need to provide your own database and modify the Jdbc driver under the Advanced tab.
When database user lookup is performed, contents of the database column named Generic1 are imported into NavisRadius as Check-Items*. Contents of the Generic2 column are imported into NavisRadius as Reply Items*. Attributes in these columns must be in the format of Attribute = Value with multiple attribute=value pairs separated by a space. See Managing User Records for more information about editing users in a database.
* Technically, what happens is that the contents of the Generic1 column are mapped into variables in the check variable group and the contents of the Generic2 column are mapped into variables in the reply variable group.
The Default Realm Name for DB Lookup field is the actual realm name NavisRadius uses in the database lookup. This is normally set to the same name as the realm you are configuring, but it is not required. If no realm is entered then the realm name DEFAULT is used.
The Attribute Sets tab enables you to select a default template. If a template name was not specified in the user's profile then the name entered in this field will be looked up in the template file. This allows all users in a realm to have a specific template without having to enter one for each user.
Select from the four preconfigured options (PPP, SLIP, CSLIP, or TELNET), create and add a custom template, or don't use an attribute set.
For Example: Users may login as robert@myisp.com, but the realm entered in the database may actually be just myisp. Also, if users for a company are allowed log in as kyle@megaco.net or kyle@megaco.com the realm may be simply entered in the database as megaco with megaco specified as the Default Realm for DB Lookup so each user does not need to be entered twice.
The File Containing Attribute Sets field on the Advanced tab is required to support the use of a profile template to simplify database record maintenance. This field sets the name of the user file in which an entry in the Reply_Template column is looked up. If the template name cannot be located in the user file, then an entry with the name of DEFAULT will be used, if if exists. The template entry may contain Check-Items and/or Reply Items. Template Check-Items and Reply Items are added to any attribute read from the user's database entry.
Note: If the same attribute appears in both the user database entry and the template, the attribute from the user database entry will take precedence.
When using an LDAP directory to store user data for a realm you will need to provide the information to connect to the LDAP server and look up the user. If you will be using an LDAP Directory and are not familiar with the terms used in this section, you should contact your local LDAP Administrator for help.
For Example: You might set the LDAP Search Base as:
LDAP Search Baseou=People, o=myisp
If you have chosen Proxy RADIUS as the user source for this realm you need to provide information about how to connect to the remote server and how to process the reply.
The Primary Server field is the remote RADIUS server to use as the primary authentication server. RADIUS Access-Requests for users in this realm will be forwarded to this server. The server should be specified in the format host:port. If :port is not specified then 1812 will be used.
For example: radius.domain.com:1645 or 192.168.1.10:1812. If a host name is used it must resolve at run time.
The Secondary Server field is an optional remote RADIUS server to use as the secondary authentication server if the primary server does not answer. The server should be specified in the same format as the Primary Authentication Server: host:port. If :port is not specified then 1812 will be used.
Note: You may use the same remote server for both Authentication and Accounting.
The Shared Secret field defines the shared secret key to used to sign packets and to encrypt passwords when forwarding requests for this realm. The same shared secret key must be used by all servers (primary and secondary, Authentication and Accounting) that will answer forwarded requests for this realm.
Note: The shared secret key must match the shared secret specified on the remote server or else packets will be rejected by the remote server.
The Trust Level field, on the Advanced tab, sets the way NavisRadius will handle attributes returned from the remote host in an Access-Accept packet. Trust level has three options:
NoneDo not use any attributes returned from the remote server. Use a locally configured profile instead. TokenAllow the remote server to specify a local profile template profile. The template name will be returned in the RADIUS Configuration-Token attribute. AllUse all reply attributes returned by the remote server.
The Local Address to Send From field is an option to specify the local address and port from which proxy packets are to be sent. Normally NavisRadius will automatically select the IP Address and port to use. This option is normally only used if it is necessary to send from a known port to support firewall applications. The local address is specified in the in the format host:port. If asterisk (*) is specified as the host, then any local IP address is used. If a port is not specified then a port is chosen at random by the operating system.
For example: Setting *:2675 will force NavisRadius to use port 2675 on any available interface. Setting 10.2.3.4:2020 will force use of port 2020 on the interface 10.2.3.4
Note: Each IP Address:Port pair can support 256 outstanding requests to a given remote host. If more than 256 outstanding proxy requests to a single remote host are expected at any given time, then additional local address can be specified in a comma separated list. For example
*:*,*:*or10.2.3.4:2567,10.2.3.4:2567
If the trust level is None or Token, the Attribute Sets dialog opens. For more information on this dialog, see the section above on Attribute Sets.
Once the user data source information has been entered, the next step is to define how Password authentication for this realm should be performed.
The By Default, Authenticate Using field sets the default authentication type to use for this realm. Alternate authentication types can be defined in individual user records and those settings can override the default setting. The available choices are:
LocalPlain text password are checked using PAP or CHAP NTLookup the users password against the NT SAM. SystemUse whatever Authentication type has been defined as the System type. SecurIDForward the the SecurID Token to a RSA ACE server for authentication.
Note: The Auth-Type Check-Item can be used in a user profile to override the default setting. Any of the authentication types in the preceding list may be used.
For example:Auth-Type = System
The If Auth-Type = System, Use field defines where to go to get additionally user information when the authentication type for the user is set to System. The options for this field are as follows:
NoneNo System source defined. If the Auth-Type Check-Item is set to System the Access-Request will be rejected. FileLookup user's password in a UNIX password or shadow file. This is valid on all platforms, including NT. NTVerify the user's password using the NT SAM (Windows NT/2000 only). GetpwnamLookup the user's password using UNIX system calls. (See ReadGetpwnam Plug-in for more information and a list of supported platforms.)
The availability and title of the final field depends on the selection made in the If Auth-Type = System, Use field as described below:
If the choice for System Authentication is... Then the Title of this field will be... And you will enter... NoneNot Available (grayed out) Leave blank FileUNIX Password File* When the system source is set to File this should contain the path, if needed, and name of the password or shadow file to use. NTNT Domain The name of the NT Domain or server to use to validate the users. GetpwnamNot Available (grayed out) Leave blank
*Note regarding Password file use: The password or shadow file needs to be formatted in standard UNIX password file format (for a full description, see the UNIX password man page, section 4 or 5, depending on your system). NavisRadius minimally requires the user's name in column one and the encrypted password in column two with the columns separated by a colon (:). Passwords may be encrypted with DES, MD5, or SHA1.
You have now completed the user source and the authentication type definition. Click Next > to go to the Accounting Configuration panel.
The final step in setting up your realm is to define how accounting records will be managed. Three accounting options are available in the PolicyAssistant for processing accounting requests.
NoneAccounting records are not saved. FileAccounting records are saved to a file in Lucent detail format. DatabaseAccounting records are saved to a database. Remote RADIUS ServerAccounting records are sent to a remote server.
If you selected File as the accounting type for this realm, enter the name for your accounting file. All accounting information for this realm is placed in this file.
Note: The file name will actually have .yyyyMM appended to the name you entered (where yyyy is the four digit year and MM is the two digit month.) This will cause the accounting file to be saved and a new file opened (rolled over) at the start of each month. For example, if you entered myisp-acct-data as the name of you file, it would actually appear something like myisp-acct-data.200106.
If you selected Database as the accounting type for this realm, but you do not use a database for your user records, specify a default Realm. (Note: If the realm uses database lookups for users then the PolicyAssistant automatically uses the default realm specified in the user lookup configuration.)
When configuring accounting to a database, a realm name is needed for identifying accounting records in the database (the realm is used as the value of the User_Realm column in the database). Typically, you would enter the realm name here. If no value is specified then a value of DEFAULT is used. Note: If the realm uses database lookups for users then the PolicyAssistant automatically uses the value specified in the user lookup configuration and this panel will not be displayed.
Now that you have defined your realm, you may quit, define another realm, or associate a DNIS with the realm(s) you have created. See the discussion of PolicyAssistant DNIS Realms for more information on associating a DNIS with a realm.