Chetan Gaonker | 7f4bf74 | 2016-05-04 15:56:08 -0700 | [diff] [blame] | 1 | # |
| 2 | # Configuration for the OTP module. |
| 3 | # |
| 4 | |
| 5 | # This module allows you to use various handheld OTP tokens |
| 6 | # for authentication (Auth-Type := otp). These tokens are |
| 7 | # available from various vendors. |
| 8 | # |
| 9 | # It works in conjunction with otpd, which implements token |
| 10 | # management and OTP verification functions; and lsmd or gsmd, |
| 11 | # which implements synchronous state management functions. |
| 12 | # otpd, lsmd and gsmd are available from TRI-D Systems: |
| 13 | # <http://www.tri-dsystems.com/> |
| 14 | |
| 15 | # You must list this module in BOTH the authorize and authenticate |
| 16 | # sections in order to use it. |
| 17 | otp { |
| 18 | # otpd rendezvous point. |
| 19 | # (default: /var/run/otpd/socket) |
| 20 | #otpd_rp = /var/run/otpd/socket |
| 21 | |
| 22 | # Text to use for the challenge. |
| 23 | # Default "Challenge: %{reply:OTP-Challenge}\n Response: " |
| 24 | |
| 25 | challenge_prompt = "Challenge: %{reply:OTP-Challenge} \n Response: " |
| 26 | |
| 27 | # Length of the challenge. Most tokens probably support a |
| 28 | # max of 8 digits. (range: 5-32 digits, default 6) |
| 29 | #challenge_length = 6 |
| 30 | |
| 31 | # Maximum time, in seconds, that a challenge is valid. |
| 32 | # (The user must respond to a challenge within this time.) |
| 33 | # It is also the minimal time between consecutive async mode |
| 34 | # authentications, a necessary restriction due to an inherent |
| 35 | # weakness of the RADIUS protocol which allows replay attacks. |
| 36 | # (default: 30) |
| 37 | #challenge_delay = 30 |
| 38 | |
| 39 | # Whether or not to allow asynchronous ("pure" challenge/ |
| 40 | # response) mode authentication. Since sync mode is much more |
| 41 | # usable, and all reasonable tokens support it, the typical |
| 42 | # use of async mode is to allow re-sync of event based tokens. |
| 43 | # But because of the vulnerability of async mode with some tokens, |
| 44 | # you probably want to disable this and require that out-of-sync |
| 45 | # users re-sync from specifically secured terminals. |
| 46 | # See the otpd docs for more info. |
| 47 | # (default: no) |
| 48 | #allow_async = no |
| 49 | |
| 50 | # Whether or not to allow synchronous mode authentication. |
| 51 | # When using otpd with lsmd, it is *CRITICALLY IMPORTANT* |
| 52 | # that if your OTP users can authenticate to multiple RADIUS |
| 53 | # servers, this must be "yes" for the primary/default server, |
| 54 | # and "no" for the others. This is because lsmd does not |
| 55 | # share state information across multiple servers. Using "yes" |
| 56 | # on all your RADIUS servers would allow replay attacks! |
| 57 | # Also, for event based tokens, the user will be out of sync |
| 58 | # on the "other" servers. In order to use "yes" on all your |
| 59 | # servers, you must either use gsmd, which synchronises state |
| 60 | # globally, or implement your own state synchronisation method. |
| 61 | # (default: yes) |
| 62 | #allow_sync = yes |
| 63 | |
| 64 | # If both allow_async and allow_sync are "yes", a challenge is |
| 65 | # always presented to the user. This is incompatible with NAS |
| 66 | # that can't present or don't handle Access-Challenge's, e.g. |
| 67 | # PPTP servers. Even though a challenge is presented, the user |
| 68 | # can still enter their synchronous passcode. |
| 69 | |
| 70 | # The following are MPPE settings. Note that MS-CHAP (v1) is |
| 71 | # strongly discouraged. All possible values are listed as |
| 72 | # {value = meaning}. Default values are first. |
| 73 | #mschapv2_mppe = {2 = required, 1 = optional, 0 = forbidden} |
| 74 | #mschapv2_mppe_bits = {2 = 128, 1 = 128 or 40, 0 = 40} |
| 75 | #mschap_mppe = {2 = required, 1 = optional, 0 = forbidden} |
| 76 | #mschap_mppe_bits = {2 = 128} |
| 77 | } |