View Issue Details

IDProjectCategoryView StatusLast Update
0022951mantisbtauthenticationpublic2017-05-31 10:37
Reportermbremer Assigned Todregad  
PrioritynormalSeveritymajorReproducibilityalways
Status acknowledgedResolutionopen 
Product Version2.4.1 
Summary0022951: Authentication against LDAP fails when using non-default port numbers
Description

We run our LDAP servers on ports different than the default port 389. This was never an issue in our old Mantis installations (e.g. Mantis 1.2.x running PHP 5.3), because we set in config_inc.php the portnumber in the $g_ldap_server variable as follows:
$g_ldap_server= 'ldap_host:ldap_port';

Older versions of PHP can deal with the host:port syntax without problems when using the ldap_connect() function, but more recent versions of PHP don't allow this syntax anymore. Now you need to specify the function as follows:
ldap_connect(host, port)

As a result we can't connect Mantis anymore to LDAP. I am currently testing with Mantis 2.4.1 and PHP7.1. I am not sure if the ldap_connect() syntax has changed in the PHP 5.4 - 5.6 branch or the PHP 7.0 - 7.1 branch, but given the fact that PHP 7 is the recommended version for Mantis, it is worth mentioning.

To solve the issue I've tested the following:

in config_inc.php I've split the ldap host and port like this:
$g_ldap_server = 'ldap_host';
$g_ldap_port = 'ldap_port';

in core/ldap_api.php around line 62

after:
$t_ldap_server = config_get( 'ldap_server' );

add:
$t_ldap_port = config_get( 'ldap_port' );

then line 64:
$t_ds = @ldap_connect( $t_ldap_server );

is replaced by:
$t_ds = @ldap_connect( $t_ldap_server , $t_ldap_port );

This configuration seems to work fine, but this needs to be verified by the Mantis developers.

Steps To Reproduce

Connect to LDAP on a non-default port, in other words something different than 389. If you only have LDAP running on the default port, you might be able to test it via an SSH tunnel where your local port is different than 389.

TagsNo tags attached.

Activities

dregad

dregad

2017-05-31 09:29

developer   ~0057003

Older versions of PHP can deal with the host:port syntax without problems when using the ldap_connect() function, but more recent versions of PHP don't allow this syntax anymore. Now you need to specify the function as follows:
ldap_connect(host, port)

As a result we can't connect Mantis anymore to LDAP. I am currently testing with Mantis 2.4.1 and PHP7.1. I am not sure if the ldap_connect() syntax has changed in the PHP 5.4 - 5.6 branch or the PHP 7.0 - 7.1 branch, but given the fact that PHP 7 is the recommended version for Mantis, it is worth mentioning.

To my knowledge, the function has not changed since PHP 4. Based on ldap_connect() documentation, the host parameter can be either a hostname, or a full LDAP URI; as mentioned there, hostname:port is not a supported LDAP URI as the schema is missing.

In short, you should set $g_ldap_server = 'ldap://hostname:port';, and there is no need to change MantisBT code.

This is clearly documented in the Admin Guide, $g_ldap_server Specifies the LDAP or Active Directory server to connect to, and must be provided as an URI.

That said, it is true that the ldap.example.com:3268 example is incorrect, I'll fix that.

mbremer

mbremer

2017-05-31 09:58

reporter   ~0057004

Thanks for mentioning the full LDAP URI, I just checked our configuration and indeed by adding ldap:// in front of the hostname:port it all work fine again with the original code. I think the ldap.example.com:3268 syntax was an undocumented feature of the ldap_connect() function, since it does work with older PHP versions., we've used this for many years.
Glad to hear there is a proper fix without a change of th MantisBT code! Thanks for the quick reply.

dregad

dregad

2017-05-31 10:37

developer   ~0057005

Actually, thinking about it, since port parameter is ignored when using an URI, we should be able to support the hostname:port syntax (without schema specification) using a parse_url() call to extract the port number from the ldap_server string.

Issue History

Date Modified Username Field Change
2017-05-30 11:16 mbremer New Issue
2017-05-31 09:29 dregad Assigned To => dregad
2017-05-31 09:29 dregad Status new => acknowledged
2017-05-31 09:29 dregad Note Added: 0057003
2017-05-31 09:58 mbremer Note Added: 0057004
2017-05-31 10:37 dregad Note Added: 0057005