Active directory integration

[AKL-MFCU]

i can see the reasons why one would want it both ways. I personally don't mind setting up the staff account because we don't "lose" that many staff in the departments that work it. Most of our staff have just always changed their passwords to their windows login so its one less thing to remember, and i set it up with the same username as windows so in looks, its all the same.

It would be nice to have staff integrated but then its another thing to have to manage in AD especially in connection with rights and departments as i assume it would be managed through AD as well. ::Shrug::

[AKL-MFCU]

that isn't weird- its simply how it works. What is happening is that the username was created in the sql database- if you delete the user and have them register or set up manually again with the same username- its going to show the previous tickets and calls unless these tables have been cleared in the database. You can also delete old ticket details if you delete their tickets they sent in and then it seems to them like its new. Anyhow, this isn't an ldap error, this is a sql issue.

[joepc]

I cant seem to get AD connection working, here are my details.

Current Config:



Error when trying to login



Not too sure what the issue is. Please let me know if you can help, I've searched through the forums to find an answer.

Thanks,
Joe

[AKL-MFCU]

one, i would do your domain backslash administrator not frontslash, it may be generating funky errors so do

domain\administrator not domain/administrator

second,

the error says that it can't bind to the server, so double verify that the server that this is hosted on can ping that address and that there is no issue of a firewall between the two.

What version are you running?

[joepc]

The backslash did it, Thanks for the help AKL-MFCU

[jamesM]

I had quite a few issues with ActiveDirectory where users where told incorrect user name or password and in the end I found I had to remove the users and email address table as soon as I did that all my users could login and all logged calls matched up to the correct users I did not loose any data.

Of cause the first time the user logs in there is a little delay as php does a ldap query to active directory but apart from that every thing is now working.

Windows 2003 Active Directory, Hosted on IIS running windows 2000 with email support through Exchange 2003 :-)

[dnicol]

We are getting ready to roll out the support center and use our ldap login. LDAP works fine for anyone user who never opened a ticket via email. If it is your first time accessing the system there seems to be no problems.

Has anyone successfully converted normal Kayako members information to LDAP? I am assuming the only thing we need to do is make all the records loginapi_moduleid and loginapi_userid are changed but I want to make sure before I muck with the database.

I also noticed that if I delete the record from swusers and swusersemails that the user still shows up or can login via ldap login but a record is not added to those tables again. Do the loginshare use a different table?

[dnicol]

I was able to debug my issue some more.

The problem we ran into is that when someone tries to use their LDAP username and password it would fail because the user already had a record in swusermeails for the email stored in the LDAP server. It looks like the LDAP piece does an insert after it grabs the LDAP stuff and because of the unique constraint on the email conlumn it fails. If you delete the record from swuseremails and then login you login successfully.

I plan on asking some of my developers to look at the ldap code and see if it can add some logic that if the email fetched from LDAP already lices in swuseremails and the loginapi_moduleid is not equal to Active Directory to delete the record and then allow the LDAP login to add the record like it normall does.

This will synch up the database so I do not have to manually manipulate the loginapi_moduleid and loginapi_userid fields with a script.

Has anyone else run into this issue or tried soemthing like this?

[AKL-MFCU]

yes, we've run into it many many times. Unfortunately the problem with ldap queries is just that, they are queries and they only run when necessary. I'd rather be one for windows authentication against it so that its an active process and no chance of a problem. However, if your developer does find an easy trick for that or a resolution, please let us know and we'd all would really be happy and use it in our own. I'm sure even kayako would add it to their code.

[jamesM]

That was the problem I had and its a real pain was hoping that kayako would fix it in the next build :-)

[gerardo]

Hello,

AKL-MFCU, you seem to be helping lots with AD integration problem. Maybe you can give me a hand, or anyone else. All help is welcome

Originally Posted by AKL-MFCU

Finally fixed my loginshare issues and got it to start working just fine. It was strange, but we needed to use both pre-2000 naming scheme as well as the standard scheme for 2003. Thanks to you guys laying so much info out, its really been a great help in getting that part of the ball rolling!

How did you do this?

If I use domain\user (or domain/user) I get "Invalid DN syntax" error. I'm not the admin for the AD and the admin has created and account with some restrictions. Does this account have to have full admin privileges on AD?

This is how I'm setting up AD:
Base DN: ou=ti,ou=ah,dc=subdomain,dc=is
RDN: cn=mr. esupport,ou=ti,ou=ah,dc=subdomain,dc=is

...and of course the password for esupport account

ldapsearch (linux cmd line tool) works fine
ldapsearch -h active.directory.server.IP -x -D "cn=mr. esupport,ou=ti,ou=ah,dc=subdomain,dc=is" -W -b ou=ah,dc=subdomain,dc=is
It brings back the list of users with info.

Apparently the "mr. esupport" is because AD uses the display name in their DN instead of the username.

Using eSupport 3.00.80 Stable

Any help is much appreciated.
Gerardo

[joshopkins]

Does anyone have a script that will import AD users into the kayako database. We have 3500 users in AD that will be end users of the system. Any help would be great. Thanks.

[AKL-MFCU]

Gerado, although im sure that kayako only needs listing capabilities and being able to pull passwords from AD, i would still recommend a full control for access to it. I'm pretty sure you can also use the user@domain command if necessary instead of the domain\username or domain/username

I know i had troubles at first with getting the base DN to work, but its actually better if you start broad (at the top of the tree and forest) and try running it from there. If you are interested in speeding up any ldap queries, you can filter it from there but i would recommend just getting it to work first of course

As for you joshhopkins, why are you wanting to do a mass import of AD users when you can have it do ldap queries? Otherwise you'll have to manage another password database where everyone will have to remember theirs and change theirs on windows and then go "oh ****, i cant remember the supportsuite one". Just seems a bit off. Personally i'd rather see windows authentication, but thats a hope PHP can't support yet.

[joshopkins]

Originally Posted by AKL-MFCU

As for you joshhopkins, why are you wanting to do a mass import of AD users when you can have it do ldap queries? Otherwise you'll have to manage another password database where everyone will have to remember theirs and change theirs on windows and then go "oh ****, i cant remember the supportsuite one". Just seems a bit off. Personally i'd rather see windows authentication, but thats a hope PHP can't support yet.

What I mean by import of AD users is that currently what happens is if a user in AD sends a ticket request in to the system before they have logged in, the auto response notice give them a password to login with when they check the status. The problem is when they go to check the system will not let them login using either thier AD account info or their email address/password (generated from the auto response email). If i delete the user from the staffcp then they are able to login using AD and see their ticket.

[Manny]

Originally Posted by joshopkins

What I mean by import of AD users is that currently what happens is if a user in AD sends a ticket request in to the system before they have logged in, the auto response notice give them a password to login with when they check the status. The problem is when they go to check the system will not let them login using either thier AD account info or their email address/password (generated from the auto response email). If i delete the user from the staffcp then they are able to login using AD and see their ticket.

I am also having the same problem. All of my users are used to sending in an email. This is the way its always been and its hard to break them of old habits. Since most of them send in the email, then they can't login because esupport creates an account for them different than the AD acct. Does anyone have a solution for this? Can we do a mass import as previously suggested? Or can we use the parser to send an auto-reply to anyone who is not in the DB yet asking them to login first? Once logged in then they will have no problems and they could send in the email as usual. If we could do either of those two things, we would be good.