Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Service Type Mapping

 

Service type mapping enables a single user to have multiple authorization attribute sets based on the service type the user is requesting. The service type is determined based on request attributes using rules that may differ depending on the NAS device.

Using static configuration parameters in the servtype.ini file, you can specify, on a NAS-by-NAS basis, a mapping of request attributes or values to service type strings. These strings can be attached to the username, either as a prefix or as a suffix. The elaborated username is used for both authentication and authorization, and for allowing different authorizations based on the service type requested.

Configuration

Configuration

Service type mapping is configured in the following way:

  • Create multiple Local User entries in the database according to specific naming and mapping conventions. For example:

  • Define a set of rules in the servtype.ini file mapping each incoming Access-Request packet to the appropriate database entry for the user.

Local User Database Entries

Local User Database Entries

The Local User entries you define to support service type mapping must follow a consistent naming convention. However, you are free to use any convention you like.

For example, you can store entries for PPP users using the convention ppp:username (for example, ppp:george and ppp:martha) and entries for VPN users using the convention vpn:username (vpn:george and vpn:martha).

For the mapping to work, however, you must define users who do not have any of these mapped prefixes or suffixes in the local users database. For example, if you want to map vpn:emil and ppp:emil so that the appropriate profiles are returned, you can enter three user entries in the local users database:

Alternatively, you can omit emil from the local users database, authenticate emil against a non-local method and then apply the mapping. The mapped names still have to be in the local user database for profiles to be returned.

You can support classes of service by varying the string you use in creating Local User entries. For example, if you offer three classes of VPN service, your VPN entries might use the conventions vpn1:username, vpn2:username, and vpn3:username (for example, vpn3:george and vpn1:martha).

A delimiting character (such as a colon) in your service type string makes your user record names easier to read—for example, vpn:amar instead of vpnamar. When you design a service type string, consider whether it is a prefix (string + separator) or a suffix (separator + string) to the username.

Note

You can define Local User records using the Administration program or the LDAP configuration interface.

servtype.ini File

servtype.ini File

The servtype.ini configuration file controls service type mapping and contains the sections listed in Table 170.

Table 170: servtype.ini Syntax

servicetype.ini Section

Meanings

[Settings]

Indicates how to attach the service type string to the username before look up in the Local User database: by prefix, by suffix, or not at all. The two fields Prefix and Suffix may be enabled (set to 1) or disabled (set to 0) independently of each other. If both are set to 0 (the default) the service type feature is completely disabled.

Using this example, if user george requests PPP service and the string for that service type is ppp:, the Local User record with the return list for this request has the name ppp:george.

[NAS]

Enables you to map NAS devices to [mapping] sections. The syntax for [NAS] is as follows:

[NAS]

NASname = mapping

NASname = mapping

.

.

.

NASname = mapping

Each NASname in the [NAS] section must match the name of a RADIUS client entry in the database. When an Access-Request is received, its NAS-IP-Address attribute is matched to a RADIUS client entry in the database. If a match is found, and the RADIUS client name matches a NASname in the [NAS] section, a corresponding [mapping] section is found.

[mapping]

Each section does the following:

Names the strings to be added to the username for performing lookups in the Local User database, to find the correct return list.

Provides a set of rules which the incoming Access-Request packet must meet if an Access-Accept is to be returned.

The syntax for each [mapping] section is as follows:

[ mapping ]

  ServiceTypeString

  RADIUSattribute = value

  ~RADIUSattribute = value

  .

  .

  .

  ServiceTypeString

  RADIUSattribute = value

RADIUSattribute = value

.

.

.

There may be zero or more rules in each ServiceTypeString section.

Each rule is a statement about an attribute in the incoming Access-Request packet. Each rule begins with a tab character, followed by a RADIUSattribute=value string, followed by a carriage return. Every component of the rule is optional.

If a rule provides a RADIUSattribute field, this field must name a standard or vendor-specific RADIUS attribute that is known to the server. If a rule provides an optional value field, this field must name a valid possible value for that attribute.

 

The following logic is applied to the [mapping] section:

  1. The next (initially, the first) ServiceTypeString in the [mapping] section is sought. It combines the ServiceTypeString with the username as defined in the [Settings] section, and tries to find a matching Local User entry.

    If a matching entry is found, each rule in the ServiceTypeString section is tried against the attributes in the incoming Access-Request packet. Otherwise, if there was no next ServiceTypeString or no match could be found, the user is rejected.

  2. In the following example, the rule syntax is: RADIUSattribute = value

    If the RADIUSattribute named is present in the Access-Request packet, and if it has the value shown, this rule is true. Evaluate the next rule. If there is no next rule, select this ServiceTypeString.

    If the RADIUSattribute named is not present in the Access-Request packet, or if it is present but does not have the value shown, then control returns to step 1.

  3. In the following example, the rule syntax is:

    RADIUSattribute

    Note: The absence of a value is important. If the RADIUSattribute is present in the Access-Request packet, this rule is true. Evaluate the next rule. If there is no next rule, select this ServiceTypeString.

    If the RADIUSattribute is not present in the Access-Request packet, control returns to step 1.

  4. In the following example, the rule syntax is:

    ~RADIUSattribute =value

    Note: Note the tilde (~) operator. If the RADIUSattribute named is present in the Access-Request packet, and if it does not have the value shown, this rule is true. Evaluate the next rule. If there is no next rule, accept this ServiceTypeString.

    If the RADIUSattribute named is not present in the Access-Request packet, or if it is present but has the value shown, control returns to step 1.

    Note: The following is not valid syntax: RADIUSattribute = ~value

  5. In the following example, the rule syntax is:

    ~RADIUSattribute

    Note: Note the tilde (~) operator and the absence of a value. If the RADIUSattribute named is not present in the Access-Request packet, this rule is true. Evaluate the next rule. If there is no next rule, accept this ServiceTypeString.

    If the RADIUSattribute named is present in the Access-Request packet, control returns to step 1.

  6. If no RADIUSattribute rules are provided and a ServiceTypeString section exists, but contains no rules, the ServiceTypeString is selected automatically.

  7. If no ServiceTypeString sections are provided and a [mapping] section exists, but is empty, the user is rejected automatically.

In addition to enabling a prefix or suffix, the [Settings] section of the servtype.ini file enables you to specify a default [ mapping ] section to be used when an Access-Request packet arrives from a NAS device that is not listed in the [NAS] section of servtype.ini. The syntax for setting this default is as follows:

 

The Default field is optional. If you do not set up a default mapping, and the server cannot determine the mapping in any other way, the server ignores the service type and authenticates the user without it.

The following is a sample servtype.ini file:

 

Any syntax error in the servtype.ini file prevents initialization of the file. If this occurs, service type mapping is disabled. This event is logged in the date.log file.