Home > Articles

Managing Active Directory OUs, Users, and Groups

The Users and Computers snap-in for Active Directory enables you to create Organizational Units (OUs) to set up an OUT Tree in the domain. This chapter coves setting up and managing OUs in Active Directory.
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 eight classes in the OUs you want:

  • Users (or alternatively, inetOrgPersons, new in AD2003)

  • Contacts

  • Computers

  • Groups

  • MSMQ queue aliases (new in AD2003)

  • Shared folders

  • Printers

This chapter covers managing OUs and the first five 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 five other classes (i.e., users, inetOrgPersons, contacts, computers, and groups).

  • Finally, we discuss some additional features of the Users and Computers snap-in, and we discuss or 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 DSAdd (new in AD2003), LDIFDE, CSVDE, scripting, or some Resource Kit tools. DSAdd we cover at the end of this chapter; the other tools we just list there, but cover later in the book.

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

MSMQ Queue Alias is listed as an alternative when you create new objects in the Users and Computers snap-in. You can, however, create and use such objects only if you first install Microsoft Message Queuing 3.0 (MSMQ). Because such aliases (corresponding to the msMQ-Custom-Recipient class) reside in the directory, they help applications to locate message queues. Further discussion of the topic is outside the scope of this book. Also, we don't mention MSMQ queue aliases later in this chapter, even though they would appear in some lists, and so on.

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 Administrative Tools, Active Directory Users and Computers.

