Section 7. Check and reply items

7.1. Check items

Check items is the name given to the RADIUS attributes in the Access-Request that is checked before the user is granted an Access-Accept. All the check items for a user are checked. If any check item does not match the access is denied. You can have multiple check items for the same attribute, and the check only passes if all check items pass.

Most check items permit exact match, alternation, or regular expression matches. For more information about using them, see Section 7.1.50. Any other attribute defined in your dictionary.

These check items can also be used in the request selection expression in a <Handler> clause. For more information, see Section 3.31. <Handler attribute=value,attribute=value, ....>.

Usually this is used to limit the conditions under which a user is permitted to log on to your system. The most common case is to require a User-Password or Encrypted-Password, and you may also want to limit access via certain NASs, or at certain times. You can use any RADIUS attribute as a check item, and there are also some special attributes that are handled within Radiator in order to provide extra ways of controlling user access.

Since different brands and models of NAS implement different subsets of the RADIUS specification, it is not possible here to describe all the things you can configure in your NAS with reply items. For more information, see your NAS vendor's documentation.

7.1.1. User-Password, Password

A (usually) plaintext password. Passes only if the given password matches that sent in the Access-Request. If CHAP-Password attribute appears in the request then CHAP authentication will be attempted. If MS-CHAP-Challenge and MS-CHAP-Response attributes appears in the request then MSCHAP authentication will be attempted. CHAP and MSCHAP authentication is only supported with plaintext or Rcrypt encrypted passwords. You may user either Password or User-Password as the attribute name, the effect is the same.

Radiator also supports HTTP Digest password authentication with plaintext passwords. Digest authentication is supported by some web servers (e.g. Apache) and some web proxies (e.g. squid).

User-Password can be in a number of formats, not necessarily in plaintext. Radiator looks for some special format passwords and interprets them as special encryptions. The following formats are supported, along with example versions of the password "fred".

Standard Unix crypt.This format is also compatible with Unix password encryption as used in Netscape LDAP server. Passwords starting with a leading {crypt} or {CRYPT} are interpreted as a standard Unix crypt password, using the native version of crypt() on your platform.
```
User-Password = {crypt}1xMKc0GIVUNbE
```
Linux MD5 password hashing. Passwords starting with "$1$" are interpreted as hashed with Linux MD5 password hashing.
```
User-Password = $1$cTpht$Obu9PLSMst1TDou.mN5bk0
```
Linux SHA256 and SHA512 crypt. Passwords starting with “$5$” or “$6$” are interpreted as hashed with Linux SHA256 or SHA512 password hashing, respectively.
```
User-Password =
      $5$cTpht$i4ihNcS7lC1orrwWu/IfHrhxdDIkjBu095szYO4AucD
User-Password = $6$cTpht$Z2pSYxleRWK8IrsynFzHcrnPlpUhA7N9AM/
8O8se885W45WHyJ2K6bXsygHI46.cjqgl2hucmKtX1shWTL1zU1
```
Linux Blowfish crypt. Passwords starting with $2a$, $2x$ or $2y$ are interpreted as hashed with Linux Blowfish password hashing. Support for these algorithms depends on the system crypt() implementation support. See the system documentation on crypt() about caveats with these hashes.
Netscape SHA password hashing as used in Netscape LDAP server. Passwords starting with {SHA}, {SSHA}, {sha}, or {ssha} are interpreted as being hashed with Netscape SHA hashing. (Requires Digest-SHA version 5.0 or later, and also Mime::Base64 from MIME-Base64-2.11.tar.gz).
```
User-Password = {SHA}MQF6ciZl5K/OWGlQ9ClEptMx2r8=
User-Password = {SSHA}k1qAjger6rE9fhCrig+QPZ/HTrJhYWE=
```

SHA-2 hashes SHA 256, 384 and 512. These are similar to {SHA} and {SSHA} above. See goodies/sha.pl and goodies/ssha.pl for a utility to generate hashes.

User-Password =
      {SHA256}0M/C5TGbgs3HGjOHPoJsk9fuETY/iskcT6Oiz80ihuU=
User-Password =
      {SSHA256}abN9UTbhi3evQvdk7uYNML+UMZn8/BnWdxJUApQ0NzGkLQTd
User-Password ={SHA384}QoAkviNtBCtNyjN+yAkEEL6ChjtUVFKDTKHrIlx/
YqIHrDG7Tx2eJhbBPKAX0mo5
User-Password =
{SSHA384}DLZqetLxS6JPok1QcugKji0U8lxt6Zq7SYoGoK5JRVeeOqCuGHwxXf
1ZYGLg8pXqgms3jw==
User-Password = {SHA512}NWbDPDXFm6JYe6wqgVJs8z6gkoER7Z4WFqpD/
P+8P10H4FjICJjNKGCVt1h61e3TUR/ZQ/19d0Ox3tckJiAm8w==
User-Password =
{SSHA512}u+34y2JyCKoVRty0ADABlzhETpPv1HnShr2427qjsn7tgSoOaP8cHB
J95GT28ENlA7vySsjBVOMiuPqk2qgPvJOV4IM=

