Sorry for the late reply, i had a lot to do.

@sucek

That looks like a server error to me. You could try to enable error reporting in php, to see if there are any programming errors. To enable that set

ini_set('display_errors', 0);

ini_set('display_startup_errors', 0);

To

ini_set('display_errors', 1);

ini_set('display_startup_errors', 1);

in main.inc.php

@kdeal108(first question), Crestmark

Up till V15, the mod fetched the clientdata (name, phone, etc) only the first time. After that osticket would fill those fields by itself with the data of the older tickets. That could lead to the behaviour you are experiencing. To check that, see if you have any tickets in your database with 'ldap_temporary' as subject and if they have an empty name.

You can test if the mod can get the contents of those fields with the ldap diagnostic page. Set the Field to 'givenname' and the username to the one, that has those problems. Then click on Test. you should get something like the following as an output if everything is set up correctly:

calling ldap_connect with: "192.168.178.40" and port "389"

setting LDAP_OPT_PROTOCOL_VERSION to 3 and LDAP_OPT_REFERRALS to 0

binding to ldap with "administrator@vpg.local" and his password

using the filter: "(&(sAMAccountName=ostclient))"

calling ldap_search with the domain: "DC=vpg,DC=local", the Filter: "(&(sAMAccountName=ostclient))" and the Attributes: "array("givenname")"

LDAP returned field data: "osticket"

Debug of function ldapGetEmail():

getting the email of user: "ostclient"

binding to ldap with "administrator@vpg.local" and his password

calling ldap_search with the domain: "DC=vpg,DC=local", the Filter: "(&(sAMAccountName=ostclient))" and the Attributes: "array("mail")"

LDAP returned field data: "ost.client@vpg.de"

Debug of function ldapGetUsernameFromEmail():

getting the user of email: "ost.client@vpg.de"

binding to ldap with "administrator@vpg.local" and his password

calling ldap_search with the domain: "DC=vpg,DC=local", the Filter: "(&(mail=ost.client@vpg.de))" and the Attributes: "array("samaccountname")"

LDAP returned field data: "ostclient"

The line LDAP returned field data: "osticket" is the important one here. ("osticket" is the given name of that user)

If you update to V15 and make sure that your ldap connection is set up correctly you should get everything populated.

@kdeal108(second question)

Currently you have to create a staff user (in osticket) with exactly the same username as the one in ldap, to allow them to log in with ldap credentials. That limits the users that can log in as staff. On client-side there is no limitation. To my knowledge there never was one. At least not in this mod.

I am having this exact same problem, Full Name is not being populated for the Ad accounts accessing osTicket. Because of this, no one can submit a ticket. I get an error that states "Missing or invalid data - check the errors and try again" but there are no red fields, so I assume because Full Name isn't populating that this is why I receive this. Anyone have input on this?

I figured this out on my install, have not tested it or dug into it to see why this is.

change sAMAccountName and givenName to samaccountname and givenname all lowercase. This is NOT what active directory expects so it shouldn't work, but in this case for whatever reason it makes it work.

Like I said, I have not yet dug deeper to fix this, just made the changes to get it to work until I have time to do that.

Hi Thane,

You are right!!! problem with the xampp web server. Thank you very very much!

Sorry for the late reply, i had a lot to do.

@sucek

That looks like a server error to me. You could try to enable error reporting in php, to see if there are any programming errors. To enable that set

ini_set('display_errors', 0);

ini_set('display_startup_errors', 0);

To

ini_set('display_errors', 1);

ini_set('display_startup_errors', 1);

in main.inc.php

@kdeal108(first question), Crestmark

Up till V15, the mod fetched the clientdata (name, phone, etc) only the first time. After that osticket would fill those fields by itself with the data of the older tickets. That could lead to the behaviour you are experiencing. To check that, see if you have any tickets in your database with 'ldap_temporary' as subject and if they have an empty name.

You can test if the mod can get the contents of those fields with the ldap diagnostic page. Set the Field to 'givenname' and the username to the one, that has those problems. Then click on Test. you should get something like the following as an output if everything is set up correctly:

calling ldap_connect with: "192.168.178.40" and port "389"

setting LDAP_OPT_PROTOCOL_VERSION to 3 and LDAP_OPT_REFERRALS to 0

binding to ldap with "administrator@vpg.local" and his password

using the filter: "(&(sAMAccountName=ostclient))"

calling ldap_search with the domain: "DC=vpg,DC=local", the Filter: "(&(sAMAccountName=ostclient))" and the Attributes: "array("givenname")"

LDAP returned field data: "osticket"

Debug of function ldapGetEmail():

getting the email of user: "ostclient"

binding to ldap with "administrator@vpg.local" and his password

calling ldap_search with the domain: "DC=vpg,DC=local", the Filter: "(&(sAMAccountName=ostclient))" and the Attributes: "array("mail")"

LDAP returned field data: "ost.client@vpg.de"

Debug of function ldapGetUsernameFromEmail():

