[MOD] LDAP Authentication

This MOD was programmed for the company that I'm employed at, to ease access to osticket for our users.

A Warning first: If you use osticket for external users or customers, you should at least force https on your webserver. You don't want to send your username+password in plaintext.

Required to use this mod:php ldap extension in php.ini

Installation Instructions:[LIST=1][*]Make sure you have the php ldap extension enabled[*]Create a backup of your osticket folder and the database[*]If you don't have any other mods installed or are sure that the files this mod provides don't influence your other mods, you can simply overwrite your osticket files with those in the *.zip. Otherwise you'll have to apply the changes by hand (PHP knowledge required).[*]After you've installed this mod you have to log into scp[*]Go to Admin-Panel[*]Go into the Settings, there you'll find the ldap settings.[*]You'll have to click on 'New LDAP Cconnection' and set everything there.[*]Save and test your Settings with LDAP Diagnostic. In LDAP Diagnostic choose a field you want to display the content of, for example 'cn'. If you get the expected content the settings correct.[/LIST]

To enable your staff/support crew to log in to scp with ldap credentials you have to create them like you usually do in osticket, with one catch, the username has to be exactly the same as in your ldap server. Osticket also compares the username you've entered in scp and will abort the log in if it doesn't find the username. I've left that in to enable admins/staff to log in without ldap even if it's configured.

