Home > Articles > Operating Systems, Server > Microsoft Servers

Managing OUs, Users, and Groups in Active Directory

This chapter covers managing OUs and Users, Contacts, Computers, and Groups in Active Directory using the Users and Computers snap-in.
This chapter is from the book

The most visible part of Active Directory administration is managing objects with the Users and Computers snap-in. This snap-in enables you to create organizational units (OUs) to set up an OU tree in a domain. You also use this snap-in to populate the OU tree by creating objects of the following six classes in the OUs you want:

  • Users
  • Contacts
  • Computers
  • Groups
  • Shared folders
  • Printers

This chapter covers managing OUs and the first four classes in the list. We will proceed as follows:

  • First, we describe the contents of your Active Directory domain right after installation.

  • Second, we explore how to manage OUs and objects of each of the four other classes (i.e., users, contacts, computers, and groups).

  • Finally, we discuss some additional features of the Users and Computers snap-in, and we list additional tools for managing objects.

This chapter focuses on the Users and Computers snap-in. If you have to create many objects, other tools you can use include LDIFDE, CSVDE, scripting, or some Resource Kit tools. Although listed at the end of this chapter, these tools are covered later in the book.


Behind the scenes, a domain object can contain objects of 23 classes and an OU can contain objects of 35 classes. However, with the Users and Computers snap-in, you can normally create and see objects of only the 7 classes just listed.

Active Directory after Installation

After you have created your first domain by installing Active Directory on a server (i.e., promoting it to a domain controller), there are certain users, computers, groups, and containers already in place (see Figure 3.1). You see these objects with the Users and Computers snap-in, which you start by clicking the Start button and selecting Programs, Administrative Tools, Active Directory Users and Computers.

Figure 3.1 A newly installed domain (sanao.com in the figure), which is the root domain of a forest


Another way to start the Users and Computers snap-in is to click the Start button, select Run, type "dsa.msc," and press Enter.

You will see the following predefined objects in the snap-in:

  • Five containers, one of which is an OU

  • Some user objects (or user accounts)

  • Some group objects (or group accounts)

  • One computer object (or computer account) for your domain controller


Active Directory contains only objects. Users, groups, and computers, however, are often called accounts instead of objects.

If you upgrade a Windows NT 4.0 or 3.51 domain, you will see the users, groups, and computers of that domain in Active Directory.

Predefined OUs and Other Containers

The objects in a domain should reside in containers instead of at the domain level, just as files on disk should reside in folders instead of in the root folder. Accordingly, the predefined objects are stored in containers below the domain level. Table 3.1 describes the five predefined containers. You cannot rename or delete them—they are always there.

TABLE 3.1 The Predefined Containers in Active Directory




Possible Contents



This is a container for the predefined built-in local security groups (you cannot create them yourself).

Computer, group, user



This is a default container for computer objects corresponding to Windows NT/2000 workstations and member servers in this domain.

Computer, contact, group, printer, user, shared folder

Domain Controllers


This is a default container for computer objects corresponding to domain controllers of this domain.

Computer, contact, group, OU, printer, user, shared folder

ForeignSecurity- Principals


This is a container for placeholders that represent group members from domains external to the forest. This includes well- known security principals, such as Authenticated Users, if they are members of some group in the domain.* Objects in this container are visible only when the snap-in's Advanced Features are turned on.

Computer, contact, group, printer, user, shared folder



This is a default container for users and Computer, contact, groups.

group, printer, user, shared folder


In Table 3.1, the Possible Contents column lists the object types (that is, classes) that you can create in the corresponding container using the Users and Computers snap-in. With an "under-the-hood" tool, such as ADSI Edit, you could create other types of objects. However, there is no need to use the predefined containers for anything but what is described in the table.

You shouldn't use the Builtin container for anything, even though it is possible to create computers, groups, and users in it. Likewise, you could create users in the Computers container or computers in the Users container, but there is no point in doing so. Putting such things together is comparable to placing your cookbooks and music CDs on the same shelf. It is possible, but why do it?