getting the user of email: "ost.client@vpg.de"

binding to ldap with "administrator@vpg.local" and his password

calling ldap_search with the domain: "DC=vpg,DC=local", the Filter: "(&(mail=ost.client@vpg.de))" and the Attributes: "array("samaccountname")"

LDAP returned field data: "ostclient"

The line LDAP returned field data: "osticket" is the important one here. ("osticket" is the given name of that user)

If you update to V15 and make sure that your ldap connection is set up correctly you should get everything populated.

@kdeal108(second question)

Currently you have to create a staff user (in osticket) with exactly the same username as the one in ldap, to allow them to log in with ldap credentials. That limits the users that can log in as staff. On client-side there is no limitation. To my knowledge there never was one. At least not in this mod.

can not change email

Hi Thane,

After success connect to LDAP, then I cannot change the email address. Email address is populated from LDAP server and its running well. But sometimes user need to use their alt email address instead of LDAP email. Or in condition that staff get the issue by phone and need to put the user email address in new ticket. How to set that ? Thank you in advanced.

First I want to thank you for putting your time into this mod and posting it!

Unfortunately I'm having an issue related to authentication. When I test from the LDAP Diag page it works quickly, however, when I try to log in from the client page most of the time it takes up to 3-5 minutes before it'll finish the authentication and allow the login. It also will happen on the admin page but it doesn't seem to happen as often there.

EDIT: To further clarify the issue... I can run ldapsearch from the command line and it will come back with the query almost instantly. I just don't know what the difference is in the login process using the ldap mod.

Bug in RDN bind and Phone Ext

For RDN bind to work is needed to use the admin login id from db:

Original Code:

if(!LDAP:($rowset))

{

$ldapusr=$rowset . $rowset;

}

else

{

$ldapusr=str_replace('%UID%',$username,$rowset);

$ldapusr=str_replace('%CN%',$rowset,$ldapusr);

}

Fixed code:

if(!LDAP:($rowset))

{

$ldapusr=$rowset . $rowset;

}

else

{

$ldapusr=str_replace('%UID%',$rowset,$rowset);

$ldapusr=str_replace('%CN%',$rowset,$ldapusr);

}

The phone extension will be set to the value of the phone if ldap_ext_length is 0:

Original Code:

