• Home
• Administering Active Directory - MCSE Prep

Section 4.7: Administering Active Directory

Active Directory is designed to provide information to queries about directory objects from users, as well as from software applications, and stores information about each object on the network. Each object is a distinct, named set of attributes that represents a specific network entity. When you add new resources to your network, new Active Directory objects that represent these resources are created. However, you must publish information pertaining to shared folders and network printers in Active Directory. The process of publishing information in Active Directory is the process of creating new directory objects. Some common Active Directory objects and the information pertaining to it that is stored in Active Directory are listed in Table 4.2.

Table 4.2: Common Active Directory Objects

Object Type	Description
User account	Information, such as user logon name, that allows a user to log on to a Windows Server 2003 domain. This information has optional fields including first name, last name, display name, telephone number, e-mail, and home page.
Contact	Information about a person with a connection to the organization. This information also has optional fields including telephone number, e-mail, address, and home page.
Group	A collection of user accounts, groups, or computers that you can create and use to simplify administration.
Shared folder	A pointer, i.e., the address, to the shared folder.
Printer	A pointer to a printer.
Computer	The information about a computer that is a member of the domain.
Domain controllers	The information about a domain controller. This can include optional descriptions for the Domain Controller; the Domain Name System (DNS) name; the pre-Windows 2000 name; the operating system version on the domain controller; the location; and the user account name of the user responsible for managing the domain controller.
Organizational Unit (OU)	Containers which contains other objects, including other OUs, and are used to organize Active Directory objects.

You can use FIND in the Active Directory Users and Computers snap-in in the Administrative Tools

folder to locate Active Directory objects. You can open find by doing the following:

The Find dialog box provides options that allow you to search the global catalog to locate Active Directory objects. Table 4.3 lists the options in the Find dialog box.

Table 4.3: Find Dialog Box Options

Option	Function
Find	Lists the object types for which you can search.
In	Lists the locations in which you can run the search.
Browse	Allows you to select the path of your search.
Advanced (tab)	Allows you to define the search criteria to locate the object that you need. The Advanced tab contains these additional options:
Find Now	Field. Lists the attributes for which you can search on the object type that you select. Condition. Lists the methods available to further define the search for an attribute. Value. Allows you to enter the value for the condition of the field or attribute that you are using to search the Directory. Search Criteria. Lists each search criteria that you have defined.
Stop	Used to begin a search after you have defined the search criteria.
Clear All	Used to stop a search.
Results

4.7.1: Active Directory Naming Contexts

Active Directory is capable of holding up to a billion objects. The Active Directory database for a domain with 150,000 objects could be more than 2 GB in size, depending on the number of groups and the length of the group membership. An Active Directory database of this size can be difficult to replicate and manage. To reduce the size of the database, so as to ease replication and management effort, Active Directory uses naming contexts to partition the Active Directory database (Ntds.dit). There are four naming contexts: the domain naming context; the schema naming context; the configuration naming context; and the application naming context.

As an Active Directory administrator, you can create a naming context at two points:

• At the domain boundary; and

• By creating a special Application naming context.

The Application naming context has only limited utility, so the only real option to partition a large Active Directory database is to create separate domains. In addition to the Domain naming context and the Application naming context, each Active Directory implementation receives a replica of the Configuration naming context and the Schema naming context. The Schema naming context replica is read-only except for the domain controller designated as the Schema Operations Master. Therefore, only the Schema Role Master, can make changes to the schema.

4.7.1.1: Application Naming Contexts

The Application Naming Context provides the ability to create additional naming contexts that can be placed on specific domain controllers. In windows Server 2003, this feature to store DNS resource (SRV) records for Active Directory Integrated zones.

When you Active Directory Integrate a zone on a DNS domain controller running Windows Server 2003, the domain controller creates two additional naming contexts:

• DomainDNSZones, a replica of which is placed on domain controllers running the DNS service; and

• ForestDNSZones, a replica of which is placed on domain controllers running DNS throughout the forest.

