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

Authentication

RADIUS uses different types of messages during user authentication. Table 12 summarizes the conditions under which each type of RADIUS authentication message is issued, and the purpose of any RADIUS attributes the message contains.

Table 12: RADIUS Authentication Messages and Attributes

Message Conditions

Purpose of Message Attributes

When a NAS receives a connection request from a user, the NAS requests authentication by sending an AccessRequest to its RADIUS server.

Identify the user.

Describe the type of connection the user is trying to establish.

When a RADIUS server is able to authenticate a user, it returns a RADIUS Access-Accept to the NAS.

Allow the NAS to complete access negotiations.

Configure connection details such as providing the NAS with an IP address it can assign to the user.

Enforce time limits and other class of service restrictions on the connection.

When a RADIUS server is unable to authenticate a connection request, it returns an Access-Reject to the NAS.

Terminate access negotiations.

Identify the reason for the authorization failure.

If initial authentication conditions are met but additional input is needed from the user, the RADIUS server returns an Access-Challenge to the NAS.

Enable the NAS to prompt the user for more authentication data.

Complete the current AccessRequest, so the NAS can issue a new one.

Authentication Methods

Each time an AccessRequest message reaches the server, an authentication transaction begins. During this transaction, the server attempts to authenticate the request by sequentially trying its configured and enabled authentication methods. The server consults its list of authentication methods to determine which methods to try and in which order to try them.

Native User Authentication

Native user authentication references user accounts stored on the Steel-Belted Radius Carrier server. When trying the native user method, Steel-Belted Radius Carrier searches its database for an entry whose User-Type is Native User, and whose username matches the username in the AccessRequest.

  • If the entry cannot be found, or if it is found and the password is invalid, Steel-Belted Radius Carrier tries the next enabled method in the authentication methods list.
  • If an entry for the user is found but the entry’s check list does not match attributes found in the AccessRequest, Steel-Belted Radius Carrier returns an AccessReject message to the NAS.
  • If the entry is found and its password and check list match perfectly, Steel-Belted Radius Carrier formats an AccessAccept message using the entry’s return list, and returns it to the NAS.

Pass-Through Authentication

Pass-through authentication methods permit Steel-Belted Radius Carrier to begin the authentication by asking another entity to validate the username and password found in the AccessRequest.

Steel-Belted Radius Carrier can pass authentication requests through to a back-end database or a third party Authentication Manager. For example, when using the optional SIM authentication module, you can authenticate users against the credentials in your HLR.

Proxy RADIUS Authentication

Steel-Belted Radius Carrier can convey an AccessRequest to some other RADIUS server, which then (1) attempts to authenticate the connection request according to its own conventions and (2) returns a response to Steel-Belted Radius Carrier. Steel-Belted Radius Carrier then relays this response to the NAS. The set of conventions for relaying packets between cooperating RADIUS servers is known as proxy RADIUS.

External Authentication

External authentication methods enable Steel-Belted Radius Carrier to authenticate users by referring to external SQL or LDAP databases. During external authentication, Steel-Belted Radius Carrier queries the database for authentication data, and uses the results to format a response packet. Steel-Belted Radius Carrier then relays this response to the NAS.

For information about using Steel-Belted Radius Carrier with SQL databases, see Configuring SQL Authentication. For information about using Steel-Belted Radius Carrier with LDAP databases, see Configuring LDAP Authentication.

Directed Authentication

Every authentication request works its way through the same Authentication Methods list until one of the methods succeeds or the end of the list is reached.

This behavior might not be ideal for every account. If you want requests from certain users or accounts to bypass the master Authentication Methods list and use an alternate list, you can do so by employing the directed authentication feature. This feature allows you to map the UserName or DNIS information in an incoming authentication request to a specific list of authentication methods. The list can include any native, pass-through, proxy-as-authentication, or external database authentication method configured on the Steel-Belted Radius Carrier server.

You can also direct authentication towards a particular realm using a technique called attribute mapping. This allows you to check for the presence or absence of a particular attribute in an authentication request, or for an attribute containing a specific value. Attribute mapping can be used with both proxy realms and directed realms.

Authenticate-Only Requests

Steel-Belted Radius Carrier supports requests to authenticate a user where the server performs no other processing. The NAS specifies this type of request by setting the Service-Type field to a value of Authenticate-Only (numeric value 8). The server responds with either an Access-Reject or an Access-Accept (without any attributes).

You can disable this feature (so that attributes are always returned in the response packet) by setting the AuthenticateOnly field in the [Configuration] section of the radius.ini file to 0. For more information about radius.ini, refer to the SBR Carrier Reference Guide.

