Implementing, Monitoring, and Troubleshooting Security Accounts and Policies
- User and Group Accounts
- Understanding Active Directory
- Understanding and Implementing Policy
- Practice Questions
- Need to Know More?
This chapter is from the book
This chapter is from the book
This chapter is from the book
Terms you'll need to understand:
Local users and groups
Workgroup
Domain
Domain users and groups
Active Directory
Organizational unit (OU)
Policy
Privilege or user right
Techniques you'll need to master:
Creating local users and groups
Creating domain users and groups
Managing user and group properties
Dealing with changes in your user population, such as renaming and copying accounts
Securing a system
Creating a local and group policy
Networks' raison d'être—their reason for being—is to allow users to access resources such as files, printers, and applications on computers other than the ones at which they are sitting. In an ideal world, we would trust every user with every file we create, and all we'd have to do is connect our computers to a network and share it all. Unfortunately, we don't trust every user with every file we create. In the real world, certain users need access to resources that others should be restricted from accessing. Therefore, we need user accounts to identify and authenticate users when they attempt to access resources. But imagine trying to define who can access a resource and at what level if you had to worry about each individual user! Using groups significantly eases the process of defining resource access; you can assign permissions and privileges to groups and thereby define access for their members, and groups may contain one, dozens, hundreds, or thousands of users.
This chapter highlights critical skills and concepts related to user, group, and computer accounts, and the process of creating security configurations and policies for a Windows 2000 Professional system.
User and Group Accounts
Windows 2000 Professional creates several default local users and groups when you first install the operating system. When you join a Windows 2000 Professional computer to a Windows domain (within a Windows NT Server, Windows 2000 Server, or a Windows Server 2003 network), several additional user and group accounts come into play from the domain. Understanding the functions of the various local users and groups and knowing the differences between local user and group accounts and domain user and group accounts is key to being an effective network administrator and important for success on the Windows 2000 Professional certification exam.
Local and Domain Accounts
User and group accounts are stored in one of two locations: the local security database or the domain's Active Directory database. When an account is created in the local security database, that account is called a local user or local group.
Each Windows 2000 Professional system has two default local user accounts—Administrator and Guest (which is disabled by default)—and several built-in group accounts, which are discussed shortly. Local user and group accounts provide privileges and permissions to resources of the system on which they are defined. For example, the Users group has the privilege to log on locally. As you create local user accounts, they are members of the Users group by default; those users are then given the privilege to log on to that system.
Local user and group accounts cannot be given privileges or permissions to resources on any other system because the security database of the system where they are created is truly local: No other system can "see" it. If a user has logged on to a computer by using a local account, the only way that user can gain access to resources of a remote system is through an account for that user on the remote system. That account must be given privileges and permissions or must be placed into appropriate groups on the remote system. When a duplicate or redundant account is created with the same username and password on the remote system as on the local system, the user "seamlessly" accesses resources on the remote system; such users cannot tell that the remote system is authenticating them. However, if the username or password on the remote system is different from that on the local system, the user is prompted with an authentication dialog box when he or she first attempts to connect to the remote system.
Two or more systems that use only their own local accounts being on a network creates what is called a workgroup, a kind of peer-to-peer network. You can imagine how difficult managing redundant accounts for a single user on two different systems might become. If a user changes his or her password on one machine, he or she must remember to change it on the other; otherwise, the user is prompted for authentication at each connection. Such challenges would become multiplied many times over in a large workgroup with multiple users and multiple machines.
Thus, networks of any size turn to a domain model, in which one or more servers, called domain controllers, maintain a centralized database of users and groups. Security accounts in a domain are stored in the domain's Active Directory database. When a user is created in a domain, that single user account can be given privileges and permissions to resources and systems throughout the domain and in other domains within the enterprise's Active Directory database. Active Directory is covered in more detail in the "Understanding Active Directory" section later in this chapter.
NOTE
Domain user and group accounts are stored within the Active Directory database for Windows 2000 Server and Windows Server 2003 domains only. The user and group domain accounts for Windows NT Server and Windows NT Server 4.0 domains are stored within the legacy Security Accounts Manager (SAM) database, which is a less robust user and group directory than Active Directory.
TIP
In a domain, it is unusual (and not a best practice) to create or use local user accounts. Most computers that are members of a domain have only the local Administrator and Guest user accounts in their security databases.
Managing Local User and Group Accounts
The Local Users and Groups snap-in allows you to manage—surprise!—local users and groups. You can get to the snap-in by choosing Start, Settings, Control Panel, Administrative Tools, Computer Management and then by expanding the tree pane of the Computer Management console until you see snap-in. In this snap-in, you can create, modify, duplicate, and delete users (in the Users folder) and groups (in the Groups folder).
Using Built-in User and Group Accounts
As mentioned earlier in this chapter, there are two built-in user accounts: Administrator and Guest. The Administrator account
Cannot be disabled, locked out, or deleted.
Cannot be removed from the Administrators group.
Has, through its membership in the Administrators group, all privileges required to perform system administration duties.
Can be renamed.
The Guest account
Is disabled by default. Only a member of the Administrators group can enable the account. If the Guest account is enabled, it should be given a password, and User Cannot Change Password should be set if multiple users will log on with the account.
Cannot be deleted.
Can be locked out.
Can be renamed.
Does not save user preferences or settings.
Built-in local groups have assigned to them specific privileges (also called user rights) that allow them to perform specific sets of tasks on a system. The following are the default local group accounts on a Windows 2000 Professional system:
Administrators—Members of this group have all built-in system privileges assigned. They can create and modify user and group accounts, manage security policies, create printers, and manage permissions to resources on the system. The local Administrator account is the default member and cannot be removed. Other accounts can be added and removed. When a system joins a domain, the Domain Admins group is added, but it can be removed.
Backup Operators—Members of this group can back up and restore files and folders, regardless of security permissions assigned to those resources. They can log on and shut down a system but cannot change security settings.
Power Users—Members of this group can share resources and create user and group accounts. They cannot modify user accounts they did not create, nor can they modify the Administrators or Backup Operators groups. Members of the Power Users group cannot take ownership of files, back up or restore directories, load or unload device drivers, or manage the security and auditing logs. Members of the Power Users group can run all Windows 2000–compatible applications as well as legacy applications, some of which members of the Users group cannot execute.
TIP
If you want certain users to have broad system administration capabilities but do not want them to be able to access all system resources, you should consider putting them in the Backup Operators and Power Users groups rather than in the Administrators group.
Users—Members of this group can log on to a system, shut down a system, use local and network printers, create local groups, and manage the groups they create. They cannot create local printers or share folders. Some older (legacy) applications do not run for members of the Users group because security settings are tighter for the Users group in Windows 2000 than in Windows NT 4. By default, all local user accounts you create are added to the Users group. In addition, when a system joins a domain, the Domain Users group is made a member of that system's local Users group.
Guests—Members of this group have limited privileges but can log on to a system and shut it down. Members of the Guests group cannot make permanent changes to their desktops or profiles. By default, the built-in local Guest account is a member of this group. When a system joins a domain, the Domain Guests group is added to the local Guests group.
Replicator—This group is used to support file replication services in a domain.
A Windows 2000 Professional system also has built-in system groups, which you do not see in the user interface while managing other group accounts. Membership of system groups changes based on how the computer is being accessed or utilized, not based on who is accessing the computer. Built-in system groups are also referred to as special identity groups and include the following:
Everyone—This group includes all users who access the computer, including the Guest account.
Authenticated Users—This group includes all users who have valid user accounts in the local security database or (in the case of domain members) in Active Directory's directory services. You should use the Authenticated Users group rather than the Everyone group to assign privileges and group permissions because doing so prevents anonymous access to resources.
Creator Owner—This group contains the user account that created or took ownership of a resource. If the user is a member of the Administrators group, the Creator Owner group is the owner of the resource.
Network—This group contains any user who currently has a connection from a remote system.
Interactive—This group contains the user account for the user who is logged on to the system locally.
System—This group includes any operating system services that are configured to run within the security context of the operating system itself.
Terminal Server User—This group includes all users who are currently connected to the computer via a remote desktop (that is, terminal services client) connection.
Anonymous Logon—This group includes any user account that Windows 2000 has not authenticated.
Dial-up—This group contains all users that currently use dial-up connections.
Creating Local User and Group Accounts
To create a local user or group account, you right-click the appropriate folder (Users or Groups) and choose New User (or New Group), enter the appropriate attributes, and then click Create.
The following guidelines apply to user account names:
They must be unique.
They are recognized only up to the twentieth character, although the name itself can be longer.
They cannot contain the following characters: " / \ [ ] ; : , = + * ? < >.
They are not case sensitive, although the user account's name property displays the case as entered.
You should determine a policy for accommodating users who have the same name. For example, you can add a number after the username (for example, JohnD1, JohnD2). Some organizations also identify certain types of users by their usernames (for example, JohnDoe-Temp for a temporary employee).
The following guidelines apply to user account passwords:
They are recommended.
They are case sensitive.
They can contain up to 127 characters, although down-level operating systems such as Windows NT 4 and Windows 9x support only 14-character passwords.
They should be a minimum of 7 to 8 characters.
They should be difficult to guess and, preferably, should mix uppercase and lowercase letters, numerals, and nonalphanumeric characters (other than those listed previously as being prohibited).
They can be set by the administrator (who can then determine whether users must, can, or cannot change their passwords) or the user (if the administrator has not specified otherwise).
From the Local Users and Groups node of the Computer Management console, or from the Active Directory Users and Computers console on a domain controller, you can select User Must Change Password at Next Logon to ensure that the user is the only one who knows the account's password. You can select User Cannot Change Password when more than one person (such as the Guest user account) uses the account.
NOTE
The User Cannot Change Password option is not available when User Must Change Password at Next Logon is selected.
The Password Never Expires option is helpful when a program or a service uses an account. To avoid having to reconfigure the service with a new password, you can simply set the service's account to retain its password indefinitely.
Configuring Account Properties
The information you can specify when creating an account is limited in Windows 2000. Therefore, after you create an account, you often need to go to the account's properties sheet, which you can access by right-clicking the account and choosing Properties. Figure 3.1 shows the properties sheets of two accounts.
)
Figure
3.1 The properties sheets of the Dan user account and the Backup Operators
group account.
Managing Local Group Membership
To manage the membership of a local group, you right-click the group and choose Properties. To remove a member, you select the account and click Remove. To add a member, you click Add and select or enter the name of the account.
In a workgroup, local groups can contain only accounts defined in the same machine's local security database. When a system belongs to a domain, its local groups can also include domain accounts, including user accounts, universal groups, and global groups from the enterprise's Active Directory database, as well as domain local groups from within the system's domain.
NOTE
Universal groups and domain local groups can be added as members only when the domain is in native mode, meaning that it contains only Windows 2000 domain controllers and no legacy (that is, Windows NT 4.0) backup domain controllers.
Renaming Accounts
To rename an account, you right-click the account and choose Rename. Then you type the new name and press Enter. Each user and group account is represented in the local security database by a long, unique string called a security identifier (SID), which is generated when the account is created. The SID is what is actually assigned permissions and privileges. The user or group name is just a user-friendly "face" on that process. Therefore, when you rename an account, the account's SID remains the same, so the account retains all its group memberships, permissions, and privileges.
Two situations mandate renaming an account. The first occurs when one user stops using a system and a new user requires the same access as the first. Rather than create a new local user account for the new user, you can simply rename the old user account. The account's SID remains the same, so its group memberships, privileges, and permissions are retained. You should also specify a new password in the account's properties sheet and select the User Must Change Password at Next Logon option.
TIP
The easiest way to "replace" a user is to rename the account. Therefore, when one user leaves and another requires the same group memberships, rights, and resource access permissions as the first, you can simply rename the former user's account. You should not forget to reset the account's password because the new user won't otherwise know the old user's password.
The second situation that warrants renaming a user account is the security practice of renaming the built-in Administrator and Guest accounts. You cannot delete these accounts, nor can you disable or remove the Administrator account from the Local Administrators group, so renaming the accounts is a recommended practice for hindering malicious access to a system.
Disabling or Enabling User Accounts
To disable or enable a user account, you open its properties sheet and select or clear the Account Is Disabled check box. If an account is disabled, a user cannot log on to the system by using that account. The Administrator account cannot be disabled, and only administrators can enable the Guest account.
Deleting Accounts
You can delete a local user or group account (but not built-in accounts such as Administrator, Guest, or Backup Operators) by right-clicking the account and choosing Delete. When you delete a group, you delete the group account only, not the accounts of its members. A group is a membership list, not a container.
NOTE
When you delete an account, you are deleting its SID. Therefore, if you delete an account by accident and then re-create the account, even with the same name, the account does not have the same permissions, privileges, or group memberships as before—you have to regenerate them. For that reason, and to facilitate auditing, it is recommended that you disable, not delete, any user who leaves an organization.
Using the Users and Passwords Applet
A different tool for administering local user accounts is the Users and Passwords applet in the Control Panel. This utility allows you to create and remove user accounts as well as specify group membership for those users. The Users and Passwords applet is wizard driven and is useful for novice administrators and home users. You double-click the Users and Passwords icon in the Control Panel to run this utility. To launch the Local Users and Groups snap-in from the Users and Passwords applet, you click the Advanced tab and then click the Advanced button (in the Advanced User Management section).
NOTE
The Users and Passwords applet provides an opportunity to override the logon requirement for a system. This feature is discussed later in this chapter, in the "Authentication" section.
Managing Domain User Accounts
You manage domain user accounts with the Active Directory Users and Computers snap-in. To access it, you choose Start, Settings, Control Panel, Administrative Tools, Active Directory Users and Computers. Note that unlike in Windows NT 4, in Windows 2000 all domain controllers can make changes to the Active Directory database. When you open the Active Directory Users and Computers snap-in, you connect to an available domain controller. If you want to specify which domain controller or which domain you want to connect to, you right-click the Active Directory Users and Computers node and choose Connect to Domain or Connect to Domain Controller.
Unlike the local security database, which is a flat list of users and groups, Active Directory has containers such as domains and organizational units (OUs), which collect database objects such as users that are administered similarly to one another. OUs are simply containers that allow administrators to logically group Active Directory objects, such as users, groups, and computers. All the objects that are contained within an OU can be administered together. Administration tasks may also be delegated to other administrators for each OU. Therefore, when you manage domain user accounts in Windows 2000, you need to start in the container or OU where the objects reside that you want to work with.
Creating Domain User Accounts
You create a domain user account by right-clicking the OU or container in which you want the user account and then choosing New User. A wizard prompts you for basic account properties, including the following:
First name
Initials
Last name
Full name (by default, the combination of the first name and last name)
User logon name and user principal name (UPN) suffix
User logon name (pre-Windows 2000)
Password and confirmed password
Windows 2000 user accounts have two logon names. The UPN is used for logon to a Windows 2000 system and consists of a logon name followed by the @ symbol and a suffix, which by default is the Domain Name System (DNS) name of the domain. Each user must have a unique UPN in the domain. The pre-Windows 2000 logon name is used for logging on to pre-Windows 2000 systems such as Windows NT 4, and Windows 95, 98, and Me. Each user's pre-Windows 2000 logon name must be unique in the domain and by default is the same as the logon name portion of the UPN.
Modifying User Account Properties
After an account is created, Active Directory provides dozens of attributes to further define that user. You can right-click a user and choose Properties to open a tabbed dialog box full of attributes that can be defined for that user. The only properties you can specify when creating the user are those on the Account tab. You must set the remainder of the properties after the account has been instantiated.
Copying User Accounts
A user object in Active Directory may have numerous attributes defined, including work location, group membership, and superiors within the organization. Often, a new user object shares many of its attributes with one or more other user objects. In that case, it is faster to copy an existing user object than to create a new object and define each and every property for the object. To copy a user, you right-click the object and choose Copy. You are asked to enter some of the basic account properties, such as name and password.
NOTE
You can copy a user only with domain user accounts, not with local user accounts.
Creating Template User Accounts
When you expect to create multiple user objects with highly similar properties, you can create a "template" account that, when copied, initiates the new accounts with its defined attributes. The only trick to working with templates is to disable the template account. Then, when you copy the account to create a new user with predefined attributes, you need to make sure to enable the new account.
TIP
When you copy a user account—whether it's a "real" user account or a template—the new copy belongs to all the same groups as the original and therefore has the same resource access that is assigned to the groups of the original account. However, the new copy does not have access to resources for which permissions are assigned directly to the original user account.
Disabling and Deleting User Accounts
The process for disabling and deleting domain user accounts is the same as for local user accounts, except that you use the Active Directory Users and Computers snap-in to perform the tasks. The check box for disabling an account is on the user's Account properties sheet.
Adding Domain User Accounts to Local Groups
In Windows 2000 you can add a user to a group with either the group's Members properties sheet or the user's Member Of properties sheet, except when adding domain user accounts to local groups, in which case you must use the group's Members properties sheet. A domain user's Member Of properties sheet displays only memberships in global, domain, local, and universal groups.
Authentication
When a user wants to access resources on a machine, that user's identity must first be verified through a process called authentication. For example, when a user logs on, the security subsystem evaluates the user's username and password. If there is a match, the user is authenticated. The process of logging on to a machine where you are physically sitting is called interactive logon. Authentication also happens when you access resources on a remote system. For example, when you open a shared folder on a server, you are being authenticated, but the process is called remote or network logon because you are not physically at the server.
The Security Dialog Box
The security dialog box allows for interactive logon to a Windows 2000 system. You can access the Security dialog box shortly after a system has started, and at any time after logon, by pressing Ctrl+Alt+Delete. If you are not currently logged on, you can enter a username and password. If the system belongs to a domain, you need to be certain that the domain in which your account exists is authenticating you. You can either select the domain from the drop-down list or enter your UPN. The UPN is an attribute of an Active Directory user object and, by default, has the form username@dnsdomain.name. The suffix, following the @ symbol, indicates the domain against which to authenticate the user.
If you are currently logged on to a system, pressing Ctrl+Alt+Delete takes you to the Windows 2000 Security dialog box, at which point you can do one of the following:
Log off the system, which closes all programs and ends the instance of the shell.
Lock the system, which allows programs to continue running but prevents access to the system. When a system is locked, you can unlock it by pressing Ctrl+Alt+Delete and entering the username and password of the user who locked the system or an administrator's username and password.
TIP
To lock a workstation automatically after a period of idle time, you use a screensaver password.
Shut down the system.
Change your password.
Open Task Manager.
Automating Logon
You can configure Windows 2000 Professional systems so that you are not required to enter a username and password; in this case, your system automatically logs on as a specified user account. From the Users and Passwords applet in the Control Panel, you click the Advanced tab and clear the Require Users to Press Ctrl+Alt+Delete Before Logging On check box. The same setting is available through a group policy object (GPO) setting. GPOs are configured via Active Directory under Windows 2000 Server and Windows Server 2003; they are discussed later in this chapter.