[x] I agree to follow this project's Code of Conduct
Is there an existing issue for this?
[x] I have searched the existing issues
Version
10.0.17
Bug description
Hi,
In the context of securing GLPI connections by transiting from LDAP to LDAPS, i face an issue with this specific use case :
GLPI is plugged to an Active Directory for user's connections,
the AD contains the root domain (rootdomain.lan) and a child domain (child.rootdomain.lan),
and users who connect to GLPI can have their account in both root and child domains.
To be able to identify users from both domain, GLPI's LDAP configuration uses port 3268, which is AD's "Global Catalog" unsecured port. With this configuration, everything works fine.
The problem appears when trying to use the secure 3269 port : then, users from the root domain are still able to connect, but not those from the child domain.
We observe that with the ldapsearch command, the AD responds as expected : only for root domain's accounts with standard LDAP ports, and also for child domain's accounts with global catalog ports.
Without scheme : leads to an LDAP connection test fail
=> We observe that inserting the scheme in the server name seems to change GLPI's behaviour.
So currently it is not possible for users from the child domain to use GLPI if LDAPS is configured.
Relevant log output
In the port "3269 with scheme" config, there are no logs written in mail-error.log, php-errors.log or sql-errors.log files in glpi/files/_log/ directory when trying to connect with the child domain account ; on the screen, only the invalid username or password message appears.
In the event.log file, only one line appears :
[login] 3: Failed connection from ChildDomainAccount from IP [ip_addr]
Configure your LDAP server with the following values : Server: 'ldaps://ldap.rootdomain.lan', Port: '3269', BaseDN: 'DC=rootdomain,DC=lan', Connection filter: none, RootDN:'bindAccount', Use TLS: none
Try to connect to GLPI with an account from child.rootdomain.lan
Your GLPI setup information
GLPI 10.0.17 ( => /var/www/glpi)
Installation mode: TARBALL
Current language:fr_FR
Operating system: Linux SERVERNAME 6.1.0-26-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.112-1 (2024-09-30) x86_64
PHP 8.2.24 apache2handler (Core, FFI, PDO, Phar, Reflection, SPL, SimpleXML, Zend OPcache, apache2handler, bz2, calendar, ctype,
curl, date, dom, exif, fileinfo, filter, ftp, gd, gettext, hash, iconv, intl, json, ldap, libxml, mbstring, mysqli, mysqlnd,
openssl, pcre, pdo_mysql, posix, random, readline, session, shmop, sockets, sodium, standard, sysvmsg, sysvsem, sysvshm,
tokenizer, xml, xmlreader, xmlwriter, xsl, zip, zlib)
Setup: max_execution_time="30" memory_limit="128M" post_max_size="8M" safe_mode="" session.save_handler="files"
upload_max_filesize="2M" disable_functions=""
Software: Apache/2.4.62 (Debian) (Apache/2.4.62 (Debian) Server at glpi.rootdomain.lan Port 443
)
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0
Server Software: Debian 12
Server Version: 10.11.6-MariaDB-0+deb12u1
Server SQL Mode: STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
Parameters: glpi@localhost/glpi
Host info: Localhost via UNIX socket
PHP version (8.2.24) is supported.
Sessions configuration is OK.
Allocated memory is sufficient.
mysqli extension is installed.
Following extensions are installed: dom, fileinfo, filter, libxml, json, simplexml, xmlreader, xmlwriter.
curl extension is installed.
gd extension is installed.
intl extension is installed.
zlib extension is installed.
The constant SODIUM_CRYPTO_AEAD_XCHACHA20POLY1305_IETF_NPUBBYTES is present.
Database engine version (10.11.6) is supported.
No files from previous GLPI version detected.
The log file has been created successfully.
Write access to /var/www/glpi/files/_cache has been validated.
Write access to /var/www/glpi/files/_cron has been validated.
Write access to /var/www/glpi/files has been validated.
Write access to /var/www/glpi/files/_dumps has been validated.
Write access to /var/www/glpi/files/_graphs has been validated.
Write access to /var/www/glpi/files/_lock has been validated.
Write access to /var/www/glpi/files/_pictures has been validated.
Write access to /var/www/glpi/files/_plugins has been validated.
Write access to /var/www/glpi/files/_rss has been validated.
Write access to /var/www/glpi/files/_sessions has been validated.
Write access to /var/www/glpi/files/_tmp has been validated.
Write access to /var/www/glpi/files/_uploads has been validated.
Web server root directory configuration seems safe.
Sessions configuration is secured.
OS and PHP are relying on 64 bits integers.
exif extension is installed.
ldap extension is installed.
openssl extension is installed.
Following extensions are installed: bz2, Phar, zip.
Zend OPcache extension is installed.
Following extensions are installed: ctype, iconv, mbstring, sodium.
Write access to /var/www/glpi/marketplace has been validated.
Access to timezone database (mysql) is not allowed.
htmlawed/htmlawed version 1.2.14 in (/var/www/glpi/vendor/htmlawed/htmlawed)
phpmailer/phpmailer version 6.8.0 in (/var/www/glpi/vendor/phpmailer/phpmailer/src)
simplepie/simplepie version 1.5.8 in (/var/www/glpi/vendor/simplepie/simplepie/library)
tecnickcom/tcpdf version 6.7.5 in (/var/www/glpi/vendor/tecnickcom/tcpdf)
michelf/php-markdown in (/var/www/glpi/vendor/michelf/php-markdown/Michelf)
true/punycode in (/var/www/glpi/vendor/true/punycode/src)
iamcal/lib_autolink in (/var/www/glpi/vendor/iamcal/lib_autolink)
sabre/dav in (/var/www/glpi/vendor/sabre/dav/lib/DAV)
sabre/http in (/var/www/glpi/vendor/sabre/http/lib)
sabre/uri in (/var/www/glpi/vendor/sabre/uri/lib)
sabre/vobject in (/var/www/glpi/vendor/sabre/vobject/lib)
laminas/laminas-i18n in (/var/www/glpi/vendor/laminas/laminas-i18n/src)
laminas/laminas-servicemanager in (/var/www/glpi/vendor/laminas/laminas-servicemanager/src)
monolog/monolog in (/var/www/glpi/vendor/monolog/monolog/src/Monolog)
sebastian/diff in (/var/www/glpi/vendor/sebastian/diff/src)
donatj/phpuseragentparser in (/var/www/glpi/vendor/donatj/phpuseragentparser/src/UserAgent)
elvanto/litemoji in (/var/www/glpi/vendor/elvanto/litemoji/src)
symfony/console in (/var/www/glpi/vendor/symfony/console)
scssphp/scssphp in (/var/www/glpi/vendor/scssphp/scssphp/src)
laminas/laminas-mail in (/var/www/glpi/vendor/laminas/laminas-mail/src/Protocol)
laminas/laminas-mime in (/var/www/glpi/vendor/laminas/laminas-mime/src)
rlanvin/php-rrule in (/var/www/glpi/vendor/rlanvin/php-rrule/src)
ramsey/uuid in (/var/www/glpi/vendor/ramsey/uuid/src)
psr/log in (/var/www/glpi/vendor/psr/log/Psr/Log)
psr/simple-cache in (/var/www/glpi/vendor/psr/simple-cache/src)
psr/cache in (/var/www/glpi/vendor/psr/cache/src)
league/csv in (/var/www/glpi/vendor/league/csv/src)
mexitek/phpcolors in (/var/www/glpi/vendor/mexitek/phpcolors/src/Mexitek/PHPColors)
guzzlehttp/guzzle in (/var/www/glpi/vendor/guzzlehttp/guzzle/src)
guzzlehttp/psr7 in (/var/www/glpi/vendor/guzzlehttp/psr7/src)
glpi-project/inventory_format in (/var/www/glpi/vendor/glpi-project/inventory_format/lib/php)
wapmorgan/unified-archive in (/var/www/glpi/vendor/wapmorgan/unified-archive/src)
paragonie/sodium_compat in (/var/www/glpi/vendor/paragonie/sodium_compat/src)
symfony/cache in (/var/www/glpi/vendor/symfony/cache)
html2text/html2text in (/var/www/glpi/vendor/html2text/html2text/src)
symfony/css-selector in (/var/www/glpi/vendor/symfony/css-selector)
symfony/dom-crawler in (/var/www/glpi/vendor/symfony/dom-crawler)
twig/twig in (/var/www/glpi/vendor/twig/twig/src)
twig/string-extra in (/var/www/glpi/vendor/twig/string-extra)
symfony/polyfill-ctype not found
symfony/polyfill-iconv not found
symfony/polyfill-mbstring not found
symfony/polyfill-php80 not found
symfony/polyfill-php81 not found
symfony/polyfill-php82 in (/var/www/glpi/vendor/symfony/polyfill-php82)
league/oauth2-client in (/var/www/glpi/vendor/league/oauth2-client/src/Provider)
league/oauth2-google in (/var/www/glpi/vendor/league/oauth2-google/src/Provider)
thenetworg/oauth2-azure in (/var/www/glpi/vendor/thenetworg/oauth2-azure/src/Provider)
Anything else?
Nothing to add except a big thank you for GLPI ! And thanks in advance for your help.
Code of Conduct
Is there an existing issue for this?
Version
10.0.17
Bug description
Hi,
In the context of securing GLPI connections by transiting from LDAP to LDAPS, i face an issue with this specific use case :
rootdomain.lan
) and a child domain (child.rootdomain.lan
),To be able to identify users from both domain, GLPI's LDAP configuration uses port 3268, which is AD's "Global Catalog" unsecured port. With this configuration, everything works fine.
The problem appears when trying to use the secure 3269 port : then, users from the root domain are still able to connect, but not those from the child domain.
Below are the results from my tests.
Test commands :
sudo -u www-data ldapsearch -x -b "DC=rootdomain,DC=lan" -D "rootdomain\bindAccount" -H 'ldap://ldap.rootdomain.lan:[$port]' -W '(|(sAMAccountName=[$account]))' -v
sudo -u www-data ldapsearch -x -b "DC=rootdomain,DC=lan" -D "rootdomain\bindAccount" -H 'ldaps://ldap.rootdomain.lan:[$port]' -W '(|(sAMAccountName=[$account]))' -v
We observe that with the ldapsearch command, the AD responds as expected : only for root domain's accounts with standard LDAP ports, and also for child domain's accounts with global catalog ports.
With standard LDAP ports :
Server: '[ldap://]ldap.rootdomain.lan', Port: '389', BaseDN: 'DC=rootdomain,DC=lan', Connection filter: none, RootDN:'bindAccount', - Use TLS: none
Server: 'ldaps://ldap.rootdomain.lan', Port: '636', BaseDN: 'DC=rootdomain,DC=lan', Connection filter: none, RootDN:'bindAccount', Use TLS: none
=> GLPI works as expected with the standard LDAP ports
With Active Directory global catalog ports :
Server: 'ldap://ldap.rootdomain.lan', Port: '3268', BaseDN: 'DC=rootdomain,DC=lan', Connection filter: none, RootDN:'bindAccount', Use TLS: none
Server: 'ldap.rootdomain.lan', Port: '3268', BaseDN: 'DC=rootdomain,DC=lan', Connection filter: none, RootDN:'bindAccount', Use TLS: none
Server: 'ldaps://ldap.rootdomain.lan', Port: '3269', BaseDN: 'DC=rootdomain,DC=lan', Connection filter: none, RootDN:'bindAccount', Use TLS: none
=> We observe that inserting the scheme in the server name seems to change GLPI's behaviour.
So currently it is not possible for users from the child domain to use GLPI if LDAPS is configured.
Relevant log output
Page URL
https://glpi.rootdomain.lan/front/login.php
Steps To reproduce
Server: 'ldaps://ldap.rootdomain.lan', Port: '3269', BaseDN: 'DC=rootdomain,DC=lan', Connection filter: none, RootDN:'bindAccount', Use TLS: none
child.rootdomain.lan
Your GLPI setup information
Anything else?
Nothing to add except a big thank you for GLPI ! And thanks in advance for your help.