PolicyAssistant

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:

User Realm

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.

Realm Configuration

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 Edit Button 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 Insert Button button. This will display an empty initial Realm Configuration dialog box which you will use to enter information about your new realm.

  1. 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.

  2. For example: If the users log in as user@myisp.com you would enter myisp.com in this field.

  3. In the User Session Limit field enter the maximum number of concurrent network a user may use.

  4. 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.

  5. In the Total Realm Session Limit field, enter the maximum total number of concurrent network available to all users in this realm.

  6. 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.

  7. Select a source for your user profiles. The options are:

  8. File The 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.
    Database The user information is stored in a database. Also, a template may be specified to define a default profile for this realm.
    LDAP The 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 Directory The user information is validated using Microsoft Active Directory.
    Proxy The 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.

Configuring File Based Realms

  1. If you selected Local File as the storage type for this realm, you must now enter the name of the user file that will contain the user profiles. Click Edit Button 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.

    The user name specified in this file must be the basic user name without any realm information added.
    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


    A special user file profile of DEFAULT may be used to match any user who does not have a profile in the file. See User File Format for more information on DEFAULT users. If a DEFAULT entry is used in the user file for this realm, it is important to use an Auth-Type that will provide authentication that can specifically authenticate the user, such as SecurID, UNIX password files, or the Windows NT SAM.
  2. Select an authentication method from the next dialog. For more information see the section Authentication Configuration.
  3. Select a method to store accounting information. For more information about accounting storage methods see the section Accounting Configuration.

Database Lookup Configuration

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.

LDAP Lookup Configuration

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.

  1. The LDAP Server Host or IP Address field identifies the location of the LDAP. This may be an IP address or host name. If using a host name it must be resolvable while NavisRadius is running.
  2. The LDAP Server Port field is the port the LDAP server is listening on for connections. Normally this is port 389.
  3. The LDAP Server Search Base field specifies the search base (the starting point for a Scope One search) within the LDAP server's directory tree. This entry may consist of any combination of distinguished name (DN) components, which restricts searches to a specified area of the LDAP directory. The example shown below would cause the ReadLdap plug-in to search for users in the organizational unit (OU) named People, within the organization myisp, in the United States.

    For Example: You might set the LDAP Search Base as:

    LDAP Search Base ou=People, o=myisp
  4. For information on the next dialog, see the section above on Attribute Sets.

Proxy Realm Configuration

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:

None Do not use any attributes returned from the remote server. Use a locally configured profile instead.
Token Allow the remote server to specify a local profile template profile. The template name will be returned in the RADIUS Configuration-Token attribute.
All Use 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 *:*,*:* or 10.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.

Authentication Configuration

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:

Local Plain text password are checked using PAP or CHAP
NT Lookup the users password against the NT SAM.
System Use whatever Authentication type has been defined as the System type.
SecurID Forward 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:

None No System source defined. If the Auth-Type Check-Item is set to System the Access-Request will be rejected.
File Lookup user's password in a UNIX password or shadow file. This is valid on all platforms, including NT.
NT Verify the user's password using the NT SAM (Windows NT/2000 only).
Getpwnam Lookup 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...
None Not Available (grayed out) Leave blank
File UNIX 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.
NT NT Domain The name of the NT Domain or server to use to validate the users.
Getpwnam Not 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.

Accounting Configuration

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.

None Accounting records are not saved.
File Accounting records are saved to a file in Lucent detail format.
Database Accounting records are saved to a database.
Remote RADIUS Server Accounting 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.

What's Next?

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.



Go to Top of Page