Section 3.32. <AuthBy xxxxxx>

3.32. <AuthBy xxxxxx>

This marks the beginning of an AuthBy clause, which defines how to authenticate and record accounting information. The xxxxxx is the name of a specific AuthBy module. This section lists the parameters all AuthBys use. AuthBys may also use other parameters that are specific for that AuthBy. AuthBy clauses may be defined at the top level or within a Realm or Handler clause.

Under special circumstances, you can have more than one AuthBy clause for a Realm or Handler or may want to use <AuthBy GROUP>, see Section 3.38. <AuthBy GROUP>. This makes the Handler or Realm or <AuthBy GROUP> try each AuthBy method in turn until one of them either Accepts or Rejects the request. You can change this with AuthByPolicy. For more information, see Section 3.38.1. AuthByPolicy. For example, it is useful to have an <AuthBy SQL> followed by an <AuthBy RADIUS>, which causes all authentication and accounting requests to be forwarded, and also all accounting requests will be recorded in SQL. This is good for keeping track of all requests forwarded to, say a global roaming server.

If there are no AuthBy clauses in a Realm or Handler, then Access requests will be rejected, and Accounting requests will be ignored.

3.32.1. Identifier

This allows you to assign a symbolic name to an AuthBy clause and its configuration. This allows you to refer to it by name in an Auth-Type check item when authenticating a user.

The most common use of this is to create a “System” authenticator, typically with an <AuthBy UNIX> clause. A typical example configuration file that uses this feature might be:

<Realm DEFAULT>
      <AuthBy FILE>
      </AuthBy>
</Realm>
<AuthBy UNIX>
      Identifier System
</AuthBy>

You can then have something like this in your users file:

DEFAULT Auth-Type = System
      Framed-IP-Netmask .....
      ...........

In this example, all users in all realms will match the DEFAULT user in the users file. This will in turn check their user name and password against a UNIX password file as configured by the AuthBy UNIX clause in the configuration file. If the password checks out, they will get the RADIUS attributes specified in the second and subsequent lines of the DEFAULT user entry in the users file (in this example, Framed-IP-Netmask).

3.32.2. StripFromReply

Strips the named attributes from Access-Accepts before replying to the originating client. The value is a comma separated list of RADIUS attribute names. StripFromReply removes attributes from the reply before AddToReply adds any to the reply. There is no default. This is useful, for example, with AuthBy RADIUS to prevent downstream RADIUS servers sending attributes you do not like back to your NAS.

# Remove dangerous attributes from the reply
StripFromReply Framed-IP-Netmask,Framed-Compression

3.32.3. AllowInReply

This optional parameter is the complement to StripFromReply: It specifies the only attributes that are permitted in an Access-Accept. It is useful, for example, to limit the attributes that are passed back to the NAS from a proxy server. This way you can prevent downstream customer RADIUS servers from sending back illegal or troublesome attributes to your NAS.

AllowInReply does not prevent other attributes being added locally by DefaultReply, AddToReply and AddToReplyIfNotExist.

# Only permit a limited set of reply attributes.
AllowInReply Session-Timeout, Framed-IP-Address

3.32.4. AllowInReject

This optional parameter specifies the only attributes that are permitted in an Access-Reject. This can be useful in Handlers with multiple AuthBys where the attributes added before a rejecting AuthBy need to be stripped from the resulting Access-Reject.

AllowInReject is not set by default and does not remove anything from Access-Rejects.

# Only permit a limited set of attributes in a reject.
AllowInReject Message-Authenticator, EAP-Message

3.32.5. AddToReply

Adds attributes to reply packets. Value is a list of comma separated attribute value pairs all on one line, exactly as for any reply item. StripFromReply removes attributes from the reply before AddToReply adds any to the reply. You can use any of the special % formats in the attribute values. There is no default. AddToReply adds attributes to replies to all types of request that are handled by this clause.

Although this parameter can be used in any AuthBy method, it is most useful in methods like AuthBy UNIX, which don’t have a way of specifying per-user reply items.