03fig01.jpgFigure 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 (sometimes referred to as 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. You could also argue that an account is something that can authenticate (user or computer), so a group is not an account, but "just" a group of accounts.

If you upgrade a Windows NT 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. Because they have extra system-flags protection, you cannot rename, move, or delete them—they are always there (unless you redirect some of them, as explained a little later in the section "Redirecting the Users and Computers Containers to OUs").

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, inetOrgPerson



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

Computer, contact, group, printer, user, inetOrgPerson, 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, inetOrgPerson, shared folder

Foreign Security 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, inetOrgPerson, shared folder



This is a default container for users and groups.

Computer, contact, group, printer, user, inetOrgPerson, 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 to Active Directory. During the upgrade process, the old user accounts and groups 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 addition to migration, the default Users and Computers containers are also used whenever users, groups, and computers are created using downlevel tools. Such tools are Windows NT User Manager and Server Manager, Net commands (Net User, Net Group, Net Localgroup, Net Computer), Windows Support Tools NetDom Add command without the /OU switch, and any tool that uses the old Windows NT APIs to create these objects. Also, when a Windows NT/2000/XP workstation joins a domain and there is no precreated computer account, the account will be created in the default Computers 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.

Redirecting the Users and Computers Containers to OUs

If your domain is on the Windows Server 2003 functional level, you can redirect the predefined Users container and the Computers container to OUs you have created. After the redirection, these new OUs will be the default containers for users, groups, and computers. For example, you can create the Employees OU and the Workstations OU, and then perform the redirection using the following commands:

redirusr OU=Employees,DC=Sanao,DC=com
redircmp OU=Workstations,DC=Sanao,DC=com

During the redirection, the system-flags protection is moved from the old default containers to the new ones. Therefore, you could rename or delete the old containers.

The predefined Users container and Computers container don't allow you to apply group policies to them, but if you perform the redirection to a normal OU, you can apply group policies. On the other hand, if your users and computers are already in normal OUs and you don't use any tools that would create new users or computers in the default containers, there is not much advantage in the redirection.

For more information, see the Microsoft Knowledge Base article 324949 at http://www.microsoft.com.

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 are installed. Table 3.2 lists the typical predefined user accounts in Active Directory.

Table 3.2. The Predefined User Accounts in Active Directory





Always (although could be renamed); cannot be disabled in AD2000 but can be disabled in AD2003

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. OutofProcess Pool component (part of IIS) uses this user account.


Always; disabled by default; hidden 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.


For Windows 2000 Terminal Services

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 or the Everyone group (and in AD2000 also to the Domain Users or Users groups). After all, anyone who "walks in the door" can use the Guest account. 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 Active Directory. You often need to assign individual rights and permissions, probably not using the predefined groups. But that's another 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.

03fig02.gifFigure 3.2 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 Active Directory, 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 an 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. Note that this note only applies to the administrative privileges for the domain account database and domain controllers. It doesn't apply to the administrative privileges for any member servers or workstations.

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, because of their system-flags protection. Note that each group in the table is always present in all domains. They have rights and/or permissions to their local domain only, and those rights/permissions apply only on the domain controllers. For example, the Remote Desktop Users group members can use the remote desktop of the domain controllers of the domain in question.

Table 3.3. The Predefined Built-in Local Security Groups


Predefined Members

Abilities [*]


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 or Delete All Child Objects" permission for almost all objects in the domain.

Account Operators


By default, members of this group can create, delete, and manage user, inetOrgPerson, group, and computer objects in the Active Directory domain, except in the Domain Controllers OU. Account operators can log on locally to domain controllers of the domain and shut them down. In Windows 2000, Account Operators can modify their own account and the accounts of other account operators. However, they cannot modify administrator accounts. Starting with Windows 2000 SP4 and Windows Server 2003, Account Operators cannot modify account operators. For more information, see the "AdminSDHolder Object" section in Chapter 4.

Server Operators


In the domain controllers of the domain, members of this group can create, delete, and manage file shares and printers, and start, stop, and configure services. Also in the domain controllers, they can log on locally, back up and restore files, change computer time, and shut down the domain controller either locally or remotely. Note that the list here is descriptive, but not quite exhaustive.

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. They can also log on locally on the domain controllers of the domain and shut the domain controllers down.

Print Operators


Members of this group can create, delete, manage, and share printers in the domain controllers of the domain, and by default they can create, delete, and manage printer objects in the Active Directory domain. They can also log on locally on the domain controllers of the domain and shut the domain controllers down.


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 (in AD2000)

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

Pre-Windows 2000 Compatible Access

Everyone [***] and Anonymous Logon, if you selected "Permissions compatible with pre-Windows 2000 server operating systems" when you installed the domain; otherwise, Authenticated Users (the latter is the default)

By default, this group has permission to see all the objects in a domain and all the properties of all users, inetOrgPersons, and groups. Everyone/Anonymous 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.

Remote Desktop Users


Members of this group are allowed to use the Remote Desktop connection.

Network Configuration Operators


Members of this group can modify the local TCP/IP settings and some other network settings of the domain control lers. For a complete list, see Microsoft Knowledge Base article 297938.

Performance Monitor Users


Members of this group can use the Performance console, or perform similar monitoring with another tool.

Performance Log Users

Network Service

Members of this group can use the Performance Logs and Alerts console, or perform similar monitoring with another tool.

Incoming Forest Trust Builders


This group appears only in the forest root domain. The members can create incoming, one-way trusts to the forest.

Windows Authorization Access Group

Enterprise Domain Controllers

Members of this group can read the constructed tokenGroupsGlobalAndUniversal (TGGAU) attribute on user, inetOrgPerson, group, and computer objects. TGGAU contains a list of the object's global and universal group memberships, and an application can use this information, for example, to make decisions about users that are not logged on. The Pre-Windows 2000 Compatible Access group can also read TGGAU, but if the application is not in that group, you could use the Windows Authorization Access Group instead. For more information, see Microsoft Knowledge Base article 331951.

Terminal Server License Servers


This group is used for Terminal Server licensing.

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.

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. This group appears only in the first domain of the forest (that is, the forest root domain.)

Schema Admins

Administrator of the first domain of the forest

Members of this group can modify the schema of the forest. This group appears only in the first domain of the forest (that is, the forest root domain.)

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 if they also have appropriate permissions for 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 that is running an enterprise certificate authority

By default, this group has permission to read and write the userCertificate property of the users and computers in the domain. Therefore, members of this group can publish certificates for users and computers.

DnsUpdate Proxy


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. This group is missing if there is no DNS service in the domain.



The IIS_WPG group (worker process group) appears with Internet Information Services (IIS) 6.0, and it is used for the needs of IIS.



Members of this group can administer the DNS service. This group is missing if there is no DNS service in the domain.

RAS and IAS Servers

Each computer that is running the Routing and Remote Access Services (RRAS)

By default, this group has permission to read Logon Information, Remote Access Information, Group Membership, and Account Restrictions of all users of the domain. RRAS servers need those permissions.

When you install the first domain of the forest, Enterprise Admins and Schema Admins are global groups. When you later change this domain to the Windows 2000 native or Windows Server 2003 functional level (as discussed in Chapter 2), those groups will change to universal groups, which allows them to have members from other domains.

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.

03fig03.gifFigure 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.

03fig04.gifFigure 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.

In AD2000, Anonymous Logon is a "member" of Everyone. In AD2003, the security was tightened, and the "membership" is true only if you enable the security policy "Network access: Let Everyone permissions apply to anonymous users." This policy is located in Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options. See Chapter 7 for more information on policies.

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.

Table 3.5. End-User Memberships



All Users in Group's Domain

All Forest Users








(see the Note)


Built-in local



only in AD2000


Authenticated Users





Domain Users




only in AD2000


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.

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