You should never need to know or even have to reset the user's password in order to eliminate that as a possible source of login problems. Your application should be smart enough to tell the difference (and tell it to the user, or at the very least include it in the logs) between a bad username/password combo and other account issues like security lockouts. If it's not, you should fix this.
That aside, the option of performing an administrative password reset is definitely preferable over disclosing the user's password to the administrator. However, there are still a few more things that should be taken into consideration:
- This action should always be logged by the application, and these logs should be regularly audited.
- The application should enforce that the user change their password after an administrative reset, and users should be trained to expect this.
- Some environments require that users have unique passwords across their last 10+ passwords, and administrative resets are not exempt to this policy. This means that, whenever you perform an administrative reset of the user's password, the user will not be able to use their old password again when they change it back. Many users will be unhappy about this.
Some have mentioned a third option that is essentially a "sanity check" against the system: Create a dummy account and verify that the system is permitting that account to login. The flaw with this is that it is simply redundant. If the dummy account can't login, then chances are that the system is rejecting logins for a lot more than just one user - and you'll probably know this already before you're done testing the dummy account.
Another option mentioned is to manipulate the password database directly, such that you store the user's password hash outside of the database temporarily and manually replace it with the hash of a known-good password for testing. This is non-optimal for a couple reasons:
- Front-line techs should not have this sort of access to the password database. It's a generally unnecessary increase in risk to the database. Thus, this sort of action should require escalation of a ticket that (most likely) should be able to be handled via other means by a lower-tier group.
- This bypasses the application-native password reset functionality, which opens up the possibility that other standard procedures and security requirements (e.g.: forcing the user to reset their password after an admin has changed it, password history enforcement) may also be skipped.
As for reasons disclosure of user passwords in general should be avoided, there are a few attack scenarios to consider in the casse of a tech gone rogue:
The attacker may use a victim's credentials to gain and abuse privileges that their own account does not have.
An attacker who has privileges necessary to conduct a desired malicious activity may still use a victim's credentials instead so that the true source of an attack cannot be easily (and, perhaps, cannot at all for legal purposes) be identified.
Abuse of user credentials may not be limited to just the one system/application, nor even only to systems/applications owned by the company. Since users very often reuse passwords across different systems/applications/environments an attacker may, for example, take the credentials for your company's personnel directory and use them to gain access to HR or financial systems, or to victims' Facebook, Twitter, or online banking accounts. (Thanks to @Izkata for the reminder on this one.)
TL;DR: You should never ask a user for their password, and users should be specifically trained to reject such requests - this is Security 101. There are too many other mechanisms which should allow you to troubleshoot user account issues without disclosure of the user password, and the risk if the passwords are misused is far too great.
The application should be able to tell the difference between a bad username/password combo and other user account problems, and users (or at least administrators) should be able to see this. Even absent this, administrators should already have a mechanism by which the password can be reset to a known value for troubleshooting purposes. As a last resort, if it's absolutely necessary that the user be able to use their old password when possible, a direct edit of the password database (where passwords are stored in salted, hashed format) could allow an administrator to test a different password without losing the user's existing one and without actual disclosure of the password itself.
The reason to disallow disclosure of passwords is simple. Once an account's password is known by more than one person, all accountability for that account's activity goes out the window. Its credentials may also be re-used in other places, some of which may pose even higher risk to the organization either directly via loss of funds or IP or indirectly through bad PR when a successful attack (e.g.: compromise of PII or hijacking of high-profile social media accounts) becomes publicly known.
TL;DR of the TL;DR: There's really no good reason to allow system administrators, much less help desk personnel, to know end-user passwords. There's too many ways to work around needing this, and if the application is designed so that there aren't then it needs to be redesigned. There's also way too many good reasons to forbid disclosure of user passwords to sysadmins/help desk people.