Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
  
[+] Expand All
[-] Collapse All

LDAP Authentication

The LDAP authentication configuration file is located in the same directory that contains the Steel-Belted Radius Carrier daemon. The configuration file must have the extension .aut and is usually called ldapauth.aut.

An LDAP authentication configuration file consists of several sections, where each section may contain multiple entries. Section names are enclosed in square brackets, for example [Bootstrap]. Each entry in the section appears on one line, and is of the form parameter = value. A section ends at the next section, or at the end of the file. Everything to the right of a semicolon (;) is ignored until the end of that line.

When Steel-Belted Radius Carrier extracts RADIUS attribute values from the incoming Access-Request and adds them to the Variable Table, the name that it gives to each variable is the same as the name of the corresponding attribute, for example User-Name or Calling-Station-ID. You may refer to the variable by this name in any subsequent entry in the .aut configuration file. This convention means that RADIUS attribute names are treated as reserved keywords. However, the .aut configuration file syntax also permits you to assign the value of an incoming RADIUS attribute to any variable.

When the LDAP Search request returns LDAP attribute values, they are added to the Variable Table. Steel-Belted Radius Carrier gives each variable the name of the corresponding LDAP attribute. This schema produces variable names such as User-Secret and Last-Name. For the names to use in your own .aut configuration file, consult your LDAP database schema. Like RADIUS attribute names, LDAP attribute names are treated as reserved keywords. However, the .aut configuration file syntax permits you to assign the value of a returned LDAP attribute to any variable.

LDAP Authentication Variable Names

When Steel-Belted Radius Carrier extracts RADIUS attribute values from the incoming Access-Request and adds them to the Variable Table, the name that it gives to each variable is the same as the name of the corresponding attribute, for example User-Name or Calling-Station-ID. You may refer to the variable by this name in any subsequent entry in the .aut configuration file. This convention means that RADIUS attribute names are treated as reserved keywords. However, the .aut configuration file syntax also permits you to assign the value of an incoming RADIUS attribute to any variable.

When the LDAP Search request returns LDAP attribute values, they are added to the Variable Table. Steel-Belted Radius Carrier gives each variable the name of the corresponding LDAP attribute. This schema produces variable names such as User-Secret and Last-Name. For the names to use in your own .aut configuration file, consult your LDAP database schema. Like RADIUS attribute names, LDAP attribute names are treated as reserved keywords. However, the .aut configuration file syntax permits you to assign the value of a returned LDAP attribute to any variable.

[Bootstrap] Section

The [Bootstrap] section (Table 167) of the LDAP authentication configuration file specifies information that Steel-Belted Radius Carrier uses to load and start the LDAP Authentication plug-in.

After you edit ldapauth.aut and restart Steel-Belted Radius Carrier, the InitializationString value that you entered in the [Bootstrap] section of ldapauth.aut appears in the Authentication Methods page in Web GUI. You can then enable, disable, or prioritize this method like any other entry in the list.

You can configure more than one LDAP authentication method. Each requires its own .aut file in the same directory as ldapauth.aut. The [Bootstrap] section of each .aut file must provide a LibraryName of ldapauth.so. The InitializationString in each .aut file must be unique, so that you can distinguish between authentication methods in the Authentication Methods page.

Table 167: *.aut [Bootstrap] Syntax

Parameter

Function

AcceptsAuthorizeOnly

  • If set to 1, Authorize-Only requests are accepted for this authentication method, when all of the following conditions are true:
    • The Access-Request contains the Service-Type attribute with a value=Authorize-Only
    • Message-Authenticator is present and valid
    • A session already exists in SBR Carrier for the AAA session ID (WiMAX)
    • AuthorizeOnly=1 in the [Configuration] section of radius.ini
  • If set to 0, Authorize-Only requests are not accepted for this authentication method regardless of whether AuthorizeOnly=1 in radius.ini.

Note: SBR Carrier is only able to process Authorize-Only requests for WiMAX sessions because a session must be located in the current session table, indexed by a WiMAX session Id.

[Settings] Section

The [Settings] section (Table 168) of the LDAP authentication configuration file defines parameters that control the database connection. Refer Table 164 for the common parameters of the LDAP configuration file.

The syntax is:

[Settings]
DelayConnect=1

Table 168: *.aut [Settings] Syntax

Parameter

Function

DelayConnect