If you want, you can keep your users in the Users container and computers in the Computers container. If you do so, however, you can neither create OUs in them nor assign Group Policy for them because these containers are not OUs. If you have more than 20 users, for example, and you want to delegate some administration, you will probably end up creating new OUs for your users and computers (i.e., outside the Users or Computers containers). We will come back to this issue in the "Administering OUs" section later in this chapter.

The Domain Controllers container is an OU and, therefore, you can create OUs in it and assign Group Policy(ies) for it. This OU already has a Default Domain Controllers Policy Group Policy object (GPO) assigned, which affects the security and other settings of your domain controllers. You are likely to keep the computer objects for your domain controllers in this container and other OUs that you create below it.

Why These Containers?

It may seem that the way these predefined containers were chosen is odd. Why are most of them not OUs? Some explanation is given by the fact that these containers ease the upgrade from Windows NT 4.0 or 3.51 to Active Directory. During the upgrade process, the old user and group accounts are migrated to the Users container, old workstation and member server accounts are migrated to the Computers container, and old domain controller accounts are migrated to the Domain Controllers container.

In Windows NT, built-in local groups were internally stored separately from other groups, users, and computer accounts. This separation was brought over to Active Directory in the form of the Builtin container.

So why are these three containers not OUs? One explanation could be that this way you are intentionally discouraged from using them in the long run and you must create new OUs instead.

Predefined Users

Two user objects are always present: Administrator and Guest. You cannot delete either of them, but you can rename them at will. Renaming Administrator offers some extra protection because a potential network intruder would need to guess the new name in addition to the password. However, if you have a large network and many administrative personnel, it may be confusing for the Administrator account to have a different name.


The default permissions of Active Directory allow any user of the forest to see the names of administrative accounts, so renaming them is really minimal "protection." You can think of it as adding a small extra hurdle in a potential intruder's path. If you chose permissions compatible with pre–Windows 2000 servers, anonymous users can also see this information.

Active Directory has predefined user accounts besides Administrator and Guest, depending on what services you installed in your server. Table 3.2 lists the predefined user accounts in Active Directory.

TABLE 3.2 The Predefined User Accounts in Active Directory





Always (although could be renamed); cannot be disabled

The only user account you can use when you log on for the first time. The Administrator account of the first domain in a forest has the widest possible administrative permissions on Active Directory and the domain controllers in the same forest. You can create other user accounts with permissions as wide. The Administrator accounts of the later domains in a forest have the widest possible administrative permissions for their own domains.


Always (although could be renamed); disabled by default

If someone doesn't have a user account, he can use the Guest account (if the account is enabled). (See the discussion in the text.)


One for each domain controller that has IIS installed

If IIS allows anonymous access (e.g., by Web browsers), anonymous users use permissions of this user account.


One for each domain controller that has IIS installed

IWAM stands for IIS Web Application Manager. The IISWAM.OutofProcessPool component (part of IIS) uses this user account.


Always; disabled by default; cannot be enabled or renamed

The Kerberos key distribution center (KDC) uses this account. "Krbtgt" is part of the KDC's service principal name (SPN). Also, a symmetric key is derived from the password of krbtgt, and this key is used to encrypt and decrypt TGTs. Only the KDC knows this password and it changes the password periodically.



When an optional Internet Connector license is enabled, Terminal Services clients are not prompted with a logon dialog box. Instead, they are logged on automatically with the TsInternetUser account.

If you enable the Guest account, be careful about the permissions you give to it. After all, anyone who "walks in the door" can use it. There are two ways to use the Guest account.

  • If your workstation is a member of a domain of the forest where the Guest account is enabled (in some of its domains), you just type "guest" in the logon dialog box, select the correct domain, and start using the workstation and the network.

  • If your workstation is in a workgroup or in a different forest from the one in which the Guest account is enabled (in some of its domains), you first need to log on with some other user account. When you connect to the resources of the domain where the Guest account is enabled, you are granted access based on that Guest account's permissions. You never type "guest" anywhere—you just use "Jack," for example. When the server doesn't recognize "Jack," it switches to use "Guest" automatically. The catch is that if there is another Jack, who most likely uses a different password, you are denied access. The server just thinks that someone is trying to crack Jack's account and doesn't use Guest at all.