MD5 Hex digest. Passwords starting with {MD5} or {md5}. Note that all hex digits are required to be lower case.
```
User-Password = "{MD5}570a90bfbf8c7eab5dc5d4e26832d5b1"
```
MD5 with Mime, as used in some other LDAP servers.
```
User-Password = "{MD5}qP0OV/oViFka8YbFMWEWeg=="
```
Rcrypt reversibly encrypted passwords. This reversible encryption format depends on a secret key. Radiator includes a reusable code module (Radius::Rcrypt) with encrypt and decrypt routines that you can call from third party programs. Rcrypt passwords require that you define the RcryptKey attribute in the AuthBy clause. The leading string can be {rcrypt} or {RCRYPT}.
```
User-Password = "{rcrypt}nYXkJKLrxm/e3RfU0aT7w4al"
```
A predigested hex MD5 signature of the concatenation of the user name, a realm and the correct password. This is only valid for Digest and SIP authentication. In this example, the user name is "mikem", the realm is "open.com.au" and the correct password is "fred".
```
User-Password = \
      "{digest-md5-hex}884663db69c36190cf4c05c068a1a303"
```
MySQL hashed password, as produced by the MySQL password() function.
```
User-Password = "{mysql}0569ef75321b8fed"
```
MD5 hashed password in the format used by old Netscape Mail Servers.
```
{NS-MTAMD5}
b6b49e37d494a09bfde663033274bc83cd1bf318fa32c5866166a7edcb1
e1c87
```

A Django style password. For more information, see User authentication in Django

User-Password =\
      "sha1$a1976$065f52b49153328da76e13c2b462b860a70eb78b"
User-Password = "md5$a1976$e67d1ca20e9c28321b86e34076cc48ab"

DEC Hashed Password as used by DEC VMS and maybe others. Contains the algorithm type number, a salt and the hashed password, separated by vertical bars. The valid algorithm numbers are 1 (PURDY), 2 (PURDY_V) or 3 (PURDY_S) The hashed password depends on the user name as well as the algorithm and salt, so the hashed passwords are not portable between users. In VMS, user names are by convention all uppercase, and passwords are case sensitive. In this example for user name MIKEM, the algorithm type number is 3 (PURDY_S), the salt is 1234, and the hashed password (fred) is 85ad61e72a41dec4.
```
User-Password = {dechpwd}3|1234|85ad61e72a41dec4
```
An NT Hashed Password, as used by Microsoft, Samba and others. This format is compatible with Samba SMB passwords (either in a flat file or in LDAP). Such password hashes can be generated with the Samba mkntpwd program.
```
User-Password = {nthash}DCB8E94AC7D0AADC8A81D9C895ACE5F4
```
A password encrypted with the Microsoft SQL pwdencrypt() function. Passwords encrypted with pwdencrypt() are case insensitive. Requires Digest::SHA module. Note that the encrypted password produced by pwdencrypt() is a 46 octet binary string. Radiator recognises the encrypted password as either 46 octets of binary or 92 octets of ASCII Hex characters. You can use the MS SQL ‘+’ string concatenation operator to prepend the ‘{mssql}’ to the encrypted password, e.g.
```
select '{mssql}' + password, ..... from .....
User-Password =
{mssql}01003A54FC73501798169BEC84C05CA0D2FBB70009C2556313DA7959
C1A798ECD34514694A13D29ED57BE9CBE5DA
```
A flagged plaintext password.
```
User-Password = {clear}fred
```
A PBKDF2 (Password-Based Key Derivation Function 2) derived password. Radiator currently supports password derivation with Pseudo Random Function (PRF) HMAC-SHA1 and the following password format (PRF:rounds:salt:hash). See goodies/pbkdf2.pl for the format details. Requires MIME::Base64.
```
User-Password = {PBKDF2}HMACSHA1:
9000:h9Pwh4tcu0w=:iN9vitCZ1mqBKEu21dlc0RW2tlc=
```
Custom format for CheckPasswordHook. For more information, see Section 3.32.23. CheckPasswordHook.
```
User-Password = {OSC-pw-hook}.......
```
Plaintext. Any other format is interpreted as a plain text password.
```
User-Password = fred
User-Password = "password with spaces"
```

7.1.2. Encrypted-Password

An encrypted password. Passes only if the password sent in the Access-Request matches the given encrypted password. Most types of encrypted password only support PAP, not CHAP, MSCHAP or MSCHAPV2 authentication. Passwords encrypted with NT Hashed passwords can support PAP, MSCHAP and MSCHAPV2 authentication.

Encrypted-Password understands a number of encrypted formats: SHA, MD5, MD5 Mime, DEC Hashed passwords, NT Hashed passwords and standard Unix crypt. All the following match the plaintext password "fred":

Encrypted-Password = "{SHA}k1qAjger6rE9fhCrig+QPZ/HTrJhYWE="
Encrypted-Password = "{crypt}1xMKc0GIVUNbE"
# This next one is also crypt:
Encrypted-Password = "1xMKc0GIVUNbE"
Encrypted-Password = "$1$cTpht$Obu9PLSMst1TDou.mN5bk0"
Encrypted-Password = "1xMKc0GIVUNbE"
Encrypted-Password = "{MD5}qP0OV/oViFka8YbFMWEWeg=="
Encrypted-Password = "{MD5}570a90bfbf8c7eab5dc5d4e26832d5b1"
Encrypted-Password = "{dechpwd}3|1234|85ad61e72a41dec4"
Encrypted-Password = "{nthash}DCB8E94AC7D0AADC8A81D9C895ACE5F4"
# This next one is also nthash:
Encrypted-Password = DCB8E94AC7D0AADC8A81D9C895ACE5F4
Encrypted-Password =
{mssql}01003A54FC73501798169BEC84C05CA0D2FBB70009C2556313DA7959
C1A798ECD34514694A13D29ED57BE9CBE5DA

If there is no indication of the encryption type in an Encrypted-Password, Radiator will assume it is a Unix crypt(3) password if it is 13 or 20 bytes long (20 bytes is the BSD/ OS DES extended format for crypt(3)), a binary NT hashed password if it is 16 bytes long and a hex encoded NT hashed password if it is 32 bytes long.

