Lesson 1: Creating Local User Accounts and Security Groups

Lesson 1: Creating Local User Accounts and Security Groups

A fundamental component of Windows security is the user account. A user account identifies the person using the computer to the operating system so that it can apply appropriate authorization to access resources. Using another fundamental component, security groups, you can manage users with similar security requirements. This lesson discusses local user accounts and security groups on workstations and member servers. Member servers are servers that are members of a domain but not domain controllers.

---

After this lesson, you will be able to

• Create and manage local user accounts

• Create and manage local security groups

Estimated lesson time: 30 minutes

---

Managing User Accounts

While logging on to a computer running Windows, a user must provide credentials (Figure 2.1), such as a user account name and password, that prove the user is authorized to access the system. Windows can also be configured to use smart cards or other types of authentication, but passwords are the default and most common form of authentication.

Windows provides two types of user accounts: local accounts and domain accounts. If you log on to a computer using a local account, you have access to that computer only. If you log on to a computer using a domain account, you have access not only to that computer, but also to network resources throughout the domain. Local accounts are stored on all Windows computers except domain controllers, and domain accounts are stored in Active Directory on domain controllers so they can be used on any computer that is a member of the domain.

Figure 2-1. The Microsoft Windows 2000 logon prompt

Joining a computer to a domain does not disable its local system accounts. Each computer has a default administrator account that can still be used to gain access to the system irrespective of its membership in a domain. Always secure the local computer administrator account with a strong password to prevent anyone from using it to exploit the computer. If computer users need administrative privileges on their own machines, create a domain account for this purpose and make that account a member of their local computer's administrators group.

Computers that are members of a domain should have the fewest possible numbers of local user accounts and security groups because it is very difficult to manage local user accounts individually on every machine in a domain. In a domain, control security using domain user accounts and groups rather than local user accounts.

To the system, a user account is represented not by its name but by its security identifier (SID). A SID uniquely identifies a security principal throughout the system. A security principal is any Active Directory object, such as a user account, a computer account, or a security group, that can be assigned permissions and rights.

Because user accounts are represented not by names in the system but by SIDs, a user account remains unchanged even when it is renamed. However, a newly created account with the same name as a deleted account will have a different SID, and will not have access to the same resources as its predecessor.

SIDs are globally unique and are never reused; no two user accounts anywhere in the world can have the same security identifier. The operating system guarantees this by including the computer's SID with each local user account SID, and by choosing computer SIDs randomly from a pool of numbers so large that it's practically impossible for any two to be the same. This means that no account from one computer will be able to log on to another computer, eliminating a serious security problem that affects other operating systems.

When attached to a domain, Windows XP Professional requires password authentication. However, for local access, the Windows XP operating system does not require password authentication by default. Users must still log on by asserting their identities, and all local Windows security mechanisms are in effect as they are described in this chapter. The only difference between providing a password and clicking an account icon is that by clicking an icon, users are trusted to identify themselves correctly (rather than proving their identity with a password) in environments where user level security is not a concern, such as a home environment where two or more family members share a computer. Account holders can set a password to protect their local accounts.

SIDs are used by the system to determine which security principals, such as user accounts and security groups, have access to specific secured resources. A structure in every secured resource, called an access control list (ACL), contains an entry for every security principal that is allowed to access the resource. If a user has access to a secure resource, the user account's SID, or the SID of a group the user belongs to, appears in the secured resource's ACL as an access control entry (ACE). The ACE contains the SID of the allowed security principal along with the type of access allowed, such as Read access or Change access. ACLs are discussed in detail in Chapter 4, "Account-Based Security."

Figure 2.2 shows the ACL for a folder named Departments. The SIDs of user accounts are displayed as the name of the account unless the account has been deleted, in which case the actual SID number is displayed.

Figure 2-2. The access control list for the Departments folder

Managing Security Groups

If every user account's individual SID were used to indicate access to a specific resource, the ACL of that resource would become unmanageably large as the number of users increased. In such a system, the folder's ACL would need to have 10,000 entries if 10,000 users required access to the folder. On a network with just a few thousand users, the time required to check permissions would eclipse all other functions performed by the operating system. Using security groups prevents this problem by dramatically reducing the number of SIDs listed in ACLs.

Optimizing Security Checking

To optimize security checking for the machine and make administration more convenient, users with the same security requirements can be combined into security groups. A security group has its own unique SID, so it can be used to specify permissions for a resource.

