LDAP/Active Directory Server Auth not working on non Standard LDAP Ports.

[jmeinicke]

Describe the bug
!! I'm not a coder, but I had problems with LDAP (AD) with phpipam after I had to switch to a new AD server that doesn't run on a standard port (port 1636). I couldn't log in anymore even though the connection test was okay. Everything was also okay with the settings in ldapsearch. But it was no longer possible to search or log in via phpipam. I spent several hours debugging with claude (Opus 4.1). And ‘we’ came up with the following solution. Please take a look at it. With this fix, I can log in via AD again.!!

phpIPAM fails to authenticate against Active Directory when using LDAPS with a non-standard port (e.g., 1636 instead of 636). The authentication fails with error "Invalid credentials 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1" even though the credentials are correct.
The issue is in the adLDAP library's connection method which incorrectly handles SSL connections with custom ports.
phpIPAM version

Latest production release [1.7.3] via Docker image phpipam/phpipam-www:latest

Your Environment (please supply the following information):

phpIPAM version: 1.7.3
OS: Docker container (Alpine Linux)
PHP version: PHP 8.x (as included in official Docker image)
Webserver: Apache (as included in official Docker image)
Database: MariaDB (via phpipam/phpipam-mariadb Docker image)
Active Directory: Windows Server with LDAPS on port 1636

Steps To Reproduce

Go to 'Administration → Authentication methods'
Add/Edit AD authentication method
Configure with:

Domain Controller: your-dc.domain.com
Use SSL: Yes
AD Port: 1636 (or any non-standard port)
Valid admin credentials

Save and try to search for users or login with AD account
See error: "AcceptSecurityContext error, data 52e, v1db1

Screenshots and error logs
The root cause is in /phpipam/functions/adLDAP/src/adLDAP.php in the connect() function:
Current (broken) code:
phpif ($this->useSSL) {
$this->ldapConnection = ldap_connect("ldaps://".$domainController, $this->adPort);
}
This results in PHP's ldap_connect() being called with separate host and port parameters, which doesn't work correctly for LDAPS with non-standard ports.
Working fix:
phpif ($this->useSSL) {
$this->ldapConnection = ldap_connect("ldaps://".$domainController.":".$this->adPort);
}
The port must be included in the URL string for LDAPS connections to work properly.
Additional Info

Direct LDAP connection using ldap_connect("ldaps://host:1636") works correctly
The issue only affects SSL connections with non-standard ports
Standard port 636 might work due to being the default, but custom ports fail
Tested and confirmed that the fix resolves the issue without affecting standard configurations

Proposed Fix:
Change line in functions/adLDAP/src/adLDAP.php:
diff- $this->ldapConnection = ldap_connect("ldaps://".$domainController, $this->adPort);

• $this->ldapConnection = ldap_connect("ldaps://".$domainController.":".$this->adPort);

[HouseIndoril]

FYI this does also appear to be happening if you use the default port. If I manually tag v1.7.3 we can log in. As soon as I go back to :latest, LDAP login no longer works.

[bberndt]

may i ask, what it is you're doing to "manually tag v1.7.3". forgive me., I don't know anything about git except what im told :)

Also confirm brand new install from git, and have a same problem I suspect, can't connect to AD.

[zaaj]

@bberndt "manually tag v.1.7.3" sounds like HouseIndoril is using git to manage what files are in his web server's phpipam directory. Git can checkout a specific branch / commit of software. Publishers can flag a specific commit with a Tag - commonly used to designate a particular version number.
If one instead just keeps up with current changes ( the ":latest" reference) one can do a git pull to grab any changes since the last time you ran git pull.

I've noticed that I'm not getting any outgoing packets going to our AD domain controllers trying to use LDAPS - the login prompt gives a permission error. I've read that can indicate no write permissions to the /tmp folder, or to whatver path was configured to store session information. Poking around in phpipam's code and config.php, it seems to be configured to use "database" as the session storage location - local logins work OK....

looking at the adLDAP sourceforge page, looks like it hasn't been updated since 2012 - the github repo for the same also shows activity only as recently as 11 years ago - perhaps it's not PHP 8 compatible?