Securing critical IT infrastructure and sensitive data is a top priority for most administrators. However, even with the best security measures in place, servers can't be run in complete isolation. Ideally, key IT systems should never depend on the security of less critical devices. But computer networks are complex, and unwanted dependencies might go unaccounted for or appear at unexpected moments.
Security should be approached with the premise that your network is already compromised -- you just don't know it yet. So it makes sense to understand how endpoint security can affect crucial IT services.
What Is a Security Dependency?
Domain controllers (DCs) provide security services for all devices in a domain, so if a DC is compromised, you must consider all the devices in your domain to be compromised. Endpoints depend on DCs for certain aspects of their security, and this is an acceptable security dependency. But if this situation is reversed and a DC becomes reliant on an endpoint for its security -- that is a dependency that should be eliminated.
Access-based dependencies involve users accessing sensitive systems from a device that has a security issue. A typical example is an IT administrator who connects remotely to a DC from a desktop computer that's infected with a key logger. Another commonly broken rule of IT security occurs when administrators create administrative dependencies, such as by using a domain admin account to log on to a workstation. If the workstation were to be compromised, the security of the domain could be put at risk: Cached domain admin credentials could be exposed or otherwise intercepted by malware. Administrators often create service account dependencies by using the same logon credentials to run a Windows service across multiple servers. If the credentials are compromised on one server, then the security of more than just one machine is in doubt.
IT administrators aren't the only ones guilty of committing some of security's cardinal sins. Users can also create undesirable security dependencies by using the same username and password for multiple systems or by transferring confidential data to a USB drive that isn't authorized for use on the network.
Protecting Crucial Infrastructure Against Rogue Systems
Sometimes a company's Active Directory (AD) domains and crucial servers are exposed to systems that are not under your control, such as when a contractor connects a netbook to your corporate network. In such cases, you can't be sure whether the device is fully patched, protected by antivirus, or running malicious software. You can deploy network segregation to help ensure that unknown and rogue devices are isolated from your crucial systems, perhaps until such time as the health of those systems can be validated by a network access control system, such as Microsoft Network Access Protection (NAP).
You can configure IPsec rules to provide domain and server isolation. In this scenario, the identity of each device on a network is validated before communications are permitted. In addition, IPsec can provide data integrity and encryption. All too often, Windows Firewall is disabled on corporate intranets in the belief that the risks are low and that the firewall at the network edge is the most important security protection mechanism. Windows Firewall can ensure that endpoints talk to servers and that endpoints are prevented from communicating with one another. For more information about IPsec server and domain isolation, see "Use IPsec to Isolate a Domain."
Eliminating Unwanted Administrative and Access-Based Security Dependencies
All but the most security-conscious small-to-midsized businesses (SMBs) are likely to give domain admin rights to new IT support personnel whose skills and integrity are yet unproven. New staff typically is given rights to manage every crucial aspect of the company's IT systems and possibly are given unrestricted access to all the confidential information held therein. CIOs take what seems an unacceptable risk because, without advanced planning, it's the fastest and most convenient way to make sure that IT staff can have all the systems access that they're likely to need.
Organizations should design AD with security in mind, separating crucial objects from those that Help desk staff manage on a daily basis. For example, service account user objects in AD should always be in a separate organizational unit (OU) from standard user accounts. Taking such a simple step facilitates restricting access to business-critical user objects. You can also segregate admin accounts into a separate group and set a fine-grained password policy to apply a more restrictive password policy for IT staff.
One of the most overlooked methods of limiting damage is to forbid the use of highly privileged domain accounts on endpoints. Microsoft recommends that a maximum of two accounts per domain should be assigned domain admin privileges. Domain admin credentials should never be entered on a machine that isn't a DC. For example, administrators might use their everyday accounts with Remote Desktop Client to connect to a DC, entering their domain admin credentials and letting Remote Desktop Client store the credentials for quick future logons.
Removing Domain Admin Rights from IT Support Staff
It's assumed that IT staff will need to log on interactively to DCs and workstations. The easiest way to achieve this goal is to assign staff domain admin privileges. But with a little bit of planning, there's no reason that domain admin rights should be required to log on to workstations with local administrator privileges. And there are other ways to manage DCs and AD without logging on locally.
To prevent malware from intercepting domain admin credentials, Microsoft recommends using accounts without domain admin privileges to log on interactively to desktop computers. You can achieve this goal easily by creating a new AD group for IT support staff and by granting local administrator access to workstations.
Using an account that has permissions to create groups in AD, open Active Directory Users and Computers under Administrative Tools on the Start menu. Create a group called Desktop Administrators, then add IT support staff user accounts to this group. At this point, you can also consider removing any highly privileged access that these accounts have, such as Domain Admin group membership.
Authenticated Users have the Add workstation to the domain right, so members of the Desktop Administrators group can add computers to the domain. But the catch is that there's a quota, which is limited to 10 by default. There are several ways around this problem: To precreate computer accounts in AD, give IT support staff the Create Computer Objects and Delete Computer Objects rights on the Computers container, or edit the ms-DS-MachineAccountQuota AD attribute. For more information about these methods, see the Microsoft article " Domain Users Cannot Join Workstation or Server to a Domain."
Once you've decided how to overcome the quota for adding workstations to the domain, you can configure Group Policy to add Desktop Administrators to the Administrators group on your workstations. Locate the Group Policy Management Console (GPMC) under Administrative Tools on the Start menu, and expand your domain in the left pane. Select the OU that contains your computer objects. Remember that you cannot link a Group Policy Object (GPO) directly to the default Computers container, so you'll need to create an OU for computer objects if you don't already have one in place. Right-click the OU, select Create a GPO in this domain and link it here, give the new GPO a name, and click OK.
In the left pane of GPMC, right-click the new GPO, and then select Edit from the context menu. The Group Policy Management Editor window opens. In the left pane, expand Computer Configuration, Windows Settings, Security Settings, and then right-click Restricted Groups, and choose Add Group. Type "Administrators" in the Add Group box and click OK. In the Administrators Properties window, which Figure 1 shows, click Add (next to Members of this group), and enter any local machine groups or accounts that are members of the local Administrators group on your workstations. Then click Browse, and add Domain Admins and Desktop Administrators. Group Policy Restricted Groups overwrites the group membership of the local Administrators group on every workstation to which the GPO is applied. If you need more flexibility, you can use Group Policy Preferences to update rather than overwrite local group membership. Click OK and close the Group Policy Management Editor.
Figure 1: Group Policy Restricted Groups setting
Wait for Group Policy to refresh on your workstations, or manually run the command
gpupdate /force
on a workstation in the OU to which the GPO is linked. You should see that the Desktop Administrators group has been added to the local Administrators group on the workstation and that the default groups remain in place. This scenario allows IT support staff to log on and support desktops with full local administrative access, without needing domain admin rights.
Understanding Cached Credentials and Credential Manager
Windows stores cached credentials for domain users in a secure part of the system registry (HKEY_local_machine\security\cache). Although it's possible to disable caching domain credentials, doing so is extremely inconvenient in all but the most secure environments -- especially for notebook users. To get access to this subkey, you need to launch regedit with SYSTEM privileges. I'm not going to explain how to do that here; even if you were to delete the necessary registry values, Windows would just stop caching credentials. The registry values are not designed to be accessed or deleted manually, so they're best left alone.
Although the cache cannot be cleared, you can delete usernames and passwords that are protected by the Credential Manager API, which allows applications such as Remote Desktop Client to securely store credentials for each Windows user. To get quickly to the Stored User Names and Passwords dialog box, which Figure 2 shows, enter
rundll32.exe keymgr.dll, KRShowKeyMgr
Figure 2: Stored User Names and Passwords dialog box
at a command prompt. In this dialog box, you can add, remove, or edit the stored credentials and back up and restore credentials if required. To get to a newer version of the interface in Windows 7, choose User Accounts, Credentials Manager from the Control Panel.
Service Accounts
Microsoft recommends using the built-in Local System account for third-party services, but many organizations opt to use an AD user account so that only the required privileges can be granted. This approach provides some damage limitation should the service be compromised. However, it also introduces the complexity of managing the account's password, which should be changed on a scheduled basis, just like any other user account password. Whenever possible, service accounts should be configured for least privilege, and you should always question the need for a service to have domain or local admin rights.
In Windows Server 2008 R2, Microsoft introduced managed service accounts (MSAs), which work like AD computer accounts in that passwords are assigned and reset automatically. These accounts can be created only by using Windows PowerShell and aren't supported by all third-party services. MSAs must be installed on a computer and by design, can be associated with only one device, and therefore can't be used in cluster-failover scenarios. When you configure a service to use an MSA, leave the password boxes blank. For more information about how to set up these accounts, see " Use MSAs to Ease the Pain of Administering Service Accounts ." (Note that the next release of Windows Server -- Windows Server 8 -- will introduce group MSAs, which will remove these restrictions.)
Best Practices for Damage Limitation
Remember the importance of least-privilege security, which applies equally to servers and PCs. Removing administrative rights from IT support staff and users helps to minimize the damage, should malware find its way onto a device. Third-party solutions, such as Avecto Privilege Guard and BeyondTrust PowerBroker, provide more sophisticated privilege-management functionality than is available out-of-the-box in Windows. These solutions can be used to solve least-privilege security challenges quickly and to provide more granular control than would otherwise be possible. Application whitelisting is also essential to block unauthorized applications in a user's logon session, especially considering that antivirus is not always effective at detecting threats.
Never enter sensitive credentials on a system that an untrusted person has used or might use or that could be exposed easily to malware. Manage sensitive computers, such as DCs, from dedicated management workstations and use AD delegation and OUs to separate objects that are crucial for running business systems from those that support staff can manage on a regular basis. And in the case of a virus outbreak or other malicious attack, following the advice in this article will make your IT infrastructure more resilient.