# Unix Crypt:
Encrypted-Password = 1xMKc0GIVUNbE
# Hex encoded NT Hashed password
Encrypted-Password = DCB8E94AC7D0AADC8A81D9C895ACE5F4

When Radiator authenticates an MSCHAP or MSCHAP2 request, the default encrypted password format is taken to be an MD4 hashed password, in the standard Windows NT hashed password format (either hex encoded or binary).

7.1.3. Realm

Checks that the realm in the login name matches. The realm is the part following the @ in the user name. You can use either exact match, alternation, or a regular expression.

Realm = open.com.au

7.1.4. ExistsInRequest

Checks for the presence of an attribute in a request. You can use either exact match or alternation. Attribute value does not matter; empty attributes match too. This type of check item is mostly useful in Handlers

<Handler ExistsInRequest = EAP-Message>
    # All EAP messages are handled here
</Handler>

<Handler ExistsInRequest = OSC-Rate-Limit-Day|OSC-Rate-Limit-Night>
    # Handler is selected when one or the both are present
</Handler>

7.1.5. Expiration, ValidTo

Specifies the account expiry date with an optional time component. Passes only if the current local date and time (according to the clock on the host where Radiator is running) is prior to the given date and time. If no time is given, it assumes midnight at the beginning of the date given. The check items Expiration and ValidTo have identical meaning. The following formats are supported:

Mmm dd yy(yy) (hh:mm:ss)
Mmm dd, yy(yy) (hh:mm:ss) Note the optional comma.
dd Mmm yy(yy) (hh:mm:ss)
yyyy-mm-dd (hh:mm:ss)
dd/mm/yy(yy) (hh:mm:ss)
dd.mm.yy (hh:mm:ss)

Some valid examples are:

Dec 30 1998
Dec 30, 2000
30 Dec 2000
Dec 30, 2000 11:30:00
30 Dec, 2000 09:32:00
2002-02-02 23:00:00
30/12/2002 01:00:00
30.12.2002

All the following Expiration check items are equivalent.

Expiration = Jan 02 1999 23:30:00
Expiration = 1999-01-02 23:30:00
Expiration = 02/01/99 23:30:00
# Unix epoch seconds (seconds since midnight, Jan 1 1970):
Expiration = 915280200

Tip

You can use Session-Timeout="until ValidTo" or Session-Timeout="until Expiration" as a reply item, which will set the session timeout to be the number of seconds until the Expiration date and time. For more information, see Section 7.2.8. Session-Timeout.

7.1.6. ValidFrom

Specifies a starting validity date. The same date formats as ValidTo are supported.

ValidFrom Jan 02 1999 23:30:00

7.1.7. Auth-Type

Auth-Type triggers special behaviour for authenticating the user. The possible values are:

Reject. Any access request will always be rejected. This is useful for temporarily disabling logins for a given user.
Accept. Forces acceptance, regardless of any following check items. Use with caution.
Reject:message. Same as for Reject, except that the message (which can be any string) will be sent back to the user in a Reply-Message (provided the enclosing Realm or Handler has RejectHasReason set). This may be useful for telling your user why their login has been rejected.
Ignore. Any access request will always be ignored (i.e. no reply will be sent back to the NAS). This is sometimes useful for triggering special behaviour in cascaded AuthBy clauses.
Anything else. Any other word specifies an Identifier in an AuthBy clause which will used to authenticate the user. The name is matched with the name specified in the Identifier parameter in an AuthBy clause. You can name any other type of AuthBy module, be it SQL, RADIUS, UNIX etc. Specifying Auth-Type for a user causes the authentication to be cascaded to another authentication module. You can cascade authentications like this to any arbitrary depth.

The Auth-Type check item is most useful when you want to have check items and/or reply items, but also want to authenticate with native Unix or NT passwords.

Checks all users using the authentication method that has the identifier System:

DEFAULT Auth-Type = System

If you want to temporarily disable logins for a single user:

username Auth-Type = Reject

This one rejects the user and tells them why:

username Auth-Type = "Reject:you did not pay your bill"

This will first authenticate with the Identifier System, and if they are also in the group "staticip", they will continue to be authenticated with the AuthBy clause that has the Identifier "statics":

DEFAULT Auth-Type=System, Group=staticip, Auth-Type=statics

7.1.8. Group

The meaning of Group depends on the type of module that is doing the authentication. For UNIX and SYSTEM, it means whether the user is a member of the group as defined by the group file (usually /etc/group/).

<AuthBy
                     SYSTEM>

supports both numeric and symbolic group names.

For <AuthBy SQL>, it runs and uses the result of the GroupMembershipQuery if defined. For more information, see Section 3.41.19. GroupMembershipQuery.

For <AuthBy LDAP2>, it requires GroupSearchFilter and related options to be defined. For more information, see Section 3.47.15. GroupSearchFilter.

For other AuthBy modules, it has no meaning, and always causes a rejection.

Group = wheel

7.1.9. GroupList

This works similarly to Group, but succeeds if the user is in any of the space separated group names.

GroupList = "wheel dialupusers nocstaff"

7.1.10. Group-Authorization

When you need Group-based authorisation for a user, this parameter defines the AuthBy that does the checking.

For usage examples, see goodies/authorize-group1.cfg and goodies/authorize-group2.cfg.

7.1.11. Block-Logon-From

Specifies a time in the format 9:00 am or 15:22. Attempts to authenticate after this time of day will fail. If Block-Logon-To is also specified for a later time of day, access is blocked between those times. The time of day that is used is the local time on the host where Radiator is running. Block-Logon-From is superseded by the Time check item and will not be supported in the future. For more information, see Section 7.1.15. Time.

7.1.12. Block-Logon-To

