Home > Articles > Operating Systems, Server > Microsoft Servers

Managing the Directory

Like this article? We recommend

Like this article? We recommend

4.4: Creating and Managing User Accounts

Overview of User Accounts

The management of user accounts is one of the primary responsibilities of system administrators. User accounts are important because they are a fundamental unit of security and audit policies. In past versions of Windows, it was uncommon for anyone but administrators to require the ability to list user accounts. Accordingly, there was little identifying information to maintain other than Login Name, Full Name, and Description.

In Windows 2000, the strategic importance of user account maintenance has increased. Active Directory now represents not just a list of accounts, but also a database and referral point for many services that require the data to be up-to-date. The Active Directory is exposed to users often—especially in collaborative activities such as video conferencing and electronic mail. As a result, more fields have been created to help associate directory objects with real people and resources.

Although this has resulted in an increased burden on administrators, powerful new tools have come to their rescue. The traditional GUI-based management applications still exist, but additional command-line applications and API (Application Program Interface) techniques are now included. Although these new tools are sophisticated, they do not require extensive application programming experience to use.

Virtually all these new fields, functionality, and tools focus on the Active Directory. Although Windows 2000 still supports the "workgroup" networking model (utilizing local accounts), Active Directory is where the exciting improvements are.

For more information on Active Directory, see Chapter 1.2, "Introduction to Active Directory," and Chapter 4.2, "DNS and Active Directory."

Local (SAM) Accounts

The concept of local accounts has been carried over from the Windows NT security model. Although every Windows 2000 computer maintains a list of accounts, only non-Domain Controllers can contain local accounts.

Local accounts are sometimes referred to as SAM accounts because the Security Accounts Manager (SAM) service is responsible for their maintenance. The SAM service stores local accounts in an encrypted file on the local computer (%systemroot%\system32\config\sam). Local accounts are known only to the local computer, so they can be used only to authenticate to and use resources on that one computer.

Local accounts are useful in the following scenarios:

  • To allow users in untrusted Domains or workgroups to access resources that exist on the local computer.

  • To ensure access to a computer when Domain authentication services may be unavailable. For example, a local administration account would be needed to reconfigure a computer that cannot communicate on the network.

Local accounts may also present you with security problems. By definition, local accounts are not centrally managed, so maintaining standards throughout your enterprise may prove difficult. In addition to the security issues, the automation tools discussed later in this chapter (Command Prompt tools and ADSI) do not apply to local accounts.

To create a local account, do the following:

  1. Ensure that you are logged on to the computer with appropriate credentials. You must be a member of the local Administrator's group to create local accounts.

  2. Launch the Computer Management MMC snap-in. The easiest way to do this is to right-click the My Computer desktop icon and choose Manage.

  3. Navigate to the Local Users and Groups section under System Tools. When you select the Users folder, a list of local accounts will appear in the right pane. If there is a red X on the icon, you are probably managing a Domain Controller, which does not support local accounts.

  4. Right-click and choose New User. The New User dialog box appears.

  5. In the User Name field, enter the new account's logon name. End users typically recognize the User Name as their logon name or the identification they provide to gain access to the computer or network.

  6. In the Full Name field, enter the full name of the user, preferably in last, first format.

  7. Enter the initial password into the Password and Confirm Password fields.

Best Practices for Local Accounts

  • Use them sparingly.

  • If you have implemented a Windows NT or Windows 2000 Domain model, do not permit end users to create local accounts on their computers. Instead, encourage them to engage the IT support process to have a Domain account created. Although this might seem like more work for you (and the user) in the beginning, you will have fewer problems in the long run.

  • Design a predictable, secure architecture for how and where you will use local accounts. Standardize their use throughout your enterprise, whenever possible. If each system has different local accounts and different passwords, you will (or should) spend a lot of time tracking this information. Consult with your organization's security group to get input.

  • Make sure that at least one local Administrator account is enabled on all workstations. This will ensure that you can gain administrative control of the workstation if it is not able to contact a Domain Controller. If you standardize the password for this account, carefully guard this password!

Domain User Accounts

