Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

proxy.ini File

 

The proxy.ini file specifies the order of realm selection methods, the realm selection rules, and other settings for all realms on the server. Settings for a realm are provided in its RealmName .pro or RealmName.dir file.

After you edit proxy.ini, you must apply your changes:

  • If you configured any proxy realms, you can load your new realm configuration without stopping and restarting the server.

    Issue the SIGHUP (1) signal to the Steel-Belted Radius Carrier process.

         #./sbrd hup

    Steel-Belted Radius Carrier re-reads proxy.ini, filter.ini, and all *.pro and *.dir files in the server directory, and resets its realm configuration.

  • If you configured any directed realms and if you added or changed:

    • Any directed accounting methods: you must stop and restart the server to load your new configuration.

    • Directed authentication methods in which external database (SQL or LDAP) authentication is used, you must stop and restart the server to load your new configuration.

    • Directed authentication methods in which local or pass-through (Native, UNIX, or Host) authentication is used, you can load your realm configuration by using a SIGHUP (1) signal.

[Configuration] Section

[Configuration] Section

The [Configuration] section (Table 91) of proxy.ini permits you to define prefix and suffix conventions for realm name parsing and specifies whether to use the primary RADIUS dictionary to process inbound proxy responses.

You can enable prefix and suffix conventions for realm name parsing if you specify a different delimiter character for each. All prefixed name decorations must use the prefix delimiter, and all suffixed name decorations must use the suffix delimiter.

If you set the prefix and suffix delimiter to the same character, both prefix and suffix conventions are enabled, but (since suffixes are checked first) prefixes may be misinterpreted.

Select different delimiter characters for tunnels, proxies, and realms.

Table 91: proxy.ini [Configuration] Syntax

Parameter

Function

RealmPrefix

Specifies the character used to identify prefixed name decorations; for example, RAS1/RAS2/joeuser.

Default value is /.

Note: Enter \\ to specify the backslash character, since a single backslash in a configuration file indicates a line continuation.

RealmSuffix

Specifies the character used to identify suffixed name decorations; for example, joeuser@RAS1@RAS2.

Default value is @.

Note: Enter \\ to specify the backslash character, since a single backslash in a configuration file indicates a line continuation.

UseMasterDictionary

  • If set to yes, inbound proxy responses use the primary Steel-Belted Radius Carrier dictionary when attributes are filtered in.

  • If set to no, proxy responses use the client-specific dictionary when attributes are filtered in.

Default value is yes.

Note: The UseMasterDictionary setting configured in individual .dir or .pro files overrides the global setting configured in the proxy.ini file.

SuppressResponseIfStatic

AcctFails

If set to yes, proxy accounting requests are discarded if static accounting or smart static accounting fails.

If set to no, proxy accounting responses are sent even if static accounting or smart static accounting fails.

Default value is no.

[Realms] Section

[Realms] Section

The [Realms] section (Table 92) of proxy.ini lists all of the proxy realms known to the server. The syntax is:

Table 92: proxy.ini [Realms] Syntax

Parameter

Function

RealmName

Each entry must match the name of a RealmName.pro file in the same directory as proxy.ini.

= match_rule

Optional. Specifies a rule for mapping the domain information in a User-Name to a proxy realm by means of prefix or suffix wildcards.

= <undecorated>

Optional. Marker indicating the specified realm is used to process requests containing undecorated User-Name information.

[Directed] Section

[Directed] Section

The [Directed] section (Table 93) of proxy.ini lists the names of all of the directed authentication and accounting realms on the server. The syntax for the [Directed] section is:

Table 93: proxy.ini [Directed] Syntax

Parameter

Function

RealmName

Each entry must match the name of a RealmName.dir file in the same directory as proxy.ini.

= match_rule

Optional. Specifies a rule for mapping the domain information in a User-Name to a directed realm by means of prefix or suffix wildcards.

= <undecorated>

Optional. Marker indicating the specified realm is used to process requests containing undecorated User-Name information.

[Processing] Section

[Processing] Section

If the [Processing] section (Table 94) is present, it lets you specify which realm selection rules are applied and the order in which they are applied. If no [Processing] section is present, routing continues in its default behavior.

Note

If the script keyword appears in the [Processing] section, Steel-Belted Radius Carrier executes the realm selection script first, before trying other built-in methods. For more information about the optional scripting module, see the SBR Carrier Administration and Configuration Guide.

Table 94: proxy.ini [Processing] Syntax

Parameter

Function

RealmSelector

