LDAP auth not working in 1.9.4, same config works in 1.7.1

[jberanek]

Hi, I have an installation of 1.7.1 on a server, configured to use our campus LDAP for authentication. It has worked as expected for many years.

I'm trying to upgrade to 1.9.4. The new version is installed on the same server, with an (upgraded) copy of the old versions database. It works as expected, but I can't authenticate. I get "Unknown User". The LDAP configuration lines in config.inc.php (host, v3, tls, base_dn, user_attrib, dn_search_dn, dn_search_password) are identical in the old and new versions.

When I set ldap_debug = true in the new version, I get these five lines logged when the authentication attempt fails:

[Mon Sep 13 14:58:36.498473 2021] [php7:notice] [pid 19031] [client 142.104.150.6:33152] [MRBS DEBUG] MRBS\\Auth\\AuthLdap->action(737): got LDAP connection using ldaps://ldap1p.uvic.ca:389

[Mon Sep 13 14:58:36.498509 2021] [php7:notice] [pid 19031] [client 142.104.150.6:33152] [MRBS DEBUG] MRBS\\Auth\\AuthLdap->action(801): constructed dn 'uid=sagordon,ou=people,dc=uvic,dc=ca' and user_search 'uid=sagordon' using 'uid'

[Mon Sep 13 14:58:36.498529 2021] [php7:notice] [pid 19031] [client 142.104.150.6:33152] [MRBS DEBUG] MRBS\\Auth\\AuthLdap::validateUserCallback(237): base_dn 'ou=people,dc=uvic,dc=ca' dn 'uid=sagordon,ou=people,dc=uvic,dc=ca' user 'sagordon'

[Mon Sep 13 14:58:36.647336 2021] [php7:notice] [pid 19031] [client 142.104.150.6:33152] \nE_USER_WARNING in /usr/local/apache2/htdocs-webapp/sagordon/meeting/lib/MRBS/Auth/AuthLdap.php at line 862\nCan't contact LDAP server\nMRBS GET: Array\n(\n)\nMRBS POST: Array\n(\n    [csrf_token] => c13b46c6d4de4c404074604e2bb7b2447607298268af7b0739b13a6cf56df406\n    [returl] => https://webapp.library.uvic.ca/sagordon/meeting/\n    [target_url] => edit_entry.php?view=day&year=2021&month=09&day=13&area=1&room=3&hour=9&minute=30\n    [action] => SetName\n    [username] => ****\n    [password] => ****\n)\nMRBS SESSION: Array\n(\n    [csrf_token] => c13b46c6d4de4c404074604e2bb7b2447607298268af7b0739b13a6cf56df406\n)\n\n

[Mon Sep 13 14:58:36.647366 2021] [php7:notice] [pid 19031] [client 142.104.150.6:33152] [MRBS DEBUG] MRBS\\Auth\\AuthLdap::validateUserCallback(309): bind to 'uid=sagordon,ou=people,dc=uvic,dc=ca' failed: Can't contact LDAP server

Any idea why this is happening? Thanks,

Sandy

Reported by: *anonymous

Original Ticket: mrbs/support-requests/2419

[jberanek]

The error message is saying that it can't contact the LDAP server. Is your 1.7.1 system still there? Is it working? What output do you get if you set $ldap_debug = true; on the 1.7.1 system?

Original comment by: campbell-m

[jberanek]

Hi, Yes, the 1.7.1 system is still running on the same server, using the same LDAP directory. When I set ldap_debug = true and authenticate there I get:

[Tue Sep 14 10:17:01.375892 2021] [php7:notice] [pid 30668] [client 142.104.150.6:34978] authLdapAction: Got LDAP connection

[Tue Sep 14 10:17:01.375930 2021] [php7:notice] [pid 30668] [client 142.104.150.6:34978] authLdapAction: Constructed dn 'uid=sagordon,ou=people,dc=uvic,dc=ca' and user_search 'uid=sagordon' using 'uid'

[Tue Sep 14 10:17:01.375950 2021] [php7:notice] [pid 30668] [client 142.104.150.6:34978] authValidateUserCallback: base_dn 'ou=people,dc=uvic,dc=ca' dn 'uid=sagordon,ou=people,dc=uvic,dc=ca' user 'sagordon'