When you elect to Active Directory Integrate a zone, a new entry called Replication is added to the General tab in the zone Properties window. You can use this window to set the replication options of the zone. The possible replication options are:

• All DNS servers in the forest, which is the broadest scope and involves the most replication traffic. If you select this option, the zone records are placed in the ForestDNSZones naming context.

• All DNS servers in the domain, in which case the resource records are placed in the DomainDNSZones naming context for the domain of the DNS server. This limits the scope of replication to a particular domain

• All domain controllers in the domain, in which case the zone records are placed in the Domain naming context.

• All domain controllers specified in the scope of the application directory partition, which allows you to select a specific application naming context.

4.7.1.2: Configuration Naming Context

The Configuration naming context holds information about parameters that control the services that support

Active Directory. Every domain controller in a forest hosts a read/write copy of the Configuration naming

context. It holds eight top-level containers:

• The Display Specifiers container, which holds objects that alter the viewable attributes for other object classes. Display Specifiers provide localization and context menu functions.

• The Extended Rights container, which controls access to Active Directory objects by consolidating sets of property permissions into a single entity. Active Directory objects are also Windows security objects. This makes it possible to assign permissions to the object itself as well as any of the properties associated with the object.

• The Lost and Found Config container, which holds objects that are orphaned during database replication.

• The Partitions container, which holds the cross-reference objects that list other domains in the forest. Domain controllers use the contents of this container to build referrals to other domains. Only one domain controller in a forest is permitted to update the contents of this container.

• The Physical Locations container, which holds Physical Location Domain Name objects associated with Directory Enabled Networking (DEN).

• The Services container, which holds objects that are exposed in the Active Directory Sites and Services console. Distributed applications put objects into this container where they can be seen by other servers running the same application.

• The Sites container, which is also exposed in the Active Directory Sites and Services console. The objects in this container control Active Directory replication and other site-specific functions.

• The Well-Known Security Principals container, which holds well-known SIDs that represents special-purpose groups. This includes groups like Interactive, which designates users who are logged on at the console of a machine; Network, which designates users who have logged on to the domain; and Everyone, which designates every user.

4.7.2: Moving Active Directory Objects

You can move Active Directory objects within a domain through the use of the Active Directory Users and Computers snap-in. In the Active Directory Users and Computers snap-in, simply point to the object, and select a target container for the Move operation. Moving objects between domains is a more complicated. The process of moving Active Directory objects between domains that belong to different forests is migrating objects.

In Windows Server 2003, Active Directory supports a number of tools that can be used for the purposes of object migration. These tools include: the MoveTree command-line utility; the ClonePrincipal; and the Active Directory Migration Tool (ADMT). All of the utilities are included in the /Support/Tools folder on the Windows Server 2003 Installation CD, except the ADMT, which is available in the /i386/ADMT folder. All three tools add the original objects' SIDs to the sIDHistory attribute of target objects if the domains are in the Windows 2000 native domains functional level.

4.7.2.1: The MoveTree Utility

You can use the MoveTree command-line utility (Movetree.exe) to move the user, group, and OU objects within an Active Directory-based forest. The MoveTree command-line utility allows administrators to reconstruct Active Directory-based domains which belong to the same forest. This tool can move both single Active Directory objects, such as user accounts; empty domain local and global groups; universal groups; and entire containers, such as OUs, from one domain to another and are removed from their original location. In such an intra-forest migration, the user accounts retain their passwords after being moved, while membership to Universal groups is preserved. The MoveTree command-line utility cannot be used to move computer accounts, system objects, or domain controllers. Microsoft, however, recommends that you use the ADMT instead of the MoveTree command-line utility, except for moving contracts which cannot be handled by the ADTM.

4.7.2.2: The ClonePrincipal

The ClonePrincipal is a set of scripts that allows administrators to perform inter-forest migration, such as when incrementally migrating accounts from an existing Windows NT 4.0 domain to an Active Directory domain. The ClonePrincipal can also be used to reorganize Active Directory forests. Microsoft, however, recommends that you use the ADMT instead of the ClonePrincipal.

