Securing the Administrator Account

By Bobby Rogers, August 29th, 2005 Posted in User Account. Subscribe to our RSS Feed

You might be thinking that this is a lot of trouble to go through, especially when we may have 5 or 10 trusted admins in our network that may need to use admin privileges several times a day to do their job.  Here’s the reason why this is critical:  If 5 or 10 people are using the local administrator account to do their jobs with, how can you trace a particular action to a single person?  You can’t!  Let’s say someone logs in with the administrator account and deletes the company president’s user account.  Who do you hold accountable for it, since so many people have access to the account?  What if it’s not one of your admins, but someone who has accessed your network with this account?  How would you know?

So, even after securing the administrator account, use the following best practices to ensure that administrative – level privileges are well managed and that administrators are held accountable:

First, never allow your trusted admins to use the administrator account during the course of normal user business, such as writing a word document, surfing the web, or checking their e-mail.  The reason for this is that any and all programs that run while a user is logged on runs with whatever privileges that user has.  If any malware executes on the computer, just like any other program it will execute with the same privileges as the user logged on, in this case with those of the administrator account.

Instead, create two accounts for every trusted admin:  a normal user account to do everyday tasks with and a uniquely identifiable administrator account assigned only to that person that has appropriate privileges.  For example, the account name brogers might be my normal user account that is used to read email and do normal tasks, and another account, RogersAdmin, might be the account I log onto the system with which to perform administrative functions.  This account would have only the necessary privileges with which to do my job.  This separation of accounts serves several purposes.  First, it doesn’t allow  my normal programs (especially those I may inadvertently open from an untrusted web site) to run with any admin privileges, and second, since I am not using the local administrator account, but rather an account that is tied to me and me alone, my actions can be audited and I can be held accountable for them.  Create separate administrator accounts for each trusted administrator so that any actions taken can be traced to a particular person rather than a group of people using one account.

Second, have these administrators use the runas command to run specified programs requiring elevated privileges when at all possible, rather than having them simply log in as their administrative account.  The reason for this is that, again, any and all programs running will use these elevated privileges, not just the one the admin intended to use.  Using the runas command will specifically allow only one process or program to run under the context of their administrative account rather than all of them.

Finally, audit the use of all accounts having elevated privileges. This includes local administrator, domain-level, and enterprise-level accounts.  Assign the task of reviewing the audit logs to a trusted, higher-level security administrator if possible, and review the logs daily.  Question any unusual uses of privileges that aren’t scheduled or previously coordinated, such as data backups/restores or event log deletion.  Be able to trace any given action back to a particular person.

If used in conjunction with other defense-in-depth practices, these measures will go a long way towards securing your workstations, servers, and even your entire network.

Written by Bobby Rogers - Visit Website

Go To Page: 1 2 3

All Tutorials by Category:

Entire site Copyright © 1999-2007 2000Trainers.com, all rights reserved.
Content on this site may not be copied or reproduced in any way without permission.

IT Showcase