Specifies a time in the format 9:00 am or 15:22. Attempts to authenticate before this time of day will fail. If Block-Logon-From is also specified for an earlier time of day, access is blocked between those times. The time of day that is used is the local time on the host where Radiator is running. Block-Logon-From is superseded by the Time check item and will not be supported in the future. For more information, see Section 7.1.15. Time.

Block-Logon-From = 9:00 am,
Block-Logon-To = 5.00 pm

7.1.13. Prefix

This check item checks for the presence of a certain prefix in the user name. If it is not present the check item will fail. If it is present, it will be removed from the user name and accepted. This is most useful in DEFAULT items to handle different variations of the same users name, but with different reply attributes.

In this example, there might be a user mikem in the System authentication method. These user entries will allow Pmikem to log in as a PPP user, and Smikem to login as a Slip user:

DEFAULT     Prefix = P, Auth-Type = System
            Service-Type = Framed-User,
            Framed-Protocol = PPP,
            Framed-IP-Address = 255.255.255.254,
            Framed-MTU = 1500
DEFAULT     Prefix = S, Auth-Type = System
            Service-Type = Framed-User,
            Framed-Protocol = SLIP,
            Framed-IP-Address = 255.255.255.254,
            Framed-Compression = None

Tip

Prefix should appear before any Auth-Type check items.

7.1.14. Suffix

This check item is very similar to Prefix above, but checks for the presence of a certain suffix in the user name. If it is not present the check item will fail. If it is present, it will be removed from the user name and accepted. This is most useful in DEFAULT items to handle different variations of the same users name, but with different reply attributes.

In this example, there might be a user mikem in the System authentication method. These user entries will allow mikem.ppp to log in as a PPP user, and mikem.slip to login as a Slip user:

DEFAULT     Suffix = .ppp, Auth-Type = System
            Service-Type = Framed-User,
            Framed-Protocol = PPP,
            Framed-IP-Address = 255.255.255.254,
            Framed-MTU = 1500
DEFAULT     Suffix = .slip, Auth-Type = System
            Service-Type = Framed-User,
            Framed-Protocol = SLIP,
            Framed-IP-Address = 255.255.255.254,
            Framed-Compression = None

Tip

Suffix should appear before any Auth-Type check items.

7.1.15. Time

This check item allows you to specify which times of day and which days of the week the user is allowed to log on. The Time check is preferred to the Block-Logon-From and Block-Logon-To check items, which will not be supported in the future.