The ClonePrincipal can be used to duplicate user accounts; and security group accounts, which include local groups, global groups, domain local groups and universal groups. However, the ClonePrincipal cannot be used to duplicate computer accounts; inter-domain trusts; and accounts with well-known SIDs since these accounts have identical SIDs in every domain. The accounts with well-known SIDs are: Account Operators; Administrators; Backup Operators; Guests; Power Users; Print Operators; Replicator; Server Operators; and Users.

4.7.2.3: The Active Directory Migration Tool

The ADMT is a Microsoft Management Console snap-in that should be installed in the target domain only the by running the Admigration.msi file in the /i386/ADMT folder on the Windows Server 2003 Installation CD. It can be used to perform the same functions as the MoveTree utility and the ClonePrincipal through the help of wizards. It can be used to migrate user accounts, groups, and computer accounts:

• From Windows NT 4.0 domains to an Active Directory domain environment;

• Between Active Directory domains in different forests; and

• Between Active Directory domains in the same forest.

When you perform inter-forest migrations, you must run ADMT on a domain controller that belongs to the target domain. When you perform intra-forest migrations, you must run ADMT on the RID Master in the target domain.

The ADMT also supports a log file for each operation. These files are located in the Logs folder that resides in the ADMT installation folder and can be used to analyze failed migration operations.

4.7.3: Controlling Access to Active Directory Objects

Windows Server 2003 uses an object-based security model, that is similar to the one used to implement NTFS security, to implement access control to all Active Directory objects. Each Active Directory object has a security descriptor that defines the permissions to the object and the type of access that is allowed. Windows Server 2003 uses these security descriptors to control access to the Active Directory objects. An administrator or the object owner must assign permissions to the object before users can gain access to the object. Windows Server 2003 stores a list of these assigned user access permissions for every Active Directory object in the access control list (ACL). This allows you to assign permissions or administrative privileges to a specific user or group for an OU, a hierarchy of OUs, or a single object, without assigning administrative permissions for controlling other Active Directory objects.

In addition, you can allow or deny permissions to Active Directory objects. The Deny permission takes precedence over any permission that you otherwise allow for user accounts and groups. You can also set standard permissions and special permissions on objects. Standard permissions are the most frequently assigned permissions and are composed of special permissions. Special permissions provide you with a finer degree of control for assigning access to objects. Table 4.4 lists standard object permissions that are available for most objects and the type of access that each standard permission allows.

Table 4.4: Standard Active Directory Object Permissions

Object Permission	Description
Read	Allows the user to view objects and object attributes, the object owner, and Active Directory permissions.
Write	Allows the user to change object attributes.
Create All Child Objects	Allows the user to add any type of child object to an OU.
Delete All Child Objects	Allows the user to remove any type of object from an OU.
Full Control	Allows the user to change permissions and take ownership and to perform all the tasks that are allowed by the above standard permissions.

You can use the Active Directory Users and Computers console to set standard permissions for objects and attributes of objects and you can use the Security tab of the Properties dialog box for the object to assign permissions. In addition, you can either allow permission inheritance to have permissions to propagate from a parent object to child objects or you can prevent permissions inheritance.

4.7.4: Delegating Administrative Control

Active Directory allows you to assign permissions and grant user rights in specific ways. You can assign permissions and grant user rights so as to delegate administrative privileges for certain objects to appropriate individuals in an organization. You can delegate: • Permissions for specific organizational units to different administrators.

• The permissions to modify specific attributes of an object in a single organizational unit.

• The permissions to perform particular tasks in all organizational units of a domain.

4.7.5: Publishing Resources

Publishing resources is the process of creating objects in Active Directory that either directly contain the information that you want to make available, or provide a reference to that information. This will make it easier for users to locate network resources. Resources should be published in Active Directory when the information contained in them is useful to a user or when it must be highly accessible. However, you do not need to publish resources, such as user accounts, that already exist in Active Directory. Though, you must publish resources that do not exist in Active Directory such as printers on a pre-Windows 2000 computer, and shared folders.

