[Solved] Agent login process is resetting password

[timR]

Not sure if this is the appropriate forum.

The quick issue is that logging in as an agent is resetting the password hash on the agent. I am constantly having to request password resets. They work. I change back to my preferred password. I logout and back in to confirm the preferred password works, but immediately after that the password hash in mysql has changed. Details below.

I have been playing around with a test setup for a few weeks. I'm using OTRS 2.4.8 installed from RPM on a CentOS 5.5 64 bit system. I have ITSM 2.1.1 installed on top of it.

I'm using LDAP from Lotus Notes for customer authentication and am using the db backend for agent authentication. LDAP was a bit of a struggle and it still isn't quite to my liking, but what I have works. I have had no problem with customer logins. I had originally installed the system back in July and do not remember this issue with agent logins, but I did not spend much time with it.

I had thought it was related to one of the otrs cron jobs, but extensive testing has confirmed that is not the issue.

This issue is 100% repeatable. I have confirmed it with 2 agent users, and I have reset the password both through the agent Preferences interface and the admin Users interface.

Steps to reproduce:

1. Check password hash in MySQL. It is currently hash1, which is not the agent password hash for the preferred password.

2. Request password reset.

3. Click e-mailed confirmation link. (MySQL shows has as hash2)

4. Log in with e-mailed password.

5. Change password in Preferences to the preferred password (MySQL now has hash3, the desired hash)

6. Either work for hours and then logout or log out immediately (MySQL still shows hash3)

7. Log back in successfully, using preferred password, changed in step 5 above.

8. MySQL now shows hash1. It is always the same hash. This is happening for every agent.

I've searched the forum, the web and otrs lists, and I've not been able to find anything similar. Of course searches using various combinations of the phrases "password hash login reset" turn up many, many hits not like my issue, so it is possible this is a known issue and I was just not able to find it.

Additional information:

1. LDAP login is using short name, not an e-mail. (Had problems getting an e-mail based customer id to work in my ldap setup. I plan to revisit this.)

2. My agent login is identical to my customer login--both userid and password, but case is different on userid. The agent login is all lower case, the customer login is mixed case. I have confirmed that I see the same behavior even if the passwords are different.

3. I have not made any modifications to login for agents. I have obviously changed customer logins to use LDAP, but I did test with db logins for customers initially.

Any help or pointers is appreciated. I was using strace to see what the GenericAgent.pl cron job did, so I'm not afraid to get in over my head, but I'm at a bit of a loss how to even try tracing this.

[crythias]

I'm not entirely certain that the MySQL database is even being touched with respect to your authentication. If you're using LDAP for auth as you've said, then it's up to LDAP to authenticate the user, not MySQL.

[timR]

I'm not entirely certain that the MySQL database is even being touched with respect to your authentication. If you're using LDAP for auth as you've said, then it's up to LDAP to authenticate the user, not MySQL.

Thanks for the quick reply.

Sorry, my wall of text probably made me not clear.

Agent is using DB. Agent passwords are getting reset immediately after login in the db. I have confirmed timing with queries in the database.

I included the full setup and that I am using ldap for customer login for completeness. It is possible that I messed up agent logins in some subtle manner when initially starting on ldap logins. I'm going over my changes and notes now.

[timR]

I'm an idiot, but I'll leave the post up so that someone else doesn't have to publically declare their stupidity.

In playing with LDAP, I had originally worked on LDAP for both Agent and User. When I ran into a "Panic! No UserData for user id" problem with Agent logins, I had followed instructions to get some of the LDAP data to synch into the db.

After switching agents back to db login, I did not uncomment those lines. Thus, after every login, it was trying to synch LDAP data, which was causing the issue. Commenting that section back out resolved my stupidity--for now.