For the most part, Domain user accounts are the preferred way to implement network security. Although there is additional complexity involved in maintaining a Domain architecture, Domain accounts have the following compelling advantages over local accounts:

  • Domain accounts exist as objects in the Active Directory, and thus may be centrally (and securely) managed.

  • Access to resources on any computer in the Domain may be granted to Domain accounts. This allows a single Domain account to have access to resources on multiple computers. To accomplish this with local accounts, each computer accessed would require an identical account and password.

  • Domain accounts can be granted access to resources in other Domains when trust relationships have been established. With new support in Windows 2000 for transitive trusts, access to other Domain resources may not even require an explicit trust.

When Active Directory is first installed, a set of default accounts is automatically included in the new directory. These accounts are created for one of two reasons:

  • They help you get started in effectively managing the Active Directory.

  • They ensure the secure, reliable operation of an option or service that is running on computer(s) in your network. Usually, these services need to run under a specific security context other than Administrative rights.

Table 4.4.1 contains a list of default Domain accounts included in a typical installation of Windows 2000.

Table 4.4.1 Default Domain Accounts

Name

Description

Administrator

Default account for administering the automatically given full permissions to manage the Domain.

Guest

Default account for guest access to the computer/Domain. A user with no defined Domain account may be able to access limited resources with the Guest account.

IUSR_<Domain-name>

This account is created when Internet Information Services is installed. It provides permissions for anonymous users to access Web pages.

For more information, see Chapter 5.8, "Internet Information Server."

IWAM_<Domain-name>

This account is also created when Internet Information Services is installed. It is used to start out-of-process applications spawned by IIS.

For more information, see Chapter 5.8, "Internet Information Server."

Krbtgt

This is the Key Distribution Center Service Account, which is used by the Kerberos security subsystem to grant Ticket Granting Tickets to network clients. Kerberos is a highly secure, yet somewhat complex security architecture. More information about this account is available in RFC 1510, available at http://www.ietf.org.

TsInternetUser

This user account is created if Terminal Services is installed on the computer. When Terminal Services Internet Connector licensing is enabled, all Terminal Server sessions are logged in with this account.

For more information, see Chapter 8.8, "Terminal Services."


Administering User Accounts

As objects in the Active Directory, user accounts are available for administration by any of the various channels provided to manipulate data in the directory. These channels include GUI (Graphical User Interface), command-line scripting, and API methods. A brief overview of each method to administer user accounts is shown in the sections that follow.

GUI Interface

The Active Directory Users and Computer MMC snap-in is the most common and convenient way to administer user accounts. The snap-in is available by default on Windows 2000 servers and is installable as an optional software package (ADMINPAK.MSI) from the Windows 2000 CD.

AD Users and Computers presents a hierarchical view of the containers within the Active Directory and the contents within those containers. Users within the containers are identified in the right pane with an icon representing a person's face. If an account is disabled (not currently permitted to log in), a red X appears in front of the icon. It is generally good practice to use the Description field to make administrative notes for special cases. In Figure 4.4.1, you can see that the account for Robert Johnson has been disabled because he is on sabbatical.

Figure 4.4.1 AD Users is showing the status of different users.

Creating and Deleting User Accounts

After you have launched Active Directory Users and Computers, and you have determined which OU should contain a new user, creating a Domain user account is very similar to the process of creating a local user:

  1. Right-click the container name and choose New, User.

  2. The New User dialog box appears. Note that the Domain name fields will be automatically included in the form.

  3. Enter the information shown in Table 4.4.2 into the appropriate fields.

  4. Table 4.4.2 New User Account Fields, Part 1

    Field

    Purpose

    First Name, Initials, Last Name

    These fields help identify the person who uses the account.

    Full Name

    This field populates a number of fields in the Active Directory. The most important of these is the Canonical Name. Because the Canonical Name is difficult to change, ensure that you standardize it among all users you create. Full names must be unique within the OU.

    User Logon Name

    Also known as the User Principal Name (UPN), the user logon name is what most users associate as their ID or account. It is the logon name they provide when first starting a session with a Windows computer. User logon names must be unique within the Domain.

    User Logon Name (pre-Windows 2000)

    This field provides compatibility with earlier versions of Windows. This field also must be unique within the Domain.


  5. When complete, click the Next button.

  6. A new property dialog box appears.

  7. Define the password and select the appropriate settings, shown in Table 4.4.3.

  8. Table 4.4.3 New User Account Fields, Part 2

    Field

    Purpose

    Password, Confirm Password

    If you want to set an initial password on the account, enter that password in these fields. These fields are not required, but it is strongly recommended that you set a password on all accounts in your network.

    User Must Change Password At Next Logon

    Check this checkbox if you want to force the next user to log in with this account to change the password.

    User Cannot Change Password

    Check this checkbox if you want to prevent the user from changing the password. This is useful if you have an account that is shared by many people or a computer service that runs in a user context.

    Password Never Expires

    This checkbox overrides any password-expiration rules and prevents the password from ever expiring.

    Account Is Disabled

    When checked, this option disables the account and prevents anyone from logging onto the network with it.


  9. Click Next. The final screen will summarize the options chosen. Verify these settings and click Finish. The user account is then created in the directory.