Configuring the Authentication Sequence

After you configure authentication methods for Steel-Belted Radius Carrier, the Authentication Methods page in Web GUI displays them in the order in which the server tries them. The Authentication Methods page in Web GUI displays both active and inactive authentication methods. During an authentication transaction, the server works down the list of Active Authentication Methods.

You can activate or deactivate methods, or reorder methods in the list, by using the controls in the Authentication Methods page in Web GUI. For information about setting up authentication sequences, see Setting Up Authentication Policies.

Configuring Authentication Methods

Each authentication method in Steel-Belted Radius Carrier performs a different type of processing on information in an incoming Access-Request. Table 13 summarizes what you need to do to configure each authentication method.

Table 13: Authentication Method Configuration

Method

How to Configure

See

Native User

Create native user entries in the Steel-Belted Radius Carrier database.

Setting Up Native Users

UNIX Pass-Through Security

This method assumes that you already have users, groups, and passwords defined in your local security database.

Create user entries in the database of the UNIX server hosting Steel-Belted Radius Carrier. Choose User-types as appropriate.

Administering Users

External SQL Database

This method assumes that you have user records stored in a SQL database. Create a Steel-Belted Radius Carrier .aut file that connects to a SQL database and issues a SELECT query based upon the username and password. Give the .aut file a unique InitializationString value. Stop and restart Steel-Belted Radius Carrier. Subsequently, the SQL authentication method appears in the Authentication Methods page, using the InitializationString value as its name. You can use the Authentication Methods page to enable, disable, and re-order the SQL authentication method.

Configuring SQL Authentication

External LDAP Database

This method assumes that you have user records stored in an LDAP database. Create a Steel-Belted Radius Carrier .aut file that validates the username and password based upon Bind and Search requests to an LDAP database. Give the .aut file a unique InitializationString value. Stop and restart Steel-Belted Radius Carrier. Subsequently, the LDAP authentication method appears in the Authentication Methods page, using the InitializationString value as its name. You can use the Authentication Methods page to enable, disable, and re-order the LDAP authentication method as desired.

Configuring LDAP Authentication

Advanced Options

Steel-Belted Radius Carrier provides the following additional authentication control options:

Account Lockout

Account lockout allows you to disable an account after a configurable number of failed login attempts within a configurable period. For example, if a user enters an incorrect password three times within two minutes, Steel-Belted Radius Carrier can lock out the user’s account temporarily. During the lockout period, the user cannot log in, even with the correct password.

When a user account is locked out, the user must wait until the expiration of the lockout period, or a network administrator can clear the lockout status for the account.

For information about displaying and administering locked accounts, see Using the Locked Accounts List.

Note: Do not enable account lockout and account redirection at the same time. If account lockout and account redirection are both enabled, account lockout is used and account redirection settings are ignored.

Note: Account lockout state is not maintained if Steel-Belted Radius Carrier is restarted. Steel-Belted Radius Carrier enforces lockout locally only, not globally.

Account Redirection

Account redirection allows you to flag an account for special processing after a configurable number of failed login attempts within a configurable period. For example, if a user enters an incorrect password three times within two minutes, Steel-Belted Radius Carrier can accept the user (even with an incorrect password) but limit the user’s access to specific network resources, such as a secure webpage that prompts the user to provide other authentication information. If the user can obtain his or her current password (or can create a new one through such a secure webpage), he or she can then reconnect and log in successfully.

When account redirection is enabled and a user repeatedly enters an incorrect password, Steel-Belted Radius Carrier places the user in redirect state. When a user is in redirect state:

  • If the user does not submit another authentication request within a specified timeout period, the user account is released from redirect state and returned to normal state.
  • If the user submits another authentication request within a specified timeout period, the user is accepted without authentication/authorization processing. The accept message for the user includes the attributes and values specified in a redirection profile, and the user is placed into Access-Pending state. The attributes and values in the Access-Accept message are used by an external customer process, which may prompt the user to enter alternate authentication information to receive a password by email.

    When a user is in Accept-Pending state, the next authentication request received determines whether the user is accepted or locked out:

    • If the user enters the appropriate authentication information, the user is returned to normal state and Steel-Belted Radius Carrier generates an informational SNMP trap message.
    • If the user does not enter the appropriate authentication information, Steel-Belted Radius Carrier issues an Accept-Reject message, locks the user out of the network for a configurable lockout period, and generates an informational SNMP trap message. During this lockout period, authentication requests for the user are automatically rejected, even if the user enters the correct password.