# Append some necessary attributes for our pops
AddToReply cisco-avpair="ip:addr_pool=mypool"

3.32.6. AddToReplyIfNotExist

This is similar to AddToReply, but only adds an attribute to a reply if and only if it is not already present in the reply. Therefore, it can be used to add, but not override a reply attribute. This is contributed by Vincent Gillet <vgi@oleane.net>.

3.32.7. DefaultReply

This is similar to Section 3.14.20. AddToReply except it adds attributes to an Access-Accept only if there would otherwise be no reply attributes. StripFromReply does never remove any attributes added by DefaultReply. Value is a list of comma separated attribute value pairs all on one line, exactly as for any reply item. You can use any of the special % formats in the attribute values. There is no default.

Although this parameter can be used in any AuthBy method, it is most useful in methods like <AuthBy UNIX> and <AuthBy SYSTEM>, which do not have a way of specifying per-user reply items. In other AuthBy methods you can also very easily set up a standard set of reply items for all users, yet you can still override reply items on a per-user basis.

# If the user had no reply items set some
DefaultReply Service-Type=Framed,Framed-Protocol=PPP

3.32.8. FramedGroup

This optional parameter acts similarly to Framed-Group reply items, but it applies to all Access-Requests authenticated by this clause. If FramedGroup is set and a matching FramedGroupBaseAddress is set in the Client from where the request came, then a Framed-IP-Address reply item is automatically calculated by adding the NASPort in the request to the FramedGroupBaseAddress specified by FramedGroup. For more information, see Section 3.14.38. FramedGroupBaseAddress.

Note

You can override the value of FramedGroup for a single user by setting a Framed-Group reply item for the user.

# Work out the users IP address from the first 
# FramedGroupBaseAddress specified in out client
FramedGroup 0

3.32.9. NoDefault

Normally if Radiator searches for a user in the database and either does not find one, or finds one but the users check items fail, Radiator will then consult the DEFAULT user entry. However, if the NoDefault parameter is set, Radiator will never look for a DEFAULT.

# Save time by never looking for a default
NoDefault

3.32.10. NoDefaultIfFound

Normally if Radiator searches for a user in the database and finds one, but the users check items fail, Radiator will then consult the DEFAULT user entry. However, if the NoDefaultIfFound parameter is set, Radiator will only look for a DEFAULT if there were no entries found in the user database for the user.

# do not fall through to DEFAULT if a users check item failed
NoDefaultIfFound

3.32.11. DefaultLimit

This optional parameter specifies the maximum number of DEFAULT users to look up in the database.

3.32.12. AcceptIfMissing

Normally, if a user is not present in the user database, they will always be rejected. If this optional parameter is set, and a user is not in the database they will be unconditionally accepted. If they are in the database, they will be accepted if and only if their check items pass in the normal way.

This option is usually only useful in conjunction with a following AuthBy that will actually check all passwords. It can therefore be used to impose additional checks on a subset of your user population.

Note

When you specify AcceptIfMissing, all reply attributes set for this AuthBy (such as DefaultReply, AddToReply, AddToReplyIfNotExist, etc.) will be applied.

Note

This does not automatically accept DEFAULT users.

# Apply some extra checks for those users in the users file, 
# then authenticate them with a SQL DB.
<Handler>
      AuthByPolicy ContinueWhileAccept
      <AuthBy FILE>
            AcceptIfMissing
            Filename %D/users
      </AuthBy>
      <AuthBy SQL>
            # whatever
      </AuthBy>
</Handler>

3.32.13. IgnoreIfMissing

Normally, if a user is not present in the user database, they will always be rejected. If this optional parameter is set, and a user is not in the database, the enclosing AuthBy ignores the request. If they are in the database, they will be accepted if and only if their check items pass in the normal way.

This option is usually only useful in conjunction with one or more following AuthBys.