[Tue Sep 14 10:17:01.518934 2021] [php7:notice] [pid 30668] [client 142.104.150.6:34978] authValidateUserCallback: Successful authenticated bind with no $ldap_filter

The authentication is successful.

Sandy

Original comment by: *anonymous

[jberanek]

If I had to have a guess, I'd guess the new system is somehow not trusting the TLS certificate of the LDAP server, though that does seem less likely if the 2 systems are on the same server. Do they both use the same PHP?

Original comment by: jberanek

[jberanek]

However, I must say that an LDAP URL of ldaps://whatever:389 looks a little odd, as that's instructing the LDAP client to do explicit TLS, which is not normally what servers do on port 389, which is implicit/STARTTLS. However, I'm not sure we handle the URL any differently been the 2 MRBS versions

Original comment by: jberanek

[jberanek]

However, I'm not sure we handle the URL any differently been the 2 MRBS versions

Ah, that could be the problem as we do in fact handle them differently. In 1.9.4 you might need to set the scheme and port explicitly:

// Where is the LDAP server.   This should ideally consist of a scheme and
// a host, eg "ldap://foo.com" or "ldaps://bar.com", but just a hostname
// is supported for backwards compatibility.
// This can be an array.
//$ldap_host = "localhost";

// If you have a non-standard LDAP port, you can define it here.
// This can be an array.
//$ldap_port = 389;

If you don't set the scheme explicitly the code makes an educated guess based on the port.

Original comment by: campbell-m

[jberanek]

Hi John, Yes, both on the same server, both using the same PHP 7.4.14. The config.inc.php host line is: $ldap_host = "ldaps://ldap1p.uvic.ca"; with no explicit $ldap_port setting, so I don't know where the 389 is coming from. Sandy

Original comment by: *anonymous

[jberanek]

Looks like there's a bug in the code. It is assuming port 389. Try setting

$ldap_port = 636;

Original comment by: campbell-m

[jberanek]

I've set the port explicitly to 636. The authentication still fails, but I no longer see the 'Unknow User' message. There's no error message displayed, just back to the login page.

In the logs I now get:

[Tue Sep 14 11:26:52.789941 2021] [php7:notice] [pid 3240] [client 142.104.150.6:35596] [MRBS DEBUG] MRBS\\Auth\\AuthLdap->action(737): got LDAP connection using ldaps://ldap1p.uvic.ca:636

[Tue Sep 14 11:26:52.789989 2021] [php7:notice] [pid 3240] [client 142.104.150.6:35596] [MRBS DEBUG] MRBS\\Auth\\AuthLdap->action(801): constructed dn 'uid=sagordon,ou=people,dc=uvic,dc=ca' and user_search 'uid=sagordon' using 'uid'

[Tue Sep 14 11:26:52.790016 2021] [php7:notice] [pid 3240] [client 142.104.150.6:35596] [MRBS DEBUG] MRBS\\Auth\\AuthLdap::validateUserCallback(237): base_dn 'ou=people,dc=uvic,dc=ca' dn 'uid=sagordon,ou=people,dc=uvic,dc=ca' user 'sagordon'

[Tue Sep 14 11:26:52.918723 2021] [php7:notice] [pid 3240] [client 142.104.150.6:35596] [MRBS DEBUG] MRBS\\Auth\\AuthLdap::validateUserCallback(249): successful authenticated bind with no $ldap_filter

[Tue Sep 14 11:26:52.919028 2021] [php7:notice] [pid 3240] [client 142.104.150.6:35596] [MRBS DEBUG] MRBS\\Auth\\AuthLdap->action(737): got LDAP connection using ldaps://ldap1p.uvic.ca:636

[Tue Sep 14 11:26:52.919051 2021] [php7:notice] [pid 3240] [client 142.104.150.6:35596] [MRBS DEBUG] MRBS\\Auth\\AuthLdap->action(801): constructed dn 'uid=sagordon,ou=people,dc=uvic,dc=ca' and user_search 'uid=sagordon' using 'uid'

[Tue Sep 14 11:26:52.919089 2021] [php7:notice] [pid 3240] [client 142.104.150.6:35596] [MRBS DEBUG] MRBS\\Auth\\AuthLdap::getUserCallback(386): base_dn 'ou=people,dc=uvic,dc=ca' dn 'uid=sagordon,ou=people,dc=uvic,dc=ca' user_search 'uid=sagordon' user 'sagordon'

