Tips for Tightening User Account Security

Windows comes in for a lot of criticism about its lack of security, but in fact, the Windows platform has all the necessary elements for a secure OS. Windows has strong user and group management features, detailed access control mechanisms, extensive rights separation, and robust authentication and encryption features. Even so, just having these features isn't enough—to maximize system security, administrators and applications must make use of the features.

One common problem area is that of user access. User authentication is the foundation of the Windows security mechanism. So, for example, if an intruder discovers an Administrator password and logs on as that user, the intruder will gain administrative access to the machine. Moreover, if a user can move his or her account into the Administrators group, he or she gains full access to all machines to which the group has access. Therefore, one key to securing Windows is to properly secure user accounts. Here are the steps you can take to do that.

Prohibit Account Sharing
A secure system lets you associate any audited event with a specific user identity. Therefore, you should never allow users to share accounts. Everyone seems to agree on this basic rule, but few actually follow it. The simple truth is that failing to follow this guideline completely undermines the Windows security model.

Remove or Disable Unused Accounts
A typical Windows installation has default accounts such as those that Table 1 shows. Remove any of these accounts that you don't use. You can't delete the built-in Administrator and Guest accounts, so you need to take special care with them.

Every Windows Server 2003, XP, Win2K, and NT system has a local Administrator account that you can't remove. Instead of using this account, many administrators use a domain account for administering machines in a network environment, so the local Administrator account often sits idle. When this happens, the account can be a security risk both because of the idleness and because the account is by default exempt from account lockout and password expiration policies. Another problem with the Administrator account is that, as a role, it might not uniquely identify a specific user. In too many situations, multiple users share the Administrator account. This account should instead be used for emergency situations and day-to-day administration handled by a unique account for each user.

Although you can't delete the Administrator account, in Windows 2003 and XP, you can disable it by using the Accounts: Administrator account status policy. With this policy, you can disable the account for normal local and network logons, but Windows still lets you use it in emergencies by allowing logon to the account through Safe Mode.

Whether you disable the local Administrator account or not, consider renaming it. Although many argue that discovering the new name of a renamed Administrator account isn't difficult, renaming the account still serves as a somewhat effective obstacle: for example, in cases where an attacker can't discover the new account name or an automated attack doesn't recognize the renamed account. Renaming the Administrator account isn't a strong defense, but it does provide enough obscurity to be helpful.

You can't completely remove the Guest account, either, but you can enforce disabling and renaming this account by using Accounts: Guest account status and Accounts: Rename guest accounts. Like all policies, you can set these either through Group Policy or through a system's Local Security Policy.

By default, the Guest account has no password, and even though the account is disabled, assigning it a password in case it somehow gets enabled is a good practice. Here's a quick command to assign a random complex password to the account:

net user Guest Aa%RANDOM%-%RANDOM%-%RANDOM%-  %RANDOM%-%RANDOM%

Assign User Rights
Grouping users gives you an effective mechanism for role-based access control (RBAC). Always plan group membership carefully. The key to using groups effectively is to properly limit a group's rights and permissions and then carefully enforce group membership.

If you look at the User Rights Assignments section of a security policy, you'll notice that for the most part, Windows assigns these rights to groups, not individual users. You should follow this strategy when adjusting these rights. When you set a user rights assignment policy, sometimes it's confusing and time-consuming to determine exactly which rights you should give to which groups. For example, a system set to the default lets Administrators and Server Operators change the system time and lets Administrators, Backup Operators, and Server Operators back up files and directories. Rather than spend a lot of time trying to determine whether you need to assign rights to these groups, first check to see whether you even use the groups. Many built-in groups are empty by default; if you don't use the groups, you don't need to assign any rights to them.

Many of the user rights default settings are sufficiently secure for most purposes, but there are some rights you might want to carefully consider, such as the following:

Access this computer from the network and Deny access to this computer from the network. These rights determine which accounts can and cannot access resources that the server service provides over the network. You should always have at least one administrator with access rights, because they're required for many administrative tools that use the network APIs, even for local access. Note that these rights don't affect Terminal Services logons.

Allow logon through Terminal Services and Deny logon through Terminal Services. These are new rights in Windows 2003 that control access to Terminal Services. Any users who need to log on through Terminal Services must have these rights.

Debug programs. Consider removing this right from all users, including Administrators. Doing so prevents malicious users with this right from using tools such as Pwdump2 and L0phtCrack to dump the local SAM hashes.

Log on locally. This right determines which users can log on interactively at the console. Administrators should always have this right. In Win2K, this right is required to log on through Terminal Services.

Restrict Group Membership
As I've mentioned, controlling group membership by limiting which users can join which groups is important. Consider first the Everyone group, which, depending on your version of Windows, might by default include anonymous users. You don't want to inadvertently allow anonymous access through Everyone. To eliminate the possibility, disable the Network access: Let Everyone permissions apply to anonymous users security policy.

Many administrators overlook or fail to make use of the Restricted Groups policy. By using a security template with this policy, you can enforce group membership and even configure groups so that they can't have any members. To set up a template, create a text file in the %SystemRoot%SecurityTemplates directory with a name like restrictedgroups.inf. Using any text editor, add the text that Figure 1 shows, adjusting the names as appropriate for your environment. Note that the template in Figure 1 will prevent any user from gaining membership to the Power Users or Backup Operators groups because no users are listed for these groups.

You can apply the template with the following command:

secedit /configure /db   %SecurityPath%Database    groups.db /cfg   %systemroot%securityinf    restrictedgroups.inf /verbose

When Group Policy is refreshed after you initiate this command, you won't be able to change the members of any of these groups, even if you have administrator access. If you need to change group membership in the future, you'll need to modify and reapply the security template.

Be Strong
Ultimately, the best way to secure user accounts is with careful planning and organization along with regular audits and reviews. A strong user policy combined with the techniques described here will help you do a better job of minimizing account abuse.