I'm seeing the same issue on 1.17 - SOME users must put domain\id in order to login.

This is odd because I have not seen this issue before on the old server (still running 1.11)

My environment is this. I setup a new Ubuntu 22.04 Server VM and installed the latest 1.17 release, brought over my DB from the old server, and the 1.17 DB upgrade succeeded. So I configured the LDAP plugin just as it was configured on the old osticket system (which was on a Win 2016/IIS server). However, some - not all - users are not able to login unless they specify the domain name.

Once logged in, users can see their old closed tickets, create or update existing tickets that came over with the DB import, etc.

Looking at their accounts in the directory, I don't see a difference from a user that does vs a user that does not need the domain\ for logging in.

Everything in v1.17 seems to be working great, but I have yet to make this the Prod helpdesk due to this domain login issue. So I'm still hitting it via IP instead of intranet url.

Any suggestions?

dgcupit

Can you look at the backend for the Users in the ost_user_account table? Want to see if the ones having to do full domain and username is related to ones with backend set to old way instead of new way with multi-instance.

Cheers.

We are seeing the same issue.

Some people have used their email address as their username.

The top account worked without needing any prefix to the username, however that is likely because I've not signed in with that account before until today.

Our LDAP Schema setting in the plugin settings is set to Microsoft Active Directory.

I fixed it in my private branch to not require plugins naming conventions in getAllowedBackends() and getBkId() to be a precise match... allowing the old and new format/s to match as "close enough"... it a bit verbose with a few extra intermediate variables than it had before, so that debugging is easier. :-) Feel free to use this, or take inspiration from it.... or to improve the plugin migration code to upgrade plugin names . applying this diff "worked for me".

diff --git a/include/class.auth.php b/include/class.auth.php
index 6039b24..1ff487a 100644
--- a/include/class.auth.php
+++ b/include/class.auth.php
@@ -327,10 +327,19 @@ abstract class AuthenticationBackend extends ServiceRegistry {
             return false;
 
         $backends =  static::getAllowedBackends($username);
-        foreach (static::allRegistered() as $bk) {
+        $x = static::allRegistered();
+        foreach ($x as $bk) {
+
+            $y = $bk->supportsInteractiveAuthentication();
+            $ii = $bk->getBkId(); //might not be formatted the same as the $backends array, with or without the .pXXiYY extension.
+            $z = in_array($ii, $backends); //check if the backend is in the list of allowed backends for this user - exact check first.
+            foreach ($backends as $idx => $val ) { // fuzzy check by prefix, allowing either of the strings to be a prefix of the other.
+                if ( stripos($val, $ii) === 0 ) { $z = true; break;}
+                if ( stripos($ii, $val) === 0 ) { $z = true; break;}
+            }
             if ($backends //Allowed backends
-                    && $bk->supportsInteractiveAuthentication()
-                    && !in_array($bk->getBkId(), $backends))
+                    && $y
+                    && !$z)
                 // User cannot be authenticated against this backend
                 continue;

KevinTheJedi

Well, I would, but I'm no expert at SQL, so I'm not sure how I'd go about doing it. Do you have a query I could run to gather the info you're requesting?

Seems like there should be an LDAP checkmark in the user's account, or some front-end method to set the auth method, as you have in the Agents account settings, or better a universal first-method for auth configuration. LDAP first, internal 2nd, etc.

MarkMansveld

Yes, there are three ways.

1. Login as an ldap user in the client portal that does not already exist in osticket. This will create a new account with the appropriate backend.
2. If you have LDAP available for agents you can go to any agent account in the admin panel, right click the Authentication drop-down, click Inspect to view the raw HTML, and look at the name for the ldap selection.
3. (Probably easiest) Go to the database, go to the plugin table, note the ldap plugin id (eg. 3), go to the plugin_instance table, search for where plugin_id equal to the ID of the plugin, and note the instance id (eg. 6). Now in my example query just replace p123i123 with the IDs you copied (eg. ldap.client.p3i6).

For agents you can simply set any agents Authentication dropdown to LDAP and view their account in the database and they should have the appropriate backend set.

Cheers.

dgcupit

If you delete a user from the helpdesk it requires the deletion of all associated tickets as well. So no, if you delete the user you will lose their tickets.

We can do so with our Professional Support services (go to our website and fill out the Contact Us form to submit a request) but honestly it's rather simple with the steps I outlined above; I even provided the queries you'll need.

Otherwise you can wait for a community member to chime in here for further assistance.

Cheers.