Oh - you might be on to something here! On v15 it presents the domain name twice as well, in the first instance. Then it binds as 'svc LDAP', successfully. It then performs an LDAP Search Request on my 'mail' attribute.

That returns my account, with a mass of 85 attributes.

It then searches for '<ROOT>', scope baseObject, class *, which is apparently successful, though the matchedDN is blank.

That's where they diverge. v16 unbinds from LDAP, whereas v15... Wow - v15 requests every attribute available in the AD and gets about 1470 packets dumped in its lap... v15 then binds to my user, authenticates, and finishes.

I had to increase the buffer size for the packet capture for this beast. Right - it's going to take me a lot more concentration than I'll be mustering at this time of day. I'm going to try to look through this with a clear head in the morning, but it appears to me that v16 is not receiving something that it expects, whereas v15 is happy to push on and demand 1.8MB of attributes in order to login. :-/

Thanks - I'll update this once I've had a good scour at the packet capture.

If I skip the UPN Suffix on v15, it binds correctly on the first attempt, within 12 packets. Doesn't change anything, but it shows that the login process isn't as ugly as it first seemed!! Okay - tomorrow I'm looking through the big wireshark.

10 days later

Not had a whole lot of time to decypher this, but I've spun up a fresh server and installed a blank copy of OsTicket v1.16.5. Set up the LDAP connector, and added my own username as an agent - it authenticates 100% fine. It appears to do the same as v15 - tries to double up on the domain name, and then performs a (large) LDAP search, but it does get there!

So, I think the best route from here, seeing as I've proved that it can work is for me to compare the databases between the live and the test machines.

It may be worth saying that this used to be a v1.9 installation which has been upgraded, and getting from 1.9 to 1.10 was a headache due to cruft lying around in the database...

The old database had records in ost_config with the plugin.1 namespace and keys of auth, conn_info, ldap and msad - no values. I've removed these, and everything still seems to authenticate. I'll try an update next week once I know it's all good.

Still plugging away at this. I've created a fresh installation of v1.15 - it works, and it can upgrade no problem.
I've exported this clean v1.15 schema from MariaDB, cleared out the database, imported the schema, and then imported the row data from our live system.

So some table is the wrong shape.

A little history on this. As mentioned above, this was a v1.9 installation. I had trouble updating to v1.10, and had to create a clean v1.9 database schema and import the row data in order to be able to upgrade then. So I know the schema hasn't been tampered with since then, other than official upgrades.

I'm going to export the live schema and compare it with the clean v1.15 installation.

    I've created a clone of my 1.15.8 installation, upgraded it to v1.16.5, uninstalled the LDAP plugin, replaced it with this one and configured it, and I'm delighted to say that I have LDAP logins running (for my own user at least) on 1.16.5.

    I'll try this upgrade again tomorrow on the test platform, and I'll report back, but this plugin clearly can work.

    Now that I've got 1.16 running, I've unpacked the 1.17.2 files into my OsTicket installation, but it now won't let me authenticate at all, even to start the upgrade. And that's with either a local or LDAP user. Should I be able to use this?

    I've run the database files through the mangle a few times, so I'll start with a fresh export of that tomorrow, and I can test some more.

    Thanks!

      mhay

      Any external auth via plugin won't work as the plugin backend changed dramatically. So you'll have to use local auth, upgrade, then you should be able to login using external auth. Just make sure you have the new plugins installed (placed in the plugin directory) before upgrading as the system will use the new plugins to fix the configs, user/agent backends, etc.

      If you need to reset your password use any bcrypt generator online with 8 round entropy and replace the current password in the database for your Agent account to the new, hashed password from the generator.

      Cheers.

      • mhay replied to this.

          KevinTheJedi So you'll have to use local auth, upgrade, then you should be able to login.

          Hmm - that's not happening.
          Right, I'm not going to worry about it today. As I say, I've twisted and pulled that database every which way, so I'll start again with a clean copy on Thursday (off work tomorrow), and see how I get on. As I say, though, that updated plugin is working with 1.16.5.

          Cheers!

            I can now confirm that we've updated to v1.16.6 using the interim LDAP plugin release. Testing went fine, and I've updated the live platform. Many thanks for that!

            Can I check, then, should this LDAP plugin work with OsTicket v1.17? Or should I wait until a new release for that? (I'm more than happy to hang on for a new LDAP plugin, now that I'm on a supported version.)

            Cheers!

              mhay

              Yes, that’s what I was testing with. Always try to stay on top of the latest releases as they include improvements, etc.

              Cheers.

                I've installed v1.17.3 now, and LDAP works fine for me on that. I think I had to re-enter the LDAP lookup account's password, but that was about it. It was a bit grumpy after putting the files into place, but I logged in in an incognito browser, and everything seemed to work from there.

                I've got other issues now with email collection, but that's beyond the scope of this, so I'll look for another fix. As far as getting the updates installed, though, the posted LDAP plugin update worked like a champ.

                Thanks for your help - I think we can call this resolved now!

                Write a Reply...