How to manage admin rights for helpdesk staff?

Question

My question is about issuing administrative rights to helpdesk staff in a large Active Directory setting.

Helpdesk staff commonly require administrative rights to provide support for end users. I know that this is commonly done (see [1] [2] [3]) by creating a "Workstation Admins" group, and adding that group to the local Administrators group on each PC. Ideally, the helpdesk staff will use a low-privilege account for daily tasks, and only use their "Workstation Admins" account when needed.

System Administrators commonly do the same thing, and use an account with higher privileges when accessing servers. This makes sense because servers are trusted machines that are protected both physically and electronically. Therefore, logging in to a server with a privileged account is basically safe.

However, staff at the helpdesk will be logging into machines that were probably constantly left unattended and used for daily email or web browsing. These computers can't be trusted the same way servers can. It's easy to imagine a staff member at the helpdesk logging in to a computer which contains a malware payload that immediately spreads across the network because it has admin rights on many other computers.

Or worse, a malicious user could perform a real-life phishing scam by having a keylogger on their computer, then having somebody from the helpdesk log in.

Is there any way to give helpdesk staff the access they need without creating a significant risk? (I can imagine an ideal solution would use a one-time password for authentication, and the logged-in the user would only be authorized as a local administrator. In other words, I want the helpdesk staff to have access to ANY computer, not EVERY computer.)

Answer 1

If an administrator is going to type in his password on a hostile workstation, then he's effectively telling the user (or a hacker) his password, whether he sees it that way or not. This is very definitely a well-known and used exploit pathway, and I've even witnessed it used in the real world at IBM.

There's really only two options here:

1. Don't allow users to type in their password on someone else's workstation

2. Use two-factor authentication

Changing your password afterwards is important, but it still leaves an exploit window and even several minutes is already too long. Requiring two-factor authentication gives you the time you need to return to a safe workstation and change your password.

Note that even still, you're vulnerable to a variant of a man-in-the-middle attack where the hostile workstation uses your security token for purposes other than what you see on the screen. This is not a difficult attack to orchestrate, so it's worth taking seriously.

Answer 2

Mitigation 1: Use two-factor authentication, for logging into admin accounts.

Mitigation 2: Give helpdesk staff a tablet or netbook that they can carry with them. Instead of typing their password into the user's machine, they could log into their tablet/netbook and use the internal remote administration services to administer the user's machine. Make this workflow as easy and frictionless as possible.

Mitigation 3: Have the helpdesk staff change their admin password regularly (once a week might not be overkill).

Answer 3

Depending upon the complexity of support they need to provide on a workstation or server, I would suggest using some kind of remote management tools for the bulk of incidents. That way, administrators aren't logging directly into a machine every time they provide support.

I recommend taking a look at System Frontier, but I own the company that makes it. It let's you delegate more granular rights that can be easily done in Windows.

Whatever product or method you choose, don't assume that because it's a server that it's basically safe for any admin to log in directly. It can be just as dangerous behind your firewall as it is outside of it. Idea: Maybe for machines that are just for web browsing, you have an automatic wipe and rebuild policy if issues can't be resolved remotely?