After you've made a user account a member of a security group, the security group's SID is placed in the user's access token when the user logs on. An access token represents the complete credentials of the logged on user. When the user attempts to access a secured resource, the user's access token contains the security group's SID, which matches the SID in the ACL for that resource, so the system allows the user access to anything the group can access. Access tokens are described in detail later in this lesson.

Essentially, when users are combined into security groups, Windows has to search through security groups only when a user logs on to gather all the SIDs to create the user's access token. When the user is logged on, there's no further need to check group access. Another benefit of using security groups is that ACLs can be much smaller because they need to contain only the SIDs of security groups, rather than those of individual users.

Administering Groups

Create a security group whenever a unique combination of security requirements applies to a number of users. Any time a folder should be secured for a unique set of users, create a security group, secure the folder using the security group, and add those users who need access to the folder to the group.

For example, if a working group of engineers embarks on a new project that is sensitive and requires secure handling, create a security group that contains the members of the working group, and create a folder on a server that has its NTFS file system permissions set to allow access only to that security group.

Security groups frequently mirror the structure of departments, working groups, teams, and corollary duties in an organization, and they are usually created ad hoc to fulfill an immediate security need.

Information about how to effectively use permissions is contained in Chapter 4, "Account-Based Security."

User accounts can be members of any number of security groups, so there's no need to limit your use of them. For example, a financial controller might be a member of the Controller, Bookkeeping, Accounts Payable, Accounts Receivable, and Accountant groups. In this way, the financial controller has access to all the resources to which these groups have access.

Authenticating a User on a Local Computer

A user who attempts to use a Windows 2000 computer must authenticate with the computer, usually by providing the user account name and password that are stored with that user account. Windows checks the information provided against the user account database to see if the password matches. If the password matches, the user is presumed to be the person for whom the account was established, and access to the computer is allowed. Other authentication methods are supported by Windows, such as biometric authentication or smart card authentication, but password authentication is the default and most widely used method.

Chapter 6, "Managing a Public Key Infrastructure," and Chapter 7, "Increasing Authentication Security," contain more information about alternative authentication methods.

Local Logon Process

As Windows 2000 starts, its final task is to start the Winlogon component of the Local Security Authority (LSA). The Local Security Authority is the process in Windows that is responsible for enforcing authorization in Windows. The LSA performs nearly all security-related functions, including logging on users and creating access tokens, accessing security accounts databases, and checking permissions on secured resources.

The LSA process constantly runs in the background on all Windows computers, and it appears in Task Manager as Lsass.exe.

The Winlogon component of the LSA is responsible for displaying the familiar logon dialog box in Windows (Figure 2.1), which collects the user's account name and password. The LSA uses that information to query the Security Accounts Manager (SAM), a secure database of user accounts stored in the registry, to check the password and, if it matches, to retrieve the user's SID and the SIDs of all the groups to which the user belongs. The LSA combines these SIDs to form an access token. The LSA then starts the user's shell program (usually Microsoft Windows Explorer) and passes the access token to the shell program.

When any program starts another program, it passes the access token that it inherited to the program it launches. In this way, every application executes with the credentials of the user who originally logged on, and every application is said to run in that user's security context.

Figure 2.3 shows the local authentication process.

Figure 2-3. The local logon process

The interactive logon process works like this:

1. Winlogon service of the Local Security Authority collects the user name and password.

2. LSA queries the SAM to verify the user name and password.

3. LSA creates an access token based on the user account SID and security group SIDs.

4. The access token is passed to subsequent processes, which is Windows Explorer unless the default has been changed by Group Policy. The user is now logged on.

Local Resource Access

When a program requires access to a secured resource, such as a file, it provides its access token (which is the access token of the user who originally logged on) to the security reference monitor component of the LSA. The security reference monitor compares the SIDs contained in the access token to the SIDs contained in the secure resource's ACL and allows access only if a match is found between the SIDs and the type of access requested. ACLs and resource access are described in greater detail in Chapter 4, "Account-Based Security."

Local Built-In Groups

Windows 2000 provides a set of built-in local groups. Built-in groups are groups that have been predefined with specific user rights, and are used to secure the base operating system. By making user accounts members of these built-in groups, as shown in Table 2.1, you can easily define the roles and rights of a user.

Table 2-1. Built-In Local Groups

Group	Use
Administrators	Users who have full administrative access to the computer. The built-in administrator account is a member of this group. The Domain Admins group is made a member of this group if the machine is joined to a domain.
Backup Operators	Users who have the ability to back up and restore files to the computer irrespective of the security permissions on those files. They do not have any other administrative rights.
Guests	Members whose use is limited to specifically assigned secured resources for occasional use. Guests cannot make permanent changes to their desktop settings. The built-in guest account is a member of this group by default, and the Domain Guests group is added to Guests if the machine belongs to a domain.
Power Users	User accounts with the elevated user rights to modify accounts and create shares.
Replicator	A user account with the right to replicate files in a domain.
Users	Standard users. All user accounts are added to this group by default, and domain users are added to this group if the computer is a member of a domain.

System Groups

System groups are local groups that do not have administrator-definable lists of members. The system automatically places users in these groups whenever their usage meets the purpose of the group. Table 2.2 lists the system groups and describes the groups' members.

Table 2-2. System Groups for a Local Computer

System group	Use
Everyone	All user accounts that access the computer, including anonymous users and users who have not specifically logged on (if the Guest account is enabled)
Authenticated Users	All user accounts that have successfully authenticated on the local machine and the Active Directory (if the machine is part of a domain)
Creator Owner	The user account that owns a specific secured resource
Network	Any account that logged on to the computer through the server service
Interactive	Users who have logged on locally or through Terminal Services
Anonymous Logon	Users who have enough access to determine which shares are available without logging on
Dialup	Users who have logged on through a Routing and Remote Access Service (RRAS) dial-up session

The most commonly used system group is the Everyone group. When an NTFS disk is formatted, the permissions on the root directory are set to allow the Everyone group Full Control permission to access it, and these permissions are automatically inherited by files and folders placed in the volume. For this reason, the Everyone group appears in many ACLs throughout most systems.

It is always a security mistake to allow the Everyone group Full Control permission to persist on the root of a new NTFS volume, except on the root of the C drive or where page files exist because Windows recreates the page file at every logon, and permissions in the containing folder affect this process. At the very least, permissions for volumes without page files should be changed to remove the Everyone Group ACE and allow the Authenticated Users group to have Full Control. The Everyone system group includes users who may not have provided credentials to the system, and that is essentially the same as having no security set at all.

Remember to change the root permissions of newly formatted volumes right after you format them to ensure that files and folders moved onto the volume inherit secure permissions.

Workgroup Background Authentication

Although local accounts do not have credentials on other machines, you can make accessing a remote computer seamless when using local system accounts.

Windows 2000 automatically negotiates credentials with another computer when you attempt to access a resource on that computer, sending your account credentials to the remote machine.

• If a local account exists on the remote machine with the same account name and password as the account you are using on your computer, the remote computer will use the logon name and password to generate a session and an access token without prompting for credentials.

• If the machine has an account with the same name but a different password, it will deny access.

  Users can also specify that they want to provide credentials to access a machine when they've been denied access because an account with the same name but a different password exists.

• If no matching account exists, the remote machine will prompt for credentials.

Although the automatic logon function can seem like domain authentication, it is inherently different. Domain authentication transmits the SIDs for the logged on user's domain account and global security groups (which are explained later in this lesson) between the computers involved, while workgroup background authentication passes credentials by account name.

Workgroup background authentication requires accounts to be configured independently on all local computers. Furthermore, passwords are not automatically synchronized when they are changed on any one computer. In effect, access is allowed, but under the security context of the machine's own local account of the same name, rather than by trusting the same domain account that the originating computer trusts. Because two different local accounts are in use (one on each machine), various security settings and policies could be different between the machines. For example, the user account may be an administrator on one machine, but only a typical user account on the other machine.

Another major effect is that the SIDs for the same name accounts are different, and these differences can have unexpected side effects. For example, if you secure a file on an NTFS formatted removable media device using a local system account on one machine, that file is not available to a user account with the same name and password on a different machine, because the SIDs for the two accounts are different. If you perform the same operation on two computers that are members of the same domain using domain accounts, the file is available, because the SID of the domain account used on both computers is the same. NTFS permissions and ACLs are discussed in detail in the next lesson.

Practice: Creating User Accounts and Security Groups

In this practice, you create user and group accounts on a local workstation.

Exercise 1: Managing User Accounts on a Local Computer