Predefined Groups

Active Directory includes predefined security groups. Some of them reside in the Builtin container and the rest reside in the Users container, as follows:

  • Builtin: Built-in local security groups

  • Users: Mostly global security groups

The primary purpose of most of these predefined groups is to be the means by which administrative rights and permissions are assigned. To be anything more than an end user in the network, a user needs one or more of the following types of permission or rights:

  • User rights, such as permission to change the system time or log on locally. These rights are controlled with Group Policy settings and/or local policy settings. There are also some fixed rights. For example, only members of the Administrators group can format hard drives, and you cannot give this right to anyone else.

  • Administrative permissions (i.e., the ability to create, delete, change, and so on) for Active Directory objects.

  • Administrative permissions for registry keys.

  • Administrative permissions for folders and files.

  • Administrative permissions for other resources (printers, for example).

Most of the predefined groups have specific administrative rights or permissions associated with them, so you can give some users the appropriate rights and permissions by adding their names to the corresponding groups. Instead of worrying about all of the items in the list individually, it is far easier to just put Jack in the Account Operators group and Jill in the DNS Admins group, for example. They will get suitable permissions in one package.

Sticking just to "predefined" doesn't get you through life, though—at least not with Windows 2000. You often need to assign individual rights and permissions, probably not using the predefined groups. But that's a story for another chapter (Chapter 4, to be exact).

Figure 3.2 shows the relationship among the groups in the Builtin and Users containers in an Active Directory domain. It also shows the corresponding relationships that existed in Windows NT.

Figure 3.2 I In Windows NT, the only meaning of predefined global groups (Domain Admins, Domain Users, and Domain Guests) was that they were members of some built-in local groups, which in turn had rights to administer the system. This is true also for Windows 2000, but in addition both group categories have certain direct permissions to Active Directory objects.


In addition to the permissions and rights shown in Figure 3.2, built-in local (security) groups have permissions for system files and registry keys.

In Windows NT it was easy to make a user of another domain a domain administrator in a local domain. It only required making him a member of the Administrators group in the local domain. Because of the difference in how global groups get permissions, as illustrated in Figure 3.2, this is more difficult in Active Directory. If you make the foreign user a member of Administrators in Active Directory, he won't get the permissions of Domain Admins, so he will be only a partial administrator. You cannot make him a member of Domain Admins because that group accepts members only from the same domain.

Predefined Built-in Local Security Groups

Table 3.3 describes the predefined groups in the Builtin container. You cannot delete, rename, or move any of them. Note that each group in the table is always present in all domains. They have rights and/or permissions to their local domain only.

By default, members of the Administrators and four "operators" groups can log on locally to domain controllers.


In the next chapter, we describe in more detail the default user rights and default Active Directory permissions of the groups in Table 3.3.

Predefined Groups in the Users Container

The remaining predefined groups are in the Users container. They are mostly global security groups, but there are also some domain local security groups. Table 3.4 describes the predefined groups in the Users container of a domain.


When you install the first domain of the forest, Enterprise Admins and Schema Admins are global groups. When you later change this domain to native mode (as discussed later in this chapter), those groups will change to universal groups, which allows them to have members from other domains.

Enterprise Admins and Schema Admins are present only in the first domain of the forest. The remaining groups are present in each domain, although the DNS groups are missing if there is no DNS service in the domain.

By default, Domain Admins is a member of the Administrators group of all workstations and member servers. Similarly, Domain Users is a member of the Users group of those computers.

Figure 3.3 illustrates the memberships of some predefined users, global groups, and built-in local groups that are listed in Tables 3.2 through 3.4.