Command-Prompt Utilities

The command-line utilities are well-suited for those with good Microsoft Office skills.

Two command-prompt utilities are provided with Windows 2000 that provide this functionality: CSVDE and LDIFDE.

Although generally similar, LDIFDE is more functional because it supports creation, deletion, and modification of existing objects, whereas CSVDE supports only the creation and deletion of objects.

The following sections give a brief overview of each utility and include some samples that show how to use them.

CSVDE

CSVDE is a command-line application that provides for the import or export of the attributes of many user objects at once. By transferring data between Active Directory and text files formatted in comma- separated-value (CSV) format, new objects (such as user accounts) can be created. CSV formatting allows many applications (notably Microsoft Office) to be used to manage data from Active Directory without programming.

The first line (or header) of a CSV file contains a sequential list of attribute names, separated by commas. Subsequent lines reflect the values of those attributes for the exported objects, also separated by commas. If an attribute supports multiple values (for example, a user may belong to multiple groups), the individual values are separated by a colon (:). Typically, each line after the header represents a discrete object, although it's legal to use the ampersand character (&) to continue an object's definition to the next line.

Raw CSV files are difficult for a human to read, but applications such as Microsoft Access and Excel make them a breeze to view and manipulate!

CSVDE is run from the command prompt and requires a number of command-line parameters. In addition to the parameters defined in Table 4.4.4, additional parameters may apply, depending on whether you are exporting objects (see Table 4.4.5) or importing objects (see Table 4.4.6).

Table 4.4.4 General Options for CSVDE

Option

Description

-I

If this option is not defined, CSVDE assumes it will export data from Active Directory into a CSV file (overwriting the CSV, if it exists). The –I command-line option indicates that the CSV file (specified by the –f option) is to be read, not written to, and the utility will be importing changes into the Active Directory.

-f filename

Regardless of whether you plan to import or export information with CSVDE, you must specify a CSV file. The –f command-line option allows you to do so. After specifying –f, you designate the file with which CSVDE should work. (Don't forget to add a space between –f and the filename). This option is required to run CSVDE in any mode.

-s servername

When looking for an instance of Active Directory, CSVDE normally connects to the most convenient Domain Controller for your Domain. If you want to apply CSVDE to another Domain or perhaps a specific Domain Controller in the Domain, you can specify that server or Domain name here.

-v

This option turns on Verbose mode. In this mode, the screen will output much more information on what exactly CSVDE is doing. This option does not change the behavior or file output of the command, but simply displays more information on the console when the command is executed.

-c FromDN ToDN

This powerful option allows you to replace instances of text from the source directory name with alternative text. This could be especially useful if you are moving objects from one directory to another or want to duplicate objects into a test lab that doesn't have the same namespace as the production environment.

-j path

Whether you need it or not, a detailed log of activity will be generated by CSVDE. This activity log contains the same information you would receive on the console if you requested Verbose mode (the –v option). The log is always named CSV.LOG, but with the –j option, you can specify the path where the file should be stored.

-t port#

If, by some chance, you are using CSVDE to query an LDAP server that is not operating on TCP/IP port 389 (the default), the –t option will allow you to specify a different port number.

-u

Interprets CSV file using Unicode character formatting. Unicode was developed as an alternative to ASCII so that many other languages could be supported. Although Unicode-ready systems such as Windows 2000 will recognize these files as text files, other systems may not. Unicode files are twice as big as straight ASCII text files, but may be necessary if your network spans non-Western countries and you expect directory information to contain non-Western character sets.

-a UserDN [Password| *]

Authenticates to the LDAP server using basic authentication. You must specify a login name and password.

-b UserName

Authenticates to the LDAP server using the

Domain [Password | *]

Security Support Provider Interface (SSPI) API. You must specify a login name, Domain name, and password.

-?

This option displays online help for the CSVDE command.


When using CSVDE to perform a directory Export, certain additional options are available, as shown in Table 4.4.5.

Table 4.4.5 Export Options for CSVDE

Option

Description

-d RootDN

By default, CSVDE will export objects at the root of the Domain container of the Active Directory. The –d option allows you to specify subcontainers within the directory or even other root-level containers in the Active Directory (schema and configuration).

-r Filter

This is a powerful option that allows you to limit exported objects to only those objects that meet specified filter criteria. When used in combination with the –d option, you can create very specialized exports that export only certain kinds of objects in certain parts of the directory.

 

RFC 2254, available at http://www.ietf.org, contains more information about syntax and construction of LDAP search filters.

-p [Base | OneLevel | Subtree]

Allows you to define how far into the directory the command should look for objects that meet your criteria. This option can have one of three arguments:

 

Base Examines only objects at the base of the directory hierarchy where CSVDE is operating. Does not search branches.

 

OneLevel Examines objects at the base and one level down into any child branches of the directory hierarchy.

 

Subtree Examines all objects in all child branches of the directory specified.

-l list

By default, if even one object has an entry defined for an obscure attribute, that attribute will be included in the header. CSVDE includes only object attributes that have a defined value in at least one object. If you want to ensure that an attribute is included in the export file, even if it is blank for all objects, use the –l option.

-o list

By default, CSVDE includes only object attributes that have defined values. If you want to ensure that an attribute is not included in the export file, even if it has a defined value, use the –o option.

-g

Normally, LDAP searches are performed in a paged manner, which breaks down large results into many separate pages. By delivering the result in smaller chunks, results can be processed piece-by-piece. This option disables paged searches and instead forces the entire result to be delivered at once. Although this may be more efficient, a large LDAP query result may trigger a Size Limit Exceeded message.

-m

When enabled, this option prevents the export of attributes that are specific to Active Directory objects.

-n

When enabled, this option prevents the export of attributes that contain binary values.


When using CSVDE to perform a directory Import, another option is available, as shown in Table 4.4.6.

Table 4.4.6 Import Option for CSVDE

Option

Description

-k

Normally, if CSVDE encounters an error while performing an import operation, it will halt. When this option is specified, the command will continue processing.


CSVDE Import Examples

To add a user with CSVDE, create a comma-separated file with the following minimum fields, shown in Table 4.4.7.

Field

Description

DN

DN is short for Distinguished Name. An object's DN describes its entire path through the hierarchy of Active Directory. LDAP syntax is used to describe the hierarchy.

ObjectClass

ObjectClass defines the type of object to be created. When creating users, this is always set to user. Other values such as group and organizationalUnit are also valid, however.

sAMAccountName

This field contains the SAM account name (pre-Windows 2000 User logon name).


A sample comma-separated file containing these fields might contain the following text:

The first line is the header, which contains the attribute names that will be specified for each object. In this case, only the three minimum object attributes are included. You can include additional attributes when creating the object, but Windows 2000 will accept only field names that are valid. If you are looking to set additional attributes, the ADSIEDIT application, available in the Windows 2000 Resource Kit, can be used to identify additional valid object field names available for import/export with CSVDE.

The second line contains values for each of the three minimum object attributes specified in the header line. Note that because the DN attribute contains commas within its value, DN is surrounded by two quote marks. This ensures that the commas do not indicate subsequent attribute values of the header.

After the import file has been created, you are ready to execute the CSVDE command.

In the following example, we run CSVDE and indicate that it should import users from the IMPORT.CSV file. In our example, the file exists on the root of drive C:. You can name the file as you like and place it anywhere that's convenient, however.

When executed, you should see output similar to the following:

CSVDE Export Examples

The following example uses LDAP filtering to export all directory objects that have a fax number beginning with 203-555:

The following example also uses LDAP filtering to export all organizational units in the Domain, regardless of location:

The following example is similar to the previous one, except that it exports only top-level organizational units:

The following example exports only organizational units that exist immediately under the US organizational unit in your sample Domain (jmulvey.com):

The following example builds further on the previous sample to export organizational units that exist immediately under the US organizational unit in your sample Domain (jmulvey.com) and have the location field set to Boston.

LDIFDE

Although very similar in operation, LDIFDE has some major functionality advantages over CSVDE. Although both utilities support the export and creation of objects, LDIFDE has the added capability to modify existing objects in Active Directory. LDIFDE also uses LDAP Data Interchange Format (LDIF) files instead of the comma-separated format used by CSVDE.

The LDIF file format describes objects by placing the contents of each attribute on a separate line in the text file. A blank line in the file indicates the start of a new object. LDIF files are more human-readable than CSV files, but more difficult to import or export from applications such as Microsoft Access or Excel. LDIF is an open standard, defined by the Internet Engineering Task Force. More detailed information on the LDIF file format standard can be found at http://www.ietf.org.

When using LDIFDE to import data, an entry is required for each object in the text file. The entry changetype indicates whether the object is to be added as a new object, or instead represents changes to an existing object. The changetype entry can be set to create, modify, or delete.

Like CSVDE, LDIFDE is run from the command prompt and requires several command-line parameters. These parameters are identical in form and function to the options available in CSVDE. (Refer to Tables 4.4.4, 4.4.5 and 4.4.6).

Adding a User with LDIFDE

To create a new Windows 2000 user using the LDIFDE command, first create an LDIF file (in this case, name it IMPORT.LDF). This file must contain the following minimum attributes to successfully create a new user (of course, the values for these attributes may be different):

Of course, additional object attributes can be defined within the LDIF file if you have more information you want to include with the user. The ADSIEDIT application, available in the Windows 2000 Resource Kit, can be used to identify additional valid object field names available for import/export with LDIFDE.

Next, execute the LDIFDE command as follows:

The new user should now exist in the Users container (as defined in the IMPORT.LDF file).

Deleting a User with LDIFDE

When deleting a user, only the Distinguished Name (DN) of the object needs to be specified. For example, to delete the test user you created previously, create a file called DELETE.LDF with the following contents:

Next, execute the LDIFDE command as follows:

The user should now be removed from the directory.

Modifying a User with LDIFDE

Creation of LDIF files when modifying users is a bit more involved than in other scenarios. After specifying the Distinguished Name (DN) and indicating a changetype of modify, a change operation identifier is used to indicate which attributes are to be modified. Finally, each attribute change is concluded with a dash on a blank line.

In the examples used here, you will use a Change Operation Identifier of replace.

For example, to change the location of your test user, create an LDIF file with the following contents:

Next, execute the LDIFDE command as follows:

If you want to modify several attributes of an object at once, you do not need to respecify the object each time. Simply separate each attribute with a dash on one line and include the additional attribute function and content.

When this file is imported with LDIFDE, both the location and telephone number will be replaced with Boston and 617-555-5555, respectively.

Using ADSI Scripts to Manage User Accounts

API interfaces can be easily scripted with only a little knowledge of Microsoft Visual Basic.

Scripting though ADSI represents the most complex, yet most powerful way to manage user accounts in Active Directory.

Creating a user with ADSI looks like this:

Deleting a user with ADSI looks like this:

Part x.Delete "user", "cn=" & DeleteName

Best Practices When Administering Accounts

  • Use the Description field to make administrative notes and reminders relative to the management of directory objects.

  • Use Last, First format for the Display Name field. By conforming to this standard, you will be able to more easily locate users who may prefer nicknames as their first name (for example, Robert versus Bob).

  • Consider automating data feeds from other systems to keep data in the Active Directory up-to-date. For example, many corporate telephony departments maintain accurate electronic lists of employee telephone numbers, which can be integrated into appropriate Active Directory fields. Another idea: Find out if your Human Resource department can supply updates to the organizational reporting structure. This information could be used to update the Manager and Direct Reports fields in Active Directory. There are endless possibilities here. In any event, make sure the data provided is relevant and kept up-to-date.

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.

Overview


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.

Surveys

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.

Newsletters

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.

Security


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

Children


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

Marketing


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.

Choice/Opt-out


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.

Links


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