The object that is published in the directory is completely separate from the shared resource that it represents. The published object contains a reference to the location of the shared resource. When a user accesses the published object, Windows Server 2003 redirects the user to the shared resource. Therefore, by publishing resources in Active Directory you can allow users to locate resources even if the physical location of the resources changes. Furthermore, because a shared resource and the published object that refers to the shared resource are two different objects, each of these objects has its own discretionary access control list (DACL), which is used to control access to that shared resource. A user requires Read permission on the DACL of a published object to view the published object in the results list when searching for a published resource but may not be able to access the shared resource, depending on the DACL on the shared resource.

4.7.5.1: Setting Up and Managing Published Printers

All printers shared on Windows 2000 or Windows Server 2003-based print servers that are members of either a domain or a domain controller are automatically published in Active Directory. However, you must publish printers that run on pre-Windows 2000 computers by using Active Directory Users and Computers. When you publish a printer, it is the print queue is published, and the object in Active Directory is called a printQueue. You only need to manage printers if you change the default behaviour of the printer.

By default any printer shared on a Windows 2000 and Windows Server 2003 print server that has an account in an Active Directory domain is published in Active Directory. When a print server is removed from the network, its published printers are automatically removed from Active Directory. When you configure or modify a printer's properties, Windows Server 2003 automatically updates the appropriate published printer object's attributes in Active Directory.

Managing printers includes tasks such as moving printers, connecting to printers on the network, and modifying properties of the print queue objects. After you publish printers in Active Directory, user and organization printing needs may change. This change may require you to configure printer settings so that your printing resources better fit these needs.

To organize published printers, you can move related published printers that are installed on multiple computers into a single organizational unit. By moving printers into a single organizational unit, you can perform administrative functions on all of the printers in the organizational unit. To move printers in a domain:

To use a print device the operating system on each computer that must connect to the print server requires a different version of the printer driver that is written for that operating system. Windows 95, Windows 98, Windows ME, Windows NT, Windows 2000, Windows XP Professional and Windows Server 2003 client computers will automatically downloads the appropriate printer driver if a copy of the driver on the print server. To install a driver for a different operating system:

For clients running Windows 3.11 non-Microsoft operating systems, such as Macintosh or UNIX, you must manually install a printer driver on the client computers. You must also install a print service on the print server for these clients.

4.7.5.2: Installing Printer Drivers

To use a print device the operating system on each computer that must connect to the print server requires a different version of the printer driver that is written for that operating system. Windows 95, Windows 98, Windows ME, Windows NT, Windows 2000, Windows XP Professional and Windows Server 2003 client computers will automatically downloads the appropriate printer driver if a copy of the driver on the print server. To install a driver for a different operating system:

For clients running Windows 3.11 non-Microsoft operating systems, such as Macintosh or UNIX, you must manually install a printer driver on the client computers. You must also install a print service on the print server for these clients.

4.7.5.3: Setting Up and Managing Published Shared Folders

You can publish any shared folder that can be accessed by using a UNC name, in Active Directory. A computer running Windows 2000 or Windows Server 2003 can use Active Directory to locate and connect to the shared folder. You can also define keywords and a description for the shared folders in Active Directory and you can move shared folders to related organizational units. You publish shared folders by using Active Directory Users and Computers but you must first share the folder, and then publish the shared folder in Active Directory. To publish a shared folder:

After you publish a shared folder, you can add a description, which can provide more information about the shared folder, and keywords, which are a list of words that you can define for the shared folder object, to make it easier for users to locate the folder. To add a description and keywords to the shared folder objects:

Once a shared folder has been published, you can move the published folder to another container or organizational unit by moving the shared folder object, which contains information or references the shared folder, in Active Directory. The physical location of the shared folder does not change.