RT 5.0.6 Documentation
RT::Authen::ExternalAuth::LDAP
NAME
RT::Authen::ExternalAuth::LDAP - LDAP source for RT authentication
DESCRIPTION
Provides the LDAP implementation for RT::Authen::ExternalAuth.
SYNOPSIS
Set($ExternalSettings, {
# AN EXAMPLE LDAP SERVICE
'My_LDAP' => {
'type' => 'ldap',
'server' => 'server.domain.tld',
'user' => 'rt_ldap_username',
'pass' => 'rt_ldap_password',
'base' => 'ou=Organisational Unit,dc=domain,dc=TLD',
'filter' => '(FILTER_STRING)',
'd_filter' => '(FILTER_STRING)',
'group' => 'GROUP_NAME',
'group_attr' => 'GROUP_ATTR',
'tls' => { verify => "require", cafile => "/path/to/ca.pem" },
'net_ldap_args' => [ version => 3 ],
'attr_match_list' => [
'Name',
'EmailAddress',
],
'attr_map' => {
'Name' => 'sAMAccountName',
'EmailAddress' => 'mail',
'Organization' => 'physicalDeliveryOfficeName',
'RealName' => 'cn',
'Gecos' => 'sAMAccountName',
'WorkPhone' => 'telephoneNumber',
'Address1' => 'streetAddress',
'City' => 'l',
'State' => 'st',
'Zip' => 'postalCode',
'Country' => 'co'
},
},
} );
CONFIGURATION
LDAP-specific options are described here. Shared options are described in RT::Authen::ExternalAuth.
The example in the "SYNOPSIS" lists all available options and they are described below. Note that many of these values are specific to LDAP, so you should consult your LDAP documentation for details.
- server
-
The server hosting the LDAP or AD service.
- user, pass
-
The username and password RT should use to connect to the LDAP server.
If you can bind to your LDAP server anonymously you may be able to omit these options. Many servers do not allow anonymous binds, or restrict what information they can see or how much information they can retrieve. If your server does not allow anonymous binds then you must have a service account created for this component to function.
- base
-
The LDAP search base.
- filter
-
The filter to use to match RT users. You must specify it and it must be a valid LDAP filter encased in parentheses.
For example:
filter => '(objectClass=*)',
- d_filter
-
The filter that will only match disabled users. Optional. Must be a valid LDAP filter encased in parentheses.
For example with Active Directory the following can be used:
d_filter => '(userAccountControl:1.2.840.113556.1.4.803:=2)'
- group
-
Does authentication depend on group membership? What group name?
- group_attr
-
What is the attribute for the group object that determines membership?
- group_scope
-
What is the scope of the group search?
base
,one
orsub
. Optional; defaults tobase
, which is good enough for most cases.sub
is appropriate when you have nested groups. - group_attr_value
-
What is the attribute of the user entry that should be matched against group_attr above? Optional; defaults to
dn
. - tls
-
Should we try to use TLS to encrypt connections? Either a scalar, for simple enabling, or a hash of values to pass to "start_tls" in Net::LDAP. By default, Net::LDAP does no certificate validation! To validate certificates, you must pass a hash with the
verify
option set, along with eithercapath
orcafile
.capath
is a directory that contains certificates named using the hash value of the certificates' subject names. On Debian-based distributions, theca-certificates
package manages a directory/etc/ssl/certs
suitable for this purpose (see Debian documentation). You can validate against public certificate authorities by passing:tls => { verify => 'require', capath => "/etc/ssl/certs" },
On Red Hat-based distributions, the
ca-certificates
package manages a directory/etc/pki/tls/certs
suitable for this purpose (see RedHat documentation). You can validate against public certificate authorities by passing:tls => { verify => 'require', capath => "/etc/pki/tls/certs" },
If you don't have this directory set up, or if you want to validate the LDAP server certificate against a specific certificate authority, you can pass the path to one public certificate in the
cafile
option:tls => { verify => 'require', cafile => "/etc/YourCACertPath.pem" },
- net_ldap_args
-
What other args should be passed to Net::LDAP->new($host,@args)?