You can set up multiple ldap connections to different domains. Set them up with a priority and this mod will try to log in to them with the entered username one after another. If all log in to ldap entries fails this mod will try to log in to osticket the old way (it assumes you didn't enter a ldap username).This has a downside. If multiple ldap domains have the same username, but with a different password (example: Administrator) and you log in to domain with priority 3, let's say 10 times, that user will probably be locked in the domains with priority 1 and 2.So make sure that doesn't happen. I warned you.

Other features:Client-side authentication with ldap credentials can be toggled. It's a global setting, if at least one ldap connection has it set to on it'll be on.

You can let this mod automatically complete a part of the Ticket-Form. It can fetch the Full Name+Email-Address+Phone Number of Clients/Users. This requires (obviously) Client-side authentication to be on in that connection.

You can also force Client-side authentication. This'll restrict Ticket creation to only those Users/Clients, that can log in.

Autofill will only be used with the first ticket, that the user/customer creates. After that osticket will Autofill by itself. That also means that Autofill will not work for the users, that had tickets prior to this mod.

How Client Log on works:It's a simplified version without sso and various other stuff. [LIST=1][*]A guest can create tickets without logging in, that is if you don't force clients to log in. But he has to fill the fields by himself, since osticket doesn't know him.[*]If a user logs in instead of using the username+pw that the user typed in to log into osticket, the ldap mod uses that to try and log the user into an ldap session. And if a valid ldap session could be created the ldap mod closes that session, then uses the admin credentials to fetch the email of the user. At this point i assume you have the client autofill feature on. The mod checks if he already has tickets, if thats the case 3. happens, else 4 happens[*]The mail of the user and a ticketid of the user are userd to log him into osticket. The user will then be redirected to the overview of his tickets and can create new tickets (see 5.), look at his tickets or log out.[*]The ldap mod creates a new ticket for this user (subject is ldap_temporary) with all the info the ldap mod can get (first name + last name, phone, phone_ext), then fetches the ticket_id of that new ticket, creates a new session for that user as if he logged in with email+ticketid and finally redirects him to open.php (the create ticket page). Then happens 5.[*]Osticket sees that this is a user with a valid session (requires a ticket) and tries to autofill the fields with the known info in the tickets of the user. Then step 6.[*]Osticket creates a new ticket for that user. On creation of the new ticket the ldap mod checks, if the user has any tickets with the subject ldap_temporary and deletes them. At this point they are not needed anymore.[/LIST]

LDAPS/LDAP over SSL:This Feature requires the openssl php extension and correct setup of openssl.Here is an example on openssl configuration for ldaps: http://greg.cathell.net/php_ldap_ssl.htmlYou probably can omit step 2 in that example. After step 6 you should be able to set up an ldaps connection.

Single Sign OnFor SSO you need to configure your webserver to authenticate the login.php with ntlm/kerberos/etc. Depending on your webserver you get a Server variable like PHP_AUTH_USER or AUTH_USER that contains the username. You have to write that variable in the PHP Server Auth Variable textfield.

Special thanks to:CotterPinvelinath

If you have any questions or found any bugs don't hesitate to ask/post.Suggestions/Ideas for improvements are also welcome.

Fixed a bug in the SQL-Query of the staff statistics. (thanks to velinath)

Ported the mod to osticket 1.7.1 (DO NOT USE V13 for osticket 1.7)

16.09.2013 (ldap_mod_V14):

Fixed the mcrypt bug. Sorry, I've overlooked that when I've tested it. (thanks to webvoyant)Note: You'll have to re-save the LDAP Admin-Password in your connection settings.

21.09.2013 (ldap_mod_V15):

The mod now populates the new tickets with up to date clientinfo

Updated to osTicket 1.7.1.3

26.09.2013 (ldap_mod_V16):

Added the fix for RDN by iconoeugen, sorry that i didn't see that myself

Compatible with 1.7.1.4

23.10.2013 (ldap_mod_V167):

updated to 1.7.2

optimized database access and queries

fixed a few bugs

added ability to overwrite email addresses in the open ticket form, !!!use this sparingly!!!. Currently the users won't be able to access the tickets with a modified email-address via ldap-login, as long as it isn't their default email-address. osticket doesn't support additional email-addresses for a user. Also a side-effect: After creating such a ticket, the user logs out, since osticket tries to log in the user with the other email-address (and fails).

added debug logging, toggle it in the global settings

added timestaps (with microseconds) to the debug entries. I've used a fairly new way (since mysql 5.6.4 or mariadb 5.3) to save those timestamps (the datetime(6)). If the debug logging doesn't work for you or if you get error messages associented with ldap logs please tell me.

Added since i was asked if i could combine my two mods.These Multilanguage versions require a working Multilanguage mod setup. After your multilanguage mod works you copy the content of these zip over it. I've translated only the most necessary ldap stuff for now.

I have managed to get it working, however there are a couple of issues.

The correct password allows login and if you enter a wrong password it fails login (as it should do). However If you put the username and leave the password field blank you can login.

Also only the surname appears, first name doesn't I have tried changing this in the field boxes it doesn't make a difference in fact for testing purposes I put random text in all the fields it still shows the same results as if it's not reading from it. The phone extension doesn't appear either

port number value isn't stored, when saving the settings, and going back to it, it displays 0. having to put the port number again every time you want to update the settings.

Thanks for reporting those issues. I've actually never tried testing with an empty password on client-side. And regarding first name fetching, try a user with an email-adress with which never created any ticket before. I'll set up a test ldap field page tomorrow.

Thanks for this! I'm new to PHP, so please bear with me. A few things:

When I try to delete an LDAP entry from the Connections page, I get an error "Unknown action delete - get technical help."

It would be greatly helpful if I could debug the LDAP query by echoing the output to the configuration page or to the syslog.

We are already challenging the user for LDAP credentials for SSL negotiation, and using the resulting $_SERVER['PHP_AUTH_USER'] variable as their user name (email address) within our internal wiki. Is there a way to fully automate the logins (both clients and staff) using that same variable?

I'd be happy to post my solution to the wiki authentication if anyone is interested.

I'll look into the 'Unknown action'. I probably missed something in a switch case or had a typo somwhere. I'll also look into automatically authenticating users (wanted to do that for our users anyway). If i remember correctly, most browsers can hook into the Windows Session to get the user credentials.

To your second point. Would a diagnostic page be sufficient? I planned to make a diagnostic page for ldap similar to the email one in osticket. Otherwise i could do some debug marked syslogs.

Thanks for the quick reply. I investigated automatic Windows browser authentication with Apache/PHP, but couldn't find a viable way to do it - I found a few posts that said it wasn't possible for security reasons. My users' workstations are also in various AD domains, so that was also a confounding factor.

A diagnostic page would absolutely work -- I just need some way to see what's going to the LDAP server. The one we're using requires SSL and is not under our control, so I can't see what the query looks like to see what I'm doing wrong in the LDAP dialog. I can make a successful connection from Apache/SSL and JXplorer, but not through osTicket.

It's possible to force users to log on only using LDAP, disabling the guest mode (and, possibly, also disabling the log on with email/ticketID)?

In this way 'login.php' can be merged with 'view.php', and this became the welcome page. After login the user can be redirected to 'my tickets' page (the search for a specific ticketID it's already possibile in this page).

The 'open.php' must be accessible only after log on, with the forms name/email/phone already filled.

Tell me if I can help to do this job in some way, unfortunately i'm not a good php programmer :(

It's possible to force users to log on only using LDAP, disabling the guest mode (and, possibly, also disabling the log on with email/ticketID)?

In this way 'login.php' can be merged with 'view.php', and this became the welcome page. After login the user can be redirected to 'my tickets' page (the search for a specific ticketID it's already possibile in this page).

The 'open.php' must be accessible only after log on, with the forms name/email/phone already filled.

Tell me if I can help to do this job in some way, unfortunately i'm not a good php programmer :(

Thanks again!

This is possible, however i can't remove the email/ticketID authentication altogether (would be unsecure, see first post). I can only block authenticating that way on the login.php. My mod will still login the user via email/ticketid in the background (as it does now). I'll have to make a testing platform, so you'll have to wait a bit till those things are done.

CotterPin;37716 said:

We are already challenging the user for LDAP credentials for SSL negotiation, and using the resulting $_SERVER['PHP_AUTH_USER'] variable as their user name (email address) within our internal wiki. Is there a way to fully automate the logins (both clients and staff) using that same variable?

I still have to look into SSO, for now you could omit ldap authentication and pass the email-address by itself. You can do that by modifying the following:replace the line 25 in login.php:

if($_POST) {

with

if($_POST||isset($_SERVER['PHP_AUTH_USER'])) {

replace the line 30 in login.php:

if(LDAP::ldapAuthenticate($tmp_user,$tmp_pw))

with

if(isset($_SERVER['PHP_AUTH_USER']))

and the line 32:

$tmp_email=strtolower(LDAP::ldapGetEmail($tmp_user));

with

$tmp_email=$_SERVER['PHP_AUTH_USER'];

In theory now calling login.php should automatically send you to the "my tickets" page or the "open.php" page. However i didn't test that, so i can't guarantee that.

It seems osTicket has a additional security check for 'automatic logins' (which is a good thing) that i didn't expect. You'll have to make the following additional changes after making the ones i listed above to work around that security feature. Keep in mind you'll authenticate users only via email address.

I didn't test the instance a new user would try to login, as i don't have a sufficient test setup yet. But that should work (again in theory). Please report if those changes work or throw errors, thanks.

I tested the additional changes, and it works great if the user already has tickets in the system. However, when I tested it with a client user that had never logged in before, the Full Name field is missing, and won't allow ticket creation with the error "Missing or invalid data - check the errors and try again". Screen shot attached.

I tested the additional changes, and it works great if the user already has tickets in the system. However, when I tested it with a client user that had never logged in before, the Full Name field is missing, and won't allow ticket creation with the error "Missing or invalid data - check the errors and try again". Screen shot attached.

I see my mistake. I'll need to create a new function in class.ldap.php to get the username from the email address. I'll have to do that tomorrow, since my samba4 setup still doesn't like me :(

@allI've noticed the download link of ldap_mod_V4.zip was linking to ldap_mod_V3.zip. I've corrected that mistake. Please check if you downloaded the V4. If that isn't the case please download and use the V4.

Thanks again for the quick turnaround! Updating to v.4 worked great, but I'm having an issue with class.ldap.php once I apply the SSO code. I get an error 500 on the site, and a "Parse error: syntax error, unexpected T_PUBLIC in CODE on line 560". I've tried to figure it out, but can't see what the issue is. I'm assuming you wanted me to populate the ldap user field in the LDAP Settings section of osTicket settings. Unfortunately, with the SSO code, I can't get to the Admin panel.

Thanks again for the quick turnaround! Updating to v.4 worked great, but I'm having an issue with class.ldap.php once I apply the SSO code. I get an error 500 on the site, and a "Parse error: syntax error, unexpected T_PUBLIC in CODE on line 560". I've tried to figure it out, but can't see what the issue is. I'm assuming you wanted me to populate the ldap user field in the LDAP Settings section of osTicket settings. Unfortunately, with the SSO code, I can't get to the Admin panel.

Hey CotterPin,

Sorry, I've removed a '}' too much when removing other mods. Please add a } to line 559 or redownload the ldap_mod_sso.

D'oh! I looked for missing curly braces, but not in that section. Thanks for that.

After updating with the latest code, SSO works great against our local internal LDAP. For the clients, though, we have to use the corporate LDAP, which has our user names as [email]user@domain.com[/email]. I think the LDAP mod is appending @domain.com again for the authentication. So I think what's going to our LDAP server is [email]user@domain.com@domain.com[/email]. Is there a way I can set the LDAP suffix to be null? I poked around the files, but as you've probably noticed, my PHP skills are level n00b.

D'oh! I looked for missing curly braces, but not in that section. Thanks for that.

After updating with the latest code, SSO works great against our local internal LDAP. For the clients, though, we have to use the corporate LDAP, which has our user names as [email]user@domain.com[/email]. I think the LDAP mod is appending @domain.com again for the authentication. So I think what's going to our LDAP server is [email]user@domain.com@domain.com[/email]. Is there a way I can set the LDAP suffix to be null? I poked around the files, but as you've probably noticed, my PHP skills are level n00b.

This checks if the suffix is there and only adds the suffix if there isn't one already. I can't remove the suffix entirely as it's used in other parts as well.

What also may cause your problem is the one i have in our company. We have to support two different domains. However those two domains don't trust each other and don't even know each other.

The result is the following: The Webserver that is hosting osticket is in domain A and users from domain A can sso without problems with the way i provided you. The users from domain B however can't, since the webserver doesn't know their domain and thus can't authenticate them.

Thank you for taking the time to create a mod that supports LDAP - I do have a question since I'm coming from a non-AD LDAP server. My LDAP server doesn't use the user principle name format (admin@my.domain.com) for doing LDAP binds - it uses a format similar to uid=admin,cn=users,dc=my,dc=domain

Since I'm not a php guy, could the mod be tweaked to support a bind call other than the user principal one?

Thank you for taking the time to create a mod that supports LDAP - I do have a question since I'm coming from a non-AD LDAP server. My LDAP server doesn't use the user principle name format (admin@my.domain.com) for doing LDAP binds - it uses a format similar to uid=admin,cn=users,dc=my,dc=domain

Since I'm not a php guy, could the mod be tweaked to support a bind call other than the user principal one?

It is possible to do (see first comment here: http://php.net/manual/de/function.ldap-bind.php). I'll add the functionality to use rdn bind instead of user principle name in V5 of this mod. I'll also add ggdag85s request to force users to log in. I'm unfamiliar with rdn type of binding, so could you answer the following questions: Does it look like in the following site?http://www.zytrax.com/books/ldap/apa/dn-rdn.htmlDoes 'cn' have to be the full name of the user and is it needed at all?What do your users enter for username? The uid?And for the last question, is your ldap based on Opendirectory?

I'll take a few more days, since i have some other problems to deal with at the moment. Sorry to make you wait.

Just to give some feedback, I'm now able to successfully authenticate with both domains. One final thing - if I authenticate with a user that's never created a ticket, the user's Full Name is not getting populated, so they can't create a ticket (see screen shot). If their email address is already in the database, they can login and create tickets fine.

Double-check your LDAP configuration of the LDAP connection page within the Admin Panel under Settings. I used JXplorer to validate my LDAP settings to ensure I had the correct field names. Also, make sure you've selected the enabled radio button in the LDAP Settings section.

In addition to what CotterPin already wrote, check if your staff members have the same username that they have in your ldap. Osticket checks that one and if they differ authentication fails.

CotterPin;38365 said:

Just to give some feedback, I'm now able to successfully authenticate with both domains. One final thing - if I authenticate with a user that's never created a ticket, the user's Full Name is not getting populated, so they can't create a ticket (see screen shot). If their email address is already in the database, they can login and create tickets fine.

Could you login with a new client-user and check in your osticket db if a ticket with the subject 'ldap_temporary' was created for that user with the fields first name and last name filled? If that isn't the case the mod can't fetch those fields for some reason.

Could you login with a new client-user and check in your osticket db if a ticket with the subject 'ldap_temporary' was created for that user with the fields first name and last name filled? If that isn't the case the mod can't fetch those fields for some reason.

There is an 'ldap_temporary' ticket in the database for that user, but the name field is blank.

Could you check in LDAP Diagnostic if the ldap_firstname_field and ldap_lastname_field are returning anything from that username?

Oh! I missed that you'd added the diagnostic php file. I ran the ldaptest.php, and it looks like it's failing authentication with LDAP. It appears that it's not using the custom LDAP User Field (for us the LDAP User Field is uid, not sAMAccountName). It says:

calling ldap_search with the domain: "o=[domain]", the Filter: "(&(objectCategory=person)(sAMAccountName=[user]))" and the Attributes: "array("ldap_firstname_field")"

Oh! I missed that you'd added the diagnostic php file. I ran the ldaptest.php, and it looks like it's failing authentication with LDAP. It appears that it's not using the custom LDAP User Field (for us the LDAP User Field is uid, not sAMAccountName). It says:

ok, i'll have to adjust that along with opendirectory support. I'm afraid you'll have to wait a few more days for that.