|
|
The MMC snap-in tools handle most of the Active Directory management. This section examines how to use these tools to perform the most common Active Directory functions. Excluded is the use of these tools in relation to user, group, and group policy management; that is covered in Chapter 7, "User Accounts and Groups," and Chapter 8, "Group Policies."
Three Active Directory snap-in administrative tools are part of the standard installation; two optional tools are installed separately:
Active Directory Domains and Trusts Manager
Active Directory Sites and Services Manager
Active Directory Users and Group Manager
Active Directory Replication (optional, available from the Resource Kit)
Active Directory Schema Manager (optional, available from adminpak)
The standard tools are obtained from the Start 
Administrative Tools menu and the optional tools are obtained from Start Service Tools (Figure 6.7). They may be added to the MMC by following these steps:
Launch Microsoft Management Console.
Select the Console (you must be in author mode to select this option).
Select Add/Remove Snap-in in the Add/Remove Snap-in dialog, click Add highlight the Active Directory snap-in from the Add Snap-in dialog box click Add.
Repeat this process for each snap-in.
Click Close for the Add Snap-in dialog box click Close for the Add/Remove Snap-in dialog.
These snap-in tools provide support for a wide assortment of Active Directory administrative functions.
The Active Directory Domains and Trusts snap-in provides the system administrator support for the management of trust relationships among domains, trees, and forests. It also provides assistance for managing mixed-mode environments involving Windows Server 2003 and earlier Windows NT/Windows 2000 domains. In this section we will review how to use the Active Directory Domains and Trusts snap-in to perform the following tasks:
Create trust relationships, both transitive two-way and explicit one-way.
Change from mixed to native Windows Server mode.
Add UPN suffixes for alternative user logon.
Assign a Domain Naming Master domain controller.
Delegate domain controller administration.
Windows Server 2003 enhances the scope of forest trust relationships. Microsoft recognized that independent organizations maintain their own IT infrastructures but may need to share information and resources. The new enhancements simplify cross-forest security administration. They also enable the trusting forest to enforce constraints on what security principal names it trusts other forests to authenticate. There are three forms of trust functionality:
Forest trust. This trust type allows all domains in one forest to transitively trust all domains in another forest. This is accomplished through a single trust link between the two forest root domains. Forest trust is not transitive at the forest level across three or more forests. Forest trusts can be one-way or two-way.
Trust management. A new wizard is provided to create all types of trust links and forest trust. A new property page is available to manage the trusted namespaces associated with forest trusts.
Trusted namespaces. Trusted namespaces are used to route authentication and authorization requests for security principals. The domain, UPN, service principal name (SPN), and security identifier SID namespaces are automatically collected when a forest trust is created, and refreshed by the Active Directory Domains and Trust User Interface. A forest is trusted to be authoritative for the namespaces it publishes. In order to avoid collisions, this data is accepted on a first-come basis. Overlapping trusted namespaces are automatically rejected.
NOTE
When Windows Server 2003 is installed, user-based Group Policy and roaming user profiles (RUPs) are not processed when a user is in a different Active Directory forest. This tightening of security denies user-based Group Policy across a forest boundary and cross-forest RUPs.
In order to facilitate cross-forest policy management, a new setting allows Group Policy and RUPs to be processed in this situation. However, this policy must be explicitly enabled. Also added is new Event Log message to inform the administrator that "loopback" processing took place. See Chapter 7 for more information on group policies.
The previous chapter describes the types of trust relationship that can exist in a Windows Server 2003 enterprise. The Active Directory Domains and Trusts MMC snap-in tool is the easiest method for managing these relationships.
The default relationship between domains in the same tree or forest is transitive. Users have access to resources in the same tree or forest, assuming they have access permission to a requested object.
Explicit one-way trusts are created only between otherwise nonrelated forests. The trusting domain permits access to resources by a trusted domain in a one-directional interaction. The one-way trust is limited and does not create a permanent link. Nor does it automatically provide access to other domains in the tree. To extend the one-way relationship to other domains, additional explicit relationships are required.
Two-way (shortcut) transitive trusts are established by following these steps:
Open the Active Directory Domains and Trusts snap-in.
Right-click the domain you want to administer click Properties click the Trusts tab.
Click the Domains trusted by this domain, click Add, type in the targeted domain name, and supply the password information; then select the Domains that trust this domain and follow the same procedure. (For Windows 2000, the domain name is the DNS name for the domain. For earlier Windows NT domains, type the name of that domain.)
If the domain to be added is a Windows Server 2003 domain, type its DNS name. Or, if the domain is running an earlier version of Windows, type the domain name.
Gain Administrative logon to the targeted trust domain and repeat steps 1 through 4.
Explicit one-way domain trusts are created by following these steps (Figure 6.8):
Open the Active Directory Domains and Trusts snap-in.
Right-click the domain you want to administer click Properties click the Trusts tab.
Click Domains trusted by this domain, click Add, and type in the targeted domain name and password information. (For Windows 2000, the domain name is the DNS name for the domain. For earlier Windows NT domains, type the name of that domain.)
Once the process of establishing a trust is completed or during the normal course of auditing a domain, the trust relationship can be verified. To do so, take the following steps:
Open the Active Directory Domains and Trusts MMC snap-in.
Right-click the domain you want to administer click Properties click the Trusts tab.
In either the Domains trusted by this domain or the Domains that trust this domain list, click the trust to be verified, then click Edit.
Click Verify/Reset.
As organizational relationships change, trust relationships between domains may need to be removed. To do this, perform the following steps:
Open the Active Directory Domains and Trusts MMC snap-in.
Right-click the domain you want to administer select Properties click the Trusts tab.
In either the Domains trusted by this domain or the Domains that trust this domain list, click the trust to be revoked, then click Edit.
Click Remove.
Repeat the process for the corresponding trusted domain.
Most enterprises initially operate in a mixed Windows Server 2003/Windows 2000 NT mode. In this case, the Active Directory supports the existing Windows NT BDCs. Remember, these modes impact domain controllers, not downlevel member servers or client systems. When the migration is complete, the Windows Server 2003 Active Directory should be moved to native mode. This task, illustrated in Figure 6.9, is accomplished by the following steps:
Open the Active Directory Domain and Trusts snap-in (the Active Directory Users and Computers snap-in can also perform this task).
Select the domain to be upgraded to native mode, right-click, and select Properties.
On the General tab, select Change Mode and click Yes in the confirming dialog window.
CAUTION
It is impossible to reverse the upgrading of a domain to native mode. If any Windows NT domain controllers exist in the domain, they must be upgraded to Windows 2000 or Server 2003 and the Active Directory in order to be properly recognized.
Alias domain names can be applied to a user account, perhaps to provide a user account with a different identity by shortening long domain or child domain names. The user principal name suffix is the portion of the DNS name that identifies a user's domain of origin. For example, @EntCert.com is the UPN suffix of the e-mail address bob@EntCert.com. For administrative and security reasons, alternative UPN suffixes can also be assigned to a user logon name (the UPN prefix).
To add UPN suffixes (Figure 6.10), follow these steps:
Open the Active Directory Domains and Trusts MMC snap-in.
Right-click Active Directory Domains and Trusts and then click Properties.
From the UPN Suffixes tab, type an additional or alternative UPN for the domain and then click Add.
Repeat the previous step to add more alternative UPN suffixes.
When creating a new user account (as discussed later in this chapter), you can select which of the alternative domain UPN suffixes will be assigned to that user, as shown in Figure 6.11. In this example, three alternatives can be applied to user bob.
In a multidomain controller environment, certain operation management tasks should be delegated to particular domain controller servers. The Active Directory Domains and Trusts snap-in permits the system administrator to identify and change the location of the Domain Naming Master domain controller. The original location of the Domain Naming Master is the root domain controller.
The current location of the Domain Naming Master is identified by the following steps:
Open the Active Directory Domains and Trusts MMC snap-in.
Right-click Active Directory Domains and Trusts and select Operations Masters.
The name of the current Domain Naming Master appears in Domain naming operations master.
The location of the Domain Naming Master is changed from one domain controller to another by following these steps:
Open the Active Directory Domains and Trusts snap-in.
Right-click Active Directory Domains and Trusts, select the Connect to Domain Controller, choose the targeted domain controller, and click OK.
Right-click Active Directory Domains and Trusts, select the Operations Masters, and make sure the targeted domain controller is listed in the second dialog text window. Click Change.
System administrative responsibility can be delegated to specific user groups, but this should be done with great care. Remember, when authority is delegated to a domain controller or the entire domain, the rights to create or demote other domain controllers are vested in other people. Granting such authority might be appropriate when a designated group of IT professionals shares system administration responsibility for the domain. It also makes sense when an administrator needs temporary authority while the primary system administrator is on leave or on vacation.
Authority is delegated to a domain or domain controller (Figure 6.12) as follows:
Open the Active Directory Domains and Trusts MMC snap-in.
Right-click the domain or domain controller and select Properties.
On the Managed By tab, select the name of the group, click Change, and Add the desired user or group.
Click OK to confirm the new setting.
The Active Directory Schema Manager is not loaded as part of the default Active Directory installation. Presumably, Microsoft made it an extra step because schema changes should be treated with great care. If a system administrator who has the knowledge truly needs to make modifications to the schema, he or she must deliberately install this tool. Installation is from the adminpak application suite available on the Windows Server 2003 or higher CD within the I386 folder. The following steps should be followed:
Load the adminpak from the Windows Server 2003 installation CD in the I386 folder, double-click Support, double-click adminpak, select Setup, and follow the instructions for Typical installation.
Launch the Microsoft Management Console, select the Console menu, click Add/Remove Snap-in, and click Add from this dialog box. In the Add Snap-in dialog box, double-click Active Directory Schema and select Close. Click OK.
Active Directory objects represent resources within the network. The most common domain objects include user accounts, groups, printers, computers, domain controllers, organizational units, and shared folders. The Active Directory schema defines the structure, the classes, and the attributes of allowable objects. These definitions can be viewed as the framework of the Active Directory.
Object classes inherit characteristics of parent objects. This creates a ripple effect in that changes can both positively and negatively affect objects down the line. The schema can be extended dynamically to modify and add to the objects stored by the Active Directory. In addition to the Admin group, the Schema Management group is the default system administrator group with full control to make schema changes. Other groups can be added, but with great caution. If the Active Directory schema were inappropriately changed or damaged, your domain could be brought to its knees.
In this section, we will explore how to use the Active Directory Schema snap-in for the following tasks:
Identify and modify object classes.
Identify and change attributes.
Change the Schema Master domain controller.
Ensure schema availability and restoration.
CAUTION
Changes to the Active Directory schema should be made only after full consideration of their impacts. It should be noted that the Schema Master by default cannot accept modifications. Modifications must be enabled manually by checking that the schema may be modified on this server in the Active Directory Schema snap-in's Operations Master dialog. However, while this protects the enterprise from accidental changes, other actions should be taken. If the system administrator makes modifications, the domain controller that functions as the Schema Manager should first be removed from the network. This will allow for recovery if those modifications prove inappropriate or harmful. Alternatively, changes in the schema can be tested in an isolated network environment and moved over for replication only after full testing and troubleshooting are completed.
To view the attributes associated with a schema object class, simply click the targeted class in the Active Directory Schema snap-in Classes. As shown in Figure 6.13, the right pane displays the attributes for classSchema. If you look closely, you will note that both optional and mandatory attributes are identified. That is because all object attributes are either "must have" or "may have." Changing the mandatory setting will significantly impact the class's function and integrity.
To view additional information about a class or to make specific changes, right-click the desired object and select Properties. The Properties dialog box displays four tabs:
General provides the class common name, description, X.500 OID number, and class type. (Most Active Directory default classes have a structural class type, but a few, like country, are of the class type abstract.) The class category is also shown with an option to change a class to one of the other classes available. An option to display classes of the same type and to deactivate the class is provided as well. Obvious caution should be used in making any changes to the schema's structural classes.
Relationships provides information on how a class fits into the class hierarchy. For example, the "group" class is identified as a "top"-level parent class. It lists several auxiliary classes, including mailRecipient, so it is logical to assume that a group member also can receive mail. Other auxiliary classes can be associated with the group class by selecting Add and choosing among listed classes. This tab also lists classes that have a Possible Superior position, such as organizationalUnit, domainDNS, builtinDomain, and container classes. You can use the Add button to select other classes.
Attributes provides a list of both mandatory and optional attributes. While no option can increase or change the mandatory attributes, click Add to add optional attributes, which can be deleted by clicking Remove.
Security provides the list of permissions granted to different groups for each class. By default, Authenticated Users have Read permission for most objects. The Domain Administrator Group and the SYSTEM Group generally have Read, Write, and Full Control. These two groups are also authorized to create and delete child classes for some of the classes. Other groups or specific users can be added to the permissions lists.
In creating or modifying objects, it is necessary to identify their class type. The full-fledged object will be a member of the structural class. The abstract and auxiliary types are used in the formation of the structural type. The Active Directory schema recognizes four types of object class:
Structural class. The structural class is important to the system administrator in that it is the only type from which new Active Directory objects are created. Structural classes are developed from either the modification of an existing structural type or the use of one or more abstract classes.
Abstract class. Abstract classes are so named because they take the form of templates that actually create other templates (abstracts) and structural and auxiliary classes. Think of abstract classes as frameworks for the defining objects.
Auxiliary class. The auxiliary class is a list of attributes. Rather than apply numerous attributes when creating a structural class, it provides a streamlined alternative by applying a combination of attributes with a single include action.
88 class. The 88 class includes object classes defined prior to 1993, when the 1988 X.500 specification was adopted. This type does not use the structural, abstract, and auxiliary definitions, nor is it in common use for the development of objects in Windows Server 2003 environments.
NOTE
Remember that the schema is loaded in the domain controller cache for easy access. To ensure cache consistency, there is a five-minute delay after changes are written to disk until they are moved to the cache. Threads that might have been running prior to the cache rebuild will continue to use the previous definitions. New threads use the definitions associated with the rebuilt cache.
Attributes are defined only once but may be applied to multiple classes. As discussed, the attributes associated with a specific class can be identified through the Class Properties dialog or directly from the Active Directory Schema snap-in.
A list of available attributes is found in the Active Directory Schema snap-in Attributes. The right pane of the MMC lists the attributes alphabetically. By right-clicking any attribute, you can select Properties to learn more about its features and configuration (Figure 6.14). The information provided includes the description, common name, X.500 OID, syntax (such as integer, octet string, text, etc.), and range. Other options are also provided, such as deactivation and indexing within the Active Directory. It is important to note that attributes can never be deleted once they are created. Their use can be prevented only through deactivation.
When a new object class or attribute is created, it becomes a permanent part of the enterprise. It cannot be removed, only disabled. The following steps create a new object class or attribute:
Open the Active Directory Schema snap-in.
Right-click Active Directory Schema right-click either Classes or Attributes select New select Class or Attribute.
In the message box, click Continue (or Cancel to discontinue).
In the supplied dialog box, enter a Common Name, the LDAP Display Name, and a valid OID number, and identify the Parent Class and the Class type click Next.
In the next dialog box, click Add to include Mandatory and Optional attributes.
Click Finish to complete the process.
For the creation of attributes, the process eliminates the need to set the parent class with syntax and appropriate ranges.
NOTE
One of the requirements in creating a new object class or attribute is the use of a valid OID number, which, like DNS numbers and IP addresses, is assigned on a national basis. For example, in the United States an OID number can be requested from the ANSI Web site at http://www.web.ansi.org/public/services/reg_org.html.
NOTE
Whenever possible, adding an attribute to a class is generally cleaner than creating a new class. Remember, classes cannot be removed, only disabled. However, if it is necessary to create a class, much time can be saved by starting with a parent class that provides generic definitions. Attributes can then be added and the new class inherits the characteristics of its parent.
Objects that serve no ongoing purpose should be removed. Windows Server 2003 provides a command called Repadmin that provides the ability to delete lingering objects in the Active Directory. Lingering objects may exist in the Active Directory due to a long unavailability of a domain controller. During this period objects can become "tombstoned" because their lifetimes have expired. By invoking the Repadmin command, inconsistency among replicas of the Active Directory is reduced. In turn, this reduces the growth of the Active Directory database and thereby improves performance.
In a multidomain controller environment, certain operation management tasks should be delegated to different domain controller servers. From the Active Directory Schema snap-in, it is possible to identify and change the location only of the Schema Master manager. The Active Directory Schema snap-in separates the definitions of classes and attributes.
The Schema Master domain controller can be identified by following these steps:
Open the Active Directory Schema MMC snap-in.
Right-click Active Directory Schema and select Operations Masters.
The name of the current Schema Master appears in Domain Schema operations master.
The Schema Master can be moved to another domain controller by the following steps:
Open the Active Directory Schema MMC snap-in.
Right-click Active Directory Schema, select Connect to Domain Controller, choose the targeted domain controller, and click OK.
Right-click Active Directory Schema, select Operations Masters, and make sure the targeted domain controller is listed in the second dialog text window. Click Change.
The Schema Master domain controller must be available to perform modifications or extensions. The Active Directory will not cease functioning if the Schema Master is not available, however, it will remain static until connectivity is achieved. When this occurs, the first action of a system administrator is to check the network and the system health of the domain controller that is serving as the Schema Master. It may be necessary to resize the resources on the Schema Master domain controller to accommodate increases in the number of objects, classes, and attributes being stored. If it becomes necessary to pull the Schema Master domain controller offline, it is highly recommended that its function be transferred to another domain controller.
In the event that the Schema becomes damaged or otherwise corrupted, the restoration of a default schema or a backup version will become necessary. The process of simply reloading the schema from backup is done by opening the Active Directory Schema snap-in right-click Active Directory Schema select Reload Schema.
The Active Directory Sites and Services snap-in tool ensures efficient user logon authentication, the locating of directory services and objects, and more effective control of Active Directory replication. Specifically, it is used to create sites and subnets, move servers between sites, and formulate site links and bridges.
As discussed previously, three Active Directory partitions must be replicated within and between sites. The schema data and configuration data partitions are replicated to all domain controllers in the tree or forest; the domain data partition is replicated solely to domain controllers in the domain. Replication within a site is based on a bidirectional circular topology created automatically by the KCC service. Replication of all three partitions can use the same topology ring if the site supports a single domain. In the event that two or more domains share the site, a topology ring for the schema and configuration partitions is established and separate domain topology rings are created for each domain using the site. The system administrator manually defines intersite replication. Figure 6.15 illustrates the relationship between intrasite and intersite replication.
NOTE
In Windows 2000, the process that automatically created replication connections between domain controllers in different sites was limited. It could not be used when a forest contained a large number of sites. As a result, administrators had to create and maintain manual intersite replication topologies. With Windows Server 2003, the Inter-Site Topology Generator (ISTG) has been updated. An improved algorithm is used to scale forest support. The major trick is that all domain controllers in the forest that run the ISTG role must agree on the intersite replication topology. This new algorithm is not activated until the forest has advanced to a native Windows Server 2003 Active Directory forest functionality level. Once in Windows Server Active Directory native mode, no administrative action is necessary to activate this feature.
The physical structure is created by the KCC based on information provided by using the Active Directory Sites and Services snap-in. Active Directory uses this information to determine how to replicate directory information and handle service requests. As an administrator, you can manually override the topology created by the KCC of the Active Directory. This is particularly true with respect to intersite communication and replication. The basis of intersite communication is the use of site links, which comprise four components.
Cost. The cost is a representation of a path's relative priority. The higher its cost, the lower a path will be regarded in the utilization of a link.
Replication frequency. Where latency is an issue, the interval between replications should be fairly short.
Transport mechanism. Intersite links can use either RPC over TCP/IP or send replicated data as e-mail using SMTP.
Scheduling. When the frequency of replication can be deferred, the administrator can determine off-peak times when replication should be scheduled.
The Active Directory Sites and Services snap-in manages the replication of Active Directory information both within and among sites. The system administrator can balance the timing of Active Directory data synchronization against the availability of network bandwidth and costs associated with remote connectivity. This balance is accomplished by customizing the site link connectivity properties.
When a user logs on or makes an inquiry of the Active Directory, an attempt is first made to contact the domain controllers in that defined site. In most cases, the authentication is resolved by a domain controller on the local site. The local workstation, as part of a subnet, will seek out authentication in that subnet (which is typically a local site). By not having to transmit information to a remote domain controller, network traffic is reduced, so domain controller placement must also be taken into consideration.
This section examines how to use the Active Directory Sites and Services snap-in to perform the following tasks:
Create new sites.
Create site subnets.
Create intersite links.
Establish an intersite replication schedule.
Select an application-licensing server.
Move domain controllers between sites.
Repair a domain controller.
Remove a domain controller from a site.
NOTE
Windows Server 2003 provides the ability to delegate to a group the responsibility to monitor Active Directory replication without the need to provide other administrative rights. Users assigned to this group will not be able to write or read other Active Directory information unless these rights are explicitly added.
NOTE
Site links are required before a domain controller can replicate information outside its own site. They are not automatic but require an explicit action by the system administrator to exchange Active Directory data. As new sites are created, the domain controllers are assigned to the specified site. This is accomplished when a domain controller is assigned a subnet address associated with a specific site. Links must then be established among sites in order to guarantee domain controller replication throughout the domain.
NOTE
When creating links among sites where replication activity is high, consider dedicating a single domain controller to the intersite synchronization. Known as bridgehead servers, these domain controllers accept changes made to the Active Directory in one site and transmit them to other sites. Once this information is posted, internal domain controller synchronization can occur with reduced impact on remote network connections.
The topology of intersite replication spans the entire tree or forest. When all sites can find a replication route, the topology is considered functional. As the system administrator, you can create site links from any domain controller in any site to any other domain controller in any site throughout the enterprise.
The process for creating a new site is very straightforward. Launch the Active Directory Sites and Services snap-in, right-click Sites, and select New Site. In the upper text box, enter the name of the new site and highlight the site container. Click OK. You will receive a confirmation message that the site has been created along with a list of the following tasks that should be carried out:
Make sure that the new site is appropriately linked to other sites.
Add the subnet addresses to the subnet container listed in the snap-in.
Install one or more domain controllers within the site.
Select a licensing server for the site.
Site subnets are created from within the Active Directory Sites and Services snap-in by right-clicking the Subnet menu and then selecting New Subnet. The Subnet dialog box appears, as shown in Figure 6.16. Each site typically gets its own subnet and mask. First highlight the targeted site name from the list provided in the Select a site object for this subnet list box; then insert the network address and subnet mask. Click OK.
By default, the Active Directory Sites and Services snap-in provides transport link options for Internet Protocol and Simple Mail Transport Protocol. To create site links for either or both, right-click either IP or SMTP from within the Active Directory Sites and Services snap-in and select New Site Link. The New Object—New Site Link dialog box appears. To link the sites, simply highlight the site(s) in the first column entitled Sites Not in This Site Link, click Add, and click OK. Repeat this procedure for all sites in which links are desired.
The Active Directory Sites and Services snap-in provides a nice graphical interface to schedule directory data synchronization among sites. From the Active Directory Sites and Services snap-in select the folder of the intersite transport that requires a schedule adjustment right-click the targeted site shown in the details pane and select Properties click Change Schedule in the Schedule for NTDS Sites Settings dialog box (shown in Figure 6.17), make the appropriate schedule changes.
When it is created, the Active Directory creates services for application licensing. For every site, there should be an application-licensing server installed. Unlike many other important services, the licensing server does not have to be a domain controller. However, it must have installed a copy of Windows Server 2003. To move or select the licensing server, follow these steps:
Open the Active Directory Sites and Services snap-in.
Open Sites and select the targeted site.
From the right pane, click Licensing Site Setting to open the Licensing Site Settings Properties dialog box.
Select Change and then choose the server to be the licensing server.
The movement of domain controllers provides more effective load balancing and accommodates change or redundancy in a site. Rather than install additional domain controllers, it is easy to move a domain controller from a site with fewer Active Directory demands. The following procedure should be followed:
Open the Active Directory Sites and Services snap-in.
Open the Sites folder, then domain controller sites, then Servers.
Right-click the destination domain controller and select Move.
Select the new site from the dialog box and click OK.
Periodic backup of Active Directory services (discussed in Chapter 14) should be a regular part of system administration. Of particular interest when backing up a domain controller is System State data, which constitutes the Active Directory, the Sysvol, and the Registry. There are several forms of restoration:
Nonauthoritative. The entire replica of the Active Directory is transferred under a nonauthoritative restore. Assuming that other domain controllers exist, once the replica is installed, the normal replication services will update the system with changes since the last backup. To perform this type of restoration, the server must be restarted in safe mode (press F8 during the reboot to initialize the safe mode). After the files have been restored, a flag is set in the Registry indicating that the Active Directory must be reindexed at the next reboot. When the system is rebooted, it communicates with the Active Directory and is updated with changes.
Authoritative. The authoritative restore permits the tagging of certain database information to prevent its being overwritten during a restoration. This will avoid its inadvertent destruction. When a restoration occurs, the tagged information will not be touched. It will, however, become part of the normal Active Directory database when the system is brought back online. This can apply to a single object, an OU, or an entire domain. To conduct an authoritative restore, the system must be restarted in safe mode. From the command prompt, run the Ntdsutil.exe and type restore subtree OU=name of unit, DC=domain, DC=.com. Insert the appropriate information in the italicized portion of the command. Restart the system once the Ntdsutil has confirmed its completion. The USN must be modified to ensure that it is authoritative. The authoritative information is then replicated to the other domain controllers.
The Ntdsutil command-line utility can be run from the command prompt. Help for the Ntdsutil utility can also be found at the command prompt by typing ntdsutil/?.
Repairing an Active Directory domain controller can be accomplished by forcing a check of the replication.
NOTE
The need to repair a domain controller is not a normal event. Repair should be undertaken only when it is obvious that fundamental Active Directory databases or functions are corrupted.
The domain controller replication check is accomplished by these steps:
Open the Active Directory Sites and Services snap-in.
Open the Sites folder select the folder of the targeted domain controller.
Right-click NTDS Setting select All Tasks select Replication Check.
Select the specific items to be repaired click OK.
A domain controller may need to be removed from a given site periodically for a variety of reasons. This can be done by following these steps:
Open the Active Directory Sites and Services snap-in.
Open the Sites folder select the folder of the site of the targeted domain controller.
Open the Server folder right-click the targeted domain controller.
Move to the Action menu click Delete, and confirm with OK.
NOTE
If this is the only domain controller in the domain, be sure to promote another member server prior to removing the Active Directory. If this is not done, all information will be lost and users will not be able to log on to the network.
The Active Directory Users and Computers snap-in is possibly the most important and most used system administrative tool. It supports the ability to add, modify, delete, and organize users, computer accounts, security groups, distribution groups, and resource publications. Because of the importance of user administration and group policies, we have broken their treatment into other chapters: Chapter 7, "Users and Groups"; Chapter 8, "Group Policies"; and Chapter 9, "Files and Objects Permissions."
This section examines how to use the Active Directory Users and Computers snap-in to perform the following administrative tasks:
Computer Account Management
Add computer accounts
Remove computer accounts
Locate computer accounts
Move computer accounts
- Save queries
- Edit multiple user objects
Management of local computer accounts
RID, PDC, and Infrastructure Master management
The Active Directory Users and Computers snap-in facilitates the addition, removal, location, movement, and management of computers in the domain and the tree. Remember that a computer account must be created in the Active Directory before a new computer can join the domain. This is generally before Windows Server 2003 is installed.
Computer systems are treated as objects within the Active Directory, much like user accounts. To identify a computer account or change components, use the Active Directory Users and Computers snap-in select Computers highlight the desired computer right-click Properties. From this dialog box, you can navigate to find the identification of the computer's general attributes such as names and role, installed operating system, group and domain membership, physical location, and system management data (Figure 6.18). As the next section suggests, the Active Directory can track even those computer accounts that are not based on the Windows Server 2003 operating system.
Adding a computer account to the Active Directory is required before member computers and servers can join the domain. This is an easy and straightforward process, as follows:
Open the Active Directory Users and Computers snap-in.
Open the targeted domain Computers (or OU folder).
Right-click Computers select New Computers.
Enter the computer's name, (optionally) change user groups authorized to use this computer account, check the box if computers running systems earlier than Windows Server 2003 are to use this account click OK.
When systems are taken out of service, they should be removed from the Active Directory. Consider this merely a housekeeping activity. To remove computer accounts, follow these steps:
Open the Active Directory Users and Computers snap-in.
Open the targeted Domain Computers (or OU folder).
From the right pane, right-click the targeted Computer select Delete.
Confirm Yes to remove this object.
To perform any function on a computer account, the account must first be located. Manual identification within a very large enterprise can be time consuming, but an alternative method is as follows:
Open the Active Directory Users and Computers snap-in.
Right-click the Domain select Find.
Enter the appropriate information in the dialog box.
Click Find Now.
As organizations change or IT requirements shift, the computer account should be transferred to the appropriate domain or organizational unit as follows:
Open the Active Directory Users and Computers snap-in.
Open the targeted Domain Computers (or OU folder).
From the right pane, right-click the targeted Computer and select Move.
In the Move dialog box, highlight the targeted container click Enter.
From within the Active Directory Users and Computers snap-in, it is possible to launch the Computer Management MMC applications for the listed computer systems (Figure 6.19). The method is outlined as follows:
Open the Active Directory Users and Computers snap-in.
Open the targeted Domain Computers (or OU folder).
From the right panel, right-click the targeted Computer select Manage.
The Computer Management MMC appears.
A query is a search against a data set (the directory) for items that match particular criteria. A feature new to Windows Server 2003 allows queries to be saved, reopened, refreshed, and e-mailed. Query objects and results can be viewed and manipulated in the user interface. Administrators can retrieve and reuse these queries. This feature is available by opening the Active Directory Users and Computers snap-in. When prompted whether you wish to save the query, click Yes.
With Windows Server 2003, editing user objects is greatly streamlined. This feature allows selection of multiple user objects. The administrator can then bring up a set of property sheets and clear or set object attributes across all the selected objects. Although only specific property sheets and attributes will be available for editing multiple objects this way, it should reduce the sometimes painful task of user account management. This feature is available by opening the Active Directory Users and Computers snap-in, where you can choose Edit Multiple Objects.
Three of the domain operations masters are managed from the Active Directory User and Computers snap-in. The RID Master establishes object IDs with numbers relative to a specific domain; the PDC operations master manages the PDC Emulator functions; and the Infrastructure Master manages group and user references. From the Active Directory Users and Computers snap-in, it is possible to identify and change the location of the RID, PDC, and Infrastructure Master managers. Their original location is the root domain controller.
In larger enterprises with many domain controllers, it may not be obvious which one is serving as the RID, PDC, or Infrastructure Master. To find this out, use the steps that follow:
Open the Active Directory Users and Computers MMC snap-in.
Right-click Active Users and Computers, then select Operations Masters.
The name of the master appears in the respective Domain Master tab.
When an operations manager is taken offline, another domain controller must be promoted to perform this function. The promotion must be accomplished before the older domain controller is taken offline. Promotion of a domain controller to a RID, PDC, or Infrastructure Master is accomplished as follows:
Open the Active Directory Users and Computers MMC snap-in.
Right-click Active Users and Computers, select the Connect to Domain Controller, and choose the targeted domain controller. Click OK.
Right-click Active Users and Computers, select Operations Masters, and make sure the targeted domain controller is listed in the second dialog text window click Change.
The Active Directory Replication Monitor is not loaded as part of the default installation but as part of the Windows Server 2003 Resource Kit located on the Windows Server 2003 or higher CD in the /support/tools folder. This tool does exactly what its name implies—monitor Active Directory replication—and can be very useful. It is used specifically to view replication topologies, identify replication partners, and map transitive replication partners.
|
|
|
| Top |