Specifies whether to establish a connection to the LDAP server during SBR startup.

  • If set to 0, Steel-Belted Radius Carrier establishes a connection to the LDAP server during SBR startup.
  • If set to 1, Steel-Belted Radius Carrier does not establish a connection to the LDAP server during SBR startup. Only when an LDAP authentication request is received from a user, Steel-Belted Radius Carrier establishes a connection to the LDAP server. This setting is useful when not all users are required to be authenticated through the LDAP server, for example when JavaScript in the ldapauth.aut file is used to differentiate users.

Default value is 0.

Note: The DelayConnect parameter is applicable only for the Bind authentication.

[JavaScript] Section

The [JavaScript] section Table 169 of the LDAP authentication configuration file contains the configuration parameters for the Javascript engine.

The syntax is:

[JavaScript]
;JSEngineRuntimeMemory=8

Table 169: *.aut [JavaScript] Syntax

Parameter

Function

JSEngineRuntimeMemory

Sets the runtime memory of the Javascript engine from which a new instance of Javascript engine is created during Javascript service initialization.

For 32-bit version of SBR Carrier, default value is 8 MB.

For 64-bit version of SBR Carrier, default value is 32 MB.

[Attributes/name] Sections

LDAP database entries may have many attributes, many of which may be irrelevant to the authentication process. An LDAP Search returns all of the attributes associated with an LDAP entry. Therefore, when specifying an LDAP Search for authentication purposes, you may want to provide a list of specific LDAP attributes relevant to Steel-Belted Radius Carrier. Only these attributes are placed in the Variable Table.

Each [Attributes/ name ] section in the LDAP authentication configuration file lists LDAP attributes relevant to a specific LDAP Search request. The syntax is:

[Attributes/name]attributeattribute...

where attribute is the name of an LDAP attribute and name is an arbitrary name for the section. You must type the attribute names exactly as they appear in your LDAP database schema. Use one line per attribute. For example:

[Attributes/InterestingAttributes]
User-Secret
RADIUS-Profile
Inactivity-Timeout

An [Attributes/ name ] section is associated with a Search request by referencing it from within a [Search/ name ] section using the Attributes parameter. For example:

[Search/DoLdapSearch]
Attributes = InterestingAttributes

If the Attributes parameter is omitted from a [Search/ name ] section, Steel-Belted Radius Carrier retains all of the attributes associated with the LDAP entry. Of these attributes, Steel-Belted Radius Carrier uses only those referenced in the .aut configuration file; all others stay in the Variable Table until the authentication transaction is complete and the table is discarded.

For BindName authentication, you must ensure that the [Attributes/ name ] section lists the attribute in which the user’s password is stored and that your [Response] section assigns the value of this attribute to the outgoing %Password parameter. Steel-Belted Radius Carrier completes authentication by comparing the returned %Password value with the password that arrived in the Access-Request. For example:

[Attributes/InterestingAttributes]
User-Secret
RADIUS-Profile
Inactivity-Timeout

[Response]
%Password = User-Secret
%Profile = RADIUS-Profile
Vendor-Specific-NAS-Attribute = Inactivity-Timeout

[RejectResponse] Section

This [RejectResponse] section defines the attributes you want to return in an Access-Reject message.

The [RejectResponse] section syntax

[RejectResponse]attribute = variableattribute = variable...

where attribute is the name of a RADIUS attribute you want to include in the Access-Reject message, and variable is the name of a variable in the Variable Table. The end result of the [RejectResponse] syntax is that the value in the variable is assigned to the attribute.

Example:

[Response]Kineto-UMA-Reg-Reject-Cause = Kineto-UMA-Reg-Reject-CauseService-Type= Service-Type
[RejectResponse]Kineto-UMA-Reg-Reject-Cause = Kineto-UMA-Reg-Reject-CauseFilter-ID = Filter-ID

[Response] Section

During an authentication transaction, the [Response] section is the last section in the LDAP authentication configuration file to be processed. At this point in processing, all Bind and Search requests to the LDAP database have been completed.

The [Response] section instructs Steel-Belted Radius Carrier what to do with the information that it has retrieved from the incoming Access-Request and from the LDAP database. The goal at this point is for Steel-Belted Radius Carrier to complete authentication and issue an Access-Response to the RADIUS client.

The [Response] section syntax (Table 170) is:

[Response]attribute = variableattribute = variable...

where attribute is the name of a RADIUS attribute or other special item needed to complete authentication, and variable is the name of a variable in the Variable Table. The end result of the [Response] syntax is that the value in the variable is assigned to the attribute.

