In the wonderful networked world of Windows and Active Directory (AD) services it may seem like a logical step to separate the user account that is used to check email from the administrator account that is used to install a new application on a server. However, I have seen a number of organizations that do not use separate user and administrative accounts. Using one login for all daily user tasks and administrative tasks can cause confusion and is dangerous.
So why use separate accounts?
There are a number of reasons, but they all relate to two primary ones: troubleshooting and security.
If the administrator is using a domain administrator account while trying to help a normal user, many times the administrator is not seeing a true representation of what that a normal user is seeing. Accounts in AD that are in the domain admin group automatically get elevated rights to any PC in that domain. These accounts can overcome a lot of permission or installation issues that a normal user might encounter. With the introduction of Vista and Windows 7, there are even more issues that can arise because of the User Account Controls that are built into and turned on by default in Windows.
Another reason to use separate user and administrative accounts, and I believe the most important reason, is for security.As much as IT professionals like to think they are safe, any piece of malware that gets introduced through the use of a domain admin account most likely will spread and get installed everywhere. Hackers know that if they get a user’s account, they can usually only do harm to that user. If they get access to the administrator account, then they can do harm to all of the users. Many times the goal of a hacker is to get those administrative privileges.
Your company’s security policy should reflect best practices for creating, removing, managing, and using administrative accounts.
Here are some of the best practices I suggest for Microsoft AD-serviced networks:
- IT Administrators should have a normal user account that is used for everyday tasks (i.e., email, browsing, editing documents) and a separate administrator account just for specific administrator tasks (i.e., setting up new users, installing or managing server applications).
- Administrator accounts should not have email enabled.
- Administrator accounts should not have login scripts or GPOs that map drives, map printers, or install software.
- Even though this will upset some people, I believe that Windows domain admin accounts should not even have access to the Internet. This alone will kill almost every attack vector that any malware or hacker might have to access private or protected data.
- The password for an administrator's user account should be different from the administrator's admin account. The password rules for the admin account should be very strict, with rules such as auto-lockout after three tries.
- If an administrator really needs to use an admin tool on his primary desktop, then the “run as” command should be used; however, the best place to run administrative tools is from a VM or a server set up specifically for administration work.
- Specific administrator accounts should be further separated.
- Further separate the specific administrator accounts. Too many times IT administrators are granted full domain or enterprise rights when all they really need are special rights to a specific server or application. Specific admin accounts should be limited to only those rights that are actually needed for that administrator.
- Administrator accounts should not be used to start server services; specific service accounts should be created for this function.
- Administrator accounts and service accounts should be kept in separate subtrees in AD. This helps with managing higher privileged accounts and eliminates any possibility of a GPO causing issues (assuming you are not just applying GPOs to the root of the domain, but that’s a whole other issue).