This can be one of six identifiers: Attribute-Mapping, DNIS, Prefix, Suffix, Undecorated or RealmScript (requires optional scripting license). Only the rules corresponding to the values listed are applied, and they are applied in the order you specify them.

The following example enables undecorated Usernames, suffix delimiters, prefix delimiters, and DNIS rules (in that order).

[AttributeMap] Sections

[AttributeMap] Sections

The [AuthAttributeMap] and [AcctAttributeMap] sections of proxy.ini let you map the presence, absence, or specific value of an attribute or subattribute in the incoming packet to a specific realm. This is referred to as attribute mapping.

An [AuthAttributeMap] or [AcctAttributeMap] section consists of one or more RealmName entries. Each RealmName must match the name of a realm configuration file (RealmName.pro or RealmName.dir) in the same directory as proxy.ini.

Note

Attribute and subattribute mapping is supported by proxy realms and directed realms. You cannot use this feature when forwarding packets to a proxy target that is not accessed through a realm.

Each RealmName entry is a list of statements that can be true or false regarding the attributes or subattributes in an incoming RADIUS packet; we call these statements rules. Rules found in [AuthAttributeMap] apply to authentication packets; rules found in [AcctAttributeMap] apply to accounting packets. In all other respects, [AuthAttributeMap] or [AcctAttributeMap] are the same. The syntax for individual rules may vary; the following example shows all of the possible syntax variations:

For example:

Each attribute or subattribute mapping rule must begin with a space or tab character, followed optionally by a tilde ‘~’, then the name of a standard or vendor-specific RADIUS Attribute or subattribute that is in one of the Steel-Belted Radius Carrier dictionary files. If a Value is present, it is preceded by an equal sign ‘=’, and must specify a valid possible value for that attribute or subattribute. You can use wildcards (‘?’ and ‘*’) for values. A ‘?’ wildcard matches any character and a ‘*’ wildcard matches the remainder of the string (but can appear only at the end of a string). For example, entering Called-Station-ID=800* indicates any 800 number. The rule is terminated by a carriage return. Tilde ‘~’ indicates that the rule is satisfied only if the attribute or attribute value pair is not present in the packet.

Each RealmName entry in an [AuthAttributeMap] or [AcctAttributeMap] section is examined in sequence from top to bottom. Within each RealmName entry, each rule is evaluated in sequence from top to bottom. The results are:

  • If all of the rules in a RealmName entry evaluate to true, the packet is routed to the realm called RealmName and the remaining entries in the attribute map are ignored.

  • If any of the rules in a RealmName entry evaluate to false, this entry does not result in a mapping. Steel-Belted Radius Carrier evaluates the next entry in the map.

  • If Steel-Belted Radius Carrier encounters a RealmName entry that contains no rules, the packet is automatically directed to that realm.

Table 95 explains how the various types of rules are evaluated.

Table 95: Attribute Mapping Rules

Syntax Variation

Function of the Attribute Mapping Rule

Attribute=Value

If the Attribute is present in the request packet and it has the Value shown, then this rule is true. If the Attribute is not present, or if it is present but does not have the Value shown, then this rule is false.

Note: The Steel-Belted Radius Carrier dictionary file radius.dct provides string aliases for certain integer values defined in the RADIUS standard. You can use these strings in attribute mapping rules.

Attribute

If the Attribute is present in the request packet, then regardless of its value, this rule is true. If the Attribute is not present, then this rule is false.

Note: You are likely to use the Attribute rule without a Value infrequently, because most of the RADIUS packets coming into your configuration will contain the same set of RADIUS attributes, but with different values.

~Attribute=Value

Note the tilde (~) operator. This rule is looking for a specific attribute that may have any value except the one listed. If Attribute is present in the request packet and it does not have the Value shown, then this rule is true. If Attribute is not present, or if it is present but does have the Value shown, then this rule is false.

Note: The following is not valid syntax: Attribute=~Value

~Attribute

Note the tilde (~) operator and the absence of a Value. If Attribute is not present in the request packet, then this rule is true. If Attribute is present, then this rule is false.

When setting up [AuthAttributeMap] or [AcctAttributeMap] rules for your configuration, distinguish between the different realms whose requests you are processing. Consider how specific your rules must be to identify each realm uniquely. Is the presence of a particular attribute sufficient (Ascend-IP-Address), or must the attribute have a specific value before you can be sure of its source (NASIPAddr= n.n.n.n)? Make sure that your logic does not permit a crossing of requests between realms.

