35

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.

5
  • 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, 2014 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. Feb 12, 2014 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, 2014 at 18:41
  • 2
    @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. Feb 12, 2014 at 18:46
  • 1
    @Dolda2000 UAC prevents processes from executing privileged functions on the local machine. If you're logged in as a Domain Admin, you can run privileged commands remotely on other machines and they will run elevated on the remote machines without a UAC prompt. Thus malware specifically designed to exploit this can infect your entire domain (and then infect your local machine using another remote machine) without you ever seeing a UAC prompt.
    – Monstieur
    May 13, 2015 at 11:11

8 Answers 8

26

"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.

Also on these lines, your Schema Admins group should always be EMPTY unless you are making a change to the schema and then you put the account in, make the change, and remove the account. The same could be said for Enterprise Admins especially in a single domain model.

You should also NOT allow privileged accounts to VPN into the network. Use a normal account and then elevate as required once inside.

Finally, you should use SCOM or Netwrix or some other method for auditing any privileged group and notify the appropriate group in IT whenever any of these group's members have changed. This will give you a heads up to say "wait a minute, why is so and so suddenly a Domain Admin?" etc.

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. However, now that you've read all of this, consider yourself one of the ones that will fight the good fight and do what you can to keep things secure. :)

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

2
  • Least privilege applies mostly to non admin accounts. Credential separation doesn't help from a least priv perspective if the cred is used on a dirty system compromised by the lower privleged cred.
    – Jim B
    Jan 29, 2016 at 15:11
  • True, but I consider "LPU" to also mean only giving access to privileged groups as required. Lots of IT depts. give out DA access simply because it is easier than dealing with the myriad of requests for access.
    – TheCleaner
    Jan 29, 2016 at 17:05
28

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.

14

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.

3
  • Three accounts... interesting... I have to consider that for the looming domain change in my company...
    – pepoluan
    Feb 12, 2014 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, 2014 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. Feb 13, 2014 at 16:37
9

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.
3
  • 7
    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. Feb 12, 2014 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, 2014 at 9:52
  • Actually you should be using a separate workstation that's been locked down to run only admin
    – Jim B
    Dec 4, 2015 at 0:46
4

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.

2

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 :)

1
  • +1 for recognizing that daily use of a user-level account improves troubleshooting effectiveness. Jun 3, 2015 at 3:23
1

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.

0

adding my 2 cents based on actual experience..

knowing and keeping aware that you are using an admin account for your daily work makes you very cautious on whatever you do. so you don't just click on an email/link or just run any applications without triple checking. i think it keeps you on your toes.

using a least privilege account for your daily work makes one careless.

2
  • That's a nice theory but in my experience it doesn't work (at least not for everybody). I've seen colleagues deleting massive amounts of data from production systems by mistakes (a blank in the wrong place in a command line is enough). Aug 6, 2018 at 8:59
  • not a theory, we practice it here ;-) in my experience, you vet the people whom you will give such privileges and not just hand them over for the asking.
    – badbanana
    Aug 7, 2018 at 5:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .