Limiting Risk Associated with Local Accounts - 27 May 2004

We view local user accounts on workstations and member servers as security risks. Can we disable the local accounts feature and force all our server and workstation administrators to use domain accounts?

Local accounts can expose you to additional risk for several reasons. Local accounts can't use Kerberos and must rely on the Windows NT LAN Manager (NTLM) authentication protocol, which is much easier to sniff and crack. And although local accounts are subject to the centralized password and lockout policies defined for Active Directory (AD), logon failures and account lockouts don't appear in the domain controllers' (DCs') security logs. Instead, you must monitor each computer's security log. Finally, maintenance checks (e.g., looking for dormant accounts) that you perform on AD accounts don't detect outdated local accounts. To catch such accounts, you need to perform the same checks on each computer's local accounts.

You can't completely remove the ability to have local accounts on Windows, but some techniques can limit the risk that local accounts pose. First, I show you two methods you can use on Windows 2000 and later, then I show you a method that only Windows Server 2003 and Windows XP support. Remember that local administrators can't effectively override anything that's defined in Group Policy.

In any AD Group Policy Object (GPO) under the Computer ConfigurationWindows SettingsSecurity SettingsRestricted Groups folder, you can mandate the membership of local groups. You can use Restricted Groups to limit the Administrators group so that it contains only the Domain Admins and any server administrators groups. This technique prevents administrators from giving administrator authority to local users. Although a server administrator can temporarily add a local user account to the Administrators group, Windows will remove the account the next time the OS applies Group Policy. You can similarly limit the membership of other local groups, such as Users and Backup Operators.

Another way to lock down local users is through logon rights. Windows has different logon rights for each type of logon, such as interactive (at the console), network, and Win2K Server Terminal Services logons. You can control these rights assignments from any GPO—open the Microsoft Management Console (MMC) Local Computer Policy snap-in and navigate to Computer Configuration, Windows Settings, Security Settings, Local Policies, User Rights Assignment. For example, you can create a GPO on servers that assigns the Access this computer from the network right to Domain Users only. The Domain Users group includes all users of the domain but excludes local user accounts. If you make this change, legitimate domain accounts can still connect to the server and access shared folders and other resources according to each object's permissions, but no one can use the computer's local accounts to connect to the computer.

The third way to limit local account risk is through a feature new to Windows 2003 and XP. Under Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options, you'll see the Network access: Sharing and security model for local accounts policy. This policy controls how the computer handles connection attempts from people elsewhere on the network who try to log on with a local account. As Figure 1 shows, you can set this policy to Classic or Guest only. When a user connects as Administrator and successfully authenticates in Classic mode, Windows treats the user as Administrator and lets the user perform whichever tasks the Administrator has authority to perform. But when a user connects as Administrator and successfully authenticates in Guest only mode, Windows treats the user as a guest, even if he or she correctly authenticates as Administrator. In Windows, the Guest account has very limited access. I used Administrator as an example, but this approach applies to all other local user accounts as well.

—Randy Franklin Smith