Local vs Domain User Accounts

Introduction

I find that sometimes the simplest of concepts might be more complex than first anticipated and might not be 100% understood by everyone. In the case of user accounts and where they are located, I find this to be one of those areas. When running a corporate network or even small business network, it is key to know where your user accounts are so you can control them. Without control of user accounts bad things can occur. For example, if local accounts can be created which have local admin privileges, these computers where the accounts reside become unmanageable and can cause significant damage to the network without controls. Understanding and controlling local and domain user accounts correctly is vital to a safe, secure, and well managed network.

Logging in Initially

At the initial logon is when a user is given the option to logon with either a local or a domain user account! The GUI is not 100% clear to this fact, but it is exactly what is occurring. Moving from Windows XP to Windows 7 is another move that makes this concept complicated. At logon of a Windows XP computer, the user can either select the domain (or one of many trusted domains) or the local computer, as can be seen in Figure 1.

Figure 1: Initial logon on Windows XP allows users to choose a local or domain user account.

For Windows 7, the logon has changed and the options are even more complicated. Figure 2 illustrates a Windows 7 computer joined to a domain and the options available to the user logging on.

Figure 2: Initial logon on Windows 7

If the user chooses any option but the one that says (this computer) after it for Windows XP, the user will be logging on with a domain account. The list of options above the option that says (this computer) includes the domain the current computer has joined, as well as all other trusted domains for the domain which the computer has joined.

In order for a user to choose any of the listed options, the user must have a known username and password for that option. For all of the domains listed, the user accounts are stored on the domain controllers for the listed domain. For the local computer, the user accounts are listed in the local security accounts manager (SAM) on the computer where the user is currently typing.

Here are a few key technical points about domain membership, domain controllers, and user accounts.

• A computer can only be a member of one domain at any time
• A domain controller can only be associated with one domain at a time
• There should be a minimum of (2), but usually more domain controllers per domain
• A user account can only be listed in a domain one time
• A user account can be listed in all domains, but only one time
• A trusted domain should not duplicate the user accounts from one domain to the other; it is the trust relationship which allows for a user to logon from a computer joined to one domain, which has a trust with another domain. Duplication of accounts negates the point of the trust.

Default Local Accounts

For a windows 7 computer, there are only a few default user accounts. This is by design, as for a corporation the number of local accounts on a desktop should be limited. Ideally, there should not be any additional local user accounts created on a corporate desktop. This will negate the user from logging in locally at the initial logon. The default user accounts for a Windows 7 computer include:

• Administrator
• Guest (Disabled by default)
• <configured admin>

There is a big difference between Windows 7 and Windows XP in this instance, as Windows 7 forces the installation to create a new user account, which will be used in lieu of the built-in Administrator account. The reason for this is to reduce the overall attack surface, as the built-in Administrator can be disabled, configured with a significant password, etc.

Local Account Scope

When a user logs on with a local user account the scope and access that the user has access to, is significantly reduced. Local user accounts only have access to resources on the local computer and nothing else. A local user account can’t be placed on an access control list (ACL) or placed in a domain group. Thus, the access in a corporate environment is diminished enough to make the configuration undesired.

Default Domain Accounts

There are plenty of default domain accounts when Active Directory is installed. For a Windows Server 2008 or 2008 R2 freshly installed domain controller for a new domain, the list of user accounts include:

• Administrator
• Guest (Disabled by default)
• Krbtgt (Kerberos service account)
• <configured admin>

Again, notice that in a newer operating system domain, there is a forced admin account to be created, which is intended to be used in lieu of the built-in Administrator. For the domain, it is not highly suggested to disabled the Administrator account, but rather rename it, configure a long and strong password, and then create a false Administrator account (which has no admin privileges).

Domain Account Scope

The scope of a domain account is where the power of a Windows Active Directory domain comes into play. Domain user accounts can be configured for the following:

• Domain group membership
• Located on an ACL for ANY resource on any computer that has also joined the domain
• Located in a local group of ANY computer that has joined the domain
• Placed in a user right of ANY computer that has joined the domain
• To receive centralized Group Policy settings to set security, profile, desktop, etc. information

As you can see, the role of a domain user account is a “true enterprise” account. To allow users to logon with a local account creates an insecure situation, as there is little that can be done to control local accounts. Domain user accounts can be controlled, disabled, and managed centrally.

Summary

The concept of domain vs local user account is really not much of a debate. For any organization, I highly suggest that all local user accounts be deleted and only those that are truly required be allowed. This might include service accounts, developer test accounts, application type accounts, etc. Allowing a user to log on to the local computer provides little control. The worst possible case is to allow a user to logon with local administrative privileges, which is impossible to control. It also creates a situation where the user can attack the network from a computer that is part of the domain. This is never good. Removing all local user accounts forces the user to logon using a domain user account. This immediately gains benefits for the entire enterprise and the network admins can control all access and functionality of the user account in this scenario.