Is it best practices to have separate login for a domain for domain admins?

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.

"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

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.

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.