TABLE 3.3 The Predefined Built-in Local Security Groups


Predefined Members



Administrator, Domain Admins, Enterprise Admins

By default, members of this group have almost total control of the domain controllers of the domain, including formatting hard drives and all the rights that the following four "operators" have. For Active Directory, this group has by default "Full Control except Delete Subtree" permission for almost all objects in the domain.

Account Operators


By default, members of this group can create, delete, and manage user, group, and computer objects in the Active Directory domain.

Server Operators


Members of this group can create, delete, and manage file shares, printers, and services in the domain controllers of the domain.

Backup Operators


By default, members of this group can back up and restore files and folders in the domain controllers of the domain, even if the member user doesn't have permissions for those files and folders.

Print Operators


Members of this group can create, delete, manage, and share printers in domain controllers of the domain, and by default they can create, delete, and manage printer objects in the Active Directory domain.


Domain Users, Authenticated Users, Interactive

By default, this group has no user rights or permissions. You can just ignore this group.* If you want to give permissions to all forest users, you can use Authenticated Users. You can also create groups such as SanaoUsers or SanaoBostonUsers and use them instead of the predefined Users group.


Guest, Domain Guests, IUSR_servername, IWAM servername, TsInternetUser

By default, this group has no rights or permissions. You can just ignore this group.

Pre-Windows 2000 Compatible Access

Everyone**, if you selected "Permissions compatible with pre-Windows 2000 servers when you installed the domain; otherwise, no members

By default, this group has permission to see all the objects in a domain and all the properties of all users and groups. You need these permissions if you have certain server services (e.g., Remote Access Service) running on Windows NT servers in your Active Directory domain.



Windows NT servers and workstations use this group for the Directory Replicator service.

Figure 3.3 The predefined users and groups have several predefined memberships. In addition, any new user is a member of Domain Users.

In Chapter 4, we discuss the well-known security principals. Many of them are like groups, and you can assign permissions to them. They are not real groups, however, because the operating system, not a network administrator, controls their "membership."

Well-known security principals include Authenticated Users and Everyone, which you already saw as group members in Table 3.3 and Table 3.4. Therefore, we have included Figure 3.4 to illustrate those memberships here, even though the remaining discussion is in the next chapter.

TABLE 3.4 The Predefined Groups in the Users Container


Predefined Members


Enterprise Admins

Administrator of the first domain of the forest

Members of this group can administer all the domains in the enterprise. By default, this group is a member of Administrators in all domains of the forest. Enterprise Admins has Full Control to practically all objects in all domains of the forest. In addition, membership in this group is necessary to create child domains or sites.

Schema Admins

Administrator of the first domain of the forest

Members of this group can modify the schema of the forest.

Domain Admins


Members of this group can administer this domain. By default, this group is a member of Administrators in this domain and all joined workstations/member servers. Domain Admins has Full Control to most objects of the domain.

Group Policy Creator Owners


Members of this group can create Group Policy objects (GPOs) if they also have appropriate permissions for the the OU for which they are creating the GPO. In addition, they can manage the GPOs they have created.

Domain Users

Every user account of the same domain

By default, this group has no rights or permissions. You can use it if you need to give permissions to all users of the domain.

Domain Guests


By default, this group has no rights or permissions. You probably don't need this group.

Domain Controllers

Each domain controller of the same domain

By default, this group has no rights or permissions. You can use it if you need to give permissions to all domain controllers of the domain.

Domain Computers

Each workstation and member server of the same domain

By default, this group has no rights or permissions. You can use it if you need to give permissions to all workstations and member servers of the domain.

Cert Publishers

Each computer

By default, this group has permission to read and write that is running an the userCertificate property of the users and com-enterprise certificate puters in the domain. Therefore, members of this group authority can publish certificates for users and computers.



DHCP servers may dynamically register DNS resource records on behalf of DHCP clients. In this case, the DHCP servers become the owners of those records. This is a problem if the client or some other DHCP server later wants to start maintaining those records. By placing the computer objects of the DHCP servers as members in this group, the servers won't become record owners, so the problem described here is resolved.



