Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I typically like to set up separate logins for myself, one with regular user permissions, and a separate one for administrative tasks. For example, if the domain was XXXX, I'd set up a XXXX\bpeikes and a XXXX\adminbp account. I've always done it because frankly I don't trust myself to be logged in as an adminstrator, but in every place that I've worked, the system administrators seem to just add their usual accounts to the Domain Admins group.

Are there any best practices? I've seen an article from MS which does appear to say that you should use Run As, and not login as an admin, but they don't give an example of an implementation and I've never seen anyone else do it.

share|improve this question
1  
As one who deals primarily in Linux/Unix and isn't a Windows expert, isn't this precisely what UAC is supposed to fix? By which I mean, so that one can use one account but still have only authorized processes receive administrative privileges. –  Dolda2000 Feb 12 at 18:16
    
@Dolda2000 UAC was more for end-users in the habit of running as an administrator on their local machine. There are additional concerns when you're running as a domain admin on your local machine - your credentials and access can be used for a lot worse than installing a virus on your machine, seeing as how you've got elevated rights to most things in the entire domain. –  HopelessN00b Feb 12 at 18:28
1  
@HopelessN00b: And you're saying UAC doesn't apply to those things? Why not? Are there technical reasons, or is the implementation simply lacking? –  Dolda2000 Feb 12 at 18:41
1  
@Dolda2000 Well, UAC was supposed to fix the issue with malware being able to use the logged-on administrative user's user context to install itself on end-users' and consumers' PCs. And it does. It would also block that specific vector from using a domain admin's user context to install malware locally, however, that's not the extent of the security concerns involved in running as a domain administrator instead of a limited user. –  HopelessN00b Feb 12 at 18:46
add comment

7 Answers 7

up vote 18 down vote accepted

"Best Practice" typically dictates LPU (least privileged user)...but you are correct (as is ETL and Joe so +1) that people rarely follow this model.

Most recommendations are to do as you say...create 2 accounts and not share those accounts with others. One account shouldn't have admin rights on even the local workstation you are using in theory, but again who follows that rule, especially with UAC these days (which in theory should be enabled).

There are multiple factors in why you want to go this route though. You have to factor security, convenience, corp policy, regulatory restrictions (if any), risk, etc.

Keeping the Domain Admins and Administrators domain level groups nice and clean with minimal accounts is always a good idea. But don't simply share common domain admin accounts if you can avoid it. Otherwise there's a risk of someone doing something and then finger pointing between sysadmins of "it wasn't me that used that account". Better to have individual accounts or use something like CyberArk EPA to audit it correctly.

At the end of the day there's a reason it's called "Best Practice" and not "Only Practice"...there are acceptable choices made by IT groups based on their own needs and philosophies on this. Some (like Joe said) are simply lazy...while others simply don't care because they aren't interested in plugging one security hole when there are hundreds already and daily fires to fight.

References:

http://www.microsoft.com/en-us/download/details.aspx?id=4868

http://technet.microsoft.com/en-us/library/cc700846.aspx

http://technet.microsoft.com/en-us/library/bb456992.aspx

share|improve this answer
add comment

AFAIK, it is considered best practice for domain/network administrators to have a standard user account for logging on to their workstation to perform routine "user" tasks (email, documentation, etc.) and to have a named administrative account that has the appropriate group membership to allow them to perform administrative tasks.

This is the model I try to follow, although it's tough to implement if the existing IT staff isn't used to doing it this way.

Personally, if I find an IT staff that's reticent to move in this direction I'm of the opinion that they're either lazy, inexperienced, or they don't understand the practice of system administration.

share|improve this answer
add comment

This is a best practice for security reasons. As others have mentioned, it prevents you from doing something accidentally, or from you getting compromised from browsing the network. It also limits the damage your personal browsing can do -- ideally, your day to day work shouldn't even have local admin privileges, much less domain admin.

It's also incredibly useful to counter Pass the Hash or Windows authentication token hijacks. (Example) A proper penetration test will prove this easily. Namely, once an attacker gains access to a local admin account, they will use that power to migrate into a process with a Domain Admin token. Then they effectively have those powers.

As for an example of people using this, my company does! (200ish people, 6 man ops team) In fact, our Domain Admins have -THREE- accounts. One for everyday use, one for PC administration/installing software locally. The third is the Domain Admin accounts, and used solely for administering servers and the domain. If we wanted to be more paranoid/secure, a fourth would probably be in order.

