10 Tips for Securing Your Service Accounts

Win2K service accounts have their share of security risks

By default, many application services log on with the System account. Although using the System account can ease administrative overhead, you should consider having application services log on with a special service account instead. If intruders attack a service that uses the highly privileged System account, they might be able to conduct further exploits under that account's context. If intruders attack a service that uses a service account, their exploits are limited because a service account typically has only the permissions it needs to perform its function.

To use a service account rather than a System account for a service in a Windows 2000 environment, open Control Panel and select Administrative Tools, Services. Right-click the target service's name, click Properties, and select the Log On tab. As Figure 1 shows, the Local System account option is typically selected by default. To use a service account instead, select the This account option and specify the account (e.g., a local or domain account) and the password in the adjacent text boxes. However, before you select this option, you need to know that service accounts have their share of risks, too. If intruders know the name of the account, they can use a brute-force attack, network sniffer, or another password-cracking method to acquire the password and log on. Even administrators who know the password can use the service account to carry out unauthorized tasks or attacks. Fortunately, you can take countermeasures to mitigate these risks. Here are 10 tips for securing your service accounts.

Tip 1: Eliminate Back Doors
You should close as many back doors to your service accounts as possible by closing all unnecessary Access Points (APs). Before creating a service account, you need to determine the degree of functionality that the account requires. If a service doesn't require a particular function, eliminate that function's AP.

For example, intruders can use a remote access server as a back door to networks. So, if your service doesn't need remote access functionality, you should deny dial-in privileges for the service account. As Figure 2 shows, Win2K lets you explicitly allow or deny dial-in privileges on the service's property sheet, which you can access by right-clicking the service and selecting Properties. If you plan to use scripts or programmatic procedures to create service accounts, make sure that you explicitly deny dial-in privileges in those scripts or procedures as well.

In Figure 2, notice the Control access through Remote Access Policy option that's shaded out. This new Win2K option lets you allow or deny dial-in privileges through RRAS. However, if you're implementing RRAS and you select this option, you can inadvertently assign dial-in privileges to a service account. As a safeguard, select the Deny access option instead.

Besides dial-in privileges, other common back doors to watch out for include terminal service logons and remote control privileges. You can access the terminal service properties from the Terminal Services Profile tab and the remote control properties from the Remote control tab on the service's property sheet. In addition, don't assign Internet access or an email account if possible. Having a service account with Internet or email access introduces a wide range of threats into the network. For example, if intruders obtain access to a service account with Internet access, they can automatically launch Microsoft Internet Explorer (IE) and download a Trojan horse on to all the machines to which the service account has Write permissions.

Tip 2: Avoid Copying Accounts If Possible
Creating a service account from scratch and assigning privileges as needed is typically the best practice. However, some situations warrant copying accounts. For example, large organizations might find the administrative overhead associated with creating individual accounts too high, so they opt to use the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in to copy existing accounts. The snap-in's Copy option automatically copies privileges from the source account to the target account, so you run the risk that you might be inadvertently assigning excessive privileges. Thus, avoid copying accounts when the target account's role differs from that of the source account. For example, you shouldn't create a service account for a terminal server by copying a service account for a remote access server. When the accounts' roles differ, you can almost guarantee that the required privileges will, too.

Copying can help lighten the administrative burden, but you risk leaving back doors open. A little administrative effort can go a long way toward reducing the risk associated with providing excessive privileges.

Tip 3: Use the Correct Security Group
Some organizations assign a service account to one or more built-in groups, such as the local Administrators or Domain Admins group. However, assigning a service account to a well-privileged group is extremely risky. For example, if you assign the SQL Server service account to the Administrators group, anyone in that group can use the xp_cmdshell stored procedure to access the OS and execute commands at the OS level. And tracking down the offender would be challenging given that several administrators would likely know the service account credentials.

Sometimes vendors require that you assign service accounts to built-in groups or they won't support the underlying application. In such cases, I strongly urge you to implement a combination of restrictions. For example, you might be able to assign the service account to a custom group and explicitly deny access to that group. Although such tactics might not eliminate the threat, they can serve as a good deterrent.