Members of this group can administer the DNS service.

RAS and IAS Servers

Each computer

By default, this group has permission to read Logon that is running the Information, Remote Access Information, and Account Routing and Remote Restrictions of all users of the domain. RRAS servers need Access Services those permissions.

Figure 3.4 reveals the memberships for the various end-user groups. Table 3.5 lists the end users (users of the group's domain, users of the whole forest, and so on) that are members of each user group.

Figure 3.4 The well-known security principals Authenticated Users, Everyone, and Anonymous Logon can be seen as part of the membership hierarchy. However, their "membership" is controlled by the operating system, not by a network administrator.

TABLE 3.5 End-User Memberships



Group's Domain

All Forest Users










Built-in local





Authenticated Users






Domain Users






Typically, an administrator uses Authenticated Users to assign permissions to all users of a forest and Domain Users to assign permissions only to the users of one domain.

Predefined Computer Objects

In the beginning, there is just one computer object. It is for your first (and at that point, only) domain controller in the Domain Controllers container.

Changing the Domain Mode

An Active Directory domain is in one of two modes.

  • Mixed mode: This mode enables you to have Windows NT 4.0 and 3.51 backup domain controllers (BDCs) in the domain and to install new ones.

  • Native mode: In this mode, all current and future domain controllers must be running Windows 2000.

When you install a new domain, it first runs in mixed mode. You can change the domain's mode to native mode when you don't have old BDCs and you know for sure that you are not going to add any. The mode change is irreversible. Native mode is better, so when you start straight with Windows 2000, there is normally no reason not to change the mode right after you install each new domain.

While a domain is in mixed mode, you are subject to the following restrictions:

  • You cannot have universal security groups.

  • You cannot change the type or scope of any group.

  • You cannot nest groups, except that you can make a global group a member of a domain local group.

  • Domain local groups are not available in member servers or workstations.

  • If a Windows NT workstation is joined in a mixed-mode domain, it cannot fully benefit from the transitivity of trusts between domains. The domain list in the logon dialog box contains only the workstation's host domain and the domains that are directly trusted. Consequently, users from indirectly trusted domains (i.e., using transitive trusts) cannot log on to that workstation. The same indirectly trusted domains are missing also from the List Names From list of the User Manager and permission dialog boxes. Therefore, users of those domains cannot be members or have permissions in this workstation. However, a user on this workstation can access resources from indirectly trusting domains with the help of transitive trusts.

  • You cannot use per-user remote access policies.

  • You can have "only" 40,000 objects in your domain.

  • The SID History feature is not available. When SID History becomes available in native mode, you can move users from one domain to another so that they retain their old permissions for folders and other resources.

  • A global catalog server is not very "important." Once in native mode, a global catalog server must be contacted during each logon; otherwise, the logon will fail.


In mixed mode, you have the same groups as in Windows NT and they work exactly the same way.

If you don't want to test how things work in mixed mode, you can change your test domain to native mode at this point. To do so, perform the following steps.

  1. Open the Users and Computers snap-in.

  2. Right-click your domain object and choose Properties.

  3. Click the Change Mode button on the General tab and confirm your selection by clicking the Yes button.


If you are familiar with Windows NT, you might want to postpone changing the domain mode. This will help you learn in steps, because later in this chapter we explain how groups work in mixed mode. At that point, if your test domain is still in mixed mode, you will have an opportunity to try the familiar groups in a new environment. After that, you can switch to native mode and try the groups again, this time with the new features enabled.

If there is more than one domain controller in your domain, all other domain controllers will know about the new mode once the information has replicated to them. You will know that this replication has occurred when you see the text "Domain operation mode: Native Mode" in the domain properties dialog box. Note that you must connect to a specific domain controller with the Users and Computers snap-in to see the status of that domain controller.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT 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 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 InformIT. 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.informit.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