share|improve this answer
    
Three accounts... interesting... I have to consider that for the looming domain change in my company... –  pepoluan Feb 12 at 17:04
1  
Same in my company. Normal desktop-account, admin account for local admin access on client computers AND a separate server admin account. Both admin accounts get no email and no internet access. The one single issue is that the server-admin account needs local admin rights on the workstation or else UAC interferes with running MMC locally with RunAs as the server-admin account. (Can use RDP to a server and run everything from there, but that is really hampering at times if you need to copy/paste or compare with data that runs on the desktop-account.) –  Tonny Feb 12 at 18:29
    
We've managed to do pretty well with having our Domain Admins RDP to a server for their management work. Copy & Paste actually moves across RDP amazingly well. And that single server has all our management utilities already installed. But that being said...I believe the Domain Admins group has local admin rights by default. I just prefer those credentials never touch desktops, to prevent against token theft, and the like. –  Christopher Karel Feb 13 at 16:37
add comment

In my former company's, I insisted that all the System Admins got 2 accounts, ie:

  • DOMAIN\st19085
  • DOMAIN\st19085a ("a" for admin)

Colleagues were reluctant at first but it became a rule of thumb, after the typical question about the virus threat "we got an antivirus" was debunked by an outdated virus database...

  • As you mentioned, the RUNAS command could be used (I used to have a batch script, presenting a custom menu, launching specific tasks with the RUNAS command).

  • Another thing is the use of the Microsoft Management Console, you can save the tools you need and launch them with a right-click, Run As... and your Domain Admin account.

  • The last but not the least, I used to launch a PowerShell shell as Domain Admin, and launch the stuff I needed from there.
share|improve this answer
4  
This is essentially the implementation I've used (and forced on everyone else) everywhere I've had a say in it. You log onto your computer and do your day-to-day tasks as a normal user, just like everyone else. When you need admin rights, you Run As/Run as Administrator and use the administrative user account. Just using one account for everything is a bad security practice, and in my experience, the people who object are the poeple who most need to be isolated from running everything as admin anyway. –  HopelessN00b Feb 12 at 16:29
    
+1 great observation by @HopelessN00b: "the people who object are the people who most need to be isolated from running everything as admin anyway" –  mr.b Mar 31 at 9:52
add comment

I've worked at places that do it both ways, and generally prefer having a separate account. It's actually a lot easier that way, contrary to what joeqwerty's reluctant users/customers seem to think:

Pros of using your normal, every day account for domain admin activities: Yay, all the administrative tools work on my workstation without runas! W00t!

Cons of using your normal, every day account for domain admin activities: Fear. ;) Desktop tech asks you to look at a machine because he can't figure out what's wrong with it, you log in, it has a virus. Unplug network cable, change password (somewhere else). When managers ask you why you don't get your work email on your personal blackberry through your cell phone provider you get to explain that they store your DOMAIN ADMIN password on their servers when you do that. Etc., etc. Your highly privileged password is used for things like... webmail, vpn, log in on this webpage. (Ew.) (To be fair, my account was blocked from the "change your password" webpage, so at least there was that. If I wanted to change my old LDAP password, which the webpage synced, I'd have to go to a coworker's desk.)

Pros of using a different account for domain admin activities: Intent. That account is intended for the administrative tools, etc., and not for email, webmail, vpn, webpage logins, etc. So, less fear that my normal "user" activities are exposing the entire domain to risk.

Cons of using a different account for domain admin activities: I have to use runas for administrative tools. That's just not that painful.

The TL;DR version: Having a separate account is just plain easier. It's also best practice, as it's least necessary privilege.

share|improve this answer
add comment

In all theory, it is best that you don't use a top administrator logon for your day to day activities. There are plenty of reasons such as viruses - if you get a virus and you're running Domain Admin logon, then the virus has an easy way to get on your network, full access! The possible mistakes are easier to make for sure but I don't see that as the biggest challenge. If you go around your campus and logon with your top admin, someone may be looking over your shoulder for your password. All sort of things like that.

But is it practical? I find it hard to follow that rule, but I would like to follow it.

share|improve this answer
add comment

Least Priv should be reason enough, but in case that's not, also consider that if you use an account with the same permissions as your users, you are more likely to suffer any issues that they do - and you can debug them on your own account too - often before they've even seen them!

Nothing worse than an administrator who says "it works for me" and closes the ticket :)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.