Is it best practices to have separate login for a domain for domain admins?
Solution 1:
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.
Solution 2:
"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
Solution 3:
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.
Solution 4:
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.
Solution 5:
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.