If a realm destination has been identified by applying an [AuthAttributeMap] entry to the attributes in a session’s authentication request, Steel-Belted Radius Carrier uses the same realm for that session’s accounting requests (if the realm is enabled for accounting). Generally, this is the desired behavior for the realm. Provide an [AcctAttributeMap] entry only if there is no [AuthAttributeMap] entry for a realm and you want to map the realm using one or more accounting attributes.

[DirectedAcctMethods] Section

[DirectedAcctMethods] Section

The [DirectedAcctMethods] section of the proxy.ini file lists one or more external database accounting configuration files (.acc) or local accounting initialization files (.ini) on the local server, and assigns each of these files a name by which it may be referenced in a RealmName.dir file.

The syntax for the [DirectedAcctMethods] section is:

where Description is the name by which you want to reference the accounting method and PathAndFile is the full pathname of a .acc or .ini file on the local server.

/usr/lib/extras/acctlib.acc

/usr/lib/extras/ouracct.ini

This is the file that implements the accounting method. The location of this file must not be the Steel-Belted Radius Carrier directory.

  • If your PathAndFile identifies an .acc file, external database accounting is performed as configured in the file. You may reference the Steel-Belted Radius Carrier SQL accounting module in the [Bootstrap] section of this .acc file.

  • If your PathAndFile identifies an .ini file, you may omit the [Bootstrap] section from this file. Normal Steel-Belted Radius Carrier logging is performed, except that:

    • Accounting log entries (for requests that are routed to this accounting method) are written to accounting log files (.act) in the specified Path, rather than in the server directory.

    • Logging details (which attributes are logged, and in which order) are controlled by the [Settings] and [Attributes] sections of the .ini file listed in PathAndFile, rather than the account.ini file found in the server directory.

[StaticAcct] Section

[StaticAcct] Section

Static proxy accounting lets you send duplicate copies of certain types of accounting requests to proxy realms (or any RADIUS-aware device), in addition to the normal routing of the original accounting request. The number of duplicates is not limited.

The [StaticAcct] section of proxy.ini maps possible values of the AcctStatusType attribute to a list of proxy realms that receive statically-forwarded, duplicate copies of all accounting packets of that type.

AcctStatusType is a RADIUS standard attribute that identifies the type of accounting request. Table 96 lists the names and meanings assigned to AcctStatusType values 1, 2, 3, 7, and 8. Additional values for Acct-Status-Type have been defined by network access server vendors for use with their equipment; you can also use these values in the [StaticAcct] section.

Table 96: Acct-Status-Type Attribute Values

Acct-Status-Type Value

Name

Meaning

1

Start

A user session has started

2

Stop

A user session has stopped, request contains final statistics

3

Interim

A user session is in progress, request contains current statistics

7

Accounting-On

The network access server has started

8

Accounting-Off

The network access server is about to shut down

The syntax for a [StaticAcct] section is:

where each number is a possible value of the Acct-Status-Type attribute, and each name identifies a section called [name] that appears elsewhere in the proxy.ini file.

When it receives an accounting request with an Acct-Status-Type of number, Steel-Belted Radius Carrier uses the [StaticAcct] section to match number with name, and statically forwards a duplicate copy of the packet to all of the proxy realms listed in the [name] section.

Each [name] section consists of a list name in square brackets ([name]) followed by a list of proxy realms. Each of these realms must have a RealmName.pro file in the same directory as proxy.ini. Directed realms do not support static proxy accounting.

The syntax for a [name] section is:

The [name] section is used only if its name is mapped to a number in the [StaticAcct] section of the proxy.ini file.

The following excerpt from a proxy.ini file demonstrates some of the flexibility of static proxy forwarding. Copies of all session-related accounting packets (Start, Stop, and Interim) are forwarded by proxy to a realm called billing. Copies of all device-related accounting packets (Accounting-On and Accounting-Off) are forwarded by proxy, not only to billing, but also to a realm called operations.

[Interfaces] Section

[Interfaces] Section

If your server has more than one network interface, you can assign the outgoing proxy traffic for a particular realm to a particular interface card:

  1. List the IP addresses associated with each network interface card in the [Addresses] section of the radius.ini file.

  2. Create an [Interfaces] section for the proxy.ini file with a list of one or more pairs in the following format:

    where InterfaceName is a label you assign to the given IPAddress.

  3. Extend the existing entries in the [name] sections in .pro files for proxy realms with the InterfaceName defined in the [Interfaces] section so that they are in the following format:

    where InterfaceName is the name of the interface defined in the [Interfaces] section.

For example:

Note

The ProxySource setting in the [Configuration] section of radius.ini disables per-realm control of proxy outbound interfaces. If ProxySource is not set, sockets are opened and bound for each interface on the server.