if($info > 0){

$phone=$info[$rowset;

$extlen=$rowset;

$phone=substr($phone,$extlen*(-1));

$phone=trim($phone);

if($phone!="")

{

break;

}

}

Fixed Code:

if($info > 0){

if($rowset>0)

{

$phone=$info[$rowset;

$extlen=$rowset;

$phone=substr($phone,$extlen*(-1));

$phone=trim($phone);

if($phone!="")

{

break;

}

}

}

@[deleted]

I'll look into that.

@[deleted]

There are multiple (about 8) ldap queries (and logins of course) per osticket client login and a single ldap login for scp side. Yes that's inefficient, but i didn't have a lot of time to optimize that. Still that shouldn't result in 5 minutes of fetching. I get the pages within 3 seconds. ldap server is a samba4 running in ubuntu 12.10 on a vmware host. Webserver is a Windows Server 2008 R2 with IIS and PHP 5.4, also on a vmware host (the same one).

Are the pages loading slowly (>5 seconds) in a unmodded osticket?

@[deleted]

Thanks a lot!

Added that in V16.

Sorry that i didn't notice that myself.

@[deleted]

There are multiple (about 8) ldap queries (and logins of course) per osticket client login and a single ldap login for scp side. Yes that's inefficient, but i didn't have a lot of time to optimize that. Still that shouldn't result in 5 minutes of fetching. I get the pages within 3 seconds. ldap server is a samba4 running in ubuntu 12.10 on a vmware host. Webserver is a Windows Server 2008 R2 with IIS and PHP 5.4, also on a vmware host (the same one).

Are the pages loading slowly (>5 seconds) in a unmodded osticket?

No, the pages load really quickly on an unmodded version. Our webserver is a Ubuntu 12.04 box and the LDAP authentication is being done against our corporate AD server (obviously Windows).

I know this is the line it stops on for that long period of time but haven't got further down to figure out the problem yet because I have to get this implemented soon so didn't have any more time to play. Having to skip the client LDAP authentication for now unfortunately.

if($_POST||(LDAP:()&&LDAP:()&&(isset($_SERVER)&&$_SERVER!="")))

Sorry for the late reply, i had a lot to do.

@sucek

That looks like a server error to me. You could try to enable error reporting in php, to see if there are any programming errors. To enable that set

ini_set('display_errors', 0);

ini_set('display_startup_errors', 0);

To

ini_set('display_errors', 1);

ini_set('display_startup_errors', 1);

in main.inc.php

@kdeal108(first question), Crestmark

Up till V15, the mod fetched the clientdata (name, phone, etc) only the first time. After that osticket would fill those fields by itself with the data of the older tickets. That could lead to the behaviour you are experiencing. To check that, see if you have any tickets in your database with 'ldap_temporary' as subject and if they have an empty name.

You can test if the mod can get the contents of those fields with the ldap diagnostic page. Set the Field to 'givenname' and the username to the one, that has those problems. Then click on Test. you should get something like the following as an output if everything is set up correctly:

calling ldap_connect with: "192.168.178.40" and port "389"

setting LDAP_OPT_PROTOCOL_VERSION to 3 and LDAP_OPT_REFERRALS to 0

binding to ldap with "administrator@vpg.local" and his password

using the filter: "(&(sAMAccountName=ostclient))"

calling ldap_search with the domain: "DC=vpg,DC=local", the Filter: "(&(sAMAccountName=ostclient))" and the Attributes: "array("givenname")"

LDAP returned field data: "osticket"

Debug of function ldapGetEmail():

getting the email of user: "ostclient"

binding to ldap with "administrator@vpg.local" and his password

calling ldap_search with the domain: "DC=vpg,DC=local", the Filter: "(&(sAMAccountName=ostclient))" and the Attributes: "array("mail")"

LDAP returned field data: "ost.client@vpg.de"

Debug of function ldapGetUsernameFromEmail():

getting the user of email: "ost.client@vpg.de"

binding to ldap with "administrator@vpg.local" and his password

calling ldap_search with the domain: "DC=vpg,DC=local", the Filter: "(&(mail=ost.client@vpg.de))" and the Attributes: "array("samaccountname")"

LDAP returned field data: "ostclient"

The line LDAP returned field data: "osticket" is the important one here. ("osticket" is the given name of that user)

If you update to V15 and make sure that your ldap connection is set up correctly you should get everything populated.

@kdeal108(second question)

Currently you have to create a staff user (in osticket) with exactly the same username as the one in ldap, to allow them to log in with ldap credentials. That limits the users that can log in as staff. On client-side there is no limitation. To my knowledge there never was one. At least not in this mod.

Thank you so much for the reply. I updated to the latest version and now it works so much better. Unfortunately, I have another issue now. When I look at the dashboard for reports, If i sort by staff, I can only see the administrator account and not other staffs. Is that something anyone here is experiencing? I am on version 1.7.4.

a month later

I get the same thing, obviously depending on the user I select. It brings up the email details for the account too. I can also log in to the scp with ldap details (I changed the users password to something and it let me log in using the new password)

I got this in the logs.

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '(6) COLLATE utf8_unicode_ci NOT NULL,

PRIMARY KEY (`log_id`)

) ENGINE=In' at line 4

a month later

Looks like my previous post got lost in the vBulletin troubles. I've finally upgraded to 1.7.3, and got things working. A couple of notes.

First is that the upgrade script doesn't work properly if you go directly from pre-1.7.0 to 1.7.3. It will allow you to create your LDAP entries, but when you try to modify your global LDAP settings, it fails, telling you that you need an LDAP entry. I got around this by upgrading to generic 1.7.0 first, letting that upgrade script run, then apply the LDAP mod and adding the LDAP entries. After all of that, upgrading to 1.7.3 went fine.

The second thing I was running into was that upon initial page load to index.php, it would not automatically login (I've got SSO and force LDAP login enabled). So I moved the call to login.php up to the top, which seems to have resolved the issue.

After:

require('client.inc.php');

I moved this:

global $ldapcon;

if($ldapcon->ldapActive())

{

if($ldapcon->ldapClientForceLogin())

{

if(!$thisclient)

{

//XXX: Ticket owner is assumed.

@[deleted]('Location: login.php');

require_once('login.php'); //Just in case of 'header already sent' error.

exit;

}

}

}

Is this mod compatible with OSTicket 1.8.0?

It was not written for 1.8, so while it might work as intended I wouldn't be surprised if it does not. It will also definitely not work shortly once 1.8.1 comes out. The good news is that the first planned plugin intended for release with the plugin system is the LDAP/AD Auth modules which I imagine will deprecate this mod.

11 days later

Won't able to download. I can't even access http://thane.dyndns.org/

Please fix.

4 days later

As the previous poster said, http://thane.dyndns.org/ does not respond.  Anyone have an copy of the most recent version (V17) of this mod for 1.7.2?

9 days later

Anyone can share the copy of most latest version of MOD?

I'm after this mod too - anyone got it?

This mod appears to no longer be available from the author.As an FYI 1.8.1 is coming soon, and will deprecate this mod as it will come with the new pluggable authentication. (LDAP/AD, etc)

What's the ETA for 1.8.1.  Does soon mean weeks or months?  Is the release schedule posted anywhere?

While this wont actually answer your questions yesterday dev Jared said, "Just a side note to avid users, osTicket 1.8.1 is nearing a preview release and has CC support (and LDAP too!). You can fetch a preview from https://github.com/osTicket/osTicket-1.8/tree/develop-next"source: http://osticket.com/forum/discussion/comment/76427/#Comment_76427