Win2K provides four security groups that you can use to organize and limit an account. Each group has a different scope that determines the extent to which you can nest it in other groups or reference it in Active Directory (AD) resources. The groups, in order of increasing scope, are local (to a computer), domain local, global, and universal. (For detailed information about these groups, see the Microsoft white paper "Active Directory Users, Computers, and Groups" at http://www.microsoft.com/windows2000/techinfo/howitworks/activedirectory/adusers.asp.)

You can use the four security groups to control a service account's level of exposure to the network. For example, you can create a service account as a domain account, add it to a global group, and nest the global group in a local group on a server. After you assign the local group permissions to a resource on the server, the members of the nested global group would inherit the permissions, too. However, by creating a service account at the domain level, the scope of access afforded the account would be broad because Win2K, by default, assigns a domain account to the Domain Users group.

Conversely, you can create a service account locally on the server on which the resources reside to reduce the scope of access. However, local accounts decentralize administration. Specifically, Win2K creates local accounts in the SAM on the target machine. Therefore, you can't administer the service account centrally like you can with domain accounts, which Win2K creates in AD. Over time, the lack of centralization might result in a local account that becomes neglected and abused. As a result, creating a domain account that you assign to specific groups on an as-needed basis is best. That way, the domain account is subject to more stringent security, such as domain controller (DC) Security Log monitoring and account controls that affect all accounts in the domain.

Tip 4: Explicitly Deny Permissions
In the event of an attack, discretionary ACLs (DACLs) might be your last line of defense. Because weak DACLs can inadvertently provide service accounts access to unintended resources, you need to consciously apply stringent permissions. A feature that's new to Win2K is the Deny check box, which you can use to explicitly disallow certain permissions. In service accounts, you can explicitly deny permissions to resources such as files, folders, shares, and the registry. Because Win2K always evaluates denied permissions first, it ignores any conflicting permissions.

For example, suppose that you create a service account named Svc1. By default, Win2K assigns the account to the Everyone group, which has Read and Execute permissions to system utilities such as FTP. However, you can take advantage of the Deny check box to prevent Svc1 from running FTP. Simply right-click the resource (e.g., C:winntsystem32ftp.exe), click Properties, then select the Security tab. Unless the service account needs specific permissions (e.g., Write) for the resource, you should select the Deny check box for the Full Control permission, which automatically selects the Deny check boxes for all available permissions to the resource. Selecting the Deny check box overrides any permission inherited from the parent (e.g., C:winntsystem32), even when you set inheritable permissions.

Tip 5: Remove Unnecessary User Rights
Many service accounts need only the Logon as a service right. In some cases, excessive rights are implicitly granted if you've assigned the account to one or more built-in groups. If you must add the account to a well-privileged built-in group (e.g., Administrators), you need to review and remove unnecessary user rights.

Win2K provides a way to explicitly deny several common user rights. For example, four new options in Win2K let you explicitly deny logon rights. Of interest are the Deny access to this computer from the network, Deny logon as a batch job, and Deny logon locally options.

You can use a local policy or Group Policy Object (GPO) to assign user rights. For example, you can create a GPO that denies a service account the right to log on through the network, locally, or as a batch job. Because Win2K enforces user rights assignment as a machine policy, you can use a domain-level GPO to apply the GPO on all machines that have accounts in AD. (Applying a GPO on a machine that exists in a Windows NT domain isn't possible.)

When you remove unnecessary rights, make sure that you don't remove any rights that the service might need to run. For example, the Exchange Server service account requires the rights to Act as Part of the Operating System, Log On as a Service, and Restore Files and Directories. If you are uncertain as to which rights you need, review the application's technical documentation or contact the vendor.

Tip 6: Use the Logon To Option
The Logon To option limits the machines to which a domain account can log on. This option is quite effective in limiting a domain account's exposure, especially in a single-domain model that uses WINS. To access the Logon To option, right-click the domain account, select the Account tab, and click the Logon To option. As Figure 3 shows, you must enter the machine's NetBIOS name, not the DNS name, in the Computer name text box.

Tip 7: Implement Time and Day Restrictions
For operations that occur within a finite or predictable time frame, you might want to use the Logon Hours option to implement time and day restrictions. Although administrators commonly use this option to restrict remote access, you can also use it to restrict service accounts that have a fixed logon period.

To access the Logon Hours option, right-click the domain account, select the Account tab, then click Logon Hours. As with any security control, carelessly setting this option can negatively affect the service's functionality. Because the Logon Hours option is an attribute of domain accounts (and not local accounts), you should use this option only for service accounts that you create at the domain level. In addition, you can cause the service account's logon to fail if you set the Logon Hours option and the service's startup time and type incorrectly. For example, a service account whose logon hours are from 8:00 a.m. to 5:00 p.m. would fail to log on if you set the server to automatically start up at 6:00 p.m. Thus, the Logon Hours option is better suited for services that start manually rather than automatically.

Tip 8: Set Password Options
Win2K provides two noteworthy password options that you can set to secure a service account: User cannot change password and Account is sensitive and cannot be delegated. Setting the User cannot change password option ensures that only administrators have control over password changes. Considering that service accounts aren't actual user accounts, few reasons exist for letting anyone but administrators change passwords. By default, you can't apply this restriction to service accounts that are members of the Administrators group because administrators possess the right to change their passwords. However, to reiterate, assigning a service account administrative privileges isn't a good idea.

To set the User cannot change password option, right-click the account to bring up the Properties property sheet. Select the Account tab if the service account is at the domain level or the General tab if the service account is at the local level. Then, select the User cannot change password check box.

You should change the service account password when employees who know the password leave or change their role in the organization. This practice reduces the risk that they will misuse the account. Before changing the password, keep in mind that the Local Security Authority (LSA) on the target machine stores the passwords for all service accounts. As a result, you also must change the password in the Log On tab that Figure 1 shows. (The Password text box won't be shaded out after you select the This account option following the instructions I gave at the beginning of this article.)

Setting the Account is sensitive and cannot be delegated option ensures that the account won't be delegated. Delegation lets one account use another account's privileges to connect to local or remote machines. Malicious software or Trojan horses can abuse this ability to connect under the privileges of another account to gain further access to a network.

Fortunately, only a Domain Administrators group member can enable delegation. However, as a safeguard, you should always set the Account is sensitive and cannot be delegated option for a service account, unless the account explicitly requires delegation. You set this option by selecting the Account is sensitive and cannot be delegated check box on the Account tab of the account's Properties property sheet. (This option isn't available at the local level.)

Tip 9: Apply Security Controls
The MMC Security Templates snap-in lets you define and apply security controls in seven areas: Account Policies, Local Policies, Event Log, Restricted Groups, System Services, Registry, and File System. You can use the Security Templates snap-in to create a security template that sets security attributes (including the explicit Deny permission on user rights and resources) in these areas.

Templates are helpful in situations in which users might be trying to use a service account to escalate their privileges. After you've created a template for the service account, you can even import the policies to other machines. For information about creating and importing security templates, see Paula Sharick, "Security Templates Define and Enforce the Rules," January 2002, InstantDoc ID 23375, and John Howie, "Using MMC Snap-ins to Secure Win2K Systems," August 2001, InstantDoc ID 21668.

Tip 10: Audit the Security Log
When securing service accounts, the Security Log in Win2K's Event Viewer can serve two essential functions. First, you can use the log to make sure that the countermeasures you've taken to secure your service account won't negatively affect the service logon. Second, you can monitor the log to look for suspicious activity.

For both functions, you must define an audit policy before logging can occur. You can configure the policy locally on the target machine or as a GPO in AD. To define an audit policy locally, open Control Panel, Administrative Tools, Local Security Policy. Next, expand Local Policies, then Audit Policy to review and configure the list of audit categories. For a description of the audit categories, see Randy Franklin Smith, "Auditing Windows 2000," July 20, 2000, InstantDoc ID 9633. This article also describes how to use GPOs to implement audit policies.

To determine whether your countermeasures will affect the service account's logon, you need to enable the Audit logon events policy and audit the success and failure of logon events. Afterward, you can review the logon events by opening Control Panel, Administrative Tools, Event Viewer on the target machine. In the Security Log, event ID 528 indicates a successful logon, whereas event ID 529 indicates a failed logon. If a failed logon occurs, you might have to reassess the countermeasures you've taken.

When a logon event occurs, Win2K lists a number in the Logon Type field to denote the type of logon that occurred. The right to log on as a service is designated as a Type 5 logon. From a monitoring perspective, service accounts typically don't need the right to log on locally (Type 2 logon) or over the network (Type 3 logon). As a result, traces of local or network logon events for a service account should raise a red flag. Another type of logon to watch for is Type 4, which indicates a batch-job logon. For more information about auditing logons, see Randy Franklin Smith, "Tracking Logon and Logoff Activity in Win2K," February 2001, InstantDoc ID 16430.

Another audit policy you might want to enable is Audit object access. Although auditing this policy can be resource-intensive, it can help you determine a service's baseline access requirements. For example, suppose you want to determine the baseline access requirements for a system utility such as cmd.exe. After you enable the Audit object access policy, right-click cmd.exe and select Properties, Security. Then click the Advanced button. On the Auditing tab of the dialog box that appears, select the service account and set the object access permissions (e.g., Read, Write) you want to audit. Next, start the service and run the application to establish a baseline. Finally, review the Security event log for traces of any access to the specified file. For example, if you see no traces of read access for cmd.exe in the log, you might consider selecting the Deny check box for cmd.exe's Read permission.

Beat Intruders to the Punch
Using a service account for application services is much safer than using a System account. However, even with service accounts, you still face some security risks, such as misuse of the account and escalation of privileges. Because the threat is real, you must implement countermeasures to thwart attacks. After all, if you don't spend time scrutinizing the access afforded the service account, intruders usually will.