IgnoreIfMissing does not change database failure behaviour. When a database lookup fails, database failure behaviour is triggered and ignore is returned while the database is deemed to be in failed state. Database failure behaviour is not triggered when IgnoreIfMissing sets AuthBy result to ignore.

Note

If user is not found and DEFAULT users are looked up and found, IgnoreIfMissing does not apply.

# Consider the second LDAP server only when the user is not found
# from the first LDAP server or the first LDAP server has failed.
<Handler>
      # This is also the default AuthByPolicy
      AuthByPolicy ContinueWhileIgnore
      <AuthBy LDAP2>
            IgnoreIfMissing
            # Other configuration parameters
      </AuthBy>
      <AuthBy LDAP2>
            # LDAP configuration parameters
      </AuthBy>
</Handler>

3.32.14. DefaultSimultaneousUse

This optional parameter defines a default value for Simultaneous-Use check items that will apply only if the user does not have their own user-specific Simultaneous-Use check item.

# Use sim-use of 2 unless there is a user-specific entry
DefaultSimultaneousUse 2

3.32.15. AuthenProto

AuthenProto specifies which authentication protocols are permitted for authentication. It is an optional parameter. AuthenProto is available for all AuthBy modules but its functionality depends on the specific AuthBy. It does not affect proxying or special AuthBy modules, such as

<AuthBy
                     INTERNAL>

which do their own request handling.

If the authentication request is rejected because of this parameter setting, the failure is logged as a WARNING in Radiator log, and available for all AuthLog clauses as the failure reason.

Allowed values for AuthenProto are:

PAP
CHAP
MSCHAP
MSCHAPv2
SIPDigest
EAP
AuthorizeOnly
Unknown

The default value is

PAP, CHAP, MSCHAP, MSCHAPv2, EAP,
                     AuthorizeOnly

. The value is AuthorizeOnly if the request does not match any of the other values but has Service-Type attribute set to Authorize-Only. The value is Unknown when the authentication protocol cannot be determined. The default for AuthenProto covers the usual user authentication protocols. Add Unknown to those AuthBys that need to handle the authentication requests that do not have the correct combination of any of the following:

CHAP attributes
MSCHAP attributes
MSCHAPv2 attributes
User-Password attribute
EAP-Message attributes
Service-Type attribute set to Authorize-Only

Here is an example of using AuthenProto:

# Allow PAP only
AuthenProto PAP

# Allow all CHAP variants
AuthenProto CHAP,MSCHAP,MSCHAPv2

# Empty list allows nothing
AuthenProto

# Unknown allows anything else. This allows PAP and requests that are not
# CHAP, MSCHAP, MSCHAPv2, SIPDigest, EAP or AuthorizeOnly
AuthenProto PAP, Unknown

3.32.16. CaseInsensitivePasswords

This optional parameter permits case insensitive password checking for authentication methods that support plaintext password checks, such as FILE, SQL, DBFILE and some others. It has no effect on CHAP or MSCHAP passwords, or on password checking involving any encrypted passwords.

# Permit case insensitive password checks
CaseInsensitivePasswords

3.32.17. RejectEmptyPassword

This optional parameter forces any Access-Request with an empty password to be rejected. This is provided as a work around for some broken remote RADIUS servers (VMS RADIUS server in particular) that incorrectly accept requests with empty passwords.

# Reject anything with an empty password
RejectEmptyPassword

3.32.18. AuthenticateAccounting

This optional parameter forces Radiator to authenticate accounting requests (as well as the normal Access-Requests). It is very rarely required.

3.32.19. IgnoreAuthentication

This optional parameter causes the AuthBy to IGNORE all authentication requests. This can be useful for providing fine control over authentication with multiple AuthBy clauses.

3.32.20. IgnoreAccounting

This optional parameter causes the AuthBy to IGNORE all accounting requests. This can be useful for providing fine control over authentication with multiple AuthBy clauses.

3.32.21. RcryptKey