The format consists of day specifiers followed by hours intervals. Multiple day specifications are permitted with multiple values separated by commas (if you use commas, the entire check item must be enclosed with double quotes ("). Authentication will be permitted if the current local time on the Radiator server is within at least one of the time intervals specified.

Day specifiers are Mo, Tu, We, Th, Fr, Sa, Su for the days of the week. Wk means Mo- Fr and Al means any day. Hours intervals are specified as HHMM-HHMM. Typical examples are:

Time = "MoTuWe0800-1400,Wk2200-0400" 
Time = "Al1800-0600,Wk1000-1330"

Tip

You can use Session-Timeout="until Time" as a reply item, which will set the session timeout to be the number of seconds until the end of the valid time period. For more information, see Section 7.2.8. Session-Timeout.

7.1.16. Simultaneous-Use

Specifies the maximum number of simultaneous sessions permitted for this user. Radiator keeps track of the number of current sessions for a user by counting the Accounting Start and Stop requests received for that user. The value of this check item is either an integer or the name of a file that contains an integer. You can use any of the special formatting characters in the file name. The file will be reread for each authentication: it is not cached, so using a file name can have a slight impact on performance.

Tip

You can set the maximum number of simultaneous sessions for all the users in a Realm or Handler by using the Handler MaxSessions parameter. In this case, the smaller of MaxSessions and the users Simultaneous-Use will apply. For more information about setting default limit within an AuthBy, see Section 3.32.14. DefaultSimultaneousUse.

Simultaneous-Use = 1

7.1.17. Connect-Rate

Specifies the maximum connection speed that this user is permitted to use. Uses the Connect-Info attribute in the request to determine the speed the user is requesting. If Connect-Info is not present in the request, looks for USR-Connect-Speed. Note: not all NASs send Connect-Info or USR-Connect-Speed in Access Requests. Check with your NAS vendor's documentation.

Connect-Rate = 28800

7.1.18. NAS-Address-Port-List

Specifies the name of a file that contains a list of permitted NAS address/port combinations. For more information about port list file format, see Section 9.7. Portlist file. The filename can contain any of the special file name characters. The contents of the file are read at most once, and the port list is cached inside Radiator. If the user is not attempting to log in on one of the permitted address/port combinations, they will be rejected.

NAS-Address-Port-List %D/portlist

Tip

You can limit users to a particular NAS, irrespective of the port by using the NASIP- Address check item, possibly with a regular expression.

Tip

You can limit users to a particular port or set of ports on all NASs by using the NAS-Port check item, possibly with a regular expression.

7.1.19. Client-Id

Specifies the name of a Client that the request must come from. You can use an exact, alternation or regular expression match. The match is against the Client name (i.e. the word following Client in a <Client xxxxxx> clause). Note that it is legal to use Client- Id=DEFAULT to match requests that arrive through a <Client DEFAULT> clause.

<Client nas1.open.com.au>
      ....
</Client>
<Client nas2.open.com.au>
      ....
</Client>
<Client DEFAULT>
      ....
</Client>

# This user can only log in through nas2.open.com.au:
username1 Password=fred,Client-Id=nas2.open.com.au
# And this one only through NASs other than nas1 and nas2
username2 Password=jim,Client-Id=DEFAULT

Tip

When you use the Client-Id check item, it matches against the name or address in the <Client xxxxxx> line, but not against any of the values listed in IdenticalClients.

7.1.20. Client-Identifier

Specifies the Identifier of a Client that the request must come from. You can use an exact, alternation or regular expression match. The match is against the Client Identifier (i.e. the value of the Identifier parameter in a <Client xxxxxx> clause).

# Several NASs at pop1
<Client nas1.open.com.au>
      IdenticalClients 1.1.1.1,1.1.1.2,1.1.1.3
      Identifier pop1
      ...
</Client>
# Several NASs at pop2
<Client nas2.open.com.au>
      IdenticalClients 2.1.1.1,2.1.1.2,2.1.1.3
      Identifier pop2
      ....
</Client>

# This user can only log in at NASs in pop1
username1 Password=fred,Client-Identifier=pop1
# And this one only through NASs in pop2
username2 Password=jim,Client-Identifier=pop2

7.1.21. NasType

Specifies that the request must come from a Client with the specified NasType. You can use an exact, alternation or regular expression match.

<Client xxx>
      NasType Livingston
      ....
</Client>
<Client yyy>
      NasType Ascend
      ....
</Client>

# This is can only log in through xxx, since it has a NasType
# of Livingston
username Password=fred,NasType=Livingston

7.1.22. Request-Type

Specifies that the type of the request must match the name given. You can use an exact, alternation or regular expression match. Typical values of request types are:

Access-Request
Accounting-Request

Status-Server is handled differently; it's not available as a Request-Type check item. This type of check item is mostly useful in Handlers for selecting special handling for particular request types:

<Handler Request-Type=Access-Request>
      # Accounting wont be handled here, only access requests
</Handler>

7.1.23. MS-Login-Hours

Specifies a map of permitted login hours per day. The value is an array of bits, one per hour starting at 0000 Sun UTC, 24 bits per day, 7 days. It is not an ASCII array, but an array of binary bytes. The format is exactly compatible with the LoginHours user attribute in Microsoft Active Directory, and can therefore be used when accessing Active Directory via LDAP:

<AuthBy LDAP2>
      Host uniform
      AuthDN cn=Administrator,cn=Users,dc=open,dc=com,dc=au
      AuthPasswordadmin
      BaseDN ou=csx users,dc=open,dc=com,dc=au
      ServerChecksPassword
      UsernameAttr sAMAccountName
      AuthAttrDef logonHours,MS-Login-Hours,check
</AuthBy>

7.1.24. Tagged Tunnel attributes and other tagged attributes

Radiator supports the IETF RFC 2868 standard tunnel attributes, and also permits you to specify tagged tunnel attributes. Tags are a method of grouping attributes in the same packet which refer to the same tunnel. A tag is an integer from 1 to 31 inclusive. In Radiator you can specify a tag for a tunnel attribute by prefixing it with the tag number and a colon. For example, here are 3 tunnel reply attributes, all with a tag of 1:

Tunnel-Type=1:L2F,
Tunnel-Client-Endpoint=1:xyz,
Tunnel-Password=1:1234

Note

If a tag and colon are not specified, the tag is assumed to be 0. A tag with value 0 in reply attributes may confuse some clients. We recommend using a non-0 value for reply attributes.

Radiator reply attributes that support tags are:

Tunnel-Type
Tunnel-Medium-Type
Tunnel-Client-Endpoint
Tunnel-Server-Endpoint
Acct-Tunnel-Connection (also called Tunnel-ID)
Tunnel-Password
Tunnel-Private-Group-ID
Tunnel-Assignment-ID
Tunnel-Preference
Tunnel-Client-Auth-ID
Tunnel-Server-Auth-ID

7.1.25. EAPType

If the request is an EAP request, this check item matches the EAP type number. Available EAPType numbers include 4 (MD5-Challenge), 13 (TLS) and 26 (MSCHAP-V2). Not useful for tunnelling EAP types, such as TTLS or PEAP.

7.1.26. EAPTypeName

If the request is an EAP request, this check item matches the EAP type name. Available EAPType numbers include MD5, TLS and MSCHAP-V2. Not useful for tunnelling EAP types, such as TTLS or PEAP.

7.1.27. TunnelledByTTLS

Specifies that the current request was tunnelled by EAP-TTLS.

7.1.28. TunnelledByPEAP

Specifies that the current request was tunnelled by PEAP.

7.1.29. TunnelledByFAST

Specifies that the current request was tunnelled by EAP-FAST.

7.1.30. RecvFromAddress

Specifies the IP address of the RADIUS, Radsec, or TACACS+ client the request was received from. IPv4 and IPv6 addresses are supported. You can use an exact, alternation, or regular expression match.

RecvFromAddress=203.63.154.29
RecvFromAddress=::1

Tip

This can be useful in Handler clauses to provide special handling of requests received from a specific client:

<Handler RecvFromAddress=203.63.154.29>
      ....
<Handler>

7.1.31. RecvFromName

Specifies the DNS name of the RADIUS, Radsec, or TACACS+ client the request was received from. IPv4 and IPv6 addresses are supported. You can use an exact, alternation, or regular expression match.

# Exact match
RecvFromName=radserver.open.com.au
# Regular expression:
RecvFromName=/.*\.open\.com\.au/

Tip

This can be useful in Handler clauses to provide special handling of requests received from a specific client:

<Handler RecvFromName=radsec.open.com.au>
      ....
<Handler>

CAUTION

This does a reverse name lookup on the address and depending on your environment this may take a number of seconds to resolve.

7.1.32. RecvName

This parameter specifies the DNS name of the RADIUS, Radsec, or TACACS+ client that receives the request. It supports both IPv4 and IPv6 addresses. You can use an exact, alternation, or regular expression match. Here are examples of using different matches:

# Exact match
RecvName=radserver.open.com.au

# Regular expression:
RecvName=/.*\.open\.com\.au

Tip

In Handler clauses, it can be useful to provide special handling of requests received by a local interface with a certain name:

<Handler RecvName=radsec.open.com.au>
      ....
<Handler>

CAUTION

This does a reverse name lookup on the address and depending on your environment this may take a number of seconds to resolve.

7.1.33. RecvAddress

This parameter specifies the IP address of the RADIUS, Radsec, or TACACS+ client that receives the request. It supports both IPv4 and IPv6 addresses. You can use an exact, alternation, or regular expression match. Here are examples of using different matches:

RecvAddress=203.63.154.29
RecvAddress=::1

Tip

In Handler clauses, it can be useful to provide special handling of requests received by a specific local address:

<Handler RecvAddress=203.63.154.29>
      ....
<Handler>

7.1.34. RecvPort

This parameter specifies the port number of the RADIUS, Radsec, or TACACS+ client that receives the request. It supports both IPv4 and IPv6. You can use an exact, alternation, or regular expression match. Here are examples of using different matches:

RecvPort=1812
RecvPort=/164./

Tip

In Handler clauses, it can be useful to provide special handling of requests received by a specific port:

AuthPort 1645,1812
<Handler RecvPort=1812>
      ....
<Handler>

7.1.35. Max-All-Session

Compares the total of all session times for the user against the given number. If it is exceeded, the user will be rejected. Otherwise, the time left will be available for use with Session-Timeout = until ValidTo to limit the remaining time for the user. Supported with AuthBy SQL when AcctTotalQuery is defined.

7.1.36. Max-Hourly-Session

Compares the total of all session times for the user from the beginning of the current hour against the given number. If it is exceeded, the user will be rejected. Otherwise, the time left will be available for use with ‘Session-Timeout = until ValidTo’ to limit the remaining time for the user. Supported with AuthBy SQL when AcctTotalQuery is defined.

7.1.37. Max-Daily-Session

Compares the total of all session times for the user from the beginning of the current day against the given number. If it is exceeded, the user will be rejected. Otherwise, the time left will be available for use with ‘Session-Timeout = until ValidTo’ to limit the remaining time for the user. Supported with AuthBy SQL when AcctTotalQuery is defined.

7.1.38. Max-Monthly-Session

Compares the total of all session times for the user from the beginning of the current month against the given number. If it is exceeded, the user will be rejected. Otherwise, the time left will be available for use with ‘Session-Timeout = until ValidTo’ to limit the remaining time for the user. Supported with AuthBy SQL when AcctTotalQuery is defined.

7.1.39. Max-All-Octets

Compares the total of all traffic octets for the user against the given number. If it is exceeded, the user will be rejected. Supported with AuthBy SQL when AcctTotalOctetsQuery is defined.

7.1.40. Max-All-Gigawords

Compares the total of all traffic for the user in GigaWords against the given number. If it is exceeded, the user will be rejected. Supported with AuthBy SQL when AcctTotalGigawordsQuery is defined.

7.1.41. Max-Hourly-Octets

Compares the total of all traffic octets for the user from the beginning of the current hour against the given number. If it is exceeded, the user will be rejected. Supported with AuthBy SQL when AcctTotalOctetsSinceQuery is defined.

7.1.42. Max-Hourly-Gigawords

Compares the total of all traffic GigaWords for the user from the beginning of the current hour against the given number. If it is exceeded, the user will be rejected. Supported with AuthBy SQL when AcctTotalGigawordsSinceQuery is defined.

7.1.43. Max-Daily-Octets

Compares the total of all traffic octets for the user from the beginning of the current day against the given number. If it is exceeded, the user will be rejected. Supported with AuthBy SQL when AcctTotalOctetsSinceQuery is defined.

7.1.44. Max-Daily-Gigawords

Compares the total of all traffic GigaWords for the user from the beginning of the current day against the given number. If it is exceeded, the user will be rejected. Supported with AuthBy SQL when AcctTotalGigawordsSinceQuery is defined.

7.1.45. Max-Monthly-Octets

Compares the total of all traffic octets for the user from the beginning of the current month against the given number. If it is exceeded, the user will be rejected. Supported with AuthBy SQL when AcctTotalOctetsSinceQuery is defined.

7.1.46. Max-Monthly-Gigawords

Compares the total of all traffic GigaWords for the user from the beginning of the current month against the given number. If it is exceeded, the user will be rejected. Supported with AuthBy SQL when AcctTotalGigawordsSinceQuery is defined.

7.1.47. Variable names prefixed with GlobalVar

The attribute to be compared is taken from a GlobalVar. GlobalVar variables can be set from the command line, or with the DefineFormattedGlobalVar parameter. This can be useful for activating different sets of users in multiple instances of Radiator.

# In the config file:
DefineFormattedGlobalVar system mysystem

# in a users file:
username Password=fred,GlobalVar:system=mysystem

7.1.48. Attributes prefixed with Reply

You can specify a check item that checks an attribute in the currently constructed reply (instead of the incoming request) by prefixing it with “Reply:”. This can be a convenient way to set up user profiles or similar.

# This will set up one of 2 different user profiles, depending
# on the value of the pseudo-attribute Profile, which was set in 
# and earlier AuthBy:
DEFAULT     Reply:Profile=premium
            Session-Timeout=1000000
DEFAULT     Reply:Profile=cheap
            Session-Timeout=1000

7.1.49. Attributes prefixed with DiaRequest

You can specify a check item that checks a Diameter attribute in an incoming Diameter request. This can be useful for choosing a Handler based on Diameter attributes, for example:

<Handler DiaRequest:Auth-Application-Id=NASREQ>

or:

<Handler DiaRequest:Disconnect-Cause=CREDIT_CONTROL>

7.1.50. Any other attribute defined in your dictionary

Checking of all other attributes passes only if the corresponding attribute exists in the request and matches the value specified for the check item.

Radiator allows check items to be specified either as an exact match or as a Perl regular expression (regexp). Radiator regards check items whose value is surrounded with slashes (‘/’) as a regular expression. Anything else is regarded as an exact match.

Exact match
The check item will pass only if there is an exact match. The comparison is case sensitive. Radiator will look for an exact match if the value to be matched is not surrounded by slashes.
```
NAS-IP-Address = 203.63.200.5
Calling-Station-Id = 121284
```
Alternation
Specify multiple permitted values, separated by vertical bars (‘|’). The check item will pass if at least one of the permitted values is an exact match.
```
Calling-Station-Id = 121284|122882
```
Perl Regular expression
If the check item is surrounded by slashes (‘/’), it is regarded as a Perl regular expression, and Perl is used to test whether the value of the attribute in the request matches the regexp. The expression modifiers ‘i’ (case insensitive) and ‘x’ (ignore white space in the pattern) are also permitted. Only either 'i' or 'x' modifier is allowed after the ending slash. Use (?...) syntax to enable or disable additional modifiers. Modifier 's' (dot matches also newline) is enabled by default in Radiator 4.24 and later.

Perl regular expressions give you an enormous amount of power to control the conditions under which a user can log in. The first example below only matches if the user logs in from phone numbers that contain 95980981, 95980982, 95980983 or 95980984. The second example only matches of they log into a port number with one digit (i.e. ports 1-9).
```
Calling-Station-Id = /9598098(1|2|3|4)/
NAS-Port = /^\d\z/
```
Tip

Perl regexps are very powerful, but they also take some getting used to. You should use them carefully, and test to make sure they really do what you want. Consult some Perl manuals or a Perl guru for tips on writing regexps.
Tip
You can use the ‘i’ and ‘x’ pattern modifiers to get case-insensitive or extended expressions like this, to match a Class attribute that includes "myclass" without regard to case.
```
Class = /myclass/i
```
Tip
You can set up “negative” matches (i.e. that only match if the check is not equal to some string) by using Perl negative lookahead assertions in a regexp. For example, this check item will match all Service-Types except for Framed-User:
```
Service-Type = /^(?!Framed-User)/
```
Tip
You can match a string that contains unprintable characters by using a character class negation. For example to match a user name that contains any character not in a-z, A-Z or 0-9:
```
User-Name = /[^a-zA-Z0-9]/
```

7.2. Reply items

Reply items are RADIUS attributes that are used to configure the Terminal Server or NAS when a user is successfully authenticated.

In order to determine what RADIUS attributes you need to configure your NAS, you will need to consult your NAS vendor's documentation. Some RADIUS attributes are common to all NASs, and can be used with any NAS, while some are specific to a particular vendor or model of NAS. All reply items that you use must be defined in your dictionary.

If the user is granted access, all the reply items will be returned in the Access-Accept message to the NAS. This is usually used to configure the NAS in the correct way for that user. Since different brands and models of NAS implement different subsets of the radius specification, it is not possible here to describe all the things you can configure in your NAS with reply items. Refer to your NAS vendor's documentation. Here is a typical example to configure a NAS for a dial-up PPP session:

Framed-Protocol = PPP,
Framed-IP-Netmask = 255.255.255.255,
Framed-Routing = None,
Framed-MTU = 1500,
Framed-Compression = Van-Jacobson-TCP-IP

Some reply items are given special treatment:

7.2.1. Framed-Group

The reply attribute is used in conjunction with FramedGroupBaseAddress in order to allocate an IP address for the user and return it in a Framed-IP-Address attribute. For more information, see Section 3.14.38. FramedGroupBaseAddress.

Framed-Group = 1

7.2.2. Ascend-Send-Secret

Causes the value to be encrypted with the Client's shared secret and returned to the Client.

Ascend-Send-Secret = mysecret

7.2.3. Tunnel-Password and other tagged attributes

Causes the password to be encrypted with the Client's shared secret according to RFC 2868. This is used by NASs for managing VPN tunnels. For more information, see Section 7.1.24. Tagged Tunnel attributes and other tagged attributes.

Tunnel-Password = 1:yourtunnelpassword

7.2.4. MS-CHAP-MPPE-Keys

Causes 2 session keys to be generated from the given string and then encrypted with the Client's shared secret according to RFC 2548. This is used by Microsoft MS-CHAP tunnelling. If the value is exactly 24 octets long, it is assumed to already contain 2 session keys, and will only be encrypted. Requires the Digest::MD4 Perl module to be installed.

MS-CHAP-MPPE-Keys = mymppekey

Tip

If you are doing MS-CHAP authentication with plaintext passwords and your NAS requires MS-CHAP-MPPE-Keys in the reply, then setting the AutoMPPEKeys parameter in your AuthBy clause will force Radiator to automatically reply with MSCHAP- MPPE-Keys set from the plaintext password.

7.2.5. MS-MPPE-Send-Key

Causes the key to be encrypted with the Client's shared secret according to RFC 2548. This is used by Microsoft MS-CHAP tunnelling.

MS-MPPE-Send-Key = mysendkey

7.2.6. MS-MPPE-Recv-Key

Causes the key to be encrypted with the Client's shared secret according to RFC 2548. This is used by Microsoft MS-CHAP tunnelling.

MS-MPPE-Recv-Key = myrecvkey

7.2.7. Fall-Through

This attribute is not actually returned to the NAS. Its presence causes Radiator to continue looking for a match with the next DEFAULT user name.

Fall-Through = yes

7.2.8. Session-Timeout

If your NAS supports the Session-Timeout RADIUS attribute, this attribute can be used in several ways.

As a simple number, it specifies the maximum time (in seconds) that the session is allowed to run for:

Session-Timeout=6300

With the special form "until nnnn", it will specify that the maximum time the session will last is until the time of day specified. The time is the local time (according to the host where Radiator is running). If the current time is after the time specified, the cutoff time will be that time on the following day. For example to specify that the maximum time for any session is up until 6am today:

Session-Timeout="until 0600"

With the special form "until Time", it will set the session timeout to be the number of seconds until the end of the Time check item that permitted the user to log in. This allows you to restrict users so they are only able to connect for the specified time period. In the following example, user fred can log on between 1000 and 1700 each week day, and they will be disconnected (by Session-Timeout) at 1700.

fred Password=jim, Time="Wk1000-1700"
      Session-Timeout="until Time"

With the special form "until Expiration" or “until ValidTo, it will set the session timeout to be the number of seconds until the Expiration or ValidTo check item that permitted the user to log in. This allows you to restrict users so they are only able to connect until the end of their account validity period. In the following example, user fred can log on up until January 1 2003 and they will be disconnected (by Session-Timeout) at midnight of December 31 2002.

fred Password=jim, ValidTo="2003-01-01"
      Session-Timeout="until ValidTo"

7.2.9. Exec-Program

This pseudo reply does not actually add any reply items to the reply. It runs the external program given by the argument and waits for it to terminate. It is only run during reply handling, which means that it is only run if the user successfully authenticates. This is a handy way to run an external program when a user successfully logs in. The argument may contain any special characters. For more information, see Section 3.3. Special formatters.

Tip

There is no guaranteed environment for the external program to run in, so you should specify a program with its full path name.

Exec-Program="/usr/local/bin/sendgreeting %u"

Tip

Radiator is blocked while the external program runs. On Unix, If you do not want Radiator to wait for the program to terminate, use an ampersand (&) at the end of the line:

Exec-Program="/usr/local/bin/myslowprogram %u &"

7.2.10. Ascend-Data-Filter, Ascend-Call-Filter

Radiator supports Ascend Binary Filters, which are given the type of ‘abinary’ in the dictionary. The standard dictionary contains the standard abinary attributes Ascend- Data-Filter and Ascend-Call-Filter.

Ascend Binary Filters are binary encoded strings. However Radiator allows you to create filters in a symbolic, textual form. See you NAS documentation about the meaning, construction and use of Ascend Binary Filters with your NAS.

Radiator supports three basic types of filter, each with slightly different syntax.

IP Filter
The general syntax of an IP filter is:
```
ip dir action [dstip n.n.n.n/nn] [srcip n.n.n.n/nn] [proto [dstport cmp port]
[srcport cmp port] [est]]
```
- dir is IN or OUT, case insensitive
- action is FORWARD or DROP. Case insensitive
- proto is a protocol name, such as ip, icmp, tcp, lower case
- cmp is a port comparison operator like <, =, > or !=
- port is a defined port name or integer port number, such as ftp-data, telnet, smtp, lower case
Examples:
```
Ascend-Data-Filter = "ip in forward icmp"
Ascend-Data-Filter = "ip in forward dstip 1.2.3.4/24 tcp"
Ascend-Data-Filter = "ip in forward dstip 195.174.219.30 tcp
dstport=20",
```
Generic filter
The general syntax of a generic filter is:
```
generic dir action offset mask value [cmp] [more]
```
- dir is IN or OUT, case insensitive
- action is FORWARD or DROP, case insensitive
- offset is an integer offset
- cmp is == or !=
Examples:
```
Ascend-Data-Filter = "generic in forward 0 0 0"
Ascend-Data-Filter = "generic in drop 0 ffff 0080 != more"
```

IPX Filter

The general syntax for an IPX filter is:

ipx dir action [srcipxnet nnnn srcipxnode mmmmm [srcipxsoc cmp value]]
[dstipxnet nnnn dstipxnode mmmmm [dstipxsoc cmp value]]

dir is IN or OUT, case insensitive
action is FORWARD or DROP, case insensitive
cmp is a comparison operator like <, =, > or !=

Examples:

Ascend-Call-Filter = "ipx in forward srcipxnet 1 srcipxnode
0x11223344aabb srcipxsoc > abcd dstipxnet 5678 dstipxnode 0xaabbccddee00
dstipxsoc > 1234"

CAUTION

Radiator is very strict in its interpretation of filters. You cannot change the order of filter elements, but you can omit the ones shown in square brackets [...]

7.2.11. Any other attribute defined in your dictionary

Any other attribute will be returned to the client in the reply message. All attributes must be defined in your dictionary.

Framed-Protocol = PPP,
Framed-IP-Netmask = 255.255.255.0,
Framed-Routing = None,Framed-MTU = 1500,
Framed-Compression = Van-Jacobson-TCP-IP

Attributes that are defined as type ipaddr in the dictionary (e.g. Framed-IP-Address, Framed-IP-Netmask etc.) can be specified either in dotted-quad notation (e.g. 1.2.3.4) or as 4 bytes of binary. This is most useful if you want to keep addresses in a database in binary format.

Attributes that are defined as type integer can be specified with either:

A RADIUS attribute value name
decimal (i.e. base 10) integer
A hex (i.e. base 16) integer (with a leading 0x)

Therefore, the following reply items are all equivalent:

Framed-Protocol = PPP
Framed-Protocol = 1
Framed-Protocol = 0x01