Resources For IT Professionals
Post an article
Wikis - Page Details
Options
RSSSubscribe to Article (RSS)
Can You Improve This Article?
Positively! Click Sign In to add the tip, solution, correction or comment that will help other users.

Report inappropriate content using these instructions.
Wiki  >  TechNet Articles  >  Best Practices: Using a Separate Account for Admin Tasks

Best Practices: Using a Separate Account for Admin Tasks

Best Practices: Using a Separate Account for Admin Tasks

It’s been my observation that in most organizations administrators use their normal user account for admin tasks. The account is made a member or Domain Admins, DNS Admins, Exchange Admins, or whatever admin group grants the appropriate level of permissions for their role. I would like to make the case for using a separate account for admin tasks.
 
When using a single account for normal user login and admin tasks the first thing that comes to mind is all of the Group Policy settings associated with that account. They could include drive mappings, software installation, scripts, etc. that would apply when you log on to a computer. You wouldn’t want to have all of these apply when you log on an infrastructure server or a Domain Controller.  
 
Another argument is that you will likely be logged in all day. Even the most security conscious person can step away and forget to lock the keyboard. I hate to admit it but I have done this, and when I returned 4 minutes later a co-worked had tinkered with my system as a joke. Danger isn’t always lurking in the next cubical, but there is an undeniable risk.
 
OK you concede, but then I would have to log off my normal user account and log on my admin account every time I need to do something. Not so!  Fortunately in Windows XP there is a feature known as “Run As” that will allow an administrator to log in with a normal user account and, when necessary, execute *.exe or *.msc consoles with their admin account (shift +right click “Run as”). “Run as” was removed in Vista but ShellRunas can be downloaded from Technet Sysinternals.
 
When you need to log into a server remotely using RDP “Run as” isn’t necessary, you merely login with your admin credentials.
 
Returning to the example above, if you walk away from your system and leave a console window open having a separate admin account really doesn’t help. You should only open an admin console (.msc) when needed and close it when finished. The same is true for remote sessions.
 
Keep in mind that if you decide to use a separate account for admin tasks, where ever you place it in your OU structure to make certain it is not receiving unnecessary Group Policies.
 
I hope this information is useful.
 
 
, , , , [Edit tags]
Leave a Comment
  • Please add 7 and 7 and type the answer here:
  • Post
Wiki - Revision Comment List(Revision Comment)
Sort by: Published Date | Most Recent | Most Useful
Comments
Page 1 of 1 (1 items)
Wikis - Comment List
Sort by: Published Date | Most Recent | Most Useful
Posting comments is temporarily disabled until 10:00am PST on Saturday, December 14th. Thank you for your patience.
Comments
  • Posted by
    on 10 Sep 2013 9:30 AM

    Maheshkumar S Tiwari edited Revision 2. Comment: Added Tag

  • Posted by
    on 4 Oct 2010 9:02 AM

    test

  • Posted by
    on 4 Oct 2010 9:03 AM

    UAC under Windows Vista and 7 take over the "Run As" command noted here. You may simply right click any executable and select "Run As Administrator". You will see a UAC prompt that will ask for your credentials.

    In a domain environment, managing multiple logins (user and Administrative) for each IT guy on your LAN can be cumbersome. You don't want to share admin account details with everyone as it becomes difficult or impossible to audit.

  • Posted by
    on 3 Jan 2011 7:03 AM

    I disagree with your comment. Each administrator should have a regular user account and an admin account with appropriate group membership for his role. I have first hand experience with this method in very large environments and it was not difficult to manage. I don't know where you are going with "share admin account details" or "impossible to audit". Thanks for reading and the commenting

  • Posted by
    on 14 Dec 2011 2:00 AM

    yes information is useful

  • Posted by
    on 16 Jan 2013 1:40 AM

    runas does not necessarily protects you from password hashes beeing cached on the client where you use the runas command. So you can either disable cached logons by policy or do not use highly privledged accounts on your client using runas at all.

Page 1 of 1 (6 items)