Provided by: freeradius_1.1.7-1build4_i386 bug


       rlm_pap - FreeRADIUS Module


       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 decoding 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" configuration from rlm_ldap.

       The configuration item(s):

              Automatically discover password headers.  Permitted  values  are
              "yes"  and  "no".   For  backwards compatibility, the default is

              The recommended value is "yes".

              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-Password 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:


       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.


       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, multiple 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

       Also,  setting  "Auth-Type  = Local" or "Auth-Type = Crypt-Local" is no
       longer necessary.  Any such settings 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

       The module uses a number of new attributes.

              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.

              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.

              This  attribute  has  been around for a while, but is documented
              here for completeness.  It contains  the  crypt’d  form  of  the

              This attribute contains the MD5 hashed form of the password.

              This  attribute  contains  the  MD5 hashed form of the password,
              with a salt.

              This attribute contains the SHA1 hashed form of the password.

              This attribute contains the SHA1 hashed form  of  the  password,
              with a salt.

              This  attribute  has  been around for a while, but is documented
              here for completeness.  It contains the  NT  hash  form  of  the
              password, as used by Active Directory and Samba.


       authorize authenticate




       radiusd(8), radiusd.conf(5)


       Alan DeKok <>

                                3 February 2004                     rlm_pap(5)