I have a newly installed instance of osticket 1.9.2 running on an Ubuntu 12.04 server at the moment.  The first thing I'm working on is configuring the LDAP settings for authentication.  Our current help desk system (developed in-house) is configured such that when a user is logged on to their work computer with their domain account, the authentication is passed through automatically when they connect to our help desk website (SSO).  I understand that this may not be possible for clients using LDAP and HTTP pass through authentication in osTicket, but I can't even figure out how to allow clients to log in using their AD credentials. I have tested staff logins with LDAP and that appears to work fine (so long as I set them up as a new staff user and define the authentication method as Active Directory).  Ideally, I would like to be able to send the end-users a link to our new help desk and tell them to log in using their AD credentials.  I have tested this after checking the box to enable client LDAP authentication, but when I enter a users AD credentials (both with domain\username and without), I just get an "Access denied" message.  Is there something else I should do so that users can just log straight in if they exist as an AD user?  We have over 300 users, many of whom will change month to month (workers/volunteers hired for specific projects around the country), so I would rather not have to manage the users list manually.Thank you all for any support you can provide.  I'm sure I'm just overlooking something!  I know the LDAP settings are all correct (as is the lookup) because staff authentication is working properly.  

Accounts have to be setup in osTicket before they can authenticate against LDAP/AD.

I see... Does that include a password?  Or, could I just rip a list of usernames and email addresses, then let them log in with their AD passwords?  The issue is that we have a password policy that requires changing your password every 3 months - I don't want that schedule to be out of sync with the help desk. 

The osTicket password doesn't really matter if the AD one works (it defaults to fail over).  But the account in osT currently controls as to if the staff has permission to auth via alternative authentication sources.

Thanks a ton. You've been super helpful!

I try. :)   Anything else I can answer while I'm sitting here wishing that the clock was an hour faster than it currently is?  Or should I close this thread and tell you to open another one if you have another question later. hehehe.

Hah! I feel you.  Well, I ran some tests.  I created a new Staff account with my AD username and email address.  Set that to "use any available backend", and then went to log in to the SCP portal with my AD password.  That worked great!Next, I deleted that staff account, then went to create a new User account (from the Staff Panel).  I clicked Add User, entered the email address and full name.  After saving, I clicked 'Register' and set the auth option to "use any available backend" and changed the username to my AD username.  I then saved the settings and noted that the account was "Active (Registered)".  After that, I loaded up the main client landing page and attempted to signin there with my AD username/password, but none of the information would work.  I then went back to the Staff Panel and managed the new account, manually added a password, and then saved those settings and repeated trying to log in as a Client.  It took my manually entered password, but the AD password just wasn't working.I've searched around a bit, but haven't been able to find any solid answers to my issues.

I've pointed out this thread to the devs so that maybe they can attempt to replicate what you've done, and hopefully they will get back to you on this.

Do you have both staff and client authentication enabled for LDAP authentication when you manage the plugin?

11 days later

Jared, I do have both of those options ticked and I'm using the latest version of osTicket and the latest .phar file for the LDAP plugin.  

10 days later

I'm having the same exact problem, even on v1.9.3. Have you gotten it to work? Any thoughts from a dev?

We fixed it!!!!We had to extract the files from the .phar. Then we edited authentication.php. On line 36 we changed 'email' => 'mail', to 'email' => 'userPrincipalName',Then we recreated the phar and it worked. You do not need to manually create client accounts now. Once you log in they are create for you.

I'm going to attempt this today and report back.  Thanks for the update!

I unpackaged, edited the authentication.php file, and repackaged then uploaded to my server.  Staff authentication still works just fine, but I still can't get client authentication to work.  Just says access denied.  Even when I use the same account info I used to authenticate as Staff... (after deleting the staff account of course).  I also created the account in the Users section of the Staff Panel, registered and set authentication method to Active Directory, tried to log in to submit a new ticket but still get access denied.  This is so frustrating....

2 months later

Dear twjenn2 ,I have the same issue..Are u able to fix it??Please share!!Thankspinty

Pinty, I resolved this, but only by setting the server up on a Windows 2008 R2 server with IIS.  My problems existed while running it on an ubuntu 12.04 LTS server.  After moving to windows, I had no issues with LDAP client authentication...  I was unable to resolve the problems using Ubuntu, but I am far from a Linux/ubuntu expert and am sure I just didn't configure something correctly.

I have this working now, and have run through about 6 test tickets so far. AD users accounts are created on the fly when they first sign into osTicket, and it successfully grabs the user's email from the AD information. I'm still having a couple other issues, but the Active Directory authentication is working fine.Here's my setup:osTicket version: v1.9.3 (bba9ccc) Plugin: LDAP Authentication and Lookup, authenticating against Active Directory on Win Server 2003 R2Apache/2.2.22 (Ubuntu). MySQL Version 5.5.38PHP Version 5.3.10-1ubuntu3.14. IMAP c-Client Version 2007e The Search Base setting gave me issues, but I settled on: cn=Users,dc=myactualdomain.com,dc=com (I also recall reading that it should be all lower case, and no spaces)One other thing I did is added a hosts entry on the Ubuntu box for my DC, and a manual DNS entry for the osTicket machine in the DNS settings of my DC. Not sure if that was needed, as I did it before setting up LDAP.

Thanks guys,Issue resolved.It was due to Search Base entry in Manage--> Plugins --> LDAP Authentication and LookupI changed the entry to :   DC=xyzgroup,DC=comThanks

Write a Reply...