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.

  • 9
    In general, it's not a good idea in security engineering to allow people to login as a shared account (or other people's account, for that matter) even if their permissions are identical. Authentication should be a separate process from authorization. If tasks are done under separate user accounts, they are responsible for it.
    – mmx
    Feb 4 '10 at 11:33
  • 1
    +1 to Mehrdad Afshari. I cringe every time I hear people talking about admin like this. Feb 4 '10 at 11:39
  • 2
    @Mehrdad Afshari and @Dan McG, that is all good and true, but what do you propose to do when an administrator needs access to a user account in an everyday situation? Ask the user over to enter their credentials? It happens very often that to verify or reproduce a problem, you need to check with a specific user's settings, especially when the accounts are tied to complex rights and other settings that can't be reproduced 1:1 with a neutral account.
    – Pekka
    Feb 4 '10 at 11:53
  • 4
    Your looking at it the wrong way. If the admin needs to check a users setting, we need to develop better tools to get this diagnostic information from the user. For example: If your app on windows crashes, do you want some MS admin over in Redmond RDPing into your user account to check stuff out, or do you want a highly automated method of sending required information back to them (at the user's discretion)? Feb 4 '10 at 11:55
  • 2
    @Dan: The customer might not be willing to pay for that.
    – Heinzi
    Feb 4 '10 at 12:15

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, the 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 shouldn't always be given all the rights that a user has. For example, a user may have valid reasons to view credit card numbers in a system. An admin shouldn't; this data is not part of their 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...

  • 2
    While you have valid points, I don't think the answer is quite so clear - in some cases it is the best solution.
    – sleske
    Dec 13 '13 at 12:47

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.

  • Nitpick: sudo doesn't log you in as a local user, it just runs one process as the user (a la Window's "Run as user"). To log in as a local user, use su. Otherwise, I agree.
    – sleske
    Feb 4 '10 at 11:55
  • @sleske: Of course, thanks for spotting this. Fixed.
    – Heinzi
    Feb 4 '10 at 12:00
  • @sleske: not necessarily, look at sudo -i.
    – liori
    May 7 '11 at 12:18
  • The idea of a 'login shell' has more to do with how the sh executable behaves than it does with what permissions are granted. su - user and sudo -u user sh grant the same access; the difference is that sh runs different startup scripts.
    – jpaugh
    Jul 26 '19 at 16:52

Well, phpBB3 has a "Test out user’s permissions"-functionality for admins, which is really helpful. Also it doesn't really let you interfere with that users account but really just get the experience they have, based on their permissions.

But actually logging in as someone else comes with a number of problems, as others mentioned.


Yes, such a functionality can be problematic, but sometimes there is no other way, so it might be necessary.

Some examples:

  • On Unix/Linux, this functionality exists (su - <username>, which gives the same result as logging in as that user, but requires no password for root)
  • the application I work on also has this, and it's essential for debugging problems with a user's personal settings (of which our app has many)

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy