Home > Articles

Novell eDirectory

This chapter is from the book

This chapter is from the book

Implementing eDirectory Naming

Test Objective Covered:

  1. Identify the flow and design of the eDirectory tree (continued).

Now that you understand what the eDirectory tree is made of, you need to explore how it works. As you manage the eDirectory tree, pay particular attention to its structure. A well-designed tree will make resource access and management much easier.

The structure of the eDirectory tree is both organizational and functional. The location of an object in the tree can affect how users access it and how network administrators manage it. The eDirectory tree structure impacts the following areas of administrative responsibility:

  • eDirectory planning

  • Resource access

  • Resource setup

You complete these tasks by implementing eDirectory planning guidelines, using proper eDirectory naming structure, and understanding current context. Let's take a closer look.

Planning Guidelines

An efficient eDirectory tree provides all the following benefits:

  • It makes resource access easier for users.

  • It makes administration easier for network administrators.

  • It provides fault tolerance for the eDirectory database.

  • It decreases network traffic.

The structure of the tree can be based on location, organization, or administration. In many cases, it's a combination of all three. Many factors influence the structure of your eDirectory tree. Before you design your tree, you might need to study workgroups, resource allocation, and/or learn how data flows throughout your network.

As a CNA, it's your responsibility to navigate and manage the tree, not to design or troubleshoot it—that's what CNEs are for. This material is also covered in much greater detail in Novell's CNE Study Guide for NetWare 6.


Study the eDirectory benefits carefully—they are the foundation of your life as a NetWare 6 CNA. One final important point: eDirectory does not provide fault tolerance for the file system.

eDirectory Naming Structure

eDirectory naming defines rules for locating leaf objects. One of the most important aspects of a leaf object is its position in the eDirectory tree. Proper naming is required when logging in, accessing eDirectory utilities, printing, and for most other management tasks.

The name of an eDirectory object identifies its location in the hierarchical tree. Therefore, each object name must be unique. eDirectory naming impacts two important NetWare 6 tasks:

  • Login—Typically, you need to identify the location of your User object in the eDirectory tree for NetWare 6 to authenticate you during login.

  • Resource access—eDirectory naming exactly identifies the type and location of NetWare 6 resources, including file servers, printers, login scripts, and files.

The whole NetWare 6 eDirectory naming scheme is much more complicated than "Hi, I'm Fred." It requires both your name and location. For example, a proper eDirectory name would be "Hi, I'm Fred in the ADMIN division of ACME." As you can see in Figure 3.10, Fred's eDirectory name identifies who he is and where he works.

The eDirectory tree affects resource access because the organization of objects in the tree dictates how they can be found and used. In fact, the whole eDirectory naming strategy hinges on the concept of context. Context defines the position of an object within the Directory tree structure. When you request a particular network resource, you must identify the object's context so that eDirectory can find it. Similar to locating files by using a DOS directory path, context represents a list of container objects leading from the object to the Tree Root. NetWare 6 uses specific naming guidelines for creating an object's context.

Figure 3.10Figure 3.10 Getting to know the real Fred.


Novell recommends that before you implement eDirectory, you create a document that describes your naming standards. The eDirectory naming rules you're going to learn here work only if object names are consistent across the network. A naming standards document provides guidelines for naming key container and leaf objects, including users, printers, servers, volumes, print queues, and organizational units. In addition, it identifies standard properties and value formats. Consistency, especially in the naming scheme used for objects, provides several benefits:

  • A consistent naming scheme provides a guideline for network administrators who will add, modify, or move objects within the Directory tree.

  • A naming standard eliminates redundant planning and gives network administrators an efficient model to meet their needs, but it leaves implementation of resource objects open and flexible.

  • Consistent naming schemes help users identify resources quickly, which maximizes user productivity.

  • Consistent naming enables users to identify themselves easily during login.

There are two main types of context: current context and object context. Check it out.


Current context is sometimes referred to as name context. It defines where you are in the eDirectory tree at any given time, not where you live. This is an important distinction. For example, if you are using a NetWare 6 utility, it's important to know what the utility considers as the current context in the eDirectory tree (that is, the default container to use if one is not specified). This concept is somewhat similar to knowing your current default drive/directory when using a DOS or Windows utility on your workstation.

In addition, current context affects how much of an object's distinguished name you must provide to find it. (See the section "Distinguished Names" later in this chapter for more information.) Current context also enables you to refer to an object in your current container by its common name because the object's context is the same. Note that current context always points to a container object, rather than to a leaf object. Typically, at login, you'll want a workstation's current context set to the container that holds the user's most requently used resources.

In Figure 3.10, Fred's context is ". . . in the ADMIN division of ACME." This context identifies where Fred lives in the eDirectory tree structure. It identifies all container objects leading from him to the Tree Root. In addition to context, Figure 3.10 identifies Fred's common name (CN). A leaf object's common name specifically identifies it within a given container. In this example, the User object's common name is Fred.

Two objects in the same eDirectory tree may have the same common name—provided, however, that they have different contexts. This is why naming is so important. As you can see in Figure 3.11, our eDirectory tree has two Freds, but each has a different context.

Object context (sometimes referred to as context) defines where a particular object is located in the eDirectory tree structure. It is a list of container objects leading from the object to the Tree Root. Locating an object through context is similar to locating a file using the directory path. As we learned earlier, object context is used for two important purposes: logging in and accessing resources. Unfortunately, eDirectory does not have a search path feature (such as NetWare SEARCH drives or the DOS PATH command used in the file system). This means that when you request a particular network resource, you (or your workstation) must provide eDirectory with enough information to locate the object in the tree.

Each eDirectory object has a naming type (also known as an attribute type) associated with it, which allows you to precisely identify objects in your tree. The tree organization dictates how the objects can be located and used. This naming type is identified by a one- or two-character abbreviation. Accompanying the naming type is the value of the object, or the name you enter for the object when you create it. Following are examples of naming types and associated values:

  • C = Country container

  • O = Organization container

  • OU = Organizational Unit container

  • CN = Common name (specifies a leaf object)

Figure 3.11Figure 3.11 Understanding eDirectory context.

The Common Name (CN) attribute is the name shown next to the leaf object in the eDirectory tree. This attribute applies to all leaf objects (servers, users, groups, and so on). When requesting a resource such as a server, the Common Name must be included in the request.

Now that you understand how eDirectory context works, review the naming rules associated with it:

  • Current context is a pointer to the eDirectory container that your Novell Client is currently set to.

  • An object's context defines its location in the eDirectory tree.

  • Each object has an identifier abbreviation that defines it for naming purposes, namely the following: C = Country, O = Organization, OU = Organizational Unit, and CN = common name (of leaf object).

  • Context is defined by listing all containers from the object to the Tree Root, in that order. Each object is separated by a period.

  • Context is important for logging in and accessing eDirectory resources.

There you have it. That's how context works. With this in mind, it's time to explore the two main types of eDirectory names: Distinguished Names (DN) and Relative Distinguished Names (RDN).

Distinguished Names

An object's distinguished name is its complete eDirectory path. It is a combination of common name and object context. Each object in the eDirectory tree has a distinguished name that uniquely identifies it in the tree. In other words, two objects cannot have the same distinguished name.

In Figure 3.12, AEinstein's context is .OU=R&D.OU=LABS.O=ACME, and his common name is CN=AEinstein. Therefore, Einstein's distinguished name is a simple mathematical addition of the two:


Notice the use of periods. A distinguished name always starts with a leading period. Trailing periods aren't allowed. The leading period identifies the name as distinguished (that is, complete). Otherwise, it is assumed to be incomplete. In other words, a relative distinguished name.

Relative Distinguished Names

A relative distinguished name lists an object's path to the current context, not the Tree Root. The relativity part refers to how eDirectory builds the distinguished name when you supply a relative name. By definition, for example, the common name of a leaf object is a relative distinguished name. When you use a relative distinguished name, eDirectory builds a distinguished name by appending the current context to the end:

Relative distinguished name + current context = distinguished name

Figure 3.12Figure 3.12 Building AEinstein's distinguished name.

For example, if the current context is .OU=LABS.O=ACME and you submit a relative distinguished name of CN=AEinstein.OU=R&D, the distinguished name would be resolved as (see Figure 3.13) the following:


To distinguish a relative name, you must not lead with a period. Instead, you can use trailing periods to change the current context used to resolve the name (as if naming wasn't hard enough already). The bottom line is that each trailing period tells eDirectory to remove one object name from the left side of the current context being used. This concept is somewhat similar to the trailing dot feature used in the DOS CD command.

For example, assume that .OU=R&D.OU=LABS.O=ACME is your current context and that CN=LEIA.OU=ADMIN.. is your relative distinguished name. In this case, the distinguished name would resolve as follows (see Figure 3.14):


Figure 3.13Figure 3.13 Building AEinstein's relative distinguished name.

As you can see, it's very important where you place your dots! Here's a quick summary:

  • All objects in an eDirectory name are separated by dots.

  • Distinguished names are preceded by a dot. This identifies them as complete.

  • Relative distinguished names are not preceded by a dot. This identifies them as incomplete.

  • Trailing dots can be used only in relative distinguished names because they modify the current context to be used. Each dot moves the context up one container as the distinguished name is resolved.

For a complete summary of eDirectory distinguished naming rules, refer to Table 3.4.

Figure 3.14Figure 3.14 Using trailing periods to resolve Leia's distinguished name.

Table 3.4 Getting to Know Distinguished Naming




What it is context

Complete unique name

Incomplete name based on current

How it works from the object to the Tree Root

Lists the complete path from the object to the current context

Lists the relative path




Leading period required

Leading periods allowed

No leading periods

Trailing periods allowed

No trailing periods optional

Trailing periods

Now, let's step back into reality for a moment and explore the other eDirectory naming category—typeful names.

Typeful Versus Typeless Names

Typeful names use attribute type abbreviations to distinguish between the different container types and leaf objects in eDirectory names. All the examples to this point used these abbreviations to help clarify context, distinguished names, and relative distinguished names. Following are the most popular attribute type abbreviations:

  • C = Country container

  • O = Organization container

  • OU = Organizational Unit container

  • CN = Common name of a leaf object

These attribute types help avoid the confusion that can occur when you're creating complex distinguished and relative distinguished names. I highly recommend that you use them. Of course, like most things in life, they are optional. You can imagine how crazy eDirectory naming gets when you choose not to use these attribute abbreviations. This insanity is known as typeless naming.

Typeless names operate the same as typeful names do, but they don't include object attribute types. In such cases, eDirectory has to guess what object types you're using. Take the following typeless name, for example:


Is this the ADMIN Organizational Unit under ACME? Or is this the Admin user under ACME? In both cases, it's a valid distinguished name, except that one identifies an Organizational Unit container, and the other identifies a User leaf object (see Figure 3.15).

Well, here's the bottom line: which one is it? It's up to eDirectory. If you do not provide a typeful object name, eDirectory calculates attribute types for each object. Fortunately, NetWare 6 has some guidelines for guessing what the object type should be:

  • The leftmost object is a common name (leaf object).

  • The rightmost object is an Organization (container object).

  • All middle objects are Organizational Units (container objects).

Figure 3.15Figure 3.15 Trying to understand typeless naming.

Although this works for most cases, it's only a general guideline. Many times, typeless names are more complex. Take the example in Figure 3.15, for instance. You know now that the rightmost object is an Organization, but what about Admin? Is it a common name or an Organizational Unit? We still don't know. Fortunately, NetWare 6 includes a few exceptions to deal with complex typeless scenarios. Here's how it works:

  • Exception Rule 1: Container Objects—Many NetWare 6 utilities are intelligent enough to resolve typeless names, depending on what they are trying to accomplish. CX, for example, is used primarily for changing context. If you apply the CX command to a typeless name, it assumes the leftmost object is an Organization or Organizational Unit. This is because you can't change your current context to a leaf object. ConsoleOne is the best graphical utility for changing your context. In summary, here's how the example from Figure 3.15 would look with the CX utility:

    CX .ADMIN.ACME resolves as ".OU=ADMIN.O=ACME"

  • Exception Rule 2: Leaf Objects—Similarly, resource-based utilities recognize the leftmost object of a typeless name as a leaf object. Many of these utilities are expecting to see a common name. The most prevalent are LOGIN, MAP, and CAPTURE. Here's how it works for the example in Figure 3.15:

    LOGIN .Admin.ACME resolves as ".CN=Admin.O=ACME"

  • Exception Rule 3: Contextless Login—If you have Catalog Services and Contextless Login activated, eDirectory will resolve typeless names by offering the user a list from the eDirectory Catalog. (Note: NetWare 6 eDirectory does not support Catalog Services.)

There you have it. This completes the discussion of typeless names and eDirectory naming in general. As you can see, this is an important topic because it impacts all aspects of eDirectory design, installation, and management. No matter what you do, you're going to have to use the correct name to login to the tree or access eDirectory resources. As you've learned, an object's name is a combination of what it is (common name) and where it lives (context).


As a world-class NetWare 6 CNA, you should always use typeful distinguished names in login scripts and capture statements. It is good form, and more importantly, some utilities still require naming attributes for administrative management.

Now you can complete your eDirectory adventure with a quick lesson in changing your current context.

Changing Your Current Context

A user's current context can be set in one of the following ways:

  • Before login, using the Name Context field on the Client tab of the Novell NetWare Client Properties (or Novell Client Configuration) window

  • During login, using the Context field on the eDirectory tab of the Novell Login window (which is accessed by clicking the Advanced button)

  • Using the CONTEXT login script command

  • Using the CX utility

It's best to set a user's context at login, so the user can have easy access to the network resources he or she uses the most. If a user wants to access resources located in a different context, he or she will need to use correct naming conventions. The next sections explore each of these four methods for changing a user's current context before, during, and after login.

Setting a User's Context Before Login

On Windows 95/98 and Windows NT/2000 workstations, you can set the workstation's current context before login by entering the appropriate context information in the Novell NetWare Client Properties window, as shown in Figure 3.16. The typeless distinguished name in the Name Context field sets the workstation's current context before login. It can be entered with or without a preceding period.

Figure 3.16Figure 3.16 The Novell NetWare Client Properties dialog box.

To set up a workstation's current context before login, access the Network icon in the Windows 95/98 or Windows NT/2000 Control Panel, select the Novell Client for Windows, and then click Properties. When the Novell Client Properties dialog box appears, enter the current context in the Name Context field on the Client tab. If you're already logged in to the network, a faster way to change this field is to right-click the N icon in the system tray and to select Novell Client Properties from the pop-up menu. When the Novell Client Configuration dialog box appears, enter the current context into the Name Context field on the Client tab. (Refer to Chapter 4, "NetWare 6 Connectivity," for more information regarding Novell Client installation and configuration.)

Setting a User's Context During Login

On Windows 95/98 and Windows NT/2000 workstations, you can set a workstation's current context during login by entering the appropriate context information in the Novell Login window. To do so, when the Novell Login window is displayed, click the Advanced button and then enter the current context into the Context field on the NDS tab.

Using the CONTEXT Login Script Command

Setting a workstation's current context during login sets the current context that will be in effect for the user after the user attaches to the network. This prevents the user from having to use distinguished names to access eDirectory resources. Remember, eDirectory attempts to resolve relative distinguished names into distinguished names by appending the current context to the end of the relative name.

The CONTEXT login script command is similar to the NetWare 6 CX command-line utility, except that it does not support all the same options (that is, it sets only the current context). To set a workstation's current context during login, add this command to the appropriate Container, Profile, or User login script:

CONTEXT distinguished name

For example,




Note the use of a preceding period (.) to identify the distinguished name. This method is not workstation specific; it can be set for an individual or a group.

Using the CX Command

You can view information about an object's context or change your workstation's current context using the CX command-line utility (which is executed at the DOS prompt on a client workstation). CX is the key NetWare 6 utility for dealing with eDirectory context. It enables you to perform two important tasks: change your workstation's current context and/or view information about a resource's object context.

CX is a relatively straightforward command with a great deal of versatility. In fact, it's similar to the DOS CD command in its general approach. If you type CX by itself, the system displays your workstation's current context. This is marginally interesting, at best. CX really excels when you combine it with one or more command-line switches. Following are some of the more interesting ones:

  • CX—View your workstation's current context.

  • CX .—Move the context up one container for each period (.). Don't forget the space between CX and the period (.).

  • CX /T—View the Directory tree structure below your current context.

  • CX /A /T—View all objects in the Directory tree structure below your current context.

  • CX /R /A /T—View all objects in the Directory tree below the Tree Root.

  • CX /CONT—List containers only, below the current context, in a vertical list, with no directory structure.

  • CX /C—Scroll output continuously.

  • CX .OU=ADMIN.O=ACME—Change your current context to the ADMIN container of ACME.

  • CX /?—View online help, including various CX options.

  • CX /VER—View the version number of the CX utility and the list of files it executes.

Probably the most useful CX option is CX /R/A/T. I'm sure there's a hidden meaning there somewhere in the rodent reference. Or, if you lean toward the artistic side of the fence, try CX /A/R/T. And finally, for all you urbanites, there is CX /T/A/R. Regardless, the CX /R/A/T option displays the relative location of all objects in the eDirectory tree.

Understanding Inheritance

eDirectory rights can also be obtained through inheritance. In simple terms, inheritance occurs when rights granted to a trustee of a container flow down to all objects within and below the container. Inheritance minimizes the individual rights assignments needed to administer the network because object/property rights can automatically flow down the tree from containers to subcontainers to leaf objects. Inheritance is an automatic side effect of trustee assignments. Both object and property rights can be inherited.

Congratulations! This completes the lesson on eDirectory.

So far, you've explored the basics of NetWare 6 and the intricacies of eDirectory. Now you're ready for Prime Time:

  • NetWare 6 Connectivity (Chapter 4)

  • NetWare 6 File System (Chapter 5)

  • NetWare 6 Security (Chapter 6)

  • NetWare 6 Advanced Security (Chapter 7)

  • NetWare 6 Queue-Based Printing (Chapter 8)

  • NetWare 6 NDPS Printing (Chapter 9)

  • NetWare 6 Messaging Services (Chapter 10)

  • NetWare 6 Internet Infrastructure (Chapter 11)

Don't be scared—I'll be with you every step of the way. And we'll explore eDirectory many times throughout this CNA Study Guide.

Well, that's all there is to it — not really! Remember, the glass is half full, and you have taken a huge "gulp" in this chapter. Use this information wisely as you expand the horizons of your network. Next, the discussion of NetWare 6 administration features continues as you learn how to connect to this mysterious and exciting network Directory.

See ya there!

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