In this exercise, you create a number of user accounts for a computer that will be used by multiple users before it is joined to a domain. After creating the accounts, you will delete one account and disable another. The purpose of this exercise is to highlight the difference between local system accounts and the domain accounts that will be covered in the next lesson. In practice, you will rarely use local system accounts in a corporate environment. You will be performing this exercise on a Windows 2000 Professional computer.

To create a user account

1. Right-click My Computer, and click Manage. The Computer Management console appears.

2. In the MMC console, expand System Tools, expand Local Users And Groups, and click the Users folder.

3. Right-click the Users folder, and click New User. The New User dialog box appears, as shown in Figure 2.4.

   

   Figure 2-4. Creating a local user account

4. Type kkennedy into the User Name box (first initial plus last name).

5. Type Kevin Kennedy in the Full Name box.

6. Type Engineer in the Description box.

7. Type the same randomly selected password in the Password box and in the Confirm Password box.

8. Clear the User Must Change Password At Next Logon check box.

9. Click Create. The new user account is created with the default settings.

To populate a computer with user accounts

1. Using the procedure to create a user account, create local user accounts for the following users:

   • Kevin Kennedy

   • Friske, Karen

   • Frum, John

   • Funk, Don

   • Gage, Bob

   • Galvin, Janice

   • Ganio, Jon

   • Gehring, Darren

2. Click Close to close the New User dialog box after creating the accounts.

To delete a local user account

1. In the Users folder, right-click the account named dgehring, and click Delete. A security warning appears.

2. Read the warning that you cannot recreate the account by using the same account name, and click Yes. Notice that the account has been removed from the user list.

   It is especially important not to leave unused accounts on local computers, because local accounts are frequently forgotten once a machine is joined to a domain. This leaves an active account that hackers could potentially exploit without anyone noticing.

To disable a local user account

1. In the Users folder, right-click the account named kkennedy, and click Properties. The Properties dialog box appears as shown in Figure 2.5.



Figure 2-5. The Properties dialog box

2. Select the Account Is Disabled check box, and click OK. Notice that the account now appears with a red icon indicating that the account is disabled.

Exercise 2: Managing Security Groups on a Local Computer

In this exercise, you create two local groups, and then delete one of them.

To create local groups

1. Log on to a Windows 2000 Professional computer as the Administrator.

2. Right-click My Computer, and click Manage. The Computer Management console appears.

3. Expand System Tools, and select the Local Users And Groups folder.

4. Right-click the Groups folder, and click New Group. The New Group dialog box appears

5. In the New Group dialog box, type Engineers as the name of the security group.

6. Click Add.

   A list of users appears in the Select Users Or Groups dialog box.

7. Click bgage, dfunk, jfrum, jgalvin, jganio, and kfriske to add them to the group.

8. Click OK to close the Add Users window, and then click Create to create the group.

   The New Group dialog box remains open but is empty after a group is created.

9. Type CAD Users as the name of a second new security group.

10. Click Add. The Add Users Or Groups dialog box appears.

11. Select bgage and defunk to add them to the group.

12. Click OK, and click Create.

13. Click Close to close the New Group dialog box.

To delete local groups

1. In the Users folder, right-click the CAD Users group, and click Delete. A Local Users And Groups delete confirmation dialog box appears.

2. Click Yes to confirm that you want to delete the CAD Users group. The group is deleted.

3. Close the management console.

Lesson Review

The following questions are intended to reinforce key information in this lesson. If you are unable to answer a question, review the lesson and try the question again. Answers to the questions can be found in the appendix.

1. If a user account has been deleted, can you restore it by creating a user with the same name? Why or why not?

2. What happens to local accounts when a computer is joined to a domain?

3. What is the difference between workgroup background authentication and domain authentication when a user accesses a resource on a remote computer?

Lesson Summary

• Windows authorizes access to secure resources by authenticating users before they can use the computer. User accounts with unique security identifiers represent the people who operate a computer. You can secure resources by specifying exactly which actions are permitted for which users by adding ACEs to the ACL for a secure resource.

• Local computer accounts are used to manage access to individual workstations and servers. Local computer accounts do not exist on domain controllers because they are replaced by the Active Directory service.

• User accounts can be members of security groups. Security groups also have unique security identifiers and can be used to secure resources wherever a user account could be used.

• Security groups should be created whenever a unique combination of security requirements appears. User accounts can be members of any number of security groups.