@[deleted]

Hello wbart,

please check if the V5 works for you.

@[deleted]

Hello CotterPin,

could you also check if the customizable filter works for you. Also thanks for the extensive testing.

Thane,

No worries, it's the least I could do for the extensive mod work. :) Looks like I've got it working with V5, but it appears that our corporate LDAP won't let me read the givenName attribute. I can only pull down the cn (Full Name) or sn (Last Name). Is there a way I can use the cn attribute for client tickets?

Hello CotterPin,

"givenName" returns nothing for me. I have to write in in all lowercase ('givenname') to make it work. Ldap seems very picky with the attributes. Another nice example is samaccaountname. I have to write 'sAMAccountName' to get the filter working. However if i want the content of samaccountname i have to use the attribute 'samaccountname'. So try 'givenname'. If that also doesn't work for you I'll have to patch the class.ldap.php a bit.

Ok, that worked. I now am able to use the LDAP Diagnostic to verify that I am using the correct filter for First and Last Names. However, client login is not working with the V5 mod. It leaves me as a Guest User, even after clicking "Log In". Clicking "Log In" takes me to the Check Ticket Status dialog for the Guest User.

I've removed part of the sso stuff. It was V4-specific and partially hardcoded. I'll add a slightly better configurable Sso in V6, maybe even later today (pretty shure that i'll get that done today). Sorry, i forgot to mention that.

@[deleted]

Ok, SSO is done. You'll have to set use SSO and your PHP_AUTH_USER in the LDAP Settings. Hopefully your setup will completely work with that. I've tested it with a Samba4 server with ldaps enabled, with osticket hosted on a IIS7.

@[deleted]

I've noticed that both phone fields are empty too. The cause is probably the ldapGetUsernameFromEmail function. So i've added diagnostic messages to this and the ldapGetEmail function. Please Download the V7 and check Ldap Diagnostic again.

My diagnostic output is:

calling ldap_connect with: "ldaps://192.168.178.40"

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("cn")"

LDAP returned field data: "ost client"

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"

It appears to be binding to both LDAP entries - domain.com and lex.adapps.domain.com are different LDAP domains. Anyway, here's my diagnostic output for user@domain.com:

Result: Leave empty to use the Administrator in LDAP Settings

calling ldap_connect with: "ldaps://ldap.domain.com"

setting LDAP_OPT_PROTOCOL_VERSION to 3 and LDAP_OPT_REFERRALS to 0

binding to ldap with "cn=ESCEAUTH,ou=Applications,o=domain.com" and his password

using the filter: "(&(uid=user@domain.com))"

calling ldap_search with the domain: "o=domain.com", the Filter: "(&(uid=user@domain.com))" and the Attributes: "array("givenname")"

LDAP returned field data: "FirstName"

Debug of function ldapGetEmail():

getting the email of user: "user@domain.com"

binding to ldap with "cn=ESCEAUTH,ou=Applications,o=domain.com" and his password

calling ldap_search with the domain: "o=domain.com", the Filter: "(&(uid=user@domain.com))" and the Attributes: "array("uid")"

LDAP returned field data: "user@domain.com"

Debug of function ldapGetEmail():

getting the email of user: "user@domain.com"

binding to ldap with "admin@lex.adapps.domain.com" and his password

calling ldap_search with the domain: "DC=lex,DC=adapps,DC=domain,DC=com", the Filter: "(&(sAMAccountName=user@domain.com))" and the Attributes: "array("mail")"

LDAP returned nothing...

Debug of function ldapGetUsernameFromEmail():

getting the user of email: "user@domain.com"

binding to ldap with "cn=ESCEAUTH,ou=Applications,o=domain.com" and his password

calling ldap_search with the domain: "o=domain.com", the Filter: "(&(uid=user@domain.com))" and the Attributes: "array("uid")"

LDAP returned field data: "user@domain.com"

Debug of function ldapGetUsernameFromEmail():

getting the user of email: "user@domain.com"

binding to ldap with "admin@lex.adapps.domain.com" and his password

calling ldap_search with the domain: "DC=lex,DC=adapps,DC=domain,DC=com", the Filter: "(&(mail=user@domain.com))" and the Attributes: "array("sAMAccountName")"

LDAP returned nothing...

The normal binding is in a while loop and tries all of your ldap entries. Thats why authentication with not trusted domains is possible. Though it creates a bit of overhead. I'll think of a way to remove the overhead later, i have to optimize the code anyway.

Regarding the error, i didn't expect a username@domain to return from ldapGetUsernameFromEmail. Do your users in the domain.com enter their email address/user@domain or just the username?

@[deleted]

please try using this class.ldap.php. It breaks out of the while loops when it gets results. It may be that the second run overwrites the first. That shouldn't happen with this class.ldap.php.

Download: (class.ldap.php_cotterpin_test.zip)

Sorry I wasn't clearer about that before -- the confusion comes from having two different domains to work with. In our local domain (for Staff), they use a user name as expected. However, our corporate domain (I obfuscated with domain.com) uses email as uid, so we authenticate to almost everything with our email address as user name. So in this case, I'm using uid for both user name and email, as reflected in the debug.

So for clarity, here's what we've got:

uid = user name

uid = email address

cn = full name

givenname = first name

sn = last name

Yep, that works:

Result: Leave empty to use the Administrator in LDAP Settings

calling ldap_connect with: "ldaps://ldap.domain.com"

setting LDAP_OPT_PROTOCOL_VERSION to 3 and LDAP_OPT_REFERRALS to 0

binding to ldap with "cn=ESCEAUTH,ou=Applications,o=domain.com" and his password

using the filter: "(&(uid=user@domain.com))"

calling ldap_search with the domain: "o=domain.com", the Filter: "(&(uid=user@domain.com))" and the Attributes: "array("givenname")"

LDAP returned field data: "Firstname"

Debug of function ldapGetEmail():

getting the email of user: "user@domain.com"

binding to ldap with "cn=ESCEAUTH,ou=Applications,o=domain.com" and his password

calling ldap_search with the domain: "o=domain.com", the Filter: "(&(uid=user@domain.com))" and the Attributes: "array("uid")"

LDAP returned field data: "user@domain.com"

Debug of function ldapGetUsernameFromEmail():

getting the user of email: "user@domain.com"

binding to ldap with "cn=ESCEAUTH,ou=Applications,o=domain.com" and his password

calling ldap_search with the domain: "o=domain.com", the Filter: "(&(uid=user@domain.com))" and the Attributes: "array("uid")"

LDAP returned field data: "user@domain.com"

Ok, i was considering that i have to strip the @[deleted] for the other functions. But it should work as it is now. Do new users get the fields filled now?

If the user already has tickets in the database, the Open New Ticket dialog works fine, and they can create a new ticket and view their other tickets.

In that case osTicket is filling the fields. It does that by itself if it has the data.

If the user does not have tickets in the database, it shows them logged in with 0 tickets. Whey they try to create a new one, only the Email Address field populates. Full Name is blank, and they get the error "Missing or invalid data - check the errors and try again" when they try to create one.

That could be because of the ldap_temporary tickets. They won't show on the interface (i've filtered them out), but they count in the system. If they don't have any info of the user osTicket won't fill the fields when the user tries to open a new ticket. In that case you'll have to delete the ldap_temporary ticket from that user in the database, or just delete all of them at once.

Also, the ldap_temporary database record is only created if they create the ticket while not logged in (guest). I'm thinking that's by design, but wanted to mention it for clarity.

That is bad. The only time ldap_temporary tickets are created is when the user logs in. And also only if the user in question didn't create any tickets yet. I use those tickets as a safe way to transport the user info. As mentioned above, this ldap mod actually doesn't fill any fields. Osticket does that and i merely use/misuse that feature.

What actually should happen, and does in my vm testsetup as well as my company is the following.

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, as 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 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.

So you could check if the users with unfilled fields have an empty ldap_temporary ticket. If thats the case, delete those tickets. Then try again. I don't know why guests get those tickets too, the creation happens in the login.php. I'll check that tomorrow.