Home > Articles > Operating Systems, Server

  • Print
  • + Share This
This chapter is from the book

This chapter is from the book

Active Directory Utilities

We've now seen all the components in Active Directory. Over the next few chapters, we'll see how to use those components to build a reliable, useful structure. First, though, let's take a look at the tools of the trade for Active Directory. You get some of these tools when you promote Windows Server 2003 to a domain controller. Others come from the support tools on the Windows Server 2003 CD. Others require purchasing the Resource Kit. I'll identify the origin as I discuss the tools.

Standard Active Directory Management Consoles

Windows Server 2003 comes with three standard MMC-based consoles for viewing and managing Active Directory objects. MMC console files have an .msc extension. The management consoles can be differentiated by the naming context they are used to manage:

  • AD Users and Computers. This console is used to manage the contents of a Domain naming context. The console name is Dsa.msc.

  • AD Sites and Services. This console is used to manage the Sites and Services containers inside the Configuration naming context. The console filename is Dssite.msc.

  • AD Domains and Trusts. This console is used to manage the contents of the Partitions container inside the Configuration naming context. It uses the CrossRef objects in the Partitions container to identify domains in the forest in their assigned hierarchy. The console filename is Domain.msc.

These consoles can all be launched from the Start button at Windows Server 2003 using START | PROGRAMS | ADMINISTRATIVE TOOLS | <CONSOLE NAME>. You can also launch them by entering the name of the MMC console file, such as Dssite.msc, in a Run window or on the command line. Specific instructions for using these AD management consoles are contained in the remaining Active Directory chapters. The most important thing to note at this time, as you get familiar with them, is that virtually all functionality is available from a right-click of the mouse. Very few features require operations from the menu.

Virtual List Views

If you have experience with Windows 2000, you may notice a difference in the way Windows Server 2003 displays pick lists that are built as a result of LDAP searches.

In Windows 2000, the results of the search were delivered to the client in increments of 1500 ordered sequentially as matches were found in the directory. This made pick lists difficult to manage because the items were not sorted.

In Windows Server 2003, search results are fully collected and sorted at the server then delivered in increments stipulated by the client. This means that pick lists are automatically sorted alphabetically, making it easier to locate a particular item.

Schema Console

Microsoft makes it fairly difficult to get access to the Schema naming context. It does not include a standard MMC console for managing the schema. You must create a custom console that contains the Schema snap-in. A snap-in is a Dynamic Link Library (DLL) that is loaded by the MMC executable. After you have associated one or more snap-ins with a console, you can save the console with a unique name that has an .msc extension.

Before you can create a custom MMC console for schema management, you must have access to the Schema snap-in. This snap-in is part of the administrative tools but is not registered by default. This prevents casual monkeying around with the schema. To register the Schema snap-in, open a command console, navigate to C:\Windows\System32, and run regsvr32 schmmgmt.dll.

After the Schema snap-in is registered, create a custom MMC console for it as directed in Procedure 6.1.

Procedure 6.1 Creating a Custom Schema Management Console
  1. From the Run window, type mmc and click OK. This opens an empty MMC console.

  2. From the CONSOLE menu, select FILE | ADD/REMOVE SNAP-IN. The Add/Remove Snap-in window opens.

  3. Click Add. The Add Standalone Snap-in window opens.

  4. Double-click Active Directory Schema and then click Close.

  5. Click OK to save the change and return to the MMC window. The Active Directory Schema tree will appear under the Console Root folder.

  6. Save the file with a name like Schema.msc. The system will put the file in your personal profile. Save it to the \Windows\System32 folder if you want other administrators to use it.

When you expand the Schema tree, you'll see the objects that make up the classes and attributes of the schema. You can double-click to see the properties for one of these objects. Figure 6.16 shows an example of the properties for the SamAccountName attribute, which holds a user's logon name.

06fig16.gifFigure 6.16. Properties window for the attributeSchema object used to create the SamAccountName attribute.