Optionally, you can identify RADIUS clients that you want to exclude from account redirection processing. Authentication requests from excluded RADIUS clients are processed normally, without use of redirection or account state changes.

Note: Do not enable account lockout and account redirection at the same time. If account lockout and account redirection are both enabled, account lockout is used and account redirection settings are ignored.

Note: Account redirection state is not maintained if SBR Carrier is restarted.

Blacklisting

Blacklisting allows you to automatically reject authentication requests that contain certain values. You configure blacklisting by setting up a profile that identifies check list attributes that should trigger an automatic authentication failure, and then modifying the blacklist.ini file to use that profile. For example, you could set up a profile to block users calling from a specific area code by configuring a Calling-Station-Id check list attribute in the blacklist profile. You can use * and ? wildcards in the blacklist profile.

Note: You can blacklist individual users by setting their Concurrency Limit = 0.

Blacklisting functions on all local authentication requests and can be configured to include proxy-RADIUS requests.

For information about setting up profiles, see Administering Profiles. For information about configuring the blacklist.ini file, refer to the SBR Carrier Reference Guide.

Allowed Access Hours

Steel-Belted Radius Carrier provides a vendor-specific attribute called Funk-Allowed-Access-Hours. This attribute can be placed in the check list for a user or profile entry to control the times during which a user can be allowed access.

Note: See Allowed Access Hours for the format of this value (and how to enter it into a user or profile record).

During authentication, the server processes the current time, the Funk-Allowed-Access-Hours value from the check list, and the Session-Timeout value from the return list.

  • If a Funk-Allowed-Access-Hours attribute is present in the check list, and if the present time does not fall within a valid time period according to Funk-Allowed-Access-Hours, the server rejects the session.
  • If a Funk-Allowed-Access-Hours attribute is present in the check list, and if the current time falls within a valid time range according to Funk-Allowed-Access-Hours, the server accepts the session and calculates a session end time as follows:
    • If a Session-Timeout attribute exists in the user’s return list, Steel-Belted Radius Carrier adds this number of seconds to the present time to calculate a proposed session end time. If the proposed session end time falls within the current time period (as defined by Funk-Allowed-Access-Hours), then Steel-Belted Radius Carrier returns the proposed session end time to the NAS in the Session-Timeout attribute.

      If the proposed end time occurs after the end of the current time period, then Steel-Belted Radius Carrier calculates the number of seconds between the present time and the end of the current time period (as defined by Funk-Allowed-Access-Hours, and returns this value to the NAS in the Session-Timeout attribute.

  • If a Funk-Allowed-Access-Hours attribute is present in the check list but a Session-Timeout attribute does not exist in the user’s return list, Steel-Belted Radius Carrier computes a value for Session-Timeout based on the number of seconds between the present time and the end of the current time period. Steel-Belted Radius Carrier returns this value to the NAS in the Session-Timeout attribute.
  • If Funk-Allowed-Access-Hours is not present in the check list, the server returns the Session-Timeout value from the user’s return list.
  • If neither attribute is present, no Session-Timeout value is returned in the Access-Accept message, and the session is limited by the StaleSessionTimeoutSecs setting in the radius.ini file.

Two-Factor Authentication

Extensible Authentication Protocol-Tunneled Transport Layer Security (EAP-TTLS) provides for certificate-based mutual authentication between a client and a network through an encrypted tunnel. A typical implementation of EAP-TTLS uses certificates on authentication servers to create a network-to-user encryption tunnel, and then uses EAP inside the TLS tunnel for user-to-network authentication.

An enhanced version of EAP-TTLS uses certificates on the client side to provide two-factor authentication: the end user must have both a private key for a valid certificate and the password to an active account to obtain network access.

When client certificate support in EAP-TTLS is enabled on the server, you must provide a list of trusted root certificates from which offered client certificates must derive. These certificates must be provided in DER-encoded form and must be placed in the root subdirectory of the server directory.

Optionally, you can enable certificate revocation list (CRL) checking as part of the EAP-TTLS authentication process. CRL checking verifies that an unexpired certificate has not been revoked by its issuing Certificate Authority (CA) for any reason, such as a suspected security breach. Enabling CRL checking means that, every time the client requests a connection, Steel-Belted Radius Carrier checks the CRL to confirm that the client certificate has not been revoked. This improves security but increases processing overhead.

If client certificate support is not enabled in EAP-TTLS, any trusted root certificates and CRL checking options are ignored.

Modified: 2018-01-11