An IP pool can be returned for any attribute of the appropriate type. If the returned string appears to be an IP address (that is, in the format, a.b.c.d), it is considered an IP address; otherwise, it is considered an address pool, from which an IP address is allocated.

attribute may be the name of a RADIUS attribute, or it may be one of the following keywords, which identify various special items associated with Steel-Belted Radius Carrier. Each of these keywords begins with the percent sign (%) to distinguish it clearly from the RADIUS attributes.

Table 170: *.aut [Response] Syntax

Item

Function

%LoginLimit

The name of the variable specifying the Maximum Concurrent Connection limits.

%Password

For BindName authentication, you must provide a %Password entry in the [Response] section and you must assign it the value of the password attribute retrieved from the LDAP database. Steel-Belted Radius Carrier validates the password received in the AccessRequest by comparing it with the value assigned to %Password. If the passwords do not match, the request is rejected.

Note: The user's password may be in clear-text, or encrypted with UNIXcrypt or a SHA1+Base64 hash.

For Bind authentication, omit %Password. When processing reaches the [Response] section, the password has already been validated.

%Profile

 

The name of a Profile entry in the Steel-Belted Radius Carrier database.

If the password has been validated (by BindName or Bind), with %Profile listed in the [Response] section, %Profile may be set to any variable, for example:

%Profile = userpolicy

When the search filter is set to find a user or object in the LDAP database that includes the userpolicy LDAP attribute, this value is retrieved and returned to the Steel-Belted Radius Carrier database so that it may be matched with an existing Profile entry of the same name. If the userpolicy LDAP attribute is multi-valued, the first value of userpolicy is used and subsequent values are ignored.

If the value of userpolicy is “prof1” and a Profile called prof1 exists in the Steel-Belted Radius Carrier database, any return list or check list attributes in prof1 are applied to the user's connection.

If the value returned from LDAP cannot be matched with an existing Profile in the Steel-Belted Radius Carrier database, the user is rejected due to “Insufficient Resources.”

%ProxyRealm

The realm to which the authentication must be proxied. If ProxyRealm is not set, Routed Proxy does not occur.

%ProxyUserName

The User-Name attribute, which must be sent in the proxy request. If ProxyUserName is not set, the User-Name from the original request packet is used.

Note: Enter the value for %ProxyUserName in capital letters

%Alias

The name of a Native User entry in the Steel-Belted Radius Carrier database.

If the password has been validated (by BindName or Bind), with %Alias listed in the [Response] section, %Alias may be set to any variable, for example:

%Alias = userpolicy

Important: We strongly recommend you use %Profile, because use of %Alias has been deprecated.

The %LoginLimit value lets you implement the concurrent connection limits previously available through %Alias.

Generally, even if a very large number of users reside in the LDAP database, you need to add only one or two Native User entries to the Steel-Belted Radius Carrier database. The concurrent connection limit associated with a single Native User entry may be applied to any number of users in the LDAP database. Often a Native User entry with a connection limit of 1, and a second Native User entry with a connection limit of 2, is sufficient for the entire LDAP database.

For example, analog users may be allowed a connection limit of 1, while ISDN users are allowed a connection limit of 2.

Note: The Native User authentication method displayed in the Authentication Methods page does not need to be activated for the Alias feature to work.

%FullName

The fully distinguished name of the User, for Steel-Belted Radius Carrier accounting purposes. This is the exact name against which authentication was performed. Depending on what may have occurred during Steel-Belted Radius Carrier name parsing, this name may or may not be different from the value of the User-Name attribute as it originally arrived in the Access-Request.

[Request] Section

The [Request] section (Table 171) of the LDAP authentication configuration file indicates which RADIUS attribute values Steel-Belted Radius Carrier extracts from the incoming Access-Request. Steel-Belted Radius Carrier places these values in the Variable Table before moving on to the LDAP Bind and Search requests indicated in the file.

The syntax is:

[Request]attribute = variableattribute = variable...

where attribute is the name of a RADIUS attribute or other special item associated with the incoming Access-Request, and variable is the name of a variable in the Variable Table. The end result of the [Request] syntax is that the value in the incoming attribute is assigned to this variable.

attribute may be the name of a RADIUS attribute, or it may be one of the following keywords, which identify various special items also associated with the connection request. Each of these keywords begins with the percent sign (%) to strongly distinguish it from the RADIUS attributes.

