Home > Articles > Microsoft > MCSE

Security Accounts and Policies in Windows 2000 Professional

Learn how to implement, monitor, and troubleshoot security accounts and policies in Windows 2000 Professional. You will learn how to manage user and group accounts, Active Directory, and policy on your way to a better understanding of Windows 2000 Professional.
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.


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.


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.


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.


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.1Figure 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.


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.


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.


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).


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.


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.


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.


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.


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.

Pearson IT Certification Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Pearson IT Certification and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Pearson IT Certification products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by Adobe Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.pearsonitcertification.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020