This optional parameter indicates that the passwords in the user database may have been reversibly encrypted using Rcrypt. Any password in the database read by this AuthBy and which is in the form {rcrypt}anythingatall will be interpreted as an Rcrypt password and the function Radius::Rcrypt::decrypt() will be used to decrypt it before any password comparisons are made. Rcrypt encrypted passwords are compatible with PAP, CHAP, and MS-CHAP.

Rcrypt reversible encryption allows you keep your user password database reasonably secure, but still support CHAP, MS-CHAP and other authentication methods that require access to the plaintext password. Rcrypt encryption is supported as an option by the RAdmin RADIUS user administration package from Radiator Software.

Tip

The value of RcryptKey must exactly match the key that was used to originally encrypt the passwords.

Tip

You can add Rcrypt encryption and decryption to other programs with the Radius::Rcrypt Perl module supplied with Radiator.

3.32.22. TranslatePasswordHook

This optional parameter specifies a Perl hook that can be used to convert, translate or transform plaintext passwords after retrieval from a user database and before comparison with the submitted password received from the client. The hook is passed the following arguments:

$_[0] The correct password as retrieved from the user database.
$_[1] A reference to the current AuthBy module object.
$_[2] The user name being authenticated.
$_[3] A flag saying whether the correct password is encrypted by crypt() or MSCHAP.
$_[4] A reference to the current RADIUS request.

The hook is expected to return a single scalar value containing the transformed password. In the following example, all passwords are transformed to uppercase.

# Translate all passwords to UPPERCASE
TranslatePasswordHook sub {$_[0] =~ tr/a-z/A-Z/; return $_[0]}

3.32.23. CheckPasswordHook

This optional parameter specifies a Perl hook that can be used to compare password retrieved from a user database with the submitted password received from the client. The retrieved passwords must start with the leading prefix {OSC-pw-hook}. The hook must return true when the password is deemed correct. This hook is for proprietary hash formats and other custom password check methods. This hook runs after TranslatePasswordHook. The hook is passed the following arguments:

$_[0] A reference to the current RADIUS request
$_[1] The password submitted by the user
$_[2] The correct password as retrieved from the user database without the prefix

3.32.24. AutoMPPEKeys

Some NASs, PPoE, VPDN, wireless controllers and wireless access points require MPPE key attributes in the Access-Accept message for setting up encryption. If this AuthBy is doing MS-CHAP V1 authentication, then setting this parameter will force Radiator to automatically reply with MS-CHAP-MPPE-Keys. If this AuthBy is doing MS-CHAP V2 or EAP authentication, then setting this parameter will force Radiator to automatically reply with MS-MPPE-Send-Key and MS-MPPE-Recv-Key.

This flag parameter is optional and defaults to not set. Keys may be computed from the plaintext password, password NT hash or derived by some other means that depends on the AuthBy or AuthBy's EAP method. For example AuthBy LSA and AuthBy NTLM derive the keys with the help of Active Directory. Not all EAP methods support MPPE keys.

When keys are computed based on the password, the password must be available in one of the previously mentioned formats and the user must have User-Password check item.

With TLS based EAP methods, such as EAP-FAST, EAP-TLS, EAP-TTLS and PEAP, MS-MPPE-Send-Key and MS-MPPE-Recv-Key are computed based on TLS handshake results and do not depend on password availability.

Tip

This option is almost always required with AuthBys that authenticate TLS based EAP methods or other EAP methods used with 802.1X authentication for wireless and wired networks.

3.32.25. PacketTrace

This optional flag forces all packets that pass through this module to be logged at trace level 5 until they have been completely processed. This is useful for logging packets that pass through this clause in more detail than other clauses during testing or debugging. The packet tracing stays in effect until it passes through another clause with PacketTrace set off or 0.

PacketTrace is available for the following clauses:

Client
Handler
Realm
AuthBy
ServerDIAMETER
ServerRADSEC
ServerTACACSPLUS

Here is an example of using PacketTrace:

# Debug any packets that pass through here
PacketTrace