Table 171: *.aut [Request] Syntax

Item

Function

%OriginalUserName

The original full identification of the user, before any processing (that is, user@realm).

%User

The user portion of OriginalUserName (the section before @).

%UserName

The full user identification (user and realm strings) after all stripping and processing has been performed.

%Name

Synonym for UserName.

%EffectiveUser

The name of the user (the section before @) as presented to the authentication method. This may be a modified version of the original username.

%Realm

The realm portion of the original user identification (the section after @) as presented to the authentication method. This may be a modified version of the original realm name.

%EffectiveRealm

The realm portion of the user identification as presented to the method. This may be a modified version of the original realm name.

%NASName

The name of the network access server that originated the request. This may be the name of the RADIUS Clients entry in the database or the value of the NAS-Identifier or NAS-IP-Address attribute.

%NASAddress

The address of the NAS, in dotted notation.

%NASModel

The make/model of the NAS, as specified in the Steel-Belted Radius Carrier database.

%Password

The PAP password.

Note: The %Password function cannot be used in a filter.

%AllowedAccessHours

The time periods in which the user is allowed to access the network.

%RADIUSClientName

The name of the network access server, as specified in a RADIUS Clients entry in the Steel-Belted Radius Carrier database.

variable may be omitted from any [Request] entry. If so, the value in the incoming attribute is assigned to a variable named attribute.

[Request]attribute =

In the following [Request] section example, the nasid variable receives the value of the NAS-Identifier attribute from the request packet, the Service-Type variable receives the value of the Service-Type attribute, and the %NASAddress variable receives the NAS address in dotted notation.

[Request]
NAS-Identifier = nasid
Service-Type =
%NASAddress =

[Defaults] Section

The [Defaults] section of the LDAP authentication configuration file lets you add entries to the variable table before the request is processed. You can reference these variables in your query, even if they are not supplied in the request. Any variable not listed in the [Defaults] section is initialized to a null value.

The format of each [Defaults] entry is:

variable = value

where variable is the name of a variable and value is the value you want to assign to it. For example:

[Defaults]
Default-User=SStudent

[Search/Radius]
Base = ou=people,dc=funk,dc=com
Filter = uid=<Default-User>
Scope = 2
Attributes = RadiusAttrs
Timeout = 20
%DN = dn

In this example, the Default-User variable is not created during request processing by the LDAP plug-in. Instead, the Default-User variable is inserted into the variable table by the entry in the [Defaults] section, and then substituted into the Filter setting in the [Search/Radius] section.

You can use the [Defaults] section to specify values for any variable, including temporary variables and those that represent RADIUS attributes or LDAP attributes. This way, if the Access-Request packet and LDAP database do not provide Steel-Belted Radius Carrier with all of the values that it needs to respond to an Access-Request, in each case it has an acceptable alternative value that can be used instead.

You can store multiple values for any variable; if that variable is mapped to a RADIUS attribute, all values are returned in the RADIUS response. Multiple entries set within this section are considered multiple values of the same variable.

Variable values are not additive between this section and each search. Therefore, if a search returns one or more values, all current values are replaced.

Note: The [Defaults] section is the only section in the configuration file that lets you assign static values to variables.

[Failure] Section

The [Failure] section of the LDAP authentication configuration file (Table 172) can be used to determine the result of the authentication process (accept or reject) when connectivity to all of the configured LDAP databases has failed. For example:

[Failure]
Accept = 1
Profile = XYZ
FullName = Mr Stanley Smith

Note: The Profile option and the Alias option cannot be used together. Read the following descriptions and choose the one that suits your needs.

Table 172: *.aut [Failure] Syntax

Parameter

Function

Accept

  • If set to 1, Steel-Belted Radius Carrier returns an Access-Accept packet with the Profile, FullName, and/or Alias attributes specified in the corresponding [Failure] section parameters.
  • If set to 0, the user is rejected.

Profile

This is the name of an existing Steel-Belted Radius Carrier Profile entry, whose check list and return list attributes are applied to the user's connection.

FullName

This string is the full username, which is used in the Class attribute in the Access-Accept message.

Alias

As an alternative to using the Profile parameter, you can use the Alias parameter to name an existing Steel-Belted Radius Carrier Native User entry. Steel-Belted Radius Carrier then applies the check list and return list attributes of this User entry to the user's connection.

Note: The Alias feature permits the Maximum Concurrent Connection limit (settable in the Users page) to be applied to the user's connection.