[Tue Sep 14 11:26:52.930676 2021] [php7:notice] [pid 3240] [client 142.104.150.6:35596] [MRBS DEBUG] MRBS\\Auth\\AuthLdap::getUserCallback(442): 1 entries found

[Tue Sep 14 11:26:52.930700 2021] [php7:notice] [pid 3240] [client 142.104.150.6:35596] [MRBS DEBUG] MRBS\\Auth\\AuthLdap::getUserCallback(449): ldap_read() succeeded, taking 0.011183977127075 seconds

[Tue Sep 14 11:26:52.930754 2021] [php7:notice] [pid 3240] [client 142.104.150.6:35596] [MRBS DEBUG] MRBS\\Auth\\AuthLdap::getUserCallback(475): No username found.  Check the value of $ldap_user_attrib in the MRBS config file. It is currently set to 'uid'.

So the search appears to succeed (1 entries found), but then something fails retrieving the username. 'uid' is the correct attribute. That's what we use in the 1.7.1 system where it works as expected.

Original comment by: *anonymous

[jberanek]

Try setting

$ldap_debug_attributes = true;

and see if the username attribute is being returned on the read. It's possible it's not if your server is treating this as an anonymous bind. If that's the case have you got $ldap_dn_search_attrib set? See also https://sourceforge.net/p/mrbs/support-requests/2409/.

Be warned, $ldap_debug_attributes will return a lot of confidential information so don't post it here!

Original comment by: campbell-m

[jberanek]

Hi Campbell, I've set $ldap_dn_search_attrib = "uid" and the authentication is now working. Previously I only had $ldap_user_attrib = "uid" which was sufficient in 1.7.1.

Thanks for your help getting this sorted out. Sandy

Original comment by: *anonymous

[jberanek]

OK, good, glad it's working. I'll fix the port bug.

Original comment by: campbell-m

[jberanek]

Fixed in 648b3c9.

Original comment by: campbell-m

[jberanek]

So, for as long as I can remember, $ldap_user_attrib and $ldap_dn_search_attrib have been mutually exclusive, as they change the way LDAP authentication works so much. I say this as the person who wrote much of the extra LDAP code a fair number of years ago. What was never made clear enough I believe was the documentation - I went back to the text in systemdefaults.inc.php from 1.7.1, and it's certainly not clear then:

https://github.com/meeting-room-booking-system/mrbs-code/blob/mrbs-1_7_1/web/systemdefaults.inc.php#L763

I don't know if you can read PHP well enough to appreciate the 'if' statement linked to here:

https://github.com/meeting-room-booking-system/mrbs-code/blob/mrbs-1_7_1/web/auth/auth_ldap.inc#L166

If $ldap_dn_search_attrib is defined, then it is used to find a user in the directory and then authenticate as that user. If it is not, then you get to the else clause at:

https://github.com/meeting-room-booking-system/mrbs-code/blob/mrbs-1_7_1/web/auth/auth_ldap.inc#L211

and instead $ldap_user_attrib is used to create the DN which is authenticated against in the directory[edited twice!].

Original comment by: jberanek

[jberanek]

I won't drone on too much more, but it's worth saying that what I've said above about MRBS 1.7.1 also goes for MRBS 1.9.4.

Original comment by: jberanek

[jberanek]

I won't drone on too much more, but it's worth saying that what I've said above about MRBS 1.7.1 also goes for MRBS 1.9.4.

Except that Sandy's config, once the port problem was fixed, worked in 1.7.1 and not in 1.9.4 - and other users have been reporting similar issues. I think I may have introduced changes between 1.7.1 and 1.9.4 which have changed the behaviour slightly.

Original comment by: campbell-m

[jberanek]

Indeed, which is why I've been sat here comparing the code in 1.7.1 and 'main' - I still don't see it. Baffled.

Original comment by: jberanek

[jberanek]

This little bit of debug from the original report is the telling bit that shows the "wrong" sort of LDAP search behaviour was being used on the 1.9.4 installation, namely the "constructed dn":

constructed dn 'uid=sagordon,ou=people,dc=uvic,dc=ca'

Original comment by: jberanek