Do you think it's a good practice to implement a possibilty to allow an administrator user to login in as another user, by-passing password? This could by implemented by a master password or a function inside the user administration, "Login as this user".
Administrators are asking for a such function to be able to try to reproduce a reported problem or to check if grants are ok, for example.
No. Not at all. This violates segregation of duty.
It also causes havoc on relying on logs to show user actions.
If you really need to check things like this, they admin should also have a dummy test account(s) that are set up like the users. This way they can confirm grants, etc work correct on the test user first.
As an aside too, admin users should always be given all the rights that a user has. For example, a user name have valid reasons to view credit card numbers in a system. An admin shouldn't as this data is not part of there job. Once again, this comes down to segregation of duty.
Minimise your exposure by minimising granting of inappropriate rights. This should include admins as well...
From a security and clean programming principles standpoint, it's not a good idea. But it can be a huge convenience in everyday work for the administrator, which is why I'm for it if implemented well.
To me, an o.k. implementation would have to meet the following requirements:
The system logs you in as the user in question, but bypasses password authentication if you're logged in as admin.
The system is aware through a flag that this is not user x, but an administrator logged in as user x. Any logging facility would reflect the difference.
There is no way to "break out" from the user log-in back to administrator level.
This can actually improve security because the administrator does not have to look up and use users' credentials, which in reality is often the case for the reasons the OP mentions: Something has to be checked, tested, etc... on the user's account.
As always... it depends. There is no easy answer and both systems are used in practice (e.g. Windows: Admin cannot log-on as user without resetting password vs. Linux: Admin can log on as local user using su).
Clearly, not allowing the admin to log in as another user is the more secure option, so you have to decide if the additional comfort (being able to debug problems that only occur for a certain user) outweighs the risk. If you decide to implement such an option, make sure that there is rigorous logging, so that an admin (or someone who got hold of an admin password) cannot hide his tracks.
Alternatively, you could use the pattern that Windows is using: An admin cannot log on as another user, but an admin can reset a user's password. That way, an admin can gain access, but the user will always know that someone accessed his account.
Yes, such a functionality can be problematic, but sometimes there is no other way, so it might be necessary.
Some examples:
su - <username>, which gives the same result as logging in as that user, but requires no password for root)As pointed out, if complex settings depend on the logged-in user (environment vars, paths, personal settings in an application) there is often no other practical way to debug a user's problem.
As for logging / auditing: Use of this functionality should of course be logged. Other than that, you'll have to trust your admin not to abuse it. But that is valid for admins in general.
If you need to restrict your admins more, you need some kind of MAC (mandatory access control) system, w/o a "true" admin. That is possible, but much more complicated, so it's a tradeoff.