osTicket Version v1.9.5 (ecb4f89)Web Server Software Apache/2.4.10 (Debian)MySQL Version 5.5.40PHP Version 5.6.4-1If there is a valid AD user in the search DN who does not have an email address assigned in AD and has never interacted with osticket and they login to the client web page, they are assigned the first person who is registered as a authorised client in osticket.... or at least it does in my case
has nobody else got this problem ?
I would presume that this is a "safeguard" as all users/staff are required to have an email address.That being said I will pass this on to the devs to take a look.
Hmmmm I'd prefer it to open a page to fill in the details that are missing rather than just arbitrarily assign the first person with a registered account because the person who has never interacted with osticket gets to see all of the other persons tickets and can respond to them as if he/she is the same person and osticket/ldap plugin assigns that persons email to the other user
Then don't use search when adding the user?You do have a form to fill out.
Hi Draconis,Our organization is having this same issue. If there is a person in active directory, but NOT in ostickt, and that person attempts to login to osticket using the LDAP plugin, they are authenticated and logged in as another user. I am able to repeat this issue over and over.Thanks,SC
Alright, alright. I found the issue. Within the ost_user_account table and under the username column, if there is a NULL field the non-osticket clientwill now be authenticated as the person whom is NULL.Example - Let's say there is an osticket client name Frank Miller, but his username is NULL within that table. If Jane Doe, whom is in AD but not osticket tried to login, they will be logged in as Frank Miller. Solution, I made the ost_user_account.username column non-nullable after entering the samaccount name for Frank Miller.
Really interesting, I can't remember that a username ever missed in that table on our server.
did you do it with this in mysql ?ALTER TABLE username MODIFY P_Id INT(11) NOT NULL;
We are still getting this issue especially if the user doesn't have an email address assigned in AD it's authenticating with AD and letting the user in but assigning them somebody completely random it seems who is already registered with osticket.... I need to nail this before the other 1600 users login or it will become a right mess to sort out
Right I think I've found a solution I truncated the ost_user_account field and got rid of all records. It seems to be working as intended now even when logging in with a user who has no email address in Active Directory it now prompts you to add an email address once you have been authenticated via active directory rather than blindly assigning the first registered user, I'm guessing here that this was some sort of corruption either in the creation of the table either when it was created or imported from the upgrade from 1.6ST....I'll keep checking the table to see if the same duff records turn up, on the plus side the user has nothing extra to do they just login and it takes them to their tickets or prompts them for a valid email address if one isn't found in AD ......it's also nice to see that a previously registered email address / user can't be spoofed as well by a user who has no AD email address although that can happen if the bona fide user hasn't registered with osticket yet