There is a list of options that affect how this attribute will be used in Active Directory:

  • Allow This Attribute To Be Shown In Advanced View. Each AD console has an ADVANCED VIEW option. This prevents cluttering the interface with options that are only used occasionally. (It also confounds administrators who are trying to perform an operation and don't know that the option is hidden in a normal view. This is called a feature.)

  • Attribute Is Active. Some attributes are not required for system operation and can be disabled to prevent them from getting values.

  • Index This Attribute In Active Directory. Like any database, performance improves when you search for indexed attributes. Indexing consumes disk space and processor time, though, and an attribute must be unique to make the index worthwhile. Only the most commonly searched attributes are selected for indexing.

  • Ambiguous Name Resolution (ANR). ANR permits searching for partial matches. An ANR search for a SamAccountName of “gh” would return “ghawn,” “ghaskell,” “ghowell,” and so forth. ANR searches put quite a strain on the database engine, so only nine attributes are selected to use it by default. If you design an application with an attribute that would benefit from ANR searching, you can use this option to add it to the ANR set.

  • Replicate This Attribute To The Global Catalog. This setting determines if an attribute should be included in the Global Catalog. Only commonly searched attributes are included to minimize GC size and replication load. In Windows 2000, adding or removing an attribute from the GC required a full GC rebuild and replication. This had the potential for creating significant traffic. Windows Server 2003 permits modifying the contents of the GC without forcing a full rebuild.

  • Attribute Is Copied When Duplicating A User. With this option selected, the value for the attribute would be carried over to a new User object with the Copy function. The SamAccountName must be unique in a domain, so this option is disabled for this attribute.

  • Index This Attribute For Containerized Searches In The Active Directory. The search routines provided in the LDAP API and with Microsoft ADSI permits searching a container rather than the entire directory. You can select this option to improve lookup times for container searches.

The schema can only be modified at one domain controller, the one designated as a Schema Operations Master. This ensures the integrity of the schema by preventing potentially conflicting changes from being made at two different domain controllers during the same replication interval.

You can identify the Schema Operations Master by right-clicking Active Directory Schema and selecting OPERATIONS MASTER from the flyout menu.

You do not need to be at the console of the Schema Operations Master server to view and modify the schema. You can put the focus of the Schema console on this server by right-clicking Active Directory Schema and selecting CHANGE DOMAIN CONTROLLER.

Search Flags

Several of the attribute property options listed in the Schema Manager control a value called SearchFlags. This value controls the following actions (values are additive):

  • 1 = Index this attribute

  • 2 = Index this attribute and its container

  • 4 = Add to ANR set (must have indexing set)

  • 8 = Keep the attribute when deleting the object and creating a tombstone

  • 16 = Copy the attribute's value when creating a new copy of an object

Of these settings, only number “8” cannot be controlled from the Schema Manager snap-in. You can use the ADSI Edit console (covered in the next section) to change the value.

Registry Requirements for Schema Modifications

Windows 2000 had a security measure that required a special Schema Updated Allowed parameter in the Registry of the machine where you ran the Schema console. This requirement has been removed in Windows Server 2003.

You must be a member of the Schema Admins group to modify any part of the schema. By default, the Administrator account is a member of this group. The Schema Admins group has a set of special permissions for the Schema container. These include the following:

  • Change Schema Master

  • Manage Replication Topology

  • Replicating Directory Changes

  • Replication Synchronization

  • Update Schema Cache

You should not make changes to the schema unless you are very familiar with its structure and what you want to accomplish. New schema objects cannot be deleted. Changes to existing objects can cause problems that could force reinstalling Active Directory from scratch or recovering from a backup tape.

General-Purpose Active Directory Tools

The standard AD management consoles provide a feature-rich interface for accessing and modifying Active Directory objects and attributes. They also hide a lot of the gears and pulleys that go together to make Active Directory work.

We're now going to take a look at a few tools that take us behind the glitzy façade of those fancy AD management consoles. We're going to see the real world that underlies Active Directory. If you've ever seen The Matrix, you have an idea of what we're in for. I have just one question before we start:

Do you want to take the red pill or the blue pill?


The first set of general-purpose tools we'll look at come in the suite of Support Tools on the Windows Server 2003 CD. Install the support tools by double-clicking the \Support\Tools\2000RKST.MSI icon and walking through the installation wizard.

After the tools are installed, open a Run window and enter adsiedit.msc. This is the console filename for the ADSI Editor. When the ADSI Edit console opens, you see icons representing the three standard naming contexts for a domain controller: Domain NC, Configuration Container, and Schema. (It cannot display the Application naming contexts.) See Figure 6.17 for an example.

06fig17.jpgFigure 6.17. ADSI Edit console showing the three standard naming contexts for a domain controller.

Selecting Alternative Domain Controllers for ADSI Edit

If you do not see any naming contexts when you open ADSI Edit, or you want to view a naming context on another domain controller, proceed as follows:

  1. Right-click the ADSI Edit icon and select CONNECT TO from the flyout menu. The Connection window opens.

  2. Under Computer, select the Select or Type a Domain or Server radio button.

  3. In the combo box, type the fully qualified DNS name of a domain controller. When you make this entry, the Path entry automatically changes.

  4. Click Advanced. The Advanced window opens (see Figure 6.18).

    06fig18.gifFigure 6.18. ADSI Editor Advanced window showing alternative credentials, specific port number, and protocol selection.

The options in this window are used as follows:

  • Credentials. If you are connecting to Active Directory in another domain, or you are currently logged on using an account that does not have administrator privileges, you can specify a set of administrator credentials.

  • Port Number. If this field is left blank, ADSI Editor uses well-known TCP port 389 for LDAP. You can specify a different port if you are browsing a non-standard implementation. You could also use this option to browse the Global Catalog through TCP port 3268, but it is more convenient to use the Protocol feature.

  • Protocol. Select whether you want to browse Active Directory (port 389) or the Global Catalog (port 3268).

  1. Click OK to save the changes and return to the Connections window.

  2. Click OK to save the changes and return to the main ADSI Edit console. The display refreshes to show the new settings, if you made any changes.

Using ADSI Edit to View and Modify AD Objects

Use the steps in Procedure 6.2 to view and modify information about Active Directory objects.

Procedure 6.2 Using the ADSI Editor to View AD Objects
  1. Expand the tree to show the top of the naming context you want to view. You can open several Domain naming contexts from several domain controllers at the same time, making ADSI Edit a handy way to view a big enterprise.

  2. You can view the attributes associated with any object in any naming context. For example, expand the Domain NC tree to show the list of objects under cn=Users and then right-click cn=Administrator and select PROPERTIES from the flyout menu. The Properties window opens (see Figure 6.19).

    06fig19.gifFigure 6.19. Properties for distinguished name cn=Administrator,cn=Users,dc=Company,dc=com.

  3. The Show Mandatory Attributes and Show Optional Attributes options are checked by default. Select the Show Only Attributes That Have Values option to eliminate extraneous information in the window.

  4. Scroll down through the window to view the various attributes and their values.

  5. To change a value, double-click it. ADSI Edit will select the appropriate low-level editor to modify the attribute.

Think of ADSI Edit as a kind of super Regedit for Active Directory. All the same caveats apply. You can turn a perfectly tuned domain into sad, twisted carnage with a few mouse clicks. You can also perform miraculous surgery that solves seemingly intractable problems.

LDAP Browser

ADSI Edit is built from the ground up as a tool to manage Active Directory naming contexts. The Support Tools also includes a generic LDAP tool that is capable of accessing any RFC-compliant LDAP directory service. This tool is a true executable, not an MMC snap-in. It is called the LDAP Browser, or Ldp.exe.

LDP is a little less convenient to use than ADSI Edit, and it requires you to know a little more about how to use LDAP. But it's well worth the effort to learn. LDP provides a lot more information with a single mouse click than ADSI Edit. Also, some LDAP operations are hidden by ADSI Editor but exposed by LDP.

Installing LDP

When you use LDP, you must walk through a few steps to bind (authenticate) and set up to view the directory tree. Procedure 6.3 demonstrates how it works.

Procedure 6.3 Binding with LDP
  1. At a client in a domain, open the Run window and enter LDP. This opens the LDP window.

  2. Select CONNECTION | BIND to open the Bind window.

  3. Enter administrator credentials in the domain or forest.

  4. Click OK. The attributes associated with the RootDSE object appear in the right pane. These attributes show the structure and content of the directory on the server. (LDP will bind to your logon server. You can use the Connect option to select another server.)

  5. From the menu, select VIEW | TREE. This opens the Tree View window.

  6. Under BaseDN, enter the distinguished name of the container you want to browse. For example, you can enter dc=Company,dc=com to start at the top of the Domain naming context for the Company domain. You can also specify a container lower in Active Directory. For example, you could select the Users container by entering cn=Users,dc=Company,dc=com. The interface is not case sensitive.

  7. Click OK. The left pane of the window now shows the root of the container you entered. Click the + sign or double-click the name to expand the tree. This generates an LDAP query that enumerates the child objects in the container, which are listed in the tree in the left pane. It also generates a query for the attributes associated with the domain object. These are listed in the right pane (see Figure 6.20).

    06fig20.gifFigure 6.20. LDP window showing tree view of Company.com domain.

Searching for a Specific Attribute

LDP is also a convenient place to search the directory for specific instances of an attribute (see Procedure 6.4).

Procedure 6.4 Searching with LDP
  1. Select BROWSE | SEARCH from the main menu to open a search window.

  2. In Base DN, enter the distinguished name of the container you want to search. You can enter the DN of the root domain of a tree if you want to search the entire tree, but this might take a while if you have a large enterprise with several child domains.

  3. In Filter, enter the search criteria. The syntax is a little tricky. LDAP expects to see Boolean operators such as & (AND) and | (OR) at the beginning of the search string. For example, if you want to find all Users who are in the Finance department, you would enter (&(objectclass=user)(department=finance)). The entry is not case-sensitive.

  4. If you want to search just the object you entered the DN for, select Base. If you want to search the base object and any objects directly under it, select One Level. If you want to search all containers under the base container, select Subtree. LDP cannot search an entire forest. You must select a base DN at the root of each tree in the forest and run the search multiple times.

LDP Search Wildcards

LDP only accepts wildcards at the middle and end of a filter option. You can search for department=fin* or for department=fin*ce but not for department=*ance.

You can do many fancy tricks with LDP. You can get a quick view of the security descriptor for an object. You can view the replication metadata associated with all the properties of an object (something we'll cover in more detail in Chapter 7, “Managing Active Directory Replication”). It's well worth your time to learn the ins and outs of LDP. You'll also learn a lot about LDAP and Active Directory at the same time. You'll be glad you took the red pill.


This tool comes in the Resource Kit. It is an invaluable diagnostic utility for examining and troubleshooting a variety of Active Directory operations. You'll find that these tests give great information about the current state of your Active Directory domains, trusts, and replication status. Enter dcdiag /? to get a list of the tests that are performed. Every element of Active Directory operation is tested. This utility is highly recommended.

DS Tools

Windows Server 2003 expands the number of command-line tools available for administering Active Directory with a set of DS tools. Here is a list:

  • Dsadd. Creates an object of a specified class. A wide variety of attributes can be given values at the same time. For example, here are the attributes for dsadd user:

    dsadd user <UserDN> [-samid <SAMName>] [-upn <UPN>] [-fn <FirstName>]
      [-mi <Initial>] [-ln <LastName>] [-display <DisplayName>]
      [-empid <EmployeeID>] [-pwd {<Password> | *}] [-desc <Description>]
      [-memberof <Group ...>] [-office <Office>] [-tel <Phone#>]
      [-email <Email>] [-hometel <HomePhone#>] [-pager <Pager#>]
      [-mobile <CellPhone#>] [-fax <Fax#>] [-iptel <IPPhone#>]
      [-webpg <WebPage>] [-title <Title>] [-dept <Department>]
      [-company <Company>] [-mgr <Manager>] [-hmdir <HomeDir>]
      [-hmdrv <DriveLtr:>] [-profile <ProfilePath>] [-loscr <ScriptPath>]
      [-mustchpwd {yes | no}] [-canchpwd {yes | no}]
      [-reversiblepwd {yes | no}] [-pwdneverexpires {yes | no}]
      [-acctexpires <NumDays>] [-disabled {yes | no}]
      [{-s <Server> | -d <Domain>}] [-u <UserName>]
      [-p {<Password> | *}] [-q] [{-uc | -uco | -uci}]
  • Dsmod. Modifies selected attributes of an existing object.

  • Dsrm. Removes an object or container. Use caution. You can accidentally remove an entire branch of the tree and force yourself into a tape restore to recover.

  • Dsmove. Moves an object to a new container. The container must be in the same naming context.

  • Dsquery. Finds objects that match a specified search criteria.

  • Dsget. Views selected properties from a specified object.

  • + Share This
  • 🔖 Save To Your Account