Managing Privileged Access to Servers

Even for small teams working with a handful of servers, managing privileged access can make the difference between stable, secure systems and uncontrolled change that imperils a company’s systems and data. As networks grow, the need to manage privileged access to servers as a means of basic security and change control is simply unavoidable and might also be a prerequisite for regulatory compliance. Let's dive into the access problems that many companies face, then walk through some basic steps that can put your organization on the right path to more secure systems.

Defaulting to Domain Admins

Small enterprises frequently hand out accounts with Domain Admin privileges to IT staff. Not only is this the easiest way to give immediate root access to all workstations and servers (because the Domain Admins group is added to the local Administrators group when computers are joined to a domain), but it also provides write/change access to objects stored in Active Directory (AD). But how often do junior administrators or support professionals really need Domain Admin privileges? Apart from the risk involved in granting new staff members root privilege to your entire network on their first day, administrative access to workstations needn’t be via the Domain Admins group. Best practice is to provide root access to servers on an as-needed basis.

Determining Access Levels

In contrast with UNIX security, which uses ACLs to control access to files, Windows secures all objects and comes with a series of built-in groups intended to ease the permission-granting process. Although it might be tempting to take advantage of the more granular security model in Windows and add sysadmin accounts to these groups, it should be done with caution as it becomes more difficult to audit system changes. However, it might be permissible to make a sysadmin a permanent member of read-only groups, such as Event Log Readers, as those groups don’t grant any administrative access to servers.

Service accounts often require administrative access or a privilege that standard users don't hold. Such accounts can also be used to run scheduled tasks or batch files and might also require elevated privileges. Accounts used to give temporary access to servers (i.e., firecall accounts) for maintenance purposes also require privileged access. Any other requests for permanent privileged access to servers outside the scope of service and firecall accounts should be carefully considered, and in many cases is unlikely to be necessary.

Setting the Scene

Before we look at working directly with servers and privileged accounts, it’s important that we have an AD structure that facilitates easy server management. The organizational unit (OU) hierarchy that I’ll illustrate in this article is based on recommendations in the Windows Server 2008 Security Compliance Management Toolkit (technet.microsoft.com/en-us/library/cc514539.aspx) and represents a typical structure deployed in organizations. In Figure 1, the GPOs with the prefix WS08 EC were automatically generated using the toolkit’s GPOAccelerator tool and contain the recommended settings for each server role in a standard enterprise configuration.

You’ll notice that in addition to the default container for domain controllers, I’ve created OUs for Firecall Accounts, Service Accounts, and WS08 EC Member Servers. Using OUs to separate firecall and service accounts from standard domain user accounts lets you delegate control of specific account properties in the OU to a limited set of users.

The WS08 EC Member Servers OU is further divided into OUs for specific server roles: WS08 App Servers and WS08 EC File Servers. The WS08 App Server Baseline GPO was created using the Security Configuration Wizard in Windows Server 2008 as these servers are specific to my organization. The WS08 App Servers OU contains the DMZ OU, so different security settings can be applied according to the servers’ exposure to external threats.

Firecall Accounts

Before disabling the built-in administrator accounts and randomizing the password, you should create a domain user account for each server in a dedicated AD OU. We’ll use the Restricted Groups policy to add the appropriate firecall account to each server. Firecall accounts are managed by a dedicated security team, who enable the otherwise disabled accounts and issue randomly generated passwords to sysadmins for a limited period of time, after which accounts are disabled and passwords changed.

Every time a firecall account is enabled and a password is issued to a sysadmin, the security team manually logs the details so that any problems resulting from changes made during the logon session can be traced back to a specific user, time, and change request. If sysadmins use their own accounts to log on to servers, we can track user logon and logoff events but not the level of privilege. Ideally, the security team wouldn’t know the passwords issued for firecall accounts, but that would require the deployment of a dedicated password-management system.

Delegating Control to Manage Firecall Accounts

In my example, I’ve created four firecall accounts (e.g., AppServ01_Firecall, AppServ02_Firecall) for my application servers in the Firecall Accounts OU. I have a specific team of security administrators whom I'll allow to enable, disable, unlock, and reset the passwords on accounts in the Firecall Accounts OU.

Let’s use the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in to delegate specific access to the Firecall OU:

Any users in the On Duty Security Team group who are otherwise standard domain users will now be able to open Active Directory Users and Computers and perform limited actions on user accounts in the Firecall Accounts OU.

Managing Privileged Server Access with Restricted Groups Policy

In Figure 1, apart from the WS08 App Servers Baseline GPO, there are four additional GPOs linked to the WS08 App Servers OU prefixed with Restricted Groups that are specific to the four servers whose computer accounts are located in the OU. Each Restricted Groups GPO contains a WMI filter to ensure that the settings apply only to the relevant server. To create a Restricted Groups GPO, open Group Policy Management from Administrative Tools on the Start menu as a domain administrator:

