Fresh RT 5.0.1 Install, 'Can't get LDAP Authentication Working

I just did a fresh install of RT 5.0.1 served via Apache2, on Ubuntu 20.04.

I installed from source, and made sure to get all dependencies noted by a ‘make testdeps’ installed and all is well, I can login with the root user, and everything seems to be working properly.

However, when trying to get LDAP authentication working, I just can’t seem to figure out what I’m missing. I read through the documentation, but I’m unable to login at the RT login page with an LDAP user.

The RT log shows:

…[debug]: Attempting to use external auth service: My_LDAP (/opt/rt5/sbin/…/lib/RT/Authen/ExternalAuth.pm:364)

[debug]: Calling UserExists with $username (myldapuser) and $service (My_LDAP) (/opt/rt5/sbin/…/lib/RT/Authen/ExternalAuth.pm:405)

[debug]: UserExists params: username: myldapuser , service: My_LDAP (/opt/rt5/sbin/…/lib/RT/Authen/ExternalAuth/LDAP.pm:527)

[critical]: RT::Authen::ExternalAuth::LDAP::_GetBoundLdapObj Can’t bind: LDAP_INVALID_CREDENTIALS 49 (/opt/rt5/sbin/…/lib/RT/Authen/ExternalAuth/LDAP.pm:719)

[debug]: Autohandler called ExternalAuth. Response: (0, No User) (/opt/rt5/share/html/Elements/DoAuth:58)

[error]: FAILED LOGIN for myldapuser from 10.105.1.100 (/opt/rt5/sbin/…/lib/RT/Interface/Web.pm:840)…

My SiteConfig file (/opt/rt5/etc/RT_SiteConfig.pm) has:

Set( $rtname, ‘my-domain-here’);
Set( $Organization, ‘my-domain-here’ );
Set( $WebDomain, ‘my-webdomain-here’ );

1;
Set($LogToFile, ‘debug’);
Set($LogToFileNamed, ‘help.example.net.log’);
Set($LogDir, ‘/var/log/rt5’);

Then I put a file in for my LDAP config (/opt/rt5/etc/RT_SiteConfig.d/LDAP_Config.pm), and it has:

Set($ExternalAuthPriority, [ ‘My_LDAP’,
‘My_MySQL’,
‘My_SSO_Cookie’
]
);

Set($ExternalInfoPriority, [ ‘My_LDAP’,
‘My_MySQL’,
]
);

Set($LDAPHost, ‘my-ldap-server-fqdn-here’);
Set($LDAPUser, ‘CN=binduser,DC=users,DC=example,DC=net’);
Set($LDAPPassword, ‘binduserpassword’);

Set($LDAPBase, ‘CN=Users,DC=example,DC=net’);
Set($LDAPFilter, ‘(&(objectClass=person))’);
Set($LDAPMapping, {Name => ‘userPrincipalName’,
EmailAddress => ‘mail’,
RealName => ‘name’});
Set($LDAPCreatePrivileged, 1);
Set($LDAPUpdateUsers, 1);

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);

LDAP configuration

Set($ExternalSettings, {
‘My_LDAP’ => {
‘type’ => ‘ldap’,
‘tls’ => 0,
‘server’ => ‘my-ldap-server-fqdn-here’,
‘user’ => ‘CN=binduser,DC=users,DC=example,DC=net’,
‘pass’ => ‘binduserpassword’,
‘base’ => ‘CN=users,dc=example,dc=net’,
‘filter’ => ‘(objectClass=*)’,
‘attr_match_list’ => [
‘Name’,
‘EmailAddress’,
],
‘attr_map’ => {
‘Name’ => ‘userPrincipalName’,
‘EmailAddress’ => ‘mail’,
‘RealName’ => ‘name’,
},
},
});

If anyone has any ideas on what my issue could be, I would be very grateful for your input.

Thanks.

Seems your LDAP credentials are invalid^

Right… I appreciate you taking the time to reply, but I have verified that that is not the case. It’s possible something is triggering that because of a TLS problem, me using the wrong syntax for the full distinguished name of the user or search base, etc. But the actual user that’s put in there (either to authenticate the bind, or the user trying to log in at the website), I’m sure the passwords being used are correct.

Can you confirm that you can connect with ldapsearch from the CLI using your username/password?

Yep. If I run:

ldapsearch -x -b “cn=users,dc=amplebay,dc=net” -H ldap://addc1.amplebay.net -D “CN=binduser,CN=Users,DC=amplebay,DC=net” -W

And provide the password to “binduser” when the command prompts for password, it successfully pulls the info.

Do you know if RT (or I guess in this case perl) is able to ignore the LDAP server’s self signed certificate?

I have some PHP apps that I had to configure the server to ignore certificate validation by placing “TLS_REQCERT never” into /etc/ldap/ldap.conf (in fact that’s required for ldapsearch to successfully query).

I also have another Tomcat/Java app, where I had to manually trust, and import the certificate into the Java keystore, but after doing this, it also worked without issue.

I thought I read in the documentation that RT (ExternalAuth.pm at least) was ok with self signed certs by default. I also tried manually telling it to not check the cert (in RT_SiteConfig.d/LDAP_Config.pm) with:

‘tls’ => 0,

Just to confirm this is a TLS issue, if you set tls to 1 do you still see the same error or a new one?

I left everything the same and changed only the “tls” parameter from 0 to 1 in the RT_SiteConfig.d/LDAP_Config.pm:

‘tls’ => 1,

The log still shows the same:

…[debug]: Attempting to use external auth service: My_LDAP (/opt/rt5/sbin/…/lib/RT/Authen/ExternalAuth.pm:364)

[debug]: Calling UserExists with $username (jjewett) and $service (My_LDAP) (/opt/rt5/sbin/…/lib/RT/Authen/ExternalAuth.pm:405)

[debug]: UserExists params: username: jjewett , service: My_LDAP
(/opt/rt5/sbin/…/lib/RT/Authen/ExternalAuth/LDAP.pm:527)

[critical]: RT::Authen::ExternalAuth::LDAP::_GetBoundLdapObj Can’t bind: LDAP_INVALID_CREDENTIALS 49 (/opt/rt5/sbin/…/lib/RT/Authen/ExternalAuth/LDAP.pm:719)

[debug]: Autohandler called ExternalAuth. Response: (0, No User) (/opt/rt5/share/html/Elements/DoAuth:58)

[error]: FAILED LOGIN for jjewett from 10.105.1.100 (/opt/rt5/sbin/…/lib/RT/Interface/Web.pm:840)…

Just to confirm you do have CN=binduser,CN=Users,DC=amplebay,DC=net” as the bind user in your RTSiteConfig.pm, not, CN=binduser,DC=users,DC=example,DC=net? And the base is set to cn=users,dc=amplebay,dc=net?

I’ve also had issues in the past with being able to construct outgoing network connections from Apache webservers due to default security policies (on CentOS Linux for example). You might want to check that’s OK, especially if SELinux is turned on. Something like setsebool -P httpd_can_network_connect 1 might help.

Great catch! I actually ended up catching that myself Friday at the end of the day, and hadn’t had time to update the post yet.

I had multiple issues at first install, but after having worked through them at some point that type-o (mistakenly have “users” container in my distinguished name misidentified with DC instead of the correct syntax of CN=users) made it’s way into my config, and it became the issue.

Thanks for the reply though!

Closing this issue now.

1 Like