I'm working on configuring osTickets for use in our college's IS department and ran into some trouble with the LDAP Auth plugin. The staff/faculty users on LDAP have been added to the staff panel just fine so far but the student accounts haven't been able to log in.The accounts are all in the same OU on AD. Is there something else that needs to be set in AD to allow osTicket to authenticate off of it? The student account usernames are their school ID numbers, would having a username consisting of nothing but numbers cause it to fail?

I imagine that you would need to import the users, but I haven't really played with this to figure it out yet.

Some clarification: We are trying to create osTicket staff accounts and are having the LDAP Authentication Plugin look in the Staff/Faculty OU for accounts to allow.We just wiped our test server this morning and set it up again and still have this issue on our fresh install.I've been adding the osTicket staff accounts manually by clicking the "Add New Staff" button, selecting LDAP authentication, typing in their active directory username, and selecting their user when the pop up text appears. At this point the user info fields are auto filled from Active Directory. However our student worker accounts (which are in the same OU as the rest of staff) don't work while our staff accounts do.

in order for accounts to work, you need to create them and give them access to auth via LDAP.

The accounts already exist on our active directory server and we are creating the accounts in the Add New Staff page of the osTicket control panel. When you type in their username and wait for a moment, a context menu drops down with their username. When I click on that context username, the system automatically fills in their account details with the active directory information. I then set the other required fields properly and create the account.After this, some users created this way still can't sign in at all.

The plugin seems very buggy for us as well.We have to remove the end user then let them log in again using their AD information and it will re-create the user account in OST.  Even then we have user accounts that continually get locked out or it tells them Access Denied etc even though there AD account is not locked.

After some experimenting, I think that the problem likely has something to do with a username that is all numerical characters. Would someone be willing to help verify this?

8 days later

After some experimenting, I think that the problem likely has something to do with a username that is all numerical characters. Would someone be willing to help verify this?

I don't think so... all of the usernames for regular users and staff members won't let me sign in and they're just names, most of them don't have numbers at all.

Write a Reply...