Managing Security Dependencies on Windows Networks

Securing critical IT infrastructure and sensitive data is a top priority for most administrators. However, even with the best security measures inplace, servers can't be run in complete isolation. Ideally, key IT systems should never depend on the security of less critical devices. But computernetworks 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 understandhow 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 yourdomain to be compromised. Endpoints depend on DCs for certain aspects of their security, and this is an acceptable security dependency. But if thissituation 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 administratorwho connects remotely to a DC from a desktop computer that's infected with a key logger. Another commonly broken rule of IT security occurs whenadministrators create administrative dependencies, such as by using a domain admin account to log on to a workstation. If the workstation were to becompromised, 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 thecredentials 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 dependenciesby 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 thenetwork.

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 acontractor 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 beforecommunications are permitted. In addition, IPsec can provide data integrity and encryption. All too often, Windows Firewall is disabled on corporateintranets in the belief that the risks are low and that the firewall at the network edge is the most important security protection mechanism. WindowsFirewall can ensure that endpoints talk to servers and that endpoints are prevented from communicating with one another. For more information aboutIPsec 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 skillsand integrity are yet unproven. New staff typically is given rights to manage every crucial aspect of the company's IT systems and possibly are givenunrestricted 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 stepfacilitates restricting access to business-critical user objects. You can also segregate admin accounts into a separate group and set a fine-grainedpassword 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 thata maximum of two accounts per domain should be assigned domain admin privileges. Domain admin credentials should never be entered on a machine thatisn't a DC. For example, administrators might use their everyday accounts with Remote Desktop Client to connect to a DC, entering their domain admincredentials 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 domainadmin 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 localadministrator 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 oninteractively to desktop computers. You can achieve this goal easily by creating a new AD group for IT support staff and by granting localadministrator 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 anyhighly 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 thedomain. 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 computeraccounts in AD, give IT support staff the Create Computer Objects and Delete Computer Objects rights on the Computers container, or edit thems-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 tothe Administrators group on your workstations. Locate the Group Policy Management Console (GPMC) under Administrative Tools on the Start menu, andexpand 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-clickthe 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 theleft 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 toMembers of this group), and enter any local machine groups or accounts that are members of the local Administrators group on yourworkstations. Then click Browse, and add Domain Admins and Desktop Administrators. Group Policy Restricted Groups overwrites the group membership ofthe local Administrators group on every workstation to which the GPO is applied. If you need more flexibility, you can use Group Policy Preferences toupdate 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 Administratorsgroup on the workstation and that the default groups remain in place. This scenario allows IT support staff to log on and support desktops with fulllocal 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_machinesecuritycache). Although it's possibleto disable caching domain credentials, doing so is extremely inconvenient in all but the most secure environments -- especially for notebook users. Toget 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 deletethe necessary registry values, Windows would just stop caching credentials. The registry values are not designed to be accessed or deleted manually, sothey'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 allowsapplications such as Remote Desktop Client to securely store credentials for each Windows user. To get quickly to the Stored User Names and Passwordsdialog 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 toa 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 thatonly the required privileges can be granted. This approach provides some damage limitation should the service be compromised. However, it alsointroduces 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 orlocal admin rights.

In Windows Server 2008 R2, Microsoft introduced managed service accounts (MSAs), which work like AD computer accounts in that passwords are assignedand reset automatically. These accounts can be created only by using Windows PowerShell and aren't supported by all third-party services. MSAs must beinstalled on a computer and by design, can be associated with only one device, and therefore can't be used in cluster-failover scenarios. When youconfigure 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 andusers 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 moresophisticated privilege-management functionality than is available out-of-the-box in Windows. These solutions can be used to solve least-privilegesecurity challenges quickly and to provide more granular control than would otherwise be possible. Application whitelisting is also essential to blockunauthorized 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. Managesensitive computers, such as DCs, from dedicated management workstations and use AD delegation and OUs to separate objects that are crucial for runningbusiness systems from those that support staff can manage on a regular basis. And in the case of a virus outbreak or other malicious attack, followingthe advice in this article will make your IT infrastructure more resilient.