The 'Binary' flag is required for any interface that uses this module.
The module only uses the 'str' attribute and optionally the 'User-Name' and
'User-Password' attributes from requests sent to it; the sendattr ACL is
specified for efficiency only. You don't need to specify a recvattr ACL;
you can control which attributes are returned from the directory using the
LDAP-to-RADIUS mapping file that is described below.
The following command line options are provided:
Specify an attribute mapping file name other than the default (which
can be set by changing RADLDAP_MAPFILE in Make.conf).
A DN to bind to upon startup. If this option is specified, the module
will ignore any User-Name / User-Password attributes sent to it. If left
out, the module will re-bind each time a request comes in, using User-Name
as the bind DN and User-Password as the password.
A bind password to for the DN specified with '-b'. If '-b' is specified
without '-s', the module will do an anonymous LDAP bind when starting
(and ignore User-Name and User-Password attributes in requests).
Port to contact LDAP on, if other than the default LDAP_PORT (389).
Causes the module to unbind from the LDAP after each request. This may be
especially useful for pre-v3 servers if you want to authenticate users by
binding; multiple binds during the same session are only specified since
You can also try this as a workaround for buggy LDAP libraries or servers
if the module or LDAP server seems to leak memory. It negatively affects
performance though, because LDAP's TCP connection is shut down as well
if you unbind.
Increase debugging level. Debugging messages are output on standard
error (fd 2, which can be redirected by OpenRADIUS using '-o'). With one
'-d', all operations will be shown, but without bind passwords. Two '-d's
cause the passwords to be included as well.
The LDAP attributes returned by your searches are mapped to RADIUS attributes
using a configurable mapping file, which consists of lines formatted like this:
ldapAttributeName spcnr vndnr atrnr
The default mapping file shown below is most useful if you can model your
LDAP schema according to RADIUS data types, i.e. if you can store integers
and IP addresses as 32-bit network-order binary values.
If this is inconvenient, you'll want to define some additional string-type
attributes in dict.internal and use them in the mapping file instead of the
ones listed here. You can then easily convert them to their real RADIUS
counterparts using the behaviour language's standard conversion operators.
These are the contents of the default 'radldap.attrmap' that is installed
along with the executable in the modules directory:
This module has two modes of operation, depending on its command line
if you specify a bind DN and password, the module will perform
an LDAP bind at startup, using those credentials. It will use the
resulting authenticated connection for each subsequent search operation
(unless you specify '-u', see below).
If you don't include the credentials on the command line, the module will do
its bind operation each time it gets a request, taking the DN from the last
'User-Name' attribute and using the last 'User-Password' as the password.
It will still keep its connection to the LDAP host open (unless '-u' is used).
The latter mode can only be used with PAP, but provides the easiest way to make
authentication work the same way as when using an LDAP client.
In either case, the module performs a subtree search for each request,
using the first 'str' as the base DN and the second 'str' as the search
It then translates each LDAP attribute that is present in each of the
objects returned by the search, to the OpenRADIUS space/vendor/attribute
combination that is listed in the mapping file for that attribute. The
mapping file can be specified on the command line, otherwise a compiled-in
default filename is used.
It sets the last instance of the 'int' attribute in its response to the
number of objects returned by the search.
If you specify the '-u' command line switch, the module will unbind()
from the directory after each request, to work around buggy and leaking
LDAP implementations. This may useful especially if you use the
'(re-)bind using User-Name / User-Password' mode. LDAPv3 implementations
should support multiple binds during the same session fine though.
This standard module is included with the server and installed by default.