Important: We strongly recommend you use Profile, because use of Alias has been deprecated. The LoginLimit value lets you implement the concurrent connection limits previously available through Alias.

If you want to apply concurrent connection limits to users who are being authenticated by means of LDAP, you must set up a Native User entry specifically for this purpose, with all of the appropriate check list and return list attributes, and with no password. You can set up as many such accounts as you require. These entries store a specific set of check list and return list attributes for LDAP authentication, for use only with the Alias parameter.

Note: Native User entries without passwords cannot be authenticated. This is a safety feature built into Steel-Belted Radius Carrier. Therefore, setting up User entries in preparation for using the Alias parameter with LDAP authentication does not pose a back door security risk.

Note: The Native User authentication method displayed in the Authentication Methods page does not need to be activated for the Alias feature to work.

Grouped Attributes

This section explains the use of the following LDAP grouped attributes:

  • ProfileData: Stores multiple RADIUS attribute value pairs within a single LDAP container, removing the need for multiple entries in a LDAP user object.
  • GlobalProfile: Configures users based on a global profile, which can be specified as any username concatenated with the company name (such as Profile1@Company).

GlobalProfile Attribute

The GlobalProfile attribute takes the value from an LDAP attribute and parses it to match a profile. The format of the data is that of a DN attribute. Store it as:

cn=profile-name, {optional ou’s}, o=name,
{optional dc’s \o’s \c’s}

profile-name and name are concatenated to build profilename@name. Make sure this value matches a profile stored in Steel-Belted Radius Carrier. For example:

cn=Global1, ou=Profile, ou=Radius, ou=IP Services,
o=acme, o=directoryroot

This value is parsed to form a new string: Global1@acme. This new string is then passed back as the profile by making the following entry in the response section:

[Response]
%profile= LDAP attribute that contains the global profile

This value is ignored if:

  • There is no o keyword value
  • The string does not begin with the cn keyword
  • %profile is not set to the name of the attribute that contains the Globalprofile data

An incorrect profile name results if the name parameter is not the first value of the organization name (o).

ProfileData Attribute

This feature allows an administrator to store multiple RADIUS attribute-value pairs within a single LDAP container, removing the need for multiple entries in a LDAP user object.

For example, the values for framed-ip-address, service-type, and framed-protocol can be stored in one attribute called stdDialin. Combining them saves space on the LDAP server.

Make the attribute a string data-type (directory string or string case insensitive). The format for the data stored in this attribute is:

<r|R>;attribute-name;type;value&
  • r or R—Specifies that the attribute may be single or multi-valued.
  • attribute-name—Specifies the name of the attribute that is being added.
  • value&—The value returned with this attribute, terminated with &.

    Note: The type field is ignored; the values are interpreted according to the RADIUS dictionary.

For example:

stdDialin: r; service-type; integer; 1&;r; framed-protocol; integer; 2&; r;
framed-ip-address; string;192.168.2.2&

The Profiledata attribute is retrieved from the LDAP server in the same way that other attributes are retrieved; they might be specified from the [Attributes\] section referenced in the relevant search.

Have the [Response] section of the ldapauth.aut file list each attribute contained in the profiledata attribute.

Configure the [Response] section for stdDialin to operate:

[Response]
service-type=
framed-protocol=
framed-ip-address=

Note: If the ProfileData attribute stores multiple attribute-value pairs and one or more of those attributes appears in the applicable dictionary, then that attribute and its value are returned to the RADIUS client even if the attribute is not enumerated in the [Response] section of the file.

Modifying ldapauth.aut

To modify ldapauth.aut to support the extensions:

  1. Add the following field:
    [Settings]
    UpdateResponse = 1
  2. Add a [GroupedAttributes] section to specify the GlobalProfile or ProfileData attributes, or both.
    [GroupedAttributes]GlobalProfile = GlobalProfileLDAPAttributeProfileData = ProfileDataLDAPAttribute
  3. In the appropriate [Attributes/ name ] section, add the actual LDAP attributes as specified previously.
    [Attributes/name]GlobalProfileLDAPAttributeProfileDataLDAPAttributeany other attributes
  4. In the [Response] section, set %Profile to the GlobalProfile and list any attributes that are contained in the ProfileData attribute:
    [Response]%Profile = GlobalProfileLDAPAttributeradiusattribute1=radiusattribute2=

 

Modified: 2017-03-07