1rlm_pap(5) FreeRADIUS Module rlm_pap(5)
2
6 rlm_pap - FreeRADIUS Module
7
9 The rlm_pap module performs PAP authentication.
10 This module performs authentication when the Access-Request contains a
12 User-Password attribute AND when a "known good" password has been con‐
13 figured for the user. In addition, it takes care of decoding the
14 "known good" password from hex or Base64 encoding to a form it can use
15 for authentication.
16 As a result, as of 1.1.4, the "encryption_scheme" configuration item
18 SHOULD NOT BE USED, and the rlm_ldap configuration item "pass‐
19 word_header" SHOULD NOT BE USED. Those items will continue to work in
20 1.1.4, and existing systems will work un-changed after upgrading to
21 1.1.4. We recommend, though, that sites using multiple instances of
22 rlm_pap see if they can replace those multiple instances with one
23 instance, using the new "auto_header" configuration, and remove the
24 "password_header" configuration from rlm_ldap.
25 The configuration item(s):
27 auto_header
29 Automatically discover password headers. Permitted values are
30 "yes" and "no". For backwards compatibility, the default is
31 "no".
32 The recommended value is "yes".
34 encryption_scheme
36 No longer used, and therefore no longer documented.
37 When "auto_header" is set to "yes", the module will look in the config‐
39 uration list for the User-Password attribute or the new Password-With-
40 Header attribute. If found, it will then look at the string value of
41 those attributes, for one of the following headers:
42 {clear}
44 {cleartext}
45 {crypt}
46 {md5}
47 {smd5}
48 {sha1}
49 {ssha1}
50 {nt}
51 {x-nthash}
52 {ns-mta-md5}
53 The text following the header is taken as the "known good" password,
55 either cleartext, crypted, hashed, or hashed with a salt. If the text
56 is hex or Base64 encoded, it will be decoded to obtain the correct form
57 of the "known good" password. The User-Password in the Access-Request
58 will then be crypted, or hashed as appropriate, and compared to the
59 "known good" password. If they match, the user is authenticated, oth‐
60 erwise the module returns reject.
61
63 In order for the "auto_header = yes" functionality to work, the pap
64 module MUST be listed LAST in the authorize section of radiusd.conf.
65 This lets other modules such as LDAP blindly add a "known good" pass‐
66 word to the configuration items, and the PAP module will just figure it
67 out. In most cases, multiple instances of the PAP module, along with
68 complex logic to determine which one to call when, can be replaced with
69 one instance of the module, with it listed last in the authorize sec‐
70 tion.
71 Note that the ns_mta_md5 module is no longer necessary, and can be
73 removed.
74 Also, setting "Auth-Type = Local" or "Auth-Type = Crypt-Local" is no
76 longer necessary. Any such settings SHOULD BE DELETED. Simply list
77 pap LAST in the authorize section, and the module will take care of
78 figuring out what to do. (Have we emphasized that enough?)
79 Another reason to list the module last is that it will take care of
81 normalizing any crypt'd or hashed password retrieved from a database.
82 So it is now safe to have clear-text passwords as "{clear}...", because
83 the PAP module will take care of removing the "{clear}" prefix from the
84 password. Any other modules that need access to the cleartext password
85 will
86 The module uses a number of new attributes.
88 Password-With-Header
90 This attribute should contain a "known good" password, with a
91 header such as "{crypt}, or "{md5}", etc. It should be used
92 when the passwords retrieved from a DB may have different head‐
93 ers. When pap is listed in the authorize section, the module
94 will examine this attribute, and use it to create one of the
95 other attributes listed below. That other attribute is then
96 used for authentication.
97 If the passwords in a DB do not have a header, and are always in
99 one particular form, then the attributes listed below can be
100 used directly. In that case, the PAP module will do hex or
101 Base64 decoding of the attribute contents, if necessary. So pap
102 should still be listed in the authorize section, because it will
103 enable the maximum flexibility for the server, and minimize con‐
104 figuration for the administrator.
105 Cleartext-Password
107 This attribute should contain the cleartext for a "known good"
108 password. Previously, the User-Password attribute was over‐
109 loaded to contain this, both in the FAQ and in databases in many
110 sites. Any configuration that sets a cleartext form of the
111 password using User-Password SHOULD UPDATE to using Cleartext-
112 Password. Doing so will simplify a number of debugging issues.
113 Crypt-Password
115 This attribute has been around for a while, but is documented
116 here for completeness. It contains the crypt'd form of the
117 password.
118 MD5-Password
120 This attribute contains the MD5 hashed form of the password.
121 SMD5-Password
123 This attribute contains the MD5 hashed form of the password,
124 with a salt.
125 SHA1-Password
127 This attribute contains the SHA1 hashed form of the password.
128 SSHA1-Password
130 This attribute contains the SHA1 hashed form of the password,
131 with a salt.
132 NT-Password
134 This attribute has been around for a while, but is documented
135 here for completeness. It contains the NT hash form of the
136 password, as used by Active Directory and Samba.
137
139 authorize authenticate
140
142 /etc/raddb/radiusd.conf
143
145 radiusd(8), radiusd.conf(5)
146
148 Alan DeKok <aland@freeradius.org>
149 3 February 2004 rlm_pap(5)