.. _policy-authentication: Authentication Policies ------------------------ Some authentication policies are also making use of the client field. This is described in the policy. .. _policy-authentication-pin: 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** = . 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 :ref:`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. 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. 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 for your token ”. You may use text, that can be send via SMS. The place holders and will be replaced by the OTP value and the serial number of the token. You do not need to add the serial number! 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 :ref:`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. 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 :ref:`users_in_policies`. * Client: This is a list of IP addresses or subnets this policy is valid for. 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=** The URL should be something like ``https://yourserver/ocra/check_t`` .. _cr_policy: 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=** * User: This is a comma seperated list of usernames or resolver names. Please see :ref:`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. ..