7.7. Authentication Policies

Some authentication policies are also making use of the client field. This is described in the policy.

7.7.1. OTP PIN variants

You may define the way of authenticating the users in the realms.

Define a policy like this:

• Policy name: This is the unique name of the policy.

• Scope: You need to set this to authentication.

• Realm: Enter the name of the realm here.

• Action: This field is comma separated. It should contain the keyword otppin = <id>.

  <id> can have one of the following values:

  • 0: This is the default behavior. In addition to the OTP value the user needs to enter a fixed OTP PIN, that is defined per token.
  • 1: In addition to the OTP value the user must enter the password from his user database, e.g. his LDAP or Active Directory password (in case of LDAPUserIdResolver) or his password in the Passwd-File or in the SQL Database.
  • 2: The user does not need to enter any additional OTP PIN. He will authenticate only with the OTP value.

• User: This is a list of users or resolvers, for whom this policy will be valid. Please see Users in policies.

• Client: This is a list of IP addresses or IP subnets.

Note

Using this policy you can setup scenarios, where a user needs to provide a PIN, when she logs in from the SSL VPN but does not need to provide an OTP PIN when logging in from a Radius Credential Provider.

7.7.2. Automatic SMS sending

Using this policy you may define, that a new SMS is sent after the user has successfully authenticated with an SMS OTP. This way, the user does not need to do some additional step for triggering the sending of a new SMS. When you use the client parameter, you can define, that an automatic SMS will be triggered when the user logged in to the Terminal Server but not to the SSL VPN.

• Policy name: This is the unique name of the policy.
• Scope: You need to set this to authentication.
• Realm: Enter the name of the realm here.
• Action: This field is comma separated. It should contain the keyword autosms. This keyword works as a boolean and takes no parameter.
• User: This is a list of users or ‘*’ for all users, for whom this policy will be valid.
• Client: This is a list of IP addresses or IP subnets.

7.7.3. SMS Text

Using this policy you may define the text content of the SMS. Usually the SMS only contains the OTP value. But you may change this per realm.

• Policy name: This is a unique name of the policy.
• Scope: You need to set this to authentication.
• Realm: Enter the name of the realm. These users will get a customized text.
• Action: Use the format smstext= ”Your OTP <otp> for your token <serial>”. You may use text, that can be send via SMS. The place holders <otp> and <serial> will be replaced by the OTP value and the serial number of the token. You do not need to add the serial number!

7.7.4. Authentication Passthrough

When this is activated, users who have no token assigned, will be authenticated against the password in their UserIdResolver.

• Policy name: this is a unique name of the policy.
• Scope: You need to set this to authentication.
• Realm: Enter the name of the realm.
• Action: passthru
• User: This is a comma seperated list of usernames or resolver names. Please see Users in policies.
• Client: This is a list of IP addresses or subnets this policy is valid for.

Note

Using this policy you can setup smooth rollout scenarios. Every user will have to authenticate with her active directory password until the user gets an OTP token enrolled. In such an enrollment scenario you could combine this policy with the OTP PIN policy otppin=1. Thus a user will authenticate with the AD password and will have to add the OTP value to the fixed AD password as soon as she has a token assigned.

7.7.5. Pass on no Token

If there is no token assigned to a user, the authentication request for this user will always be true, no matter which password is provided.

• Policy name: this is a unique name of the policy.
• Scope: You need to set this to authentication.
• Realm: Enter the name of the realm.
• Action: passOnNoToken
• User: This is a comma seperated list of usernames or resolver names. Please see Users in policies.
• Client: This is a list of IP addresses or subnets this policy is valid for.

7.7.6. URL for QR-TAN token

The LSE QR-TAN token has a half automatic mode, where the App tries to send the TAN to a configured URL.

This URL is transferred to the App during the enrollment process. You can define different URLs for each realm.

To do so you can set up a policy like this:

• Policy name: This is a unique name of the policy.
• Scope: authentication
• Realm: One realm, a comma separated list of realms or ‘*’
• Action: qrtanurl= <URL> The URL should be something like https://yourserver/ocra/check_t

7.7.7. Challenge Response

LinOTP can authenticate the user in a challenge response way. I.e. in the first authentication request only the OTP PIN will be passed and in the second authentication request only the OTP value will be passed. This behaviour can be activated on a per token, per realm and per client basis using this policy.

Set up the policy like this:

• Policy name: This is a unique name of the policy.
• Scope: authentication
• Realm: One realm, a comma seperated list of realms or ‘*’
• Action: challenge_response= <Token type list>
• User: This is a comma seperated list of usernames or resolver names. Please see Users in policies.
• Client: This is a list of IP addresses or subnets this policy is valid for.

The Token type list is a white space seperated list of token types, which can also contain the ‘*’. This policy will be valid for the corresponding token types.