ldap not enter whit user

leo425

Hey guys,

I configured ldap but when I access as user, I can only access using domain\user, is there any way to access using only user

That way you don't access

In this way access

KevinTheJedi

leo425

I'm far from an AD expert but I believe you can edit your LDAP plugin config and modify the Search Base to only search that particular group.

@ntozier any thoughts?

Cheers.

leo425

KevinTheJedi

Thanks for the answer,

Yes, I modified the search base, to search only one group but without success.

One thing I noticed is that I don't need to put domain\user, if I just put \user it works.

KevinTheJedi

leo425

So your issue is addressed then, right? As you wanted to login with just user instead of group\user.

Cheers.

leo425

KevinTheJedi

yes but to know if there would be any option for us to remove this \user and leave only the user.

leo425

KevinTheJedi

I downgraded to the rc3 version, and I noticed it's working perfectly

leo425

KevinTheJedi
Hello guys, what was updated to version 1.17, but this problem continues to happen, as I reported in version rc3 is working correctly

KevinTheJedi

leo425

I cannot replicate your issue. I'm using OpenLDAP and v1.17 stable and I'm able to authenticate using only the username and password from LDAP. Below is my configuration.

If all else fails you can contact your AD admin for further assistance.

Cheers.

dgcupit

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?

KevinTheJedi

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.

dgcupit

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.

pcjkollmorgen

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.

KevinTheJedi

pcjkollmorgen

Okay yea that was my suspicion. You see the backend for the top account has p then the plugin ID then i then the instance ID added to it. So the other ones it doesn’t know which plugin and which instance to use so it must be defaulting to something else or back to local login. So you can simply run an SQL query to update all user account with backend equal to ldap.client to the value set for the working account. Then everything should be good. We can look at writing and upgrader script to do this upon upgrade but for now running the query manually will do.

Cheers.

davidbuzz

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

dgcupit

No, but it's quite simple. You need to find a working user and copy their backend (eg. ldap.client.p123i123). Then you need to run a query like:

UPDATE `ost_user_account` SET `backend` = 'ldap.client.p123i123' WHERE `backend` = 'ldap.client';

For agents do the same thing but the query will look like:

UPDATE `ost_staff` SET `backend` = 'ldap.p123i123' WHERE `backend` = 'ldap';

Cheers.

dgcupit

KevinTheJedi

"You need to find a working user" - Can you clarify how I can find this person? Do you mean just identify a user, or is this something I'm supposed to look for in the DB, and if so, how?

I have a feeling this is beyond my abilities, as 'Then you need to run a query like' would require me to know what I am doing, which clearly I do not.

leo425

KevinTheJedi

Thanks for the help worked perfectly! 😃

MarkMansveld

We do not have a working user in the table, they all have ldap.client as a backend. Any way to find out what the plugin id and instance id are?

KevinTheJedi

MarkMansveld

Yes, there are three ways.

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.
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.
(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

KevinTheJedi Kevin,

Is there any plans to make a GUI-Selectable choice in the Admin panel for the client logins, or just a universal preference for login authentication first-try, where we can set LDAP as first try, then Internal Auth as 2nd, etc?

Basically, I'd like to not have to rummage thru the database, as I'm not skilled in doing so, in order to get the users to LDAP login without having to specify the domain\id

MarkMansveld

KevinTheJedi
This worked for us. Thanks

KevinTheJedi

dgcupit

We can add it to the feature request list for possible future development in v2.0. Stay tuned!

Cheers.

dgcupit

KevinTheJedi Would anyone be able to assist me in writing a script to fix whatever needs to be fixed on my system?

Here's a further question - If I delete a client from the Helpdesk, and then have that same user login again, will that fix the need for the domain? I ask because I created a test user in AD and logged into the Helpdesk with no need for specifying the domain, and I was surprised to see that it said that this test user had existing tickets. I clicked on them and it appears to be tickets created by my agent account, since for the test user account I put my agent email address. So it seems like the Helpdesk thinks that this test account owns these tickets due to the email address matching? So, if I delete a user from osTicket that has existing tickets in the system, and then have them login to the helpdesk again, will it allow them to login without the need for the domain, and will it still locate all of their previous tickets due to the email address matching in AD?