rlm_pap(5) FreeRADIUS Module rlm_pap(5)
NAME
rlm_pap - FreeRADIUS Module
DESCRIPTION
The rlm_pap module performs PAP authentication.
This module performs authentication when the Access-Request contains a User-Password attribute AND
when a "known good" password has been configured for the user. In addition, it takes care of decod-ing decoding
ing the "known good" password from hex or Base64 encoding to a form it can use for authentication.
As a result, as of 1.1.4, the "encryption_scheme" configuration item SHOULD NOT BE USED, and the
rlm_ldap configuration item "password_header" SHOULD NOT BE USED. Those items will continue to work
in 1.1.4, and existing systems will work un-changed after upgrading to 1.1.4. We recommend, though,
that sites using multiple instances of rlm_pap see if they can replace those multiple instances with
one instance, using the new "auto_header" configuration, and remove the "password_header" configura-tion configuration
tion from rlm_ldap.
The configuration item(s):
auto_header
Automatically discover password headers. Permitted values are "yes" and "no". For backwards
compatibility, the default is "no".
The recommended value is "yes".
encryption_scheme
No longer used, and therefore no longer documented.
When "auto_header" is set to "yes", the module will look in the configuration list for the User-Pass-word User-Password
word attribute or the new Password-With-Header attribute. If found, it will then look at the string
value of those attributes, for one of the following headers:
{clear}
{cleartext}
{crypt}
{md5}
{smd5}
{sha1}
{ssha1}
{nt}
{x-nthash}
{ns-mta-md5}
The text following the header is taken as the "known good" password, either cleartext, crypted,
hashed, or hashed with a salt. If the text is hex or Base64 encoded, it will be decoded to obtain
the correct form of the "known good" password. The User-Password in the Access-Request will then be
crypted, or hashed as appropriate, and compared to the "known good" password. If they match, the
user is authenticated, otherwise the module returns reject.
CAVEATS
In order for the "auto_header = yes" functionality to work, the pap module MUST be listed LAST in the
authorize section of radiusd.conf. This lets other modules such as LDAP blindly add a "known good"
password to the configuration items, and the PAP module will just figure it out. In most cases, mul-tiple multiple
tiple instances of the PAP module, along with complex logic to determine which one to call when, can
be replaced with one instance of the module, with it listed last in the authorize section.
Note that the ns_mta_md5 module is no longer necessary, and can be removed.
Also, setting "Auth-Type = Local" or "Auth-Type = Crypt-Local" is no longer necessary. Any such set-tings settings
tings SHOULD BE DELETED. Simply list pap LAST in the authorize section, and the module will take
care of figuring out what to do. (Have we emphasized that enough?)
Another reason to list the module last is that it will take care of normalizing any crypt'd or hashed
password retrieved from a database. So it is now safe to have clear-text passwords as "{clear}...",
because the PAP module will take care of removing the "{clear}" prefix from the password. Any other
modules that need access to the cleartext password will
The module uses a number of new attributes.
Password-With-Header
This attribute should contain a "known good" password, with a header such as "{crypt}, or
"{md5}", etc. It should be used when the passwords retrieved from a DB may have different
headers. When pap is listed in the authorize section, the module will examine this attribute,
and use it to create one of the other attributes listed below. That other attribute is then
used for authentication.
If the passwords in a DB do not have a header, and are always in one particular form, then the
attributes listed below can be used directly. In that case, the PAP module will do hex or
Base64 decoding of the attribute contents, if necessary. So pap should still be listed in the
authorize section, because it will enable the maximum flexibility for the server, and minimize
configuration for the administrator.
Cleartext-Password
This attribute should contain the cleartext for a "known good" password. Previously, the
User-Password attribute was overloaded to contain this, both in the FAQ and in databases in
many sites. Any configuration that sets a cleartext form of the password using User-Password
SHOULD UPDATE to using Cleartext-Password. Doing so will simplify a number of debugging
issues.
Crypt-Password
This attribute has been around for a while, but is documented here for completeness. It con-tains contains
tains the crypt'd form of the password.
MD5-Password
This attribute contains the MD5 hashed form of the password.
SMD5-Password
This attribute contains the MD5 hashed form of the password, with a salt.
SHA1-Password
This attribute contains the SHA1 hashed form of the password.
SSHA1-Password
This attribute contains the SHA1 hashed form of the password, with a salt.
NT-Password
This attribute has been around for a while, but is documented here for completeness. It con-tains contains
tains the NT hash form of the password, as used by Active Directory and Samba.
SECTIONS
authorize authenticate
FILES
/etc/raddb/radiusd.conf
SEE ALSO
radiusd(8), radiusd.conf(5)
AUTHOR
Alan DeKok <aland@freeradius.org>
3 February 2004 rlm_pap(5)
|