I’ve seen many environments lately where the Windows administrators have two Active Directory accounts, one that they use for their normal end user activities, such as reading email, and the other they use for any administrative duty. This creates several very real problems:
a) the admin now has two different accounts with a password that he must now maintain over time, probably not a huge problem but just a pain for the admin;
b) you still have to trust the admin where he will use the second admin account and hope that he doesn’t use it for normal daily activity or do damage to systems he has no business working on; and
c) the biggest problem is that these admin accounts are usually members of a group or several groups that grant broad privileges across all the windows machines, think of this as a root account for all computers or like being a member of wheel group.
It is important to remember that this model has been adopted widely as a way to separate a normal account completely from an account that would be used for administrative functions since the normal account has a much higher chance of getting infected or compromised. So, this separation was done to protect these all powerful admin accounts with more stringent password policies and controls which Microsoft is making much better in Windows Server 2012 R2 and Windows 8.1 (Read this Technet article for more info: https://technet.microsoft.com/en-us/library/dn408190.aspx)
So, in order to manage Windows systems, Windows applications and Active Directory, admins will require privileges for specific tasks they are required to do as part of their job AND we want to ensure that anyone who is attacking the environment cannot easily gain elevated privileges. We certainly don’t want them gaining access to the entire environment.
We have helped several customers setup their admin access in a way that minimizes risk and still provides the admin with the privileges he needs to perform his job function, from helpdesk to most trusted enterprise admin, through the following guidance:
- Establish granular privilege elevation with least privilege admin roles
- Restrict members of the Domain Admins group - empty if possible
- Lock down (and vault the password) the local and domain administrator accounts
- Enforce strong authentication for administrators - this is optional
- Require re-authentication for privilege elevation
- Session auditing of all administrative actions
Establish Granular Privilege Elevation with Least Privilege Admin Roles
Centrify provides privilege elevation for individual administrative tasks on specific computers which can be granted to a specific admin user based on the user’s role. In this model, individual commands and tasks should be defined for each administrative role that is required for various services such as Active Directory, SQL Server or Exchange Admin. Centrify's Brad Zehring tells all about it here http://blog.centrify.com/best-practices-windows-privilege-management/
Additionally, we find that many of our customers leverage their existing Active Directory management tools for group membership as a way to control which users are members of specific privileged roles. Many have set up self service request interfaces to enable the admin to request a temporary privilege to a task on a specific computer. Once approved, the management tool (either their trouble ticketing system or identity management platform on AD) can then programmatically add the user to the AD group or explicitly to the Centrify role that grants the permission. All of our policies can be managed programmatically via Linux CLI using the adedit command or via PowerShell. Learn more on Centrify's Developers site: http://www.centrify.com/developers/sdks/directmanage/
Restrict Members of the Domain Admin Group
Once you have established a granular set of rights to be granted to the right admins based on their role, you can now go back and clean up the environment from the previous usage of secondary admin accounts that are members of the Domain Admins group which are no longer needed. So, admins no longer need their secondary -A accounts. Also, there shouldn’t be a need for anyone to be a member of the Domain Admins group, so its membership should be nearly empty (maybe have only a break glass account with a member whose password is vaulted).
Lock Down Local and Domain Administrator Passwords
Windows admins should never need to know the administrator password on any of the computers in the environment since they should be using privilege elevation to get the privileges they need to perform their duties. These should be treated the same as UNIX root accounts - locked away in a password vault never to be used except in break glass situations, but not for day to day use.
Enforce Strong Authentication (Smart Card-based) for Administrators
Several of our Federal customers are required to adhere to HSPD-12 for Smart Card login which is a good idea for administrative accounts since a device with a PKI certificate stored on it is much more secure than the usage of a password, unless you use a very long password. Usage of these devices is as simple as plugging in the USB key from vendors such as SafeNet with their eToken Pro USB Key (http://www.safenet-inc.com/multi-factor-authentication/authenticators/pki-usb-authentication/) or YubiKey (https://www.yubico.com/products/yubikey-hardware/). Then the admin needs to remember only a single PIN used to unlock the device.
If you don’t have a CA setup, configuring your own Enterprise Root CA (Certificate Authority) to issue Smart Cards to users or allow them to self enroll via web enrollment is relatively simple and it’s already included in Active Directory. You just have to add the role to your server.
- Follow this step-by-step guide from Microsoft to setup your own CA. https://technet.microsoft.com/en-us/library/cc772393(v=ws.10).aspx
- Follow these instructions on certificate enrollment using Smart Cards. http://support.microsoft.com/kb/KbView/257480
Microsoft provides all that you need to support Smart Card login to the admin’s workstation, as well as to support Smart Card login to servers over an RDP session from the Smart Card enabled workstation. If your administrators choose to use a Mac, Centrify provides what you need to enable PKI certificate-based authentication to AD (learn more here: http://www.centrify.com/products/identity-service/mac-management/smart-card/)
Require Re-Authentication for Privilege Elevation
Now that we have setup privilege elevation for specific tasks and cleaned up the Domain Admins group and locked down the Admin accounts, you might also want to ensure that your admin is still at the keyboard when they execute a command with privilege. The easiest way to do that is to simply challenge the user for his authentication credential, either password or PKI certificate if he logged in with a Smart Card. New: Centrify Server Suite 2015 now supports Smart Card re-authentication for privileged command execution on Windows, even for users with more than one identity within Active Directory.
Note: Dual Identity Smart Cards tend to be used as a way to grant administrators with access to a second account they can use to perform administrative duties, while needing to be a member of the Domain Admins group. Microsoft provides guidance on how to set up Smart Card login where the Administrator has two AD accounts, http://blogs.technet.com/b/askds/archive/2009/08/10/mapping-one-smartcard-certificate-to-multiple-accounts.aspx. However this is NOT needed if you take the first step and move to privilege elevation using a tool such as Centrify Server Suite to provide the required privileges to the administrator, vs. having him authenticate into a separate highly privileged account.
Session Auditing of all Administrative actions
Security officers have long since known the value of video cameras on high security areas to see exactly what is happening in that area vs. traditional alarm system door/window switches and motion detectors. Similarly security information officers need video camera feeds of user activity on sensitive systems to determine what is really happening to their servers and the intent behind administrative actions, job duty related or malicious intent. Centrify provides full video session auditing along with meta data capture as a way to provide insight into the activities of administrators or users logging into servers. This activity can be narrowed to record only specific privileged commands to reduce the amount of data captured. In many cases our customers send the meta data along with individual commands out to their SIEM to enable classification and alerting on the events given Centrify provides a ton more information than syslog or Windows Event Viewer alone can capture.
- Learn more about Centrify Server Suite: http://www.centrify.com/products/server-suite/
- What's New in Centrify Server Suite 2015: http://www.centrify.com/media/1207864/whats-new-in-centrify-server-suite-2015-021315.pdf
- Get started with a trial for Centrify Server Suite 2015: http://www.centrify.com/free-trial/server-suite-form/
This is written by the individual author in his/her personal capacity, and the opinions, views and/or thoughts expressed herein are solely the author’s own. They are not intended to and may not necessarily reflect the official policy or position, or the opinions or views of ThycoticCentrify or its affiliates, employees, or any other group or individual.