Before linking our new GPO to an OU, we need to add a WMI filter to ensure that the policy applies only to a specific server. Alternatively, you could create a separate OU for each server. Either way, an additional AD object is necessary.

You can now link the GPO to the appropriate OU to apply the Restricted Groups policy to the server. If you try to add an account to the local Administrators group on the given server, then refresh the policy by using the Gpupdate /force command, you’ll notice that the account you added is removed.

Built-in Administrator Accounts

The administrator account should be disabled and password randomized when machines are initially deployed. Although the built-in administrator account is disabled by default in Windows Server 2008 and Windows Vista or later, the password for this account should be randomized on each server as it’s still possible to use this account to boot into Safe Mode and log on. For devices that have already been deployed, you can use a script to disable the built-in administrator account, as well as change and record the password. The BIOS of each server should be protected by a password and the boot order set to start only from the local disk.

Service Accounts

Service accounts often require privileged access, and like firecall accounts, they're specific to a given server. As such, service accounts can be managed in a similar way to firecall accounts in their own dedicated OU with control delegated to a limited set of people.

Server 2008 R2 introduced the concept of Managed Service Accounts (MSAs) and Virtual Accounts. MSAs are domain accounts created and managed using PowerShell cmdlets that have automatically generated 240-character passwords that are reset every 30 days by the Netlogon service in much the same way as computer accounts. MSAs can be associated with only one computer (Server 2008 R2 or Windows 7), but multiple MSAs can be used on a single machine. If your AD forest is running at Server 2008 R2 functional level, you can see the Managed Service Accounts container in Active Directory Users and Computers if you check Advanced Features on the View menu.

Virtual Accounts aren't created but are used to run services. You access them by typing NT SERVICE\[service name\] into the This account field on the service's Log On tab in the service management console and leaving the password fields blank. Virtual Accounts have the same permissions as Network Service: They have standard user rights on the local machine but communicate with the network as the local computer account. For more information about MSAs and Virtual Accounts, see Use MSAs to Ease the Pain of Administering Service Accounts.

Auditing Logoff and Logon Events

Once a sysadmin has informed the security team that his or her work is complete on a server and the firecall account can be disabled, it might be worth checking the server's security event log to ensure that the firecall account has indeed been logged off. Even if an account is disabled, that doesn’t necessarily stop the account from being used to perform administrative functions on a system if it has already received an access token. You can give the security team read access to security event logs on servers and check for 4624 and 4634 logon/logoff events.

Alternatively, you can use event forwarding and collect logs on a central server. If the source servers are running Server 2008, the Network Service account must be added to the local Event Log Readers group so that security events can be forwarded. For more information on the requirements for forwarding security events, see Forwarding Security Events from Windows XP, Server 2003, and Vista/Server 2008.

To read the Forwarded Events log on the server collecting events, you need to add the appropriate users or groups to the server’s Event Log Readers group. Each subscription can be filtered so that only the relevant logon/logoff events for a given user are forwarded, as you see in Figure 3.

Despite the fact that Restricted Groups policies are a fairly robust way to ensure that only specified accounts and groups are members of the local Administrators group on servers, you could also use a script to audit local Administrators and compare the results with a known membership list for each server. The following PowerShell code uses ADSI to enumerate members of the local Administrators group on a machine called MyServer1:

$group =\[ADSI\]"WinNT://MyServer1/Administrators" 
 $members = @($group.psbase.Invoke("Members")) 
 $members | foreach \{$_.GetType().InvokeMember("AdsPath","GetProperty",$null,$_,$null)\}

Domain Controllers

Privileged access to DCs presents a particular problem because there are no local groups, and administrative access granted to a user via a built-in AD group (e.g., Server Operators) ultimately provides enough access for a user to elevate privileges, making it impossible to completely separate access to the server and AD.

Nevertheless, firecall accounts can be created for DCs, but due to the distributed nature of AD’s built-in groups, these accounts should be restricted to the DC, which they can log on to by using the This user can log on to feature on the Account tab of the user’s properties in Active Directory users and Computers, as you see in Figure 4. Everyday administrative tasks that require a connection to a DC should be carried out using the Remote Server Administration Tools (RSAT) and the appropriate permissions delegated to users.

Minimizing Risk

When a new sysadmin joins your team, think twice before handing out an account with domain admin privileges. Establishing simple procedures and delegation of control can significantly decrease the risk associated with IT staff maliciously or unwittingly destabilizing systems or gaining unauthorized access to company data. Although the techniques in this article might not be enough to satisfy auditors, they should put you on the right track. For larger organizations, third-party products such as BeyondTrust’s PowerKeeper (www.beyondtrust.com/products/pkoverview.asp) help fully automate management of privileged accounts across hundreds of servers and assist in achieving compliance with government or industry regulations.