3.32.26. CachePasswords

This parameter enables a user password cache in this AuthBy. It can be used to improve the performance of slow AuthBy clauses, or when large number of identical requests for the same user are likely to occur, or when multiple request might result from a one-time password (in a multi-link or wireless roaming environment) etc.

If this parameter is set, all Access-Requests will first be checked against a password cache that contains a copy of the last valid Access-Accept for that user. If the cache contains a matching password that has not exceeded its CachePasswordExpiry, the previous reply will be sent back, without looking up the user again in this AuthBy. Therefore the possibly slow process of consulting the user database or proxying the request can be sometimes avoided.

Tip

Not all AuthBy clauses support this parameter (or CachePasswordExpiry and CacheReplyHook), but the ones that do include UNIX, FILE, DBFILE, SQL, LDAP, ACE, RADMIN and RADIUS. Other AuthBy clauses may or may not support this parameter.

Tip

Use of this parameter with a large user population can cause large amounts of memory use by the Radiator process.

Tip

If Radiator is restarted, the password cache is lost.

Note

Matching of cached passwords can never succeed for CHAP or MS-CHAP authentication requests.

3.32.27. CachePasswordExpiry

If CachePasswords is enabled, this parameter determined the maximum age (in seconds) for cached passwords. Defaults to 86400 seconds (1 day). Cached passwords that are more than this number of seconds old will not be used.

3.32.28. CachePasswordKey

Sets the key used when CachePasswords is enabled. %0 is replace by the current username which is also the default key when CachePasswordKey is not set.

# %0 expands to the current username which is the
# hardcoded default when CachePasswordKey is not set.
CachePasswordKey %0

# Use current username and an attribute from $p (current request)
CachePasswordKey %0:%{X-Device-Group}

3.32.29. CacheReplyHook

This optional parameter allows you to define a Perl hook that runs when a cached reply is about to be returned to the NAS because of CachePasswords.

The hook code is compiled by Perl when Radiator starts up. Compilation errors in your hook code will be reported to the log file at start-up time. Runtime errors in your hook will also be reported to the log file when your hook executes. Multiline hooks (i.e. with trailing backslashes (\)) are parsed by Radiator into one long line. Therefore you should not use trailing comments in your hook.

The hook can be an arbitrarily complicated Perl function, that might run external processes, consult databases, change or set up environment variables, umasks etc.

The arguments passed to the hook are:

Argument 0 is the object handle for this AuthBy object.
Argument 1 is the user name being authenticated.
Argument 2 is the received request packet.
Argument 3 is the cached reply packet that is about to be returned to the NAS.

3.32.30. ClearTextTunnelPassword

This optional parameter prevents Radiator from encrypting Tunnel-Password attributes in replies. This is provided in order to support older NASs that do not support encrypted Tunnel-Password.

# Old NAS does not support encrypted Tunnel-Password
ClearTextTunnelPassword
AddToReply Tunnel-Password=xxxxxx

3.32.31. NoCheckPassword

This optional parameter causes AuthBy not to check the password. This means that any password entered by the user will be accepted. This parameter is useful in conjunction with other authentication methods where the password check is done elsewhere.

3.32.32. ConsumePassword and LeavePassword

ConsumePassword and LeavePassword are optional parameters that allow an AuthBy to extract and use a portion of a password. This is typically required with multiple AuthBys to implement two-factor or one-time password authentication. When set for an AuthBy, only a portion of the current password is used by the AuthBy. The remaining portion becomes the new current password. This allows each AuthBy to check separate portions of a password.

ConsumePassword causes an AuthBy to extract a portion from the beginning of the current password. Possible values for ConsumePassword are:

