Running RT 4.2.12-5 (Installed with apt) on Ubuntu 16.04 with users in openLDAP. LDAP traffic encrypted with TLS.

I can log in with users in LDAP no problem.

I want to restrict users to a group. Thus I have set up:
‘group’ => ‘cn=it,ou=groups,dc=requesttracker,dc=services,o=cph,dc=example,dc=com’,
‘group_attr’ => ‘memberUid’,
‘group_attr_value’ => ‘uid’,

I can look up the group with with ldapsearch on the RT machine.
There is a memberUid=uid in the group for each member.

From the RT log:
LDAP Search === Base: cn=it,ou=groups,dc=request-tracker,dc=services,o=cph,dc=example,dc=com == Scope: base == Filter: (memberUid=XXX) == Attrs: dn (/usr/share/request-tracker4/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/
[244] [Tue Jun 13 09:59:09 2017] [critical]: Search for (memberUid=XXX) failed: LDAP_NO_SUCH_OBJECT 32 (/usr/share/request-tracker4/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/

Any suggestions on where to look? I even hacked to use a filer of (objectClass=*) for the group search, but I still get the result above?


Hi Tobias,

I’m not exactly certian, but you seem to be wanting to import groups
from LDAP. Is that correct?
If so then you are looking for the LDAPImport functionality.

Details of which can be found here:

If not then please excuse the noise.

Best Regards


Hello Martin.

A: I want my RT users’ accounts to exists in LDAP (This works).
B: I want only users who are member of a certain group to be able to log in (This does not work).

Could you please paste the relevant portions from your

Hello Martin.

In the following I have included: The LDAP configuration, log entries showing a failed attempt at logging in with group feature enabled, the result of looking up the group with ldapsearch.



# Use the below LDAP source for both authentication, as well as user
# information
Set($ExternalAuthPriority, ["My_LDAP"]);
Set($ExternalInfoPriority, ["My_LDAP"]);

# Make users created from LDAP Privileged
Set( $UserAutocreateDefaultsOnLogin, { Privileged => 1 } );

# Users should still be autocreated by RT as internal users if they
# fail to exist in an external service; this is so requestors (who
# are not in LDAP) can still be created when they email in.
Set( $AutoCreateNonExternalUsers, 1 );

# Minimal LDAP configuration; see RT::Authen::ExternalAuth::LDAP for
# further details and examples

Set($ExternalSettings, {
  'My_LDAP'       =>  {
    'type'             =>  'ldap',
    'server'           =>  '',
    'user'             =>  'cn=admin,dc=example,dc=com',
    'pass'             =>  '******',
    'tls'              =>  1, # TLS with No certificate validation
    'base'             =>  'o=example,dc=example,dc=com',
    'filter'           =>  '(objectClass=*)',
    #'group_scope'      =>  'sub',
    'group'            =>  'cn=it,ou=groups,dc=request-tracker,dc=services,o=example,dc=example,dc=com',
    'group_attr'       =>  'memberUid',
    'group_attr_value' =>  'uid',
    # Users are allowed to log in via these RT attributes.
    # See LDAP mapping.
    'attr_match_list'  => [ 'Name', 'EmailAddress', ],
    # Import the following properties of the user from LDAP upon
    # login
    'attr_map' => {
      'Name'           => 'uid',
      'EmailAddress'   => 'mail',
      'ExternalAuthId' => 'uid',
      'RealName'       => 'cn',
      'WorkPhone'      => 'telephoneNumber',
      'Address1'       => 'streetAddress',
      'City'           => 'l',
      'State'          => 'st',
      'Zip'            => 'postalCode',
      'Country'        => 'co',
} );

From the log when trying to log in as user “tbp”:

[140] [Wed Jun 14 07:58:25 2017] [debug]: Attempting to use external auth service: My_LDAP (/usr/share/request-tracker4/plug
[140] [Wed Jun 14 07:58:25 2017] [debug]: Calling UserExists with $username (tbp) and $service (My_LDAP) (/usr/share/request
[140] [Wed Jun 14 07:58:25 2017] [debug]: UserExists params:
username: tbp , service: My_LDAP (/usr/share/request-tracker4/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP
[140] [Wed Jun 14 07:58:25 2017] [debug]: LDAP Search ===  Base: o=example,dc=example,dc=com == Filter: (&(objectCla
ss=*)(uid=tbp)) == Attrs: streetAddress,l,uid,uid,postalCode,st,mail,cn,telephoneNumber,co (/usr/share/request-tracker4/plug
[140] [Wed Jun 14 07:58:25 2017] [debug]: Password validation required for service - Executing... (/usr/share/request-tracke
[140] [Wed Jun 14 07:58:25 2017] [debug]: Trying external auth service: My_LDAP (/usr/share/request-tracker4/plugins/RT-Auth
[140] [Wed Jun 14 07:58:25 2017] [debug]: LDAP Search ===  Base: o=example,dc=example,dc=com == Filter: (&(uid=tbp)(
objectClass=*)) == Attrs: dn,uid (/usr/share/request-tracker4/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP
[140] [Wed Jun 14 07:58:25 2017] [debug]: Found LDAP DN: uid=tbp,ou=people,c=dk,o=example,dc=example,dc=com (/usr/sh
[140] [Wed Jun 14 07:58:25 2017] [debug]: LDAP Search ===  Base: cn=it,ou=groups,dc=request-tracker,dc=services,o=example,
dc=example,dc=com == Scope: base == Filter: (memberUid=tbp) == Attrs: dn (/usr/share/request-tracker4/plugins/RT-Authe
[140] [Wed Jun 14 07:58:25 2017] [critical]: Search for (memberUid=tbp) failed: LDAP_NO_SUCH_OBJECT 32 (/usr/share/request-t
[140] [Wed Jun 14 07:58:25 2017] [debug]: LDAP password validation result: 0 (/usr/share/request-tracker4/plugins/RT-Authen-
[140] [Wed Jun 14 07:58:25 2017] [debug]: Password Validation Check Result:  0 (/usr/share/request-tracker4/plugins/RT-Authe
[140] [Wed Jun 14 07:58:25 2017] [debug]: Autohandler called ExternalAuth. Response: (0, Password Invalid) (/usr/share/reque
[140] [Wed Jun 14 07:58:25 2017] [error]: FAILED LOGIN for tbp from (/usr/share/request-tracker4/lib/RT/Interfa

Looking up the group with ldapsearch:

root@ea8fb0f05ef6:/# ldapsearch -x -h -b cn=it,ou=groups,dc=request-tracker,dc=services,o=example,dc=example,dc=com -D "cn=admin,dc=example,dc=com" -W -ZZ
Enter LDAP Password: ****
# extended LDIF
# LDAPv3
# base <cn=it,ou=groups,dc=request-tracker,dc=services,o=example,dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL

# it, groups, request-tracker, services, example,
dn: cn=it,ou=groups,dc=request-tracker,dc=services,o=example,dc=example,dc=com
cn: it
description: Users of the IT queues in Request Tracker
gidNumber: 1101
memberUid: plj
memberUid: tbp
objectClass: top
objectClass: posixGroup

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1

Hi Tobias,

Have you sanitised you email?

You seem to have a mismatch between your group config and what has been
reported in the logging, please see Base:… first line below.

[140] [Wed Jun 14 07:58:25 2017] [debug]: LDAP Search === Base:
t,dc=example,dc=com == Scope: base == Filter: (memberUid=tbp) == Attrs:
dn (/usr/share/request-tracker4/plugins/RT-Authe
[140] [Wed Jun 14 07:58:25 2017] [critical]: Search for (memberUid=tbp)
failed: LDAP_NO_SUCH_OBJECT 32 (/usr/share/request-t

Best Regards


Yes, I sanetised the log. I updated my post once I realized I had made an error.

I think I have found the reason why it’s not working:
When looking for group membership, RT binds as the user whose membership is to be checked. I expect(ed) the LDAP user from the config file (cn=admin,dc=example,dc=com in my case) to be used for the bind.

In my configuration, there is no reason why the users should be able to anything but to bind. Hence, they are not allowed to look up a group (Which they may or may not be a member of). Using the RT user for the bind seems like the more secure choice to me.

Is this current version (I’m on 4.2.12) of RT still working the same way?

From the log

{"log":"594113dd conn=1008 op=3 BIND dn=\"uid=tbp,ou=people,c=dk,o=example,dc=example,dc=com\" mech=SIMPLE ssf=0\n","stream":"stderr","time":"2017-06-14T10:45:49.41388882Z"}
{"log":"594113dd conn=1008 op=3 RESULT tag=97 err=0 text=\n","stream":"stderr","time":"2017-06-14T10:45:49.413935548Z"}
{"log":"594113dd conn=1008 op=4 SRCH base=\"cn=it,ou=groups,dc=request-tracker,dc=services,o=example,dc=example,dc=com\" scope=0 deref=2 filter=\"(memberUid=tbp)\"\n","stream":"stderr","time":"2017-06-14T10:45:49.416017059Z"}
{"log":"594113dd conn=1008 op=4 SRCH attr=dn\n","stream":"stderr","time":"2017-06-14T10:45:49.416046981Z"}
{"log":"594113dd conn=1008 op=4 SEARCH RESULT tag=101 err=32 nentries=0 text=\n","stream":"stderr","time":"2017-06-14T10:45:49.416057919Z"}
{"log":"594113dd conn=1008 fd=17 closed (connection lost)\n","stream":"stderr","time":"2017-06-14T10:45:49.417348582Z"}
1 Like

I added a new ACL to openLDAP to allow any authenticated user to look up data below “dc=request-tracker,dc=services,o=example,dc=example,dc=com”.

Remember, that ACLs are evaluated in order. That is, the new rule should be before a rule denying access for everyone.

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {1}to dn.subtree="dc=request-tracker,dc=services,o=example,dc=example,dc=com" by users read

would have preferred it, if RT looked up group memberships using the LDAP user defined in the