LDAP connection failed

DiscoTurtle

We used this code to extract the files

<?php
try {
 $pharFile = '/var/www/html/osticket/include/plugins/auth-ldap.phar';
 $extractTo = '/var/www/html/osticket/include/plugins/auth-ldap_unpacked';

    if (!file_exists($pharFile)) {
 die("Error: PHAR file not found at " . $pharFile . "\n");
 }
 if (!is_dir($extractTo)) {
 mkdir($extractTo, 0755, true);
 }

    $phar = new Phar($pharFile);
 $phar->extractTo($extractTo);
 echo "Successful extraction of " . $pharFile . "to " . $extractTo . ";
} catch (Exception $e) {
 die("PHAR decompression error: " . $e->getMessage() . "\n");
}
?>

We've added the requested lines to the config.php file.
We renamed the auth-ldap_unpacked directory to auth-ldap
We restarted the httpd and php82-php-fpm services
We added the plugin from the admin interface.
We tried to configure the plugin from the admin interface
Still the same errors
Checking sudo journalctl -u php82-php-fpm -f gives nothing

Strangely, the plugin displays LDAP Authentication and Lookup (1) (defunct - missing) when initially the addition could have been made from the folder containing the files.
From the admin interface it cannot be deleted error 500, only deactivated.

Note the initial permissions on the auth-ldap.phar file
-rw-r--r--. 1 root root 274915 Jul 3, 11:11 auth-ldap.phar
We applied the same permissions to the auth-ldap directory by trying a chmod -R apache:apache /var/www/html/osticket/include/plugins/auth-ldap which changed nothing.

KevinTheJedi

DiscoTurtle

You need to add debug statements around the lines I linked above. When you unpack the plugin you must go to the database, plugin table, remove .phar from the install_path, and set isphar to 0.

Cheers.

DiscoTurtle

KevinTheJedi
UPDATE ost_plugin SET install_path = REPLACE(install_path, '.phar', ''), isphar = 0 WHERE name = 'LDAP Authentication and Lookup';

SELECT id, name, install_path, isphar FROM ost_plugin; +----+--------------------------------+-------------------+--------+ | id | name | install_path | isphar | +----+--------------------------------+-------------------+--------+ | 2 | LDAP Authentication and Lookup | plugins/auth-ldap | 0 | +----+--------------------------------+-------------------+--------+

sudo systemctl restart php82-php-fpm
sudo systemctl restart httpd

The auth-ldap folder is present in the include/plugins folder, which contains the config.php file modified with the requested lines.
It cannot be added from the plugin admin interface. But this morning we did.
There is still a ghost entry corresponding to this morning's addition LDAP Authentication and Lookup (1) (defunct - missing)

KevinTheJedi

DiscoTurtle

What do you mean by config file? You put all plugin contents in the folder.

Cheers.

DiscoTurtle

KevinTheJedi

The contents of the auth-ldap folder

ls -l auth-ldap/
total 36
-rw-r--r--. 1 root root 17427 4 juil. 08:53 authentication.php
-rw-r--r--. 1 root root 9701 4 juil. 08:53 config.php
drwxr-xr-x. 3 root root 17 4 juil. 08:53 include
-rw-r--r--. 1 root root 678 4 juil. 08:53 plugin.php

We've modified the config.php file as you told us.

KevinTheJedi

DiscoTurtle

Okay the way you were saying it made me think you just did the config file. So you are outputting the PEAR error to a file or on screen somewhere and not seeing anything being output?

Cheers.

DiscoTurtle

KevinTheJedi

Yes, if you keep journalctl -u php82-php-fpm -f open, nothing happens.
As mentioned, now we can't add plugin from admin interface and unpack.
When adding a new plugin the folder is not seen (is chown -R apache:apache necessary?).
A residual entry is present due to this morning's addition.
However, it is possible to add the original .phar file

KevinTheJedi

DiscoTurtle

You don’t re-install the unpacked plugin - this is why you modify the record in the db manually to point to the folder instead of the PHAR file.

Cheers.

DiscoTurtle

KevinTheJedi

OK, so what do we do now?

KevinTheJedi

DiscoTurtle

Make sure the db only has one ldap plugin record. Make sure that record has the .phar removed and isphar set to 0. Then add a good debug statement like error_log($r->getMessage()); around the lines I linked above. That should output content to the error log. Also, you errors may not be logged to journal (or not within the fpm namespace) so I would also review the various other error logs like the actual PHP error log file, you web server’s error log file, etc.

Cheers.

DiscoTurtle

KevinTheJedi
How do we trigger the error if we can't manage LDAP Authentication and Lookup in the admin interface?

KevinTheJedi

DiscoTurtle

…you save the plugin details like in your OP.. the method is pre_save which gets called when saving the plugin config.

Cheers.

DiscoTurtle

KevinTheJedi

PHP-FPM switched to TCP: Configuration of PHP-FPM to listen on TCP port 127.0.0.1:9000 instead of a Unix socket, and correction of associated start-up errors.

Apache configured for PHP-FPM (TCP): Set up a dedicated VirtualHost for osTicket (osticket.conf) with SetHandler ‘proxy:fcgi://127.00.1:9000’ so that Apache communicates correctly with PHP-FPM.

Permissions and SELinux corrected: Adjusted file owners (apache:apache) and permissions, and fixed SELinux contexts (httpd_sys_content_t) to ensure Apache access and execution by PHP-FPM. Activation of httpd_can_network_connect for Apache network connections.

Reliable URL access: Harmonisation of the VirtualHost DocumentRoot with the access URL, enabling http://IPserver/info.php and then http://IPserver/ (for osTicket) to function correctly.

Validated operation: info.php is displayed, osTicket is accessible, and the LDAP plugin is activated and configured.
The link works, but when you try to connect with an account from the directory, the request to register an account appears but cannot be successful: Impossible to register the account. See messages below.
no message is displayed.

DiscoTurtle

It actually works, you just need to fill in some information (phone number, email) about the user.
Bypass possible if directory fields are empty?

A priori, only end users (customers) can authenticate with accounts from an LDAP directory and not managers (agents).
Is this a limitation of this plugin?

KevinTheJedi

DiscoTurtle

No, both can login via LDAP if setup right. You also need to make sure the Agents’ Authentication Backend is set to Use Any.

Cheers.

KevinTheJedi

DiscoTurtle

Also, I’ve seen the user registration thing hanging up with needing to fill out fields only twice before. Such a long time ago i don’t remember what the cause nor fix was. It’s an edge-case and I don’t remember if the cause was the environment or what. But it should just auto-register users without them needing to fill anything out.

Cheers.

DiscoTurtle

Users who connect via LDAP are not visible in the administration portal, agents section.
How can I define team members using this access channel?

KevinTheJedi

DiscoTurtle

You can’t. Agents need Departments configured, roles and permissions, etc. You can not automatically create Agents from any external source.

Cheers.

DiscoTurtle

We'd love to see a solution for authenticating users who don't have the email and phone fields filled in the LDAP directory so that they can connect.

KevinTheJedi

DiscoTurtle

Like I said in a previous comment above, it shouldn't happen normally. Normally, any person that doesn't exist as a User in osTicket that authenticates using LDAP (via the Client Portal) should have a User account auto-created and auto-registered without needing to do anything. The issue you are experiencing is an edge-case that I can't remember what the root issue was (wether it was environment related or what). You would need to debug the core code and plugin to see what's going on.

Cheers.