Positive number
This defines how many characters are extracted from the beginning of the password. If the number is larger than password length, the whole password is used and the next AuthBy gets a zero length password.
Negative number
This defines how many characters are left at the end of the password while the rest are extracted from the beginning of the password. If the number is larger than password length, zero length password is used is used and the next AuthBy gets the whole password.
One or more other characters
This defines a separator. Portion of the password before the first occurrence of separator is used. The separator is discarded and the next AuthBy gets what remains after the first separator. If the separator is not a part of the password, the password is used fully and the next AuthBy gets a zero length password.
Empty
The whole password is used. The next AuthBy gets a zero length password.

LeavePassword causes an AuthBy to extract a portion from the end of the current password. Possible values for LeavePassword are:

Positive number
This defines how many characters are left at the beginning of password while the rest are extracted from the end of the password. If the number is larger than password length, zero length password is used and the next AuthBy gets the whole password.
Negative number
This defines how many characters are extracted from the end of the password. If the number is larger than password length, the whole password is used and the next AuthBy gets a zero length password.
One or more other characters
This defines a separator. Portion of the password after the last occurrence of separator is used. The separator is discarded and the next AuthBy gets the portion before the last separator. If the separator is not a part of the password, zero length password is used and the next AuthBy gets the whole password.
Empty
Zero length password is used. The next AuthBy gets the whole password.

Examples

Notice in the examples how ConsumePassword consumes the beginning of password and LeavePassword leaves it unchanged:

If the password is part1:part2:part3 and ConsumePassword is :, the next AuthBy gets part2:part3
If the password is 987654variablepart and ConsumePassword is 6, the next AuthBy gets variablepart
If the password is variablepart987654 and ConsumePassword is -6, the next AuthBy gets 987654
If the password is part1:part2:part3 and LeavePassword is :, the next AuthBy gets part1:part2
If the password is variablepart987654 and LeavePassword is -6, the next AuthBy gets variablepart
If the password is 987654variablepart and LeavePassword is 6, the next AuthBy gets 987654

For more configuration examples, see goodies/duo.cfg and goodies/digipassStatic.cfg. This example shows how to check a password, for example variablepart987654, that has a variable length static password followed by 6 digit TOTP code.

<Handler>
    AuthByPolicy ContinueWhileAccept
    <AuthBy SQL>
        # Current password is static password followed by a token code
        # SQL configuration to check static password and other check attributes
        # Fetch reply attribute configuration

        # Use and remove static password leaving the token code
        ConsumePassword -6
    </AuthBy>
    <AuthBy SQLTOTP>
        # Current password is just the token code
    </AuthBy>
</Handler>

3.32.33. AuthenticateAttribute

This optional parameter allows you to control which RADIUS attribute is used to look up the user database. Normally, Radiator uses the User-Name RADIUS attribute as the key to find a user in the user database. If the AuthenticateAttribute parameter is defined, it specifies the name of an alternative RADIUS attribute that will be used as the key during the lookup in the user database. This is useful in order to do authentication based on, say, the Calling-Station-Id:

# look up database based on Calling-Station-Id
AuthenticateAttribute Calling-Station-Id

3.32.34. UsernameMatchesWithoutRealm

This optional parameter forces authenticators to strip any realm from the user name before authenticating the name. This allows users to log in with user@realm, even though their user database user name is just user.

3.32.35. Blacklist

Reverses the sense of authentication checks, making it easier to implement blacklists. If the user name matches the user database, then they will be rejected. If there is no match they will be accepted.

3.32.36. EAPErrorReject

If an EAP error occurs, REJECT instead of IGNORE. The RFCs say that IGNORE is the correct behaviour, but REJECT can work better in some load balancing situations.

3.32.37. PasswordPrompt

For AuthBys that support the feature, specifies the prompt to be used when asking for a password.

3.32.38. PostAuthHook

This optional parameter allows you to define a Perl function that is called during packet processing. PostAuthHook is called for each request when the AuthBy is done processing the request and has returned.

The hook parameters and behaviour are the same as for Handler's PostAuthHook. For more information, see Section 3.31.11. PostAuthHook.

3.32.39. AllowNULInUsername

By default, user names with NUL octets cause a reject with user database lookups. This optional flag parameter allows user database lookups when the looked up user name contains a NUL octet. This is not set by default.

Here is an example of using AllowNULInUsername:

# User-Name attributes and EAP identities are allowed to have NUL octets
AllowNULInUsername

3.32.40. AddExtraCheck

This is a string that adds check items before passing to the authentication modules. The value is a list of comma-separated check items value pairs.

3.32.41. RejectReason

This optional parameter specifies a string that is used as the Reply-Message if <AuthBy INTERNAL> rejects a request. The enclosing Realm or Handler must also have RejectHasReason enabled.

Here is an example of using RejectReason:

RejectReason Your account has been disabled

3.32.42. Fork

The parameter forces the authentication module to fork(2) before handling the request. Fork should only be set if the authentication module or the way you have it configured is slow, so that it takes more than a fraction of a second to process the request.

If you do not understand what forking is for or how it can improve the performance of your Radiator server, talk about it with someone who does before using it. Not all authentication methods will benefit from forking. Fork has no effect on Windows platforms.

Note

In particular, it does not usually make sense to use Fork with AuthBy SQL, AuthBy FILE, AuthBy LDAP2 or any of the other common authentication methods provided with Radiator. Further, some SQL and LDAP client libraries are not robust across forks. You might want to consider using Fork with AuthBy EXTERNAL or a custom authentication module if it needs to do significant amounts of IO, or to communicate with a remote system.

# This AuthBy EXTERNAL program is very slow, and does lots of IO
Fork

3.32.43. UseAddressHint

This optional parameter forces Radiator to honour a Framed-IP-Address in an Access-Request request unless it is overridden by a Framed-IP-Address in the user's reply items. If you enable this, then users will get the IP Address they ask for. If there is a Framed-IP-Address reply item for a user, that will override anything they might request.

# Let users get addresses they ask for
UseAddressHint

3.32.44. DynamicReply

This optional parameter specifies a reply item that will be eligible for run-time variable substitution. That means that you can use any of the % substitutions in Section 3.3. Special formatters in that reply item. You can specify any number of DynamicReply lines, one for each reply item you want to do replacements on. Any packet-specific replacement values will come from the Access-Accept message being constructed, and not from the incoming Access-Request. That means that special characters like %n will not be replaced by the received User-Name, because User-Name is in the request, but not the reply.

In the following example, substitution is enabled for USR-IP-Input-Filter in an AuthBy clause. When a user authenticates, the %a in the filter will be replaced by the users IP Address, which makes the filter an anti-spoof filter.

<AuthBy whatever>
      ......
      UseAddressHint
      DynamicReply USR-IP-Input-Filter
</AuthBy>

In the users file:

DEFAULT User-Password = "UNIX"
      Framed-IP-Address = 255.255.255.254,
      Framed-Routing = None,
      Framed-IP-Netmask = 255.255.255.255,
      USR-IP-Input-Filter = "1 REJECT src-addr != %a;",
      Service-Type = Framed-User

Note

This parameter used to be called Dynamic. That name is still recognised as a synonym for DynamicReply.

3.32.45. DynamicCheck

This optional parameter specifies a check item that will be eligible for run-time variable substitution prior to authentication. That means that you can use any of the % substitutions in table at Section 3.3. Special formatters in that check item. You can specify any number of Dynamic- Check lines, one for each check item you want to do replacements on.

In the following example, substitution is enabled for the Group check item. When a user authenticates, the %{Shiva-VPN-Group} in the check item will be replaced with the value of the Shiva-VPN-Group attribute in the authentication request. You could use this mechanism to verify that the user is in the Unix group corresponding to their Shiva-VPN-Group.

<AuthBy whatever>
      ......
      DynamicCheck Group
</AuthBy>

In the users file:

DEFAULT Group=%{Shiva-VPN-Group}
      Framed-IP-Address = 255.255.255.254,
      Framed-Routing = None,
      Framed-IP-Netmask = 255.255.255.255,
      ........