Active Directory

Active Directory is the directory service used in Windows 2000 Server and is the foundation of Windows 2000 distributed networks.

  • Checklists
  • New ways to do familiar tasks
  • Best practices
  • How to...
  • Concepts
  • Troubleshooting


Checklists

  • Checklist: Installing a domain controller
  • Checklist: Adding a member to a group
  • Checklist: Creating a group
  • Checklist: Upgrading a group
  • Checklist: Configuring a site
  • Checklist: Optimizing inter-site replication
  • Checklist: Before extending the schema


Checklist: Installing a domain controller

Step | Reference
Review key concepts about Active Directory. | Active Directory overview
Review role of a domain controller. | Domain controllers
Review concepts about installing domain controllers when you require multiple domains. | Understanding domain trees and forests
Review how directory data is replicated between domain controllers. | How replication works
Review the information about using pre-Windows 2000 compatible security levels. | Promoting domain controllers
Review concepts of the Domain Name System (DNS). | What is DNS?
Review concepts of how Active Directory is integrated with DNS. | Integration with DNS
Identify your DNS namespace. If your network requires a presence on the Internet, verify that you have a registered Internet domain name. | Namespace planning for DNS
Verify that the computer has a Windows 2000 NTFS partition. | Checklist: Adding a new disk
Verify that the TCP/IP protocol is correctly installed on the computer. | Checklist: Installing and configuring TCP/IP
Verify that a DNS server is available on the network. If not, you can either install the Windows 2000 DNS service on a separate Windows 2000 computer or the Active Directory Installation wizard will install and configure the DNS service on the domain controller computer. | Understanding DNS integration; Checklist: Deploying DNS for Active Directory
Install the domain controller. | Install a domain controller


Checklist: Adding a member to a group

Step Reference
Before adding members to a group, review principal concepts about group membership, how the user logon process is affected by security and distribution groups, and how to use builtin groups. Groups
Group types
Builtin and predefined groups
Use the appropriate administrative tool to add the member to the group:
  • To add a member to a local workstation or member server group, use Local Users and Groups in the Computer Management snap-in.
  • To add a member to a domain, global, or universal group in a Windows 2000 domain, use Active Directory Users and Computers.


Checklist: Creating a group

Step | Reference
Before creating a new group, review principal concepts about group types and working with groups. Groups
Group types
Understanding Groups
Identify which type of group (security or distribution) you want to create. | Understanding Groups
Identify which scope (domain local, global, or universal) you want to create for the group. | Understanding Groups
Use the appropriate administrative tool to create the group:
  • To create a group on a workstation or member server, use Local Users and Groups in the Computer Management snap-in.
  • To create a group in a Windows 2000 domain, use Active Directory Users and Computers.


Checklist: Upgrading a group

Step | Reference
Before upgrading a Windows NT 4.0 domain controller, stand-alone server, or workstation, review principal group concepts. | Groups
Review information about universal, global, and domain local scope. | Converting groups to Windows 2000 Group scope
Review information about groups on workstations and stand-alone servers. | Domain modes and groups Groups on Windows 2000 Professional and stand-alone servers
Review information about builtin and predefined groups. | Builtin and predefined groups


Checklist: Configuring a site

Step | Reference
Create a new site. | To create a site
Associate a subnet with a site. | To associate a subnet with a site
Connect the site. | To create a site link; To add a site to a site link
Select another licensing computer. | To select another licensing computer
Customize replication. | Checklist: Optimizing inter-site replication


Checklist: Optimizing inter-site replication

Step | Reference
Create site links. | To create a site link
Configure site link cost. | To configure site link cost; To configure site link replication availability
Bridge all site links or create site link bridges. | To bridge all site links; To create a site link bridge
Install SMTP on all domain controllers that will replicate using SMTP. | Add/Remove Programs overview
Install an enterprise certification authority if any of your site links will use SMTP. | Installing and configuring a certification authority


Checklist: Before extending the schema

Step | Reference
Carefully plan the changes you want to make. | The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/)
Verify that these changes are really necessary. | When to extend the schema
Fully understand the issues involved in extending the schema. | Issues in extending the schema
Fully understand how these new objects and attributes will be managed. | Issues in extending the schema
Determine the proper names for any new schema objects. | Schema object names
Obtain a valid object identifier for each new schema object. | Obtaining valid object identifiers
Understand single master operations. | Single master operations
Join the Schema Admins group. | Add a member to the Schema Admins group
Install the Active Directory Schema snap-in. | Install the Active Directory Schema snap-in
Locate the current schema master. | Identify the schema master
Enable schema modifications on that computer. | Enable this computer to extend the schema
Verify that any previous schema changes have been fully replicated to all domain controllers. | Active Directory support tools
If possible, when testing unproven schema changes, test them in a separate test forest. |
Review the information about extending the schema. | Extending the schema; The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/)


New ways to do familiar tasks

The following table lists common tasks performed using the Active Directory administrative tools and shows you how to use them in Windows 2000. For users of earlier versions of Windows NT Server, the table also shows where these tasks are performed when using the management tools provided with Windows NT Server 4.0.

If you want to | In Windows NT 4.0 use | In Windows 2000 use
Install a domain controller | Windows setup | Active Directory Installation wizard For more information, see To install a domain controller.
Manage user accounts | User Manager | Active Directory Users and Computers For more information, see Manage user accounts.
Manage groups | User Manager | Active Directory Users and Computers For more information, see Manage groups.
Manage computer accounts | Server Manager | Active Directory Users and Computers For more information, see Manage computer accounts.
Add a computer to a domain | Server Manager | Active Directory Users and Computers For more information, see Manage computer accounts.
Create or manage trust relationships | User Manager | Active Directory Domains and Trusts For more information, see Active Directory Domains and Trusts.
Manage account policy | User Manager | Active Directory Users and Computers For more information, see Account Policies
Manage user rights | User Manager | Active Directory Users and Computers Edit the Group Policy object for the domain or organizational unit containing the computers to which the user rights apply. For more information see, Work with Group Policy objects
Manage audit policy | User Manager | Active Directory Users and Computers Edit the Group Policy object assigned to the Domain Controllers organizational unit. For more information see, Work with Group Policy objects


Best practices

  • Do not log on with administrative rights. Log on as a normal user and use the Run as command when performing administrative tasks.

    Using the Run as command, you can run administrative tools with administrative rights and permissions while logged on as a normal user. You can also build shortcuts to run tools with administrative rights.

    • For more information, see:

    • Why you should not run your computer as an administrator
    • Use Run as to start a program as an administrator
    • Create a shortcut using Run as command parameters

    For details about the Run as command, see Runas.

  • Every geographic area that requires fast access to the latest directory information should be established as a site.

    Establishing areas that require immediate access to up-to-date Active Directory information as separate sites will provide the resources required to meet your needs.

    For more information, see To create a site.

  • Place at least one domain controller in every site, and make at least one domain controller in each site a global catalog.

    Sites that do not have their own domain controllers and at least one global catalog are dependent on other sites for directory information and are less efficient.

    For more information, see To enable or disable a global catalog.

  • Make all site links transitive and ignore schedules for replication.

    Transitive site links maximize available connections between sites and the times the connections can be used.

    For more information, see To ignore schedules.

  • Establish a preferred bridgehead server if you are using a firewall or if you want to dedicate a computer to inter-site replication.

    A bridgehead server serves as a proxy for communications with other sites outside of a firewall.

    All sites must be associated with at least one subnet and in at least one site link, or they will not be usable.

    For more information, see:

    • To associate a subnet with a site
    • To add a site to a site link


How to...

  • Manage domain controllers
  • Manage user accounts
  • Manage computer accounts
  • Manage groups
  • Manage organizational units
  • Manage published resources
  • Manage domains and trusts
  • Configure server settings
  • Configure site settings
  • Configure replication
  • Manage the schema


Manage Domain Controllers

  • Install a domain controller
  • Demote a domain controller
  • Find a domain controller
  • Manage a different domain
  • Manage the domain using a different domain controller
  • Delegate control
  • Modify domain controller properties
  • Manage single master operations


Install a domain controller

To install a domain controller

  1. Click Start, point to Programs, point to Administrative Tools, and then click Configure Your Server.
  2. Click Active Directory, and click Start to start the Active Directory Installation wizard.
  3. Follow the instructions in the Active Directory Installation wizard.

Notes

  • To open the Active Directory Installation wizard, click Start, click Run, and then type dcpromo.
  • This procedure cannot be performed on Windows Professional, since a Windows Professional computer cannot be a domain controller. The Configure Your Server menu option and the dcpromo command are not available on a Windows Professional computer.
  • When installing a domain controller, you must decide whether or not to implement pre-Windows 2000 compatible security. For more information, see Promoting domain controllers.
  • Before using the Active Directory Installation wizard:
    • Review Checklist: Installing a domain controller.
    • Obtain the network credentials needed to create a domain. These credentials are the logon name of a user account, the account password, and domain name. The user account must have sufficient administrative privileges to create a domain controller.
    • Decide which type of domain controller you want to create: either Additional domain controller for an existing domain or Domain controller for a new domain.

      If you are creating a domain controller for a new domain, decide whether the domain will be the first domain in a new forest, the first domain in a new domain tree in an existing forest, or a child domain in an existing domain tree. For more information about domains, domain trees and forests, see Related Topics.

  • Identify the DNS name of the domain

Related Topics


Demote a domain controller

To demote a domain controller

  1. On an existing domain controller, click Start, and then click Run.
  2. In Open, type dcpromo.
  3. Follow the instructions in the Active Directory Installation wizard.

Notes

  • If this domain controller is a global catalog, make sure that another global catalog is available to users before demoting it. For information about configuring domain controllers to host the global catalog, see Related Topics.
  • If this domain controller currently owns one or more operations master roles, transfer the operations master roles to another domain controller before demoting it. For information about locating operations masters and transferring operations master roles, see Related Topics.
  • If this domain has child domains, it cannot be deleted. If this domain controller is the last domain controller in the domain, demoting this domain controller will remove this domain from the forest. If this is the last domain in the forest, demoting this domain controller will also delete the forest.

Related Topics


Find a domain controller

To find a domain controller

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click any node or folder, and then click Find.
  3. In Find, click Computers and in Role, click Domain Controller.

  4. If you know which folder contains the domain controller, in In, click the folder.

    Or, to search the entire directory, in In, click Entire Directory.

  5. Click Find Now.

Notes

  • Use the Advanced tab for more powerful search options.
  • To find a computer, you can also click the find objects button on the toolbar.

Related Topics


Manage a different domain

To manage a different domain

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the Active Directory Users and Computers node, and then click Connect to Domain.

  3. Type the domain name.

    Or, click Browse, and then select the domain from the list.

Notes

  • You must have the correct permissions to manage the domain you select.
  • Use Run as to use Active Directory administrative tools with appropriate permissions. For more information, see Related Topics.

Related Topics


Manage the domain using a different domain controller

To manage the domain using a different domain controller

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the Active Directory Users and Computers node, and then click Connect to Domain Controller.

  3. Click on a domain controller in the list.

    Or, in Change to, type the name of the domain controller.

Notes

  • By default, domain controllers are installed in the Domain Controllers folder when they are first configured.

Related Topics


Delegate control

To delegate control

  1. Open Active Directory Users and Computers
  2. In the console tree, double-click the domain node.
  3. In the console tree, right-click the folder that you want another user or group to control.
  4. Click Delegate control to start the Delegation of Control wizard.
  5. Follow the instructions in the Delegation of Control wizard.

Notes

  • You can delegate administrative control of a particular domain or organizational unit to individual administrators responsible for only that domain or organizational unit. For more information, see Related Topics.

Related Topics


Modify domain controller properties

To modify domain controller properties

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. In the console tree, click the folder containing the domain controller.
  4. In the details pane, right-click the domain controller that you want to modify, and then click Properties.

    The following property tabs display:

    • General
    • Operating System
    • Member Of
    • Location
    • Managed By
  5. Click the property tab that contains the property you want to modify.

Notes

  • By default, domain controllers are installed in the Domain Controllers folder.
  • Some properties are automatically assigned when the computer joins the domain or whenever it is started. These properties cannot be modified by the administrator (for example, Name, Role, and Operating System).
  • If you are viewing advanced features, you will see additional property tabs.

Related Topics


Manage single master operations

  • Identify the relative ID master
  • Identify the PDC emulator
  • Identify the infrastructure master
  • Identify the domain naming master
  • Identify the schema master
  • Transfer the relative ID master role
  • Transfer the PDC emulator role
  • Transfer the infrastructure master role
  • Transfer the domain naming master role
  • Transfer the schema master role
  • Seize the relative ID master role
  • Seize the PDC emulator role
  • Seize the infrastructure master role
  • Seize the domain naming master role
  • Seize the schema master role


Identify the relative ID master

To identify the relative ID master

  1. Open Active Directory Users and Computers.
  2. Right-click the Active Directory Users and Computers node and click Operations Masters.
  3. On the RID tab, the name of the current relative ID master appears in Operations master.

Notes

  • Every domain has a relative ID master. To identify the relative ID master in a different domain, target the appropriate domain before clicking Operations Masters.

Related Topics


Identify the PDC emulator

To identify the PDC emulator

  1. Open Active Directory Users and Computers.
  2. Right-click Active Directory Users and Computers and click Operations Masters.
  3. On the PDC tab, the name of the current PDC emulator appears in Operations master.

Notes

  • Every domain has a PDC emulator. To identify the PDC emulator in a different domain, target the appropriate domain before clicking Operations Masters.

Related Topics


Identify the infrastructure master

To identify the infrastructure master

  1. Open Active Directory Users and Computers.
  2. Right-click Active Directory Users and Computers, and then click Operations Masters.
  3. On the Infrastructure tab, the name of the current infrastructure master appears in Operations master.

Notes

  • Every domain has an infrastructure master. To identify the infrastructure master in a different domain, target the appropriate domain before clicking Operations Masters.

Related Topics


Identify the domain naming master

To identify the domain naming master

  1. Open Active Directory Domains and Trusts.
  2. Right-click Active Directory Domains and Trusts and click Operations Masters.
  3. The name of the current domain naming master appears in Domain naming operations master.

Notes

  • Every forest has only one domain naming master. To identify the domain naming master in a different forest, target the appropriate forest before clicking Operations Masters.

Related Topics


Identify the schema master

To identify the schema master

  1. Open Active Directory Schema.
  2. In the console tree, right-click Active Directory Schema and then click Operations Master.
  3. The name of the current domain naming master appears in Current Operations Master.

Notes

  • If Active Directory Schema is not available, you must install the Windows 2000 Administration Tools from the Windows 2000 Server compact disc and add it to an MMC console. For more information, see Related Topics.
  • Every forest has only one schema master. To identify the schema master in a different forest, target the appropriate forest before clicking Operations Masters.

Related Topics


Transfer the relative ID master role

To transfer the relative ID master role

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the domain controller node that will become the new relative ID master, and then click Connect to Domain.
  3. Type the domain name or click Browse and select the domain from the list.
  4. In the console tree, right-click Active Directory Users and Computers, and then click Operations Masters.
  5. Click the RID tab, and then click Change.

Note

Related Topics


Transfer the PDC emulator role

To transfer the PDC emulator role

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the domain controller node that will become the new PDC emulator master, and then click Connect to Domain.
  3. Type the domain name or click Browse and select the domain from the list.
  4. In the console tree, right-click Active Directory Users and Computers, and then click Operations Masters.
  5. On the PDC tab, click Change.

Note

Related Topics


Transfer the infrastructure master role

To transfer the infrastructure master role

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the domain controller node that will become the new infrastructure master, and then click Connect to Domain.
  3. Type the domain name or click Browse and select the domain from the list.
  4. In the console tree, right-click Active Directory Users and Computers, and then click Operations Masters.
  5. On the Infrastructure tab, click Change.

Note

Related Topics


Transfer the domain naming master role

To transfer the domain naming master role

  1. Open Active Directory Domains and Trusts.
  2. In the console tree, right-click the domain controller node that will become the new domain naming master, and then click Connect to Domain.
  3. Type the domain name or click Browse and select the domain from the list.
  4. In the console tree, right-click Active Directory Domains and Trusts, and then click Operations Master.
  5. Click Change.

Note

Related Topics


Transfer the schema master role

To transfer the schema master role

  1. Open Active Directory Schema.
  2. In the console tree, right-click Active Directory Schema and then click Change Domain Controller.
  3. Click Any DC to let Active Directory select the new schema operations master.
    Or, click Specify Nameand type the name of the new schema master computer.
  4. In the console tree, right-click Active Directory Schema, and then click Operations Master.
  5. Click Change.

Note

  • If Active Directory Schema is not available, you must install the Windows 2000 Administration Tools from the Windows 2000 Server compact disc and add it to an MMC console. For more information, see Related Topics.

Related Topics


Seize the relative ID master role

To seize the relative ID master role

  1. Click Start, click Run, and then type cmd.
  2. At the command prompt, type ntdsutil.
  3. At the ntdsutil prompt, type roles.
  4. At the fsmo maintenance prompt, type connections.
  5. At the server connections prompt, type connect to server, followed by the fully qualified domain name.
  6. At the server connections prompt, type quit.
  7. At the fsmo maintenance prompt, type seize RID master.
  8. At the fsmo maintenance prompt, type quit.
  9. At the ntdsutil prompt, type quit.

Caution

  • Seizing the relative ID master is a drastic step that should be considered only if the current operations master will never be available again.

Note

  • Before seizing the relative ID master, use Repadmin, in the Active Directory support tools, to verify whether the new operations master has received any updates performed by the previous role holder, and then remove the current operations master from the network. For more information about single master operations, and the Active Directory support tools, see Related Topics.

Related Topics


Seize the PDC emulator role

To seize the PDC emulator role

  1. Click Start, click Run, and then type cmd.
  2. At the command prompt, type ntdsutil.
  3. At the ntdsutil prompt, type roles.
  4. At the fsmo maintenance prompt, type connections.
  5. At the server connections prompt, type connect to server, followed by the fully qualified domain name.
  6. At the server connections prompt, type quit.
  7. At the fsmo maintenance prompt, type seize PDC.
  8. At the fsmo maintenance prompt, type quit.
  9. At the ntdsutil prompt, type quit.

Notes

  • Before seizing the PDC emulator master, remove the current operations master from the network and verify that the new operations master is up to date.
  • When the original PDC emulator master is returned to service, you can return the role to the original domain controller. For more information about single master operations, see Related Topics.

Related Topics


Seize the infrastructure master role

To seize the infrastructure master role

  1. Click Start, click Run, and then type cmd.
  2. At the command prompt, type ntdsutil.
  3. At the ntdsutil prompt, type roles.
  4. At the fsmo maintenance prompt, type connections.
  5. At the server connections prompt, type connect to server, followed by the fully qualified domain name.
  6. At the server connections prompt, type quit.
  7. At the fsmo maintenance prompt, type seize infrastructure master.
  8. At the fsmo maintenance prompt, type quit.
  9. At the ntdsutil prompt, type quit.

Notes

  • Before seizing the infrastructure master, remove the current operations master from the network and verify that the new operations master is up to date.
  • When the original infrastructure master is returned to service, you can transfer the role back to the original domain controller. For more information about single master operations, see Related Topics.

Related Topics


Seize the domain naming master role

To seize the domain naming master role

  1. Click Start, click Run, and then type cmd.
  2. At the command prompt, type ntdsutil.
  3. At the ntdsutil prompt, type roles.
  4. At the fsmo maintenance prompt, type connections.
  5. At the server connections prompt, type connect to server, followed by the fully qualified domain name.
  6. At the server connections prompt, type quit.
  7. At the fsmo maintenance prompt, type seize domain naming master.
  8. At the fsmo maintenance prompt, type quit.
  9. At the ntdsutil prompt, type quit.

Caution

  • Seizing the domain naming master is a drastic step that should be considered only if the current operations master will never be available again.

Note

  • Before seizing the domain naming master, remove the current operations master from the network and verify that the new operations master is up to date. For more information about single master operations, see Related Topics.

Related Topics


Seize the schema master role

To seize the schema master role

  1. Click Start, click Run, and then type cmd.
  2. At the command prompt, type ntdsutil.
  3. At the ntdsutil prompt, type roles.
  4. At the fsmo maintenance prompt, type connections.
  5. At the server connections prompt, type connect to server, followed by the fully qualified domain name.
  6. At the server connections prompt, type quit.
  7. At the fsmo maintenance prompt, type seize schema master.
  8. At the fsmo maintenance prompt, type quit.
  9. At the ntdsutil prompt, type quit.

Caution

  • Seizing the schema master is a drastic step that should be considered only if the current operations master will never be available again.

Note

  • Before seizing the schema master, remove the current operations master from the network and verify that the copy of the schema on the new operations master is up to date with the rest of the domain controllers in the forest. For more information about single master operations, see Related Topics.

Related Topics


Manage user accounts

  • Add a user account
  • Copy a user account
  • Disable a user account
  • Enable a disabled user account
  • Delete a user account
  • Find a user account
  • Find a contact
  • Modify user account properties
  • Move a user account
  • Rename a user account
  • Reset a user password
  • Change a user's primary group


Add a user account

To add a user account

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. In the details pane, right-click the organizational unit where you want to add the user, point to New, and then click User.
  4. In First name, type the user's first name.
  5. In Initials, type the user's initials.
  6. In Last name, type the user's last name.
  7. Modify Full name as desired.
  8. In User logon name, type the name that the user will log on with and, from the drop-down list, click the UPN suffix that must be appended to the user logon name (following the @ symbol).

    If the user will use a different name to log on from computers running Windows NT, Windows 98, or Windows 95, change the user logon name as it appears in User logon name (pre-Windows 2000) to the different name.

  9. In Password and Confirm password, type the user's password.
  10. Select the appropriate password options.

Notes

  • To add a user, you can also click Create new user button on the toolbar.
  • After creating the user account, edit the user account properties to enter additional user account information.
  • To add a user, you can also copy any previously created user account. For more information, see Related Topics.
  • A new user account with the same name as a previously deleted user account does not automatically assume the permissions and memberships of the previously deleted account because the security descriptor for each account is unique. To duplicate a deleted user account, all permissions and memberships must be manually recreated.

Related Topics


Copy a user account

To copy a user account

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Users

    Or, click the folder that contains the desired user account.

  3. In the details pane, right-click the user account that you want to copy, and then click Copy.
  4. In First name, type the user's first name.
  5. In Last name, type the user's last name.
  6. Modify Full name to add initials or reverse order of first and last names.
  7. In User logon name, type the name that the user will log on with and, from the list, click the UPN suffix that must be appended to the user logon name (following the @ symbol).

    If the user will use a different name to log on from computers running Windows NT, Windows 98, or Windows 95, change the user logon name as it appears in User logon name (pre-Windows 2000) to the different name.

  8. In Password and Confirm password, type the user's password.
  9. Select the appropriate password options.
  10. If the user account from which the new user account was copied was disabled, click Account is disabled to enable the new account.

Notes

  • After creating the user account, edit the user account properties to enter additional user account information.

Related Topics


Disable a user account

To disable a user account

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Users

    Or, click the folder that contains the desired user account.

  3. In the details pane, right-click the user.
  4. Click Disable Account.

Notes

  • User accounts can be disabled as a security measure to prevent a particular user from logging on, rather than deleting the user account.
  • By creating disabled user accounts with common group memberships, disabled user accounts can be used as account templates to simplify user account creation. For more information, see Related Topics.

Related Topics


Enable a disabled user account

To enable a disabled user account

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Users

    Or, click the folder that contains the desired user account.

  3. In the details pane, right-click the user, and then click Enable Account.

Note

Related Topics


Delete a user account

To delete a user account

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Users

    Or, click the folder that contains the user account.

  3. Right-click the user account, and then click Delete.

Notes

  • Once a user account has been deleted, all permissions and memberships associated with that user account are deleted. Because the security descriptor for each account is unique, a new user account with the same name as a previously deleted user account does not automatically assume the permissions and memberships of the previously deleted account. To duplicate a deleted user account, all permissions and memberships must be manually recreated.

Related Topics


Find a user account

To find a user account

  1. Open Active Directory Users and Computers.
  2. If you want to search the entire domain, in the console tree, right-click the domain node, and then click Find.

    Or, if you know which organizational unit the user is in, in the console tree, right-click the organizational unit, and then click Find.

  3. In Name, type the name of the user you want to find.
  4. Click Find Now.

Notes

  • Use the Advanced tab for more powerful search options.
  • To find a user, you can also click the find objects button on the toolbar.

Related Topics


Find a contact

To find a contact

  1. Open Active Directory Users and Computers.
  2. If you want to search the entire domain, in the console tree, right-click the domain node, and then click Find.

    Or, if you know which organizational unit the contact is in, in the console tree, right-click the organizational unit, and then click Find.

  3. On the Users, Contacts, and Groups tab, in Name, type the name of the contact you want to find.
  4. Click Find Now.

Notes

  • Use the Advanced tab for more powerful search options.
  • To find a contact, you can also click the find objects button on the toolbar.

Related Topics


Modify user account properties

To modify user account properties

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Users

    Or, click the folder that contains the desired user account.

  3. Right-click the user account, and then click Properties.

Note

Related Topics


Move a user account

To move a user account

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Users

    Or, click the folder that contains the desired user account.

  3. In the details pane, right-click the user you want to move, and then click Move.
  4. In the Move dialog box, click the folder to which you want to move the user account.

Notes

  • Active Directory Users and Computers cannot move user accounts between domains. To move a user account between domains use Movetree, one of the Active Directory support tools. For more information, see Related Topics.

Related Topics


Rename a user account

To rename a user account

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Users

    Or, click the container that contains the desired user account.

  3. In the details pane, right-click the user account, and then click Rename.
  4. Type the new name.

    Or, press DELETE, and then press ENTER to display the Rename User dialog box.

  5. In Rename User, in Name, type the user name.
  6. In First name, type the user's first name.
  7. In Last name, type the user's last name.
  8. In Display name, type the name used to identify the user.
  9. In User logon name, type the name that the user will log on with and, from the drop-down list, click the UPN suffix that must be appended to this name (following the @ symbol).

    If the user will use a different name to log on from computers running Windows NT, Windows 98, or Windows 95, type the different name in Pre-Windows 2000 logon name.

Note

Related Topics


Reset a user password

To reset a user password

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Users

    Or, click the folder that contains the desired user account.

  3. In the details pane, right-click the user whose password you want to reset, and then click Reset Password.
  4. Type and confirm the password.
  5. If you want to require the user to change this password at the next logon process, select the User must change password at next logon check box.

Notes

  • Any services that are authenticated with a user account must be reset if the password for the service's user account is changed.

Related Topics


Change a user's primary group

To change a user's primary group

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node, and then click Users.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Users

    Or, click the folder that contains the user account.

  3. In the details pane, right-click the user you want change, and then click Properties.
  4. On the Member of tab, click the group that you want to set as the user's primary group, and then click Set Primary Group.

Notes

  • The user's primary group applies only to users who log on to the network through Services for Macintosh or to users who run POSIX-compliant applications. Unless you are using these services there is no need to change the primary group from Domain Users, which is the default value.
  • Setting the user's primary group membership to a value other than Domain Users may adversely impact performance as all users in the domain are members of Domain Users. If the user's primary group is set to another group, it may cause the group membership to exceed the supported maximum number of members.

Related Topics


Manage computer accounts

  • Add a computer account
  • Add a computer account to a group
  • Delete a computer account
  • Find a computer account
  • Manage a computer
  • Modify computer account properties
  • Move a computer account
  • Reset a computer account
  • Disable a computer account
  • Enable a computer account
  • Allow a computer to use a different DNS name


Add a computer account

To add a computer account

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Computers.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Computers

    Or, click the container in which you want to add the computer.

  3. Right-click Computers or the container in which you want to add the computer, point to New, and then click Computer.
  4. Type the computer name.

Important

  • The Default Domain Policy settings enable only members of the group Domain Admins to add a computer account to a domain. Click Change to specify a different user or group that can add this computer to the domain.

Notes

  • To view or change the full computer name of a computer and the domain that a computer belongs to, on the desktop, right-click My Computer, click Properties, and then click the Network Identification tab.
  • There are two additional ways to give a user or group permission to add a computer to the domain: use a Group Policy object to assign the right Add computer user, or, for the organizational unit in which you want to allow them to create computer objects, assign the user or group the permission Create computer objects.

Related Topics


Add a computer account to a group

To add a computer account to a group

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Computers.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Computers

    Or, click the folder in which the computer is located.

  3. In the details pane, right-click the computer, and then click Properties.
  4. On the Member Of tab, click Add.
  5. Click the group to which you want to add the computer, and then click Add.

    Or, to add the computer to more than one group, press CTRL and click the groups to which you want to add the computer, and then click Add.

Notes

  • To add a computer to a group, you can also click the computer you want to add, click Add to group button on the toolbar, and then click the group to which you want to add the computer.
  • Adding a computer to a group allows you to assign permissions to all of the computer accounts in that group and to filter Group Policy settings on all accounts in that group.

Related Topics


Delete a computer account

To delete a computer account

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Computers.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Computers

    Or, click the folder in which the computer is located.

  3. In the details pane, right-click the computer, and then click Delete.

Note

Related Topics


Find a computer account

To find a computer account

  1. Open Active Directory Users and Computers.
  2. If you want to search the entire domain, in the console tree, right-click the domain node, and then click Find.

    Or, if you know which organizational unit the computer is in, in the console tree, right-click the organizational unit, and then click Find.

  3. In Find, click Computers.
  4. In Name, type the name of the computer you want to find.

  5. To find only domain controllers, in Role, click Domain Controller.

    Or, to find only workstations and servers (not domain controllers), in Role, click Workstations and Servers.

  6. Click Find Now.

Notes

  • Use the Advanced tab for more powerful search options.
  • To find a computer, you can also click the find objects button on the toolbar.

Related Topics


Manage a computer

To manage a computer

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Computers.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Computers

    Or, click the container that contains the computer you want to manage.

  3. In the details pane, right-click the computer, and then click Manage.

Notes

  • This starts the Computer Management snap-in, from which you can administer local and remote computers. You must have administrative rights and permissions to view or modify computer properties using this console.

Related Topics


Modify computer account properties

To modify computer account properties

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Computers.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Computers

    Or, click the container that contains the computer whose properties you want to modify.

  3. In the details pane, right-click the computer, and then click Properties.

Note

Related Topics


Move a computer account

To move a computer account

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Computers.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Computers

    Or, click the folder that contains the computer that you want to move.

  3. In the details pane, right-click the computer, and then click Move.
  4. In the Move dialog box, click the domain node.
  5. Click the folder to which you want to move the computer, and then click OK.

Note

  • Active Directory Users and Computers cannot move computer accounts between domains. To move a computer account between domains use Movetree, one of the Active Directory support tools. For more information, see Related Topics.

Related Topics


Reset a computer account

To reset a computer account

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Computers.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Computers

    Or, click the container that contains the computer that you want to reset.

  3. In the details pane, right-click the computer, and then click Reset Account.

Notes

  • Resetting a computer account breaks that computer's connection to the domain and requires it to rejoin the domain.

Related Topics


Disable a computer account

To disable a computer account

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Computers.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Computers

    Or, click the folder that contains the computer that you want to disable.

  3. In the details pane, right-click the desired computer, and then click Disable Account.

Notes

  • Disabling a computer account breaks that computer's connection with the domain and that computer will not be able to authenticate to the domain.

Related Topics


Enable a computer account

To enable a computer account

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Computers.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Computers

    Or, click the folder that contains the computer that you want to enable.

  3. In the details pane, right-click the desired computer, and then click Enable Account.

Note

Related Topics


Allow a computer to use a different DNS name

To allow a computer to use a different DNS name

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click Active Directory Users and Computers and click Connect to Domain.
  3. In Domain, type the domain name or click Browse to find the domain in which you want to enable computers to use different DNS names, and then click OK.
  4. Right-click Active Directory Users and Computers, point to View, and then click Advanced Features.
  5. Right-click the name of the domain, and then click Properties.
  6. On the Security tab, click Add, click the Self group, click Add, and then click OK.
  7. Click Advanced, click Self, and then click View/Edit.
  8. On the Properties tab, in Apply onto, click Computer Objects.
  9. Under Permissions, click Write dNSHostName, and then click the Allow check box.

Caution

  • By modifying default security in this way, there is the possibility that a computer joined to the selected domain could be operated by a malicious user and may be able to advertise itself under a different name through the service principal name attribute.

Note

  • This procedure also allows computers to have DNS host names longer than 15 bytes.

Related Topics


Manage groups

  • Add a group
  • Add a member to a group
  • Convert a group to another group type
  • Change group scope
  • Delete a group
  • Find a group
  • Find groups in which a user is a member
  • Modify group properties
  • Remove a member from a group
  • Rename a group


Add a group

To add a group

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. Right-click the folder in which you want to add the group, point to New, and then click Group.
  4. Type the name of the new group.

    By default, the name you type is also entered as the pre-Windows 2000 name of the new group.

  5. Click the Group scope you want.
  6. Click the Group type you want.

Notes

  • To add a group, you can also click the folder in which you want to add the group, and then click Create new group button on the toolbar.
  • If the domain in which you are creating the group is in mixed-mode, you can only select security groups with Domain local or Global scopes. For more information, see Related Topics.

Related Topics


Add a member to a group

To add a member to a group

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. Click the folder that contains the group to which you want to add a member.
  4. In the details pane, right-click the group, and then click Properties.
  5. Click the Members tab, and then click Add.
  6. Click Look in to display a list of domains from which users and computers can be added to the group, and then click the domain containing the users and computers you want to add.
  7. Click the users and computers to be added, and then click Add.

Notes

  • In addition to users and computers, membership in a particular group can include contacts and other groups.
  • To add members to a group, you can also select the members to be added, click Add selected objects button on the toolbar, and then click the group into which they will be added.

Related Topics


Convert a group to another group type

To convert a group to another group type

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. Click the folder that contains the group.
  4. In the details pane, right-click the group, and then click Properties.
  5. On the General tab, under Group type, click the group type.

Notes

  • For more information about groups, see Related Topics.

Related Topics


Change group scope

To change group scope

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. Click the folder that contains the group.
  4. In the details pane, right-click the group, and then click Properties.
  5. On the General tab, under Group scope, click the group scope.

Note

  • For more information about groups and group scope, see Related Topics.

Related Topics


Delete a group

To delete a group

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. Click the folder that contains the group.
  4. In the details pane, right-click the group, and then click Delete.

Notes

  • Local groups provided automatically by Windows 2000, such as Administrators and Account Operators, are located in the Builtin folder by default. Common global groups, such as Domain Admins and Domain Users, are located in the Users folder by default. New groups can be added or moved to any folder. It is recommended that they be located in an organizational unit folder.

Related Topics


Find a group

To find a group

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the domain node, and then click Find.
  3. On the Users, Contacts, and Groups tab, in Name, type the name of the group you want to find.
  4. Click Find Now.

Notes

  • Local groups provided automatically by Windows 2000, such as Administrators and Account Operators, are located in the Builtin folder by default. Common global groups, such as Domain Admins and Domain Users, are located in the Users folder by default. New groups can be added or moved to any folder; it is recommended that they be located in an organizational unit folder.
  • Use the Advanced tab for more powerful search options.
  • To find groups, you can also click the find objects button on the toolbar.

Related Topics


Find groups in which a user is a member

To find groups in which a user is a member

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Users

    Or, click the folder that contains the user account.

  3. In the details pane, right-click a user account, and then click Properties.
  4. Click the Member Of tab.

Notes

  • Local groups that are provided automatically by Windows 2000, such as Administrators and Account Operators, are located in the Builtin folder by default. Common global groups, such as Domain Admins and Domain Users, are located in the Users folder by default. New groups can be added or moved to any folder. It is recommended that they be located in an organizational unit folder.

Related Topics


Modify group properties

To modify group properties

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. Click the folder that contains the group.
  4. In the details pane, right-click the group, and then click Properties.

Note

Related Topics


Remove a member from a group

To remove a member from a group

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. Click the folder that contains the group.
  4. In the details pane, right-click the group, and then click Properties.
  5. Click the Members tab.
  6. Click the members you want to delete, and then click Remove.

Notes

  • Local groups provided automatically by Windows 2000, such as Administrators and Account Operators, are located in the Builtin folder by default. Common global groups, such as Domain Admins and Domain Users, are located in the Users folder by default. New groups can be added or moved to any folder; it is recommended that they be located in an organizational unit folder.

Related Topics


Rename a group

To rename a group

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. Click the folder in which the group is located.
  4. In the details pane, right-click the group, and then click Rename.
  5. Type the new group name.

Notes

  • Local groups provided automatically by Windows 2000, such as Administrators and Account Operators, are located in the Builtin folder by default. Common global groups, such as Domain Admins and Domain Users, are located in the Users folder by default. New groups can be added or moved to any folder. It is recommended that they be located in an organizational unit folder.

Related Topics


Manage organizational units

  • Add an organizational unit
  • Delegate control of an organizational unit
  • Delete an organizational unit
  • Find an organizational unit
  • Modify organizational unit properties
  • Move an organizational unit
  • Rename an organizational unit


Add an organizational unit

To add an organizational unit

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. Right-click the domain node or the folder in which you want to add the organizational unit.
  4. Point to New, and then click Organizational Unit.
  5. Type the name of the organizational unit.

Notes

  • To add an organizational unit, you can also click the domain node or folder in which you want to add the organizational unit, and then click Create new organizational unit button on the toolbar.

Related Topics


Delegate control of an organizational unit

To delegate control of an organizational unit

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. In the details pane, right-click the organizational unit, and then click Delegate control to start the Delegation of Control wizard.
  4. Follow the instructions in the Delegation of Control wizard.

Note

Related Topics


Delete an organizational unit

To delete an organizational unit

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. In the details pane, right-click the organizational unit, and then click Delete.

Important

  • When you delete an organizational unit that contains objects, you will be asked if you want to delete the organizational unit and the objects it contains. If you answer yes, the organizational unit and all objects in the organizational unit will be deleted.

Note

Related Topics


Find an organizational unit

To find an organizational unit

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the domain node, and then click Find.
  3. In the Find list, click Organizational Units.
  4. Type the name of the organizational unit you want to find, and then click Find Now.

Notes

  • Use the Advanced tab for more powerful search options.
  • To find organizational units, you can also click the find objects button on the toolbar.

Related Topics


Modify organizational unit properties

To modify organizational unit properties

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. In the details pane, right-click the organizational unit folder, and then click Properties.

Note

Related Topics


Move an organizational unit

To move an organizational unit

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. In the details pane, right-click the organizational unit, and then click Move.
  4. In the Move dialog box, click the folder to which you want to move the organizational unit.

Notes

  • Active Directory Users and Computers can only move organizational units within the same domain. To move organizational units between domains, use Movetree. For more information about Movetree and other Active Directory support tools, see Related Topics.

Related Topics


Rename an organizational unit

To rename an organizational unit

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. In the details pane, right-click the organizational unit you want to rename.
  4. Click Rename, and then type the new name.

Note

Related Topics


Manage published resources

  • Perform a custom search
  • Find a shared folder
  • Find a printer
  • Publish a shared folder
  • Publish a Windows NT printer


Perform a custom search

To perform a custom search

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the domain node, and then click Find.
  3. In Find, click Custom Search.
  4. Click Field, point to the kind of object for which to search, and then click the attribute of that object for which you want to specify a search value.
  5. In Condition, click the condition for your search.
  6. In Value, type the attribute value for which the search will apply the condition.
  7. Click Add to add this search condition to the custom search.
  8. Repeat steps 4 through 7 until you have added all of the desired search conditions.
  9. Click Find Now.

Notes

  • Use the Advanced tab to enter a query using LDAP syntax. For more information about LDAP, see Related Topics.
  • To start a search, you can also click the find objects button on the toolbar.

Related Topics


Find a shared folder

To find a shared folder

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the domain node, and then click Find.
  3. In the Find list, click Shared Folders.
  4. On the Shared Folders tab, in Named, type the name of the folder you want to find.
  5. Click Find Now.

Notes

  • Use the Advanced tab for more powerful search options.
  • To find shared folders, you can also click the find objects button on the toolbar.

Related Topics


Find a printer

To find a printer

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the domain node, and then click Find.
  3. In the Find list, click Printers.
  4. On the Printers tab, in Name, type the name of the printer you want to find.
  5. Click Find Now.

Notes

  • You can also click the Features tab to find a printer with particular features, or click the Advanced tab for more powerful search options.
  • To find printers, you can also click the find objects button on the toolbar.

Related Topics


Publish a shared folder

To publish a shared folder

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. Right-click the folder in which you want to add the shared folder, point to New and click Shared Folder.
  4. Type the name of the folder.
  5. Type the UNC name that you want to publish in the directory.

Note

Related Topics


Publish a Windows NT printer

To publish a Windows NT printer

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. In the console tree, right-click the folder where you want to publish the printer, point to New, and then click Printer.
  4. Type the UNC name that you want to publish in the directory.

Notes

  • The Windows NT printer must be installed before publishing in Active Directory. To install a Windows NT printer, click Start, point to Settings, and then click Printers.
  • Windows 2000 printers are automatically published in Active Directory. To install and publish Windows 2000 print servers, see Printing.

Related Topics


Manage domains and trusts

  • Add user principal name suffixes
  • Change the domain mode
  • Create an explicit domain trust
  • Verify a trust
  • Revoke a trust


Add user principal name suffixes

To add user principal name suffixes

  1. Open Active Directory Domains and Trusts.
  2. In the console tree, right-click Active Directory Domains and Trusts, and then click Properties.
  3. On the UPN Suffixes tab, type an alternative UPN suffix for the domain, and then click Add.
  4. Repeat Step 3 to add additional alternative user principal name suffixes.

Notes

  • Use Run as to use Active Directory Domains and Trusts with appropriate permissions. For more information, see Related Topics.

Related Topics


Change the domain mode

To change the domain mode

  1. Open Active Directory Domains and Trusts.
  2. Right-click the domain node for the domain you want to administer, and then click Properties.
  3. On the General tab, click Change Mode, and then click Yes.

Caution

  • Do not change domain mode if you have or will have any Windows NT 4.0 domain controllers. You can only change the mode from mixed mode to native mode. Once a domain is running in native mode, it cannot be changed back to mixed mode.

Notes

  • For more information about domain modes, see Related Topics.

Related Topics


Create an explicit domain trust

To create an explicit domain trust

  1. Open Active Directory Domains and Trusts.
  2. In the console tree, right-click the domain node for the domain you want to administer, and then click Properties.
  3. Click the Trusts tab.
  4. Depending on your requirements, click either Domains trusted by this domain or Domains that trust this domain, and then click Add.
  5. If the domain to be added is a Windows 2000 domain, type the full DNS name of the domain.

    Or, if the domain is running an earlier version of Windows, type the domain name.

  6. Type the password for this trust, and confirm the password.
  7. Repeat this procedure on the domain that forms the other part of the explicit trust relationship.

Notes

  • The password must be accepted in both the trusting and trusted domains.
  • Use Run as to administer a domain to which you are not currently logged on. For more information about Run as, see Related Topics.
  • For information about trusts, see Related Topics.

Related Topics


Verify a trust

To verify a trust

  1. Open Active Directory Domains and Trusts.
  2. In the console tree, right-click one of the domains involved in the trust you want to verify, and then click Properties.
  3. Click the Trusts tab.
  4. In either Domains trusted by this domain or Domains that trust this domain, click the trust to be verified, and then click Edit.
  5. Click Verify/Reset.

Notes

  • Use Run as to administer a domain to which you are not currently logged on. For more information about Run as, see Related Topics.

Related Topics


Revoke a trust

To revoke a trust

  1. Open Active Directory Domains and Trusts.
  2. In the console tree, right-click one of the domain nodes involved in the trust you want to verify, and then click Properties.
  3. Click the Trusts tab.
  4. In either Domains trusted by this domain or Domains that trust this domain, click the trust to be revoked, and then click Remove.
  5. Repeat this procedure for the other domain involved in the trust.

Notes

  • Use Run as to administer a domain to which you are not currently logged on. For more information about Run as, see Related Topics.
  • It is not possible to revoke the default two-way transitive trusts between domains in a forest. Explicitly created shortcut trusts can be deleted.

Related Topics


Configure server settings

  • Create a server object
  • Select a query policy
  • Enable or disable a global catalog
  • Designate a preferred bridgehead server
  • Move a domain controller between sites
  • Remove an inoperative server from a site
  • Connect to a forest
  • Connect to a domain controller
  • Check the replication topology
  • Reveal the services node


Create a Server object

To create a Server object

  1. Open Active Directory Sites and Services.
  2. In the console tree, double-click the site that you want to contain the new domain controller Server object.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • site that you want to contain the new Server object
  3. Right-click Servers, point to New, and click Server.
  4. In Name, enter a name for the new Server object.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.
  • These Server objects can represent domain controllers or member servers. Creating a Server object is not the same as installing a domain controller.

Related Topics


Select a query policy

To select a query policy

  1. Open Active Directory Sites and Services.
  2. In the console tree, click the domain controller whose query policy you want to change.

    Where?

    • Active Directory Sites and Services
    • Sites
    • site that contains the domain controller whose query policy you want to change
    • Servers
    • domain controller whose query policy you want to change
  3. In the details pane, right-click NTDS Settings, and then click Properties.
  4. In Query Policy, click a query policy.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.

Related Topics


Enable or disable a global catalog

To enable or disable a global catalog

  1. Open Active Directory Sites and Services.
  2. In the console tree, double-click the domain controller hosting the global catalog.

    Where?

    • Active Directory Sites and Services
    • Sites
    • site that contains the domain controller hosting the global catalog
    • Servers
    • domain controller hosting a global catalog
  3. Right-click NTDS Settings, and then click Properties.
  4. Select the Global Catalog check box.

Caution

  • Do not enable this option unless you are certain it will provide value in your deployment. For this option to be useful, your deployment must have multiple domains, and even then, only one global catalog is typically useful in each site.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.
  • Clients must have access to a global catalog to log on, so you should have at least one global catalog in every site to receive the benefits of containing network traffic provided by using sites.

Related Topics


Designate a preferred bridgehead server

To designate a preferred bridgehead server

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click the domain controller that you want to make a preferred bridgehead server, and then click Properties.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • site that contains the domain controller that you want to make a preferred bridgehead server
    • Servers
    • the domain controller that you want to make a preferred bridgehead server
  3. Click the inter-site transport or transports for which this computer will be a preferred bridgehead server, and then click Add.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.
  • You can establish a preferred bridgehead server for one or more protocols (such as IP or SMTP).

Related Topics


Move a domain controller between sites

To move a domain controller between sites

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click the domain controller that you want to move to a different site, and then click Move.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • site that contains the domain controller you want to move
    • Servers
    • domain controller to be moved
  3. In the Move Server dialog box, click the site to which you want to move the domain controller.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.
  • This procedure can be used to move servers, as well as domain controllers, between sites.

Related Topics


Remove an inoperative server from a site

To remove an inoperative server from a site

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click the server to be removed, and then click Delete.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • site that contains the server to be removed
    • Servers
    • server you want to remove

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.
  • Use this procedure only if you want to permanently remove this server from the site. If you plan to reactivate this server, delete the NTDS Settings object for the server, rather than the Server object itself. When you bring the server back online, Active Directory will automatically create a new NTDS Settings object, inserting the server into the replication topology as appropriate.

Related Topics


Connect to a forest

To connect to a forest

  1. Open Active Directory Sites and Services.
  2. Right-click Active Directory Sites and Services, and then click Connect to Forest.
  3. In Root domain, enter the root domain of the forest. This is the root domain of the first domain tree created in the forest.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.
  • Active Directory Sites and Services views a single forest. Change forests to view and configure Active Directory Sites and Services settings for a forest of your choosing.

Related Topics


Connect to a domain controller

To connect to a domain controller

  1. Open Active Directory Sites and Services.
  2. Right-click Active Directory Sites and Services, and then click Connect to Domain Controller.
  3. In Domain, enter the domain name, or click Browse to select from the list of available domains.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.
  • Active Directory Sites and Services views and configures a single copy of the directory data. Change the domain controller to select an alternate domain controller whose directory data Active Directory Sites and Services will read and modify.

Related Topics


Check the replication topology

To check the replication topology

  1. Open Active Directory Sites and Services.
  2. In the console tree, double-click the server you want to use to check replication topology.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • site that contains the domain controller whose replication topology you want to check
    • Servers
    • server you want to use to check replication topology
  3. Right-click NTDS Settings, point to All Tasks, and then click Check Replication Topology.

Notes

  • Active Directory runs a process that considers the cost of inter-site connections, checks if any previously available domain controllers are no longer available, checks if new domain controllers have been added, and then uses this information to add or remove Connection objects to create an efficient replication topology. This process does not affect manually created Connection objects.
  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.

Related Topics


Reveal the services node

To reveal the services node

  1. Open Active Directory Sites and Services.
  2. Click the Active Directory Sites and Services node, point to View, and then click Show Services Node.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.
  • Show Services Node is a persistent setting.

Related Topics


Configure site settings

  • Create a site
  • Rename a site
  • Create a subnet
  • Associate a subnet with a site
  • Delete a site
  • Delete a subnet
  • Select another licensing computer
  • Delegate control


Create a site

To create a site

  1. Open Active Directory Sites and Services.
  2. Right-click the Sites folder, and then click New Site.
  3. In Name, type the name of the new site
  4. Click a site link object, and then click OK.
  5. Associate a subnet with a site for this newly created site. See Related Topics for information.
  6. Move a domain controller from an existing site into this new site, or install a new domain controller. See Related Topics for information.
  7. If you want to choose a specific licensing computer, other than the one automatically selected, select another licensing computer. See Related Topics for information.
  8. Delegate control of the site. See Related Topics for information.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.

Related Topics


Rename a site

To rename a site

  1. Open Active Directory Sites and Services.
  2. Double-click the Sites folder.
  3. Right-click the site you want to rename, click Rename, and then enter the new name.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.

Related Topics


Create a subnet

To create a subnet

  1. Open Active Directory Sites and Services.
  2. In the console tree, double-click Sites.
  3. Right-click Subnets, and then click New Subnet.
  4. In Address, enter the subnet address.
  5. In Mask, enter the subnet mask that describes the range of addresses included in this site's subnet.
  6. Choose a site with which to associate this subnet, and then click OK.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.
  • Any IP address within the subnet range is a valid entry.

Related Topics


Associate a subnet with a site

To associate a subnet with a site

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click the subnet with which you want to associate the site, and then click Properties.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Subnets
    • subnet
  3. In Site, click a site with which to associate this subnet.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.

Related Topics


Delete a site

To delete a site

  1. Open Active Directory Sites and Services.
  2. In the console tree, double-click Sites.
  3. Right-click the site container, and then click Delete.

Caution

  • A site is a Container object, so deleting a site will also delete all directory objects contained within the site.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.
  • You cannot delete the site called Default-First-Site.

Related Topics


Delete a subnet

To delete a subnet

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click the subnet that you want to delete, and then click Delete.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Subnets
    • subnet that you want to delete

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.

Related Topics


Select another licensing computer

To select another licensing computer

  1. Open Active Directory Sites and Services.
  2. In the console tree, click the site you want to configure.

    Where?

    • Active Directory Sites and Services
    • Sites
    • site
  3. In the details pane, right-click Licensing Site Settings, and then click Properties.
  4. To select an alternative licensing computer, click Change.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.
  • For optimal performance, a site's licensing computer should be in the same site. Active Directory will automatically configure a licensing computer for each site. A licensing computer does not have to be a domain controller.

Related Topics


Delegate control

To delegate control

  1. Open Active Directory Sites and Services.
  2. Right-click the container whose control you want to delegate, and then click Delegate control to start the Delegation of Control wizard.
  3. Follow the instructions in the Delegation of Control wizard.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.
  • In Active Directory Sites and Services, you can delegate control for the Subnets, Inter-site Transports, Sites, and Server containers. Delegating control of an object allows you to specify who has permissions to access or modify that object or it's child objects.

Related Topics


Configure replication

  • Create a site link
  • Delete a site link
  • Create a site link bridge
  • Delete a site link bridge
  • Configure site link replication availability
  • Configure site link cost
  • Configure site link replication frequency
  • Ignore schedules
  • Bridge all site links
  • Add a site to a site link
  • Manually add or configure connections
  • Force replication over a connection


Create a site link

To create a site link

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click the inter-site transport protocol you want the site link to use, and then click New Site Link.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Inter-Site Transports
    • inter-site transport protocol you want the site link to use
  3. In Name, type the name to be given to the link.
  4. Click two or more sites to connect, and then click Add.
  5. Configure the site link's cost, schedule, and replication frequency. See Related Topics for information.

Caution

  • If you create a site link that uses SMTP, you must have an enterprise certification authority (Enterprise CA) available and SMTP must be installed on all domain controllers that will use the site link.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.
  • Creating a site link between two or more sites is a way to influence replication topology. By creating a site link, you provide Active Directory with information about what connections are available, which ones are preferred, and how much bandwidth is available. Active Directory uses this information to choose times and connections for replication that will afford the best performance.

Related Topics


Delete a site link

To delete a site link

  1. Open Active Directory Sites and Services.
  2. In the console tree, click the inter-site transport folder that contains the site link you want to delete.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Inter-Site Transports
    • inter-site transport folder that contains the site link you want to delete
  3. In the details pane, right-click the site link you want to delete, and then click Delete.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.

Related Topics


Create a site link bridge

To create a site link bridge

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click the inter-site transport folder for which you want to create a new site link bridge, and then click New Site Link Bridge.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Inter-Site Transports
    • inter-site transport for which you want to create a new site link bridge
  3. In Name, type a name for the site link bridge.
  4. Click two or more site links to be bridged, and then click Add.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.
  • If you have enabled Bridge all site links, this procedure is redundant and will have no effect.
  • Creating a site link between two or more sites is a way to influence replication topology. By creating a site link, you provide Active Directory with information about what connections are available, which ones are preferred, and how much bandwidth is available. Active Directory uses this information to choose times and connections for replication that will afford the best performance.

Related Topics


Delete a site link bridge

To delete a site link bridge

  1. Open Active Directory Sites and Services.
  2. In the console tree, click the inter-site transport folder that contains the site link bridge you want to delete.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Inter-Site Transports
    • inter-site transport folder that contains the site link bridge you want to delete
  3. In the details pane, right-click the site link bridge that you want to delete, and then click Delete.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.

Related Topics


Configure site link replication availability

To configure site link replication availability

  1. Open Active Directory Sites and Services.
  2. In the console tree, click the inter-site transport folder that contains the site link whose schedule you want to adjust.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Inter-Site Transports
    • inter-site transport folder that contains the site link whose schedule you want to adjust
  3. In the details pane, right-click the site link whose schedule you want to adjust, and then click Properties.
  4. Click Change Schedule.
  5. Select the block of time you want to schedule, and then click the desired frequency of replication for that block of time: None, Once per Hour, Twice per Hour, or Four times per Hour.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.
  • Because SMTP is asynchronous, it typically ignores all schedules. Therefore, do not configure site link replication availability on SMTP site links unless the site links use scheduled connections, or the SMTP queue is not on a schedule, and information is being exchanged directly from one server to another, and not through intermediaries as is the case, for example, on a network Ethernet backbone.

Related Topics


Configure site link cost

To configure site link cost

  1. Open Active Directory Sites and Services.
  2. In the console tree, click the inter-site transport folder that contains the type of link you are going to configure.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Inter-Site Transports
    • inter-site transport folder that contains the type of link you are going to configure
  3. In the details pane, right-click the site link whose cost you want to set, and then click Properties.
  4. In Cost, enter a value for the cost of replication.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.
  • Because cost is determined by the sum of the costs of the constituent links that make up a site link bridge, you cannot apply costs to site link bridges. You can only apply costs to site links.

Related Topics


Configure site link replication frequency

To configure site link replication frequency

  1. Open Active Directory Sites and Services.
  2. In the console tree, click the inter-site transport containing the site link to configure.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Inter-Site Transports
    • inter-site transport for the site link to configure
  3. In the details pane, right-click the site link whose replication frequency you want to set, and then click Properties.
  4. In Replicate every, enter the number of minutes between replications.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.
  • The Replicate every value will be processed as the nearest multiple of 15 ranging from a minimum of 15 to a maximum of 10,080 minutes(corresponds to one week).

Related Topics


Ignore schedules

To ignore schedules

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click the inter-site transport protocol that contains the site link schedules you want ignored, and then click Properties.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Inter-Site Transports
    • the inter-site transport protocol that contains the site link schedules you want ignored
  3. Select the Ignore schedules check box.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.

Related Topics


Bridge all site links

To bridge all site links

  1. Open Active Directory Sites and Services.
  2. Double-click the Sites folder, and then double-click the Inter-Site Transports folder.
  3. Right-click the appropriate inter-site transport folder (such as IP or SMTP), and then click Properties.
  4. Select the Bridge all site links check box.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.
  • If bridging all site links creates connections between sites that span firewalls, replication errors will occur if the firewall only allows packets to travel between specific domain controllers.

Related Topics


Add a site to a site link

To add a site to a site link

  1. Open Active Directory Sites and Services.
  2. In the console tree, click the inter-site transport folder that contains the site link to which you are adding the site.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Inter-Site Transports
    • inter-site transport folder that contains the site link to which you are adding the site
  3. In the details pane, right-click the site link to which you want to add the site, and then click Properties.
  4. Click the site you want to add to this site link, and then click Add.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.

Related Topics


Manually add or configure connections

To manually add or configure connections

  1. Open Active Directory Sites and Services.
  2. In the console tree, click the domain controller for which you want to manually add or configure a connection.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • site that contains the domain controller for which you want to manually add or configure a connection
    • Servers
    • domain controller for which you want to manually add or configure a connection
  3. Right-click NTDS Settings, and then click New Active Directory Connection.
  4. In the Find Domain Controllers dialog box, click the domain controller that you want to include in the Connection object.
  5. In the New Object-Connection dialog box, enter a name for the new Connection object.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.
  • Active Directory automatically creates and deletes connections under normal conditions. Create a connection manually only if you are certain that the connection is required and that you want it to persist until it is manually removed.

Related Topics


Force replication over a connection

To force replication over a connection

  1. Open Active Directory Sites and Services.
  2. In the console tree, double-click the domain controller for the site containing the connection over which you want to replicate directory information.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • site that contains the connection over which you want to replicate directory information
    • Servers
    • domain controller for the site containing the connection over which you want to replicate directory information
  3. In the console tree, click NTDS Settings.
  4. In the details pane, right-click the connection over which you want to replicate directory information, and then click Replicate Now.

Notes

  • Active Directory Sites and Services can only be used from a computer that has access to a Windows 2000 domain. Active Directory Sites and Services is installed on all Windows 2000 domain controllers. To use Active Directory Sites and Services on a computer that is not a domain controller, such as one running Windows 2000 Professional, install the Windows 2000 Administration Tools.

Related Topics


Manage the schema

  • Install the Active Directory Schema snap-in
  • Add a member to the Schema Admins group
  • Remove a member from the Schema Admins group
  • Modify schema permissions
  • View a class definition
  • View an attribute definition
  • Add an attribute to the global catalog
  • Index an attribute in Active Directory
  • Enable this computer to extend the schema
  • Deactivate a class or attribute
  • Reload the schema


Install the Active Directory Schema snap-in

To install the Active Directory Schema snap-in

  1. Log on as Administrator.
  2. Insert the Windows 2000 Server compact disc into your compact disc drive, and then click Browse this CD.
  3. Double-click the I386 folder, double-click Adminpak, and then follow the instructions that appear in the Windows 2000 Administration Tools Setup wizard.
  4. Click Start, click Run, type mmc /a, and then click OK.
  5. On the Console menu, click Add/Remove Snap-in, and then click Add.
  6. Under Snap-in, double-click Active Directory Schema, and then click Close.
  7. If you have no more snap-ins to add to the console, click OK.
  8. To save this console, on the Console menu, click Save.

Caution

  • Modifying the Active Directory schema is an advanced operation best performed programmatically by experienced programmers and system administrators. For detailed information about modifying the Active Directory schema, see the Active Directory Programmer's Guide at the Microsoft Web site (http://msdn.microsoft.com/developer/windows2000/adsi/actdirguide.asp) .

Related Topics


Add a member to the Schema Admins group

To add a member to the Schema Admins group

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the appropriate domain node, and then click Users.

    Or, click the folder that contains the desired user.

  3. In the details pane, right-click the user account that you want to add, and then click Properties.
  4. Click the Member Of tab, and then click Add.
  5. In the Select Groups dialog box, click Schema Admins and then click Add.

Notes

  • To add users and computers to a group, you can also select the users and computers to be added, click Add selected objects button on the toolbar, and then click the group into which they will be added.

Related Topics


Remove a member from the Schema Admins group

To remove a member from the Schema Admins group

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the appropriate domain node, and then click Users.
  3. In the details pane, right-click the Schema Admins group, and then click Properties.
  4. On the Members tab, click the members you want to delete, and then click Remove.

Note

Related Topics


Modify schema permissions

To modify schema permissions

  1. Open Active Directory Schema.
  2. In the console tree, right-click Active Directory Schema, and then click Permissions.
  3. On the Security tab, click the group whose permissions you want to change.
  4. In Permissions, select Allow or Deny for the permissions you want to change.

Note

  • If Active Directory Schema is not available, you must install the Windows 2000 Administration Tools from the Windows 2000 Server compact disc and add it to an MMC console. For more information, see Related Topics.

Related Topics


View a class definition

To view a class definition

  1. Open Active Directory Schema.
  2. In the console tree, double-click Classes.
  3. In the console tree, right-click the class whose definition you want to view, and then click Properties.

Note

  • If Active Directory Schema is not available, you must install the Windows 2000 Administration Tools from the Windows 2000 Server compact disc and add it to an MMC console. For more information, see Related Topics.

Related Topics


View an attribute definition

To view an attribute definition

  1. Open Active Directory Schema.
  2. In the console tree, click Attributes.
  3. In the details pane, right-click the attribute whose definition you want to view, and then click Properties.

Note

  • If Active Directory Schema is not available, you must install the Windows 2000 Administration Tools from the Windows 2000 Server compact disc and add it to an MMC console. For more information, see Related Topics.

Related Topics


Add an attribute to the global catalog

To add an attribute to the global catalog

  1. Open Active Directory Schema.
  2. In the console tree, click Attributes.
  3. In the details pane, right-click the attribute that you want to replicate to the global catalog, and then click Properties.
  4. Click Replicate this attribute to the Global Catalog.

Notes

  • If Active Directory Schema is not available, you must install the Windows 2000 Administration Tools from the Windows 2000 Server compact disc and add it to an MMC console. For more information, see Related Topics.
  • Adding a new attribute to the global catalog causes a full synchronization of all of the domain data from all of the domains in the forest. In a large, multi-domain forest, this synchronization can cause significant network traffic.

Related Topics


Index an attribute in Active Directory

To index an attribute in Active Directory

  1. Open Active Directory Schema.
  2. In the console tree, click Attributes.
  3. In the details pane, right-click the attribute that you want to index in the global catalog, and then click Properties.
  4. Click Index this attribute in the Active Directory.

Note

  • If Active Directory Schema is not available, you must install the Windows 2000 Administration Tools from the Windows 2000 Server compact disc and add it to an MMC console. For more information, see Related Topics.

Related Topics


Enable this computer to extend the schema

To enable this computer to extend the schema

  1. Open Active Directory Schema.
  2. In the console tree, right-click Active Directory Schema, and then click Operations Master.
  3. Click The Schema may be modified on this domain controller.

Note

  • If Active Directory Schema is not available, you must install the Windows 2000 Administration Tools from the Windows 2000 Server compact disc and add it to an MMC console. For more information, see Related Topics.

Related Topics


Deactivate a class or attribute

To deactivate a class or attribute

  1. Open Active Directory Schema.
  2. Do one of the following, depending on whether you want to deactivate a class or attribute:
    • To deactivate a class, in the console tree, double-click Classes, right-click the class you want to deactivate, and then click Properties.
    • To deactivate an attribute, in the console tree, click Attributes, in the details pane, right-click the attribute you want to deactivate, and then click Properties.
  3. On the General tab, click either Deactivate this class or Deactivate this attribute as appropriate.

Note

  • If Active Directory Schema is not available, you must install the Windows 2000 Administration Tools from the Windows 2000 Server compact disc and add it to an MMC console. For more information, see Related Topics.

Related Topics


Reload the schema

To reload the schema

  1. Open Active Directory Schema.
  2. In the console tree, right-click Active Directory Schema, and then click Reload the Schema.

Note

  • If Active Directory Schema is not available, you must install the Windows 2000 Administration Tools from the Windows 2000 Server compact disc and add it to an MMC console. For more information, see Related Topics.

Related Topics


Concepts

This section covers:

  • Active Directory overview
  • Understanding Active Directory
  • Planning for Active Directory
  • Using Active Directory
  • Resources


Active Directory overview

Active Directory is the directory service for Windows 2000 Server. It stores information about objects on the network and makes this information easy for administrators and users to find and use. Active Directory directory service uses a structured data store as the basis for a logical, hierarchical organization of directory information.

Security is integrated with Active Directory through logon authentication and access control to objects in the directory. With a single network logon, administrators can manage directory data and organization throughout their network, and authorized network users can access resources anywhere on the network. Policy-based administration eases the management of even the most complex network.

  • Benefits of Active Directory
  • Introduction to Active Directory


Benefits of Active Directory

Active Directory provides:

  • Information security
  • Policy-based administration
  • Extensibility
  • Scalability
  • Replication of information
  • Integration with DNS
  • Interoperability with other directory services
  • Flexible querying


Information security

Security is fully integrated with Active Directory. Access control can be defined not only on each object in the directory but also on each property of each object. For more information, see Security.

Active Directory provides both the store and the scope of application for security policies. A security policy can include account information, such as domain-wide password restrictions or rights to particular domain resources. Security policies are implemented through Group Policy settings. For more information, see Group Policy.


Policy-based administration

Active Directory directory service includes both a data store and a logical, hierarchical structure. As a logical structure, it provides a hierarchy of contexts for the application of policy. As a directory, it stores the policies (called Group Policy objects) that are assigned to a particular context. A Group Policy object expresses a set of business rules containing settings that, for the context to which it is applied, can determine:

  • Access to directory objects and domain resources
  • What domain resources (such as applications) are available to users
  • How these domain resources are configured for use

For example, a Group Policy object can determine what applications users see on their computer when they log on, how many users can connect to Microsoft SQL Server when it starts on a server, and what documents or services users can access when they move to different departments or groups. Group Policy objects enable you to manage a small number of policies rather than a large number of users and computers. Active Directory enables you to apply Group Policy settings to the appropriate contexts, whether this is your entire organization or specific units of your organization.

For more information about policies, see Group Policy. For more information about the Active Directory contexts to which Group Policy settings can be applied, see Understanding Group Policy.


Extensibility

Active Directory is extensible, which means that administrators can add new classes of objects to the schema and can add new attributes to existing classes of objects.

For example, you could add a Purchase Authority attribute to the User object and then store each user's purchase authority limit as part of the user's account.

You can add objects and attributes to the directory by using the Active Directory schema or by creating scripts based on Active Directory Service Interfaces (ADSI) or the LDIFDE or CSVDE command-line utilities. For more information, see Active Directory schema overview, Importing and exporting directory information, and Programming interfaces.


Scalability

Active Directory includes one or more domains, each with one or more domain controllers, enabling you to scale the directory to meet any network requirements. Multiple domains can be combined into a domain tree and multiple domain trees can be combined into a forest.

The directory distributes its schema and configuration information to all domain controllers in the directory. This information is stored in the initial domain controller for a domain and replicated to any additional domain controllers in the domain. When the directory is configured as a single domain, adding domain controllers scales the directory without the administrative overhead involved with additional domains.

Adding domains to the directory enables you to partition the directory for different policy contexts and scale the directory to accommodate a large number of resources and objects. For more information, see Understanding Domains.


Replication of information

Replication provides information availability, fault tolerance, load balancing, and performance benefits for the directory. Active Directory uses multimaster replication, enabling you to update the directory at any domain controller, rather than at a single, primary domain controller. The multimaster model has the benefit of greater fault tolerance, since, with multiple domain controllers, replication continues, even if any single domain controller stops working.

Although users may not realize it, due to multimaster replication, they are updating a single copy of the directory. After directory information has been created or modified at a domain controller, the new or changed information is sent to all other domain controllers in the domain, so their directory information is current.

Domain controllers need the latest directory information, but to be efficient, they must limit their updates only to times when there is new or changed directory information. Indiscriminantly exchanging directory information among domain controllers can quickly overwhelm any network. Active Directory has been designed to replicate only changed directory information.

With multimaster replication, there is always the potential for the exact same directory change to occur at more than one domain controller. Active Directory has also been designed to track and mediate conflicting changes to the directory, resolving conflicts automatically in nearly all cases.

Deploying multiple domain controllers in one domain provides fault tolerance and load balancing. If one domain controller within a domain slows, stops, or fails, other domain controllers within the same domain can provide necessary directory access, since they contain the same directory data.

For more information about domain controllers see Domain controllers. For more information about replication see How Replication Works.


Integration with DNS

Active Directory uses the Domain Name System (DNS). DNS is an Internet standard service that translates easily readable host names, such as mycomputer.microsoft.com, to numeric IP addresses. This enables identification and connection to processes running on computers on TCP/IP networks.

Domain names for DNS are based on the DNS hierarchical naming structure, which is an inverted tree structure: a single root domain, underneath which can be parent and child domains (branches and leaves). For example, a Windows 2000 domain name such as child.parent.microsoft.com identifies a domain named "child," that is a child domain of the domain named "parent," itself a child of the root domain microsoft.com.

Each computer in a DNS domain is uniquely identified by its DNS fully qualified domain name. The fully qualified domain name of a computer located in the domain child.parent.microsoft.com would be computername.child.parent.microsoft.com. For more information on DNS, see Understanding DNS

Active Directory is integrated with DNS in the following ways:

  1. Active Directory and DNS have the same hierarchical structure.

    2. Although separate and implemented differently for different purposes, an organization's namespace for DNS and Active Directory have an identical structure. For example, microsoft.com is a DNS domain and an Active Directory domain.

  2. DNS zones can be stored in Active Directory.

    3. If you are using the Windows 2000 DNS service, primary zone files can be stored in Active Directory for replication to other Active Directory domain controllers. For more information, see Active Directory integration.

  3. Active Directory clients use DNS to locate domain controllers.

    4. To locate a domain controller for a specified domain, Active Directory clients query their configured DNS server for specific resource records. For more information, see Active Directory clients

For more information on Active Directory and DNS integration, see Understanding DNS integration.

If you do not already have a DNS infrastructure in place, see Planning issues.


Interoperability with other directory services

Because Active Directory is based on standard directory access protocols, such as Lightweight Directory Access Protocol (LDAP) version 3, and the Name Service Provider Interface (NSPI), it can interoperate with other directory services employing these protocols.

LDAP is the directory access protocol used to query and retrieve information from Active Directory. Because it is an industry-standard directory service protocol, programs can be developed using LDAP to share Active Directory information with other directory services that also support LDAP.

The NSPI protocol, which is used by Microsoft Exchange 4.0 and 5.x clients, is supported by Active Directory to provide compatibility with the Exchange directory.


Flexible querying

Users and administrators can use the Search command on the Startmenu, My Network Places or Active Directory Users and Computers to quickly find an object on the network using object properties. For example, you can find a user by first name, last name, e-mail name, office location, or other properties of that person's user account. Finding information is optimized by use of the global catalog. For more information, see Global Catalog.

To learn more about searching for specific kinds of information, see Finding directory information.


Introduction to Active Directory

A directory is a hierarchical structure that stores information about objects on the network. A directory service, such as Active Directory, provides the methods for storing directory data and making this data available to network users and administrators. For example, Active Directory stores information about user accounts, such as names, passwords, phone numbers, and so on, and enables other authorized users on the same network to access this information.

Before exploring Active Directory, you should familiarize yourself with the following information:

  • Directory service
  • Domains overview
  • Introducing domain trees and forests
  • Domain trusts
  • Organizational units
  • Active Directory sites and services overview
  • Groups
  • Active Directory schema overview
  • Server roles


Directory service

The Active Directory directory service has the following features:

  • A data store, also known as the directory, which stores information about Active Directory objects. These objects typically include shared resources such as servers, files, printers, and the network user and computer accounts. For more information about the Active Directory data store, see Directory data store.
  • A set of rules, the schema, that defines the classes of objects and attributes contained in the directory, the constraints and limits on instances of these objects, and the format of their names. For more information about the schema, see Active Directory schema overview.
  • A global catalog that contains information about every object in the directory. This allows users and administrators to find directory information regardless of which domain in the directory actually contains the data. For more information about the global catalog, see Global catalog.
  • A query and index mechanism, so that objects and their properties can be published and found by network users or applications. For more information about querying the directory, see Finding directory information.
  • A replication service that distributes directory data across a network. All domain controllers in a domain participate in replication and contain a complete copy of all directory information for their domain. Any change to directory data is replicated to all domain controllers in the domain. For more information about Active Directory replication, see Replication goals and strategies.
  • Integration with the security subsystem for a secure logon process to a network, as well as access control on both directory data queries and data modifications. For more information about Active Directory security, see Security model.
  • To gain the full benefits of Active Directory, the computer accessing the Active Directory over the network must be running the correct client software. To computers not running Active Directory client software, the directory will appear just like a Windows NT directory. For more information about client software, see Active Directory clients.


Domains overview

A domain defines a security boundary. The directory includes one or more domains, each having its own security policies and trust relationships with other domains. Domains provide several benefits:

  • Security policies and settings (such as administrative rights and access control lists) do not cross from one domain to another.
  • Delegating administrative authority to domains or organizational units eliminates the need for a number of administrators with sweeping administrative authority.
  • Domains help structure your network to better reflect your organization.
  • Each domain stores only the information about the objects located in that domain. By partitioning the directory this way, Active Directory can scale to very large numbers of objects.

Domains are units of replication. All of the domain controllers in a particular domain can receive changes and replicate those changes to all other domain controllers in the domain.

A single domain can span multiple physical locations or sites. Using a single domain greatly simplifies administrative overhead.

For more information about domains, see Understanding domains, Domain and account naming, and Planning your domain structure.


Introducing domain trees and forests

Multiple domains form a forest. Domains can also be combined into hierarchical structures called domain trees.

Domain trees

The first domain in a domain tree is called the root domain. Additional domains in the same domain tree are child domains. A domain immediately above another domain in the same domain tree is referred to as the parent of the child domain.

Parent and child domain relationships

All domains that have a common root domain are said to form a contiguous namespace. This means that the domain name of a child domain is the name of that child domain, added to the name of the parent domain. In this illustration, child.microsoft.com is a child domain of microsoft.com and the parent domain of grandchild.child.microsoft.com. The microsoft.com domain is the parent domain of child.microsoft.com. It is also the root domain of this domain tree.

Windows 2000 domains in a tree are joined together through two-way, transitive trust relationships. Because these trust relationships are two-way and transitive, a Windows 2000 domain newly created in a domain tree or forest immediately has trust relationships established with every other Windows 2000 domain in the domain tree or forest. These trust relationships allow a single logon process to authenticate a user on all domains in the domain tree or forest. This does not necessarily mean that the authenticated user has rights and permissions in all domains in the domain tree. Because a domain is a security boundary, rights and permissions must be assigned on a per-domain basis.

Forests

A forest consists of multiple domain trees. The domain trees in a forest do not form a contiguous namespace. For example, although the two domain trees, microsoft.com and microsoftasia.com may each have a child domain named "support", the DNS names for these child domains would be support.microsoft.com and support.microsoftasia.com. There is no shared namespace.

A forest with three domain trees.

However, a forest does have a root domain. The forest root domain is the first domain created in the forest. The root domains of all domain trees in the forest establish transitive trust relationships with the forest root domain. In the illustration, microsoft.com is the forest root domain. The root domains of the other domain trees, microsofteurope.com and microsoftasia.com, have transitive trust relationships with microsoft.com. This is necessary for the purposes of establishing trust across all the domain trees in the forest. For more information, see Domain trusts.

All of the Windows 2000 domains in all of the domain trees in a forest share the following traits:

  • Transitive trust relationships between the domains
  • Transitive trust relationships between the domain trees
  • A common schema
  • Common configuration information
  • A common global catalog

Using both domain trees and forests provides you with the flexibility of both contiguous and noncontiguous naming conventions. This can be useful in, for example, companies with independent divisions that must each maintain their own DNS names.

For more information about domain trees and forests, see Understanding domain trees and forests.


Domain trusts

A domain trust is a relationship established between two domains that enables users in one domain to be authenticated by a domain controller in another domain. All domain trust relationships have only two domains in the relationship: the trusting domain and the trusted domain.

Simple domain trust

In the first illustration, trusts are indicated by an arrow (pointing to the trusted domain).

In earlier versions of Windows, trusts were limited to the two domains involved in the trust and the trust relationship was one-way. In Windows 2000, all trusts are transitive and two-way. Both domains in a trust relationship automatically trust each other.

Transitive trusts in a domain tree

As shown in this illustration, this means that if Domain A trusts Domain B and Domain B trusts Domain C, users from Domain C (when granted the proper permissions) can access resources in Domain A.

For more information about domain trusts, see Understanding Domain Trusts and Explicit domain trusts.

Note

  • When a user is authenticated by a domain controller, this does not imply any access to resources in that domain. This is determined solely by the rights and permissions granted to the user account by the domain administrator for the trusting domain. For more information, see Authentication.


Organizational units

A particularly useful type of directory object contained within domains is the organizational unit. Organizational units are Active Directory containers into which you can place users, groups, computers, and other organizational units. An organizational unit cannot contain objects from other domains.

An organizational unit is the smallest scope or unit to which you can assign Group Policy settings or delegate administrative authority. Using organizational units, you can create containers within a domain that represent the hierarchical, logical structures within your organization. This enables you to manage the configuration and use of accounts and resources based on your organizational model. For more information about Group Policy settings, see Group Policy.

Organizational unit hierarchy within a domain

As shown in the illustration, organizational units can contain other organizational units. A hierarchy of containers can be extended as necessary to model your organization's hierarchy within a domain. Using organizational units will help you minimize the number of domains required for your network.

You can use organizational units to create an administrative model that can be scaled to any size. A user can be granted administrative authority for all organizational units in a domain or for a single organizational unit. An administrator of an organizational unit does not need to have administrative authority for any other organizational units in the domain. For more information about delegating administrative authority, see Delegating administration.

For more information about organizational units, see Planning organizational unit structure and Delegating administration.


Active Directory Sites and Services overview

Active Directory uses multimaster replication, enabling any Windows 2000 domain controller in the forest to service requests, including modifications to the directory by users.

If you have a small deployment of well-connected computers, arbitrary selection of a domain controller may not cause problems. However, a deployment that comprises a Wide Area Network (WAN) could be extraordinarily inefficient when, for example, users in Sydney attempt to authenticate to domain controllers in New York using a dial-up connection. Active Directory Sites and Services can improve the efficiency of directory services for most deployments through the use of sites.

You provide information about the physical structure of your network by publishing sites to Active Directory using Active Directory Sites and Services. Active Directory uses this information to determine how to replicate directory information and handle service requests.

Computers are assigned to sites based on their location in a subnet or in a set of well-connected subnets. Subnets provide a simple way to represent network groupings, much the same way that postal codes conveniently group mailing addresses. Subnets are formatted in terms that make it easy to post physical information about network connectivity to the directory. Having all computers in one or more well-connected subnets also reinforces the standard that all computers in a site must be well-connected, since computers in the same subnet typically have better connections than an arbitrary selection of computers on a network.

Sites facilitate:

  • Authentication. When clients log on using a domain account, the logon mechanism first searches for domain controllers that are in the same site as the client. Attempting to use domain controllers in the client's site first localizes network traffic, increasing the efficiency of the authentication process.

  • Replication. Directory information is replicated both within and among sites. Active Directory replicates information within a site more frequently than across sites. This balances the need for up-to-date directory information with the limitations imposed by available network bandwidth.

    You customize how Active Directory replicates information using site links to specify how your sites are connected. Active Directory uses the information about how sites are connected to generate Connection objects that provide efficient replication and fault tolerance.

    You provide information about the cost of a site link, times when the link is available for use and how often the link should be used. Active Directory uses this information to determine which site link will be used to replicate information. Customizing replication schedules so replication occurs during specific times, such as when network traffic is low, will make replication more efficient.

    Ordinarily, all domain controllers are used to exchange information between sites, but you can further control replication behavior by specifying a bridgehead server for inter-site replicated information. Establish a bridgehead server when you have a specific server you want to dedicate for inter-site replication, rather than using any server available. You can also establish a bridgehead server when your deployment uses proxy servers, such as for sending and receiving information through a firewall.

  • Active Directory enabled services. Information such as service bindings and configurations can be made available through the directory, making administration and use of network resources easier and more efficient. Sites help structure and optimize distribution of service information, so the current information is available to clients and distributed efficiently throughout your network.


Groups

Groups are Active Directory or local computer objects that can contain users, contacts, computers, and other groups. Use groups to:

  • Manage user and computer access to shared resources such as Active Directory objects and their properties, network shares, files, directories, printer queues, and so on
  • Filter Group Policy settings
  • Create e-mail distribution lists

There are two kinds of groups:

  • Security groups
  • Distribution groups

Security groups are used to collect users, computers and other groups into manageable units. When assigning permissions for resources (file shares, printers, and so on), administrators should assign those permissions to a security group rather than to individual users. The permissions are assigned once to the group, instead of several times to each individual user. Each account added to a group receives the rights and permissions defined for that group. Working with groups instead of with individual users helps simplify network maintenance and administration.

Distribution groups can only be used as e-mail distribution lists. They cannot be used to filter Group Policy settings. Distribution groups have no security function.

As opposed to groups, organizational units are used to create collections of objects within a single domain, but do not confer membership. The administration of an organizational unit and the objects it contains, can be delegated to an individual administrator or a group. For more information about organizational units, see Organizational units and Planning organizational unit structure.

Group Policy objects can be applied to sites, domains or organizational units, but never to groups. A Group Policy object is a collection of settings that affects users or computers. Group membership is used to filter which Group Policy objects will affect the users and computers in the site, domain or organizational unit. For more information about Group Policy, see Understanding Group Policy.

To learn more about groups and how to use them, see Understanding Groups.


Active Directory schema overview

The Active Directory schema is the set of definitions that defines the kinds of objects, and the types of information about those objects, that can be stored in Active Directory. The definitions are themselves stored as objects so that Active Directory can manage the schema objects with the same object management operations used for managing the rest of the objects in the directory.

There are two types of definitions in the schema: attributes and classes. Attributes and classes are also referred to as schema objects or metadata.

Attributes are defined separately from classes. Each attribute is defined only once and can be used in multiple classes. For example, the Description attribute is used in many classes, but is defined once in the schema, assuring consistency.

Classes, also referred to as object classes, describe the possible directory objects that can be created. Each class is a collection of attributes. When you create an object, the attributes store the information that describes the object. The User class, for example, is composed of many attributes, including Network Address, Home Directory, and so on. Every object in Active Directory is an instance of an object class.

A set of basic classes and attributes are supplied with Windows 2000 Server. Experienced developers and network administrators can dynamically extend the schema by defining new classes and new attributes for existing classes. Active Directory does not support deletion of schema objects; however, objects can be marked as deactivated, providing many of the benefits of deletion. Extending the schema is an advanced operation with the potential for adverse consequences. Before extending the schema in any way, see Checklist: Before extending the schema.

The structure and content of the schema is controlled by the domain controller that holds the schema operations master role. A copy of the schema is replicated to all domain controllers in the forest. The use of this common schema ensures data integrity and consistency throughout the forest. For more information about the schema master, see Single master operations.

The recommended way to extend the Active Directory schema is programmatically, through the Active Directory Service Interfaces (ADSI) described in the Windows 2000 Software Developer's Kit. For detailed information about extending the schema programmatically, see The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/) and The Internet Engineering Task Force (http://www.ietf.org/) Web site.

For development and testing purposes, you can also view and modify the Active Directory schema with the Active Directory Schema snap-in, included with the Windows 2000 Administration Tools on the Windows 2000 Server compact disc. For more information, see Managing servers remotely.


Server roles

Windows 2000 Server can operate in any of several roles. You can easily change Windows 2000 Server between the various roles to accommodate the needs of your organization.

For more information about Windows 2000 Server roles and how to change those roles, see:

  • Domain controllers
  • Member servers
  • Stand-alone servers
  • Changing server roles


Domain controllers

A domain controller is a computer running Windows 2000 Server that has been configured using the Active Directory Installation wizard. The Active Directory Installation wizard installs and configures components that provide Active Directory directory service to network users and computers. Domain controllers store directory data and manage user-domain interactions, including user logon processes, authentication, and directory searches.

A domain can have one or more domain controllers. A small organization using a single local area network (LAN) may need only one domain with two domain controllers for high availability and fault tolerance. A large company with many network locations will need one or more domain controllers in each location to provide high availability and fault tolerance.

Active Directory supports multimaster replication of directory data between all domain controllers in the domain. Some changes are impractical to perform in multimaster fashion, however, so only one domain controller, called the operations master, accepts requests for such changes. In any Active Directory forest, there are at least five different operations master roles that are assigned to one or more domain controllers. For more information about operations masters, see Single master operations.

Windows 2000 Server domain controllers provide an extension of the capabilities and features provided by Windows NT Server 4.0 domain controllers. Windows 2000 Server multimaster replication synchronizes directory data on each domain controller, ensuring consistency of information over time. Multimaster replication is an evolution of the primary and backup domain controller model used in Windows NT Server 4.0, in which only one server, the primary domain controller, had a read and write copy of the directory.


Member servers

Computers that function as servers within a domain can have one of two roles: domain controller or member server.

A member server is a computer that is:

  • Running Windows 2000 Server
  • A member of a domain
  • Not a domain controller

Because it is not a domain controller, a member server does not handle the account logon process, does not participate in Active Directory replication, and does not store domain security policy information.

Member servers typically function as the following types of servers:

  • File servers
  • Application servers
  • Database servers
  • Web servers
  • Certificate servers
  • Firewalls
  • Remote access servers

These member servers have a common set of security-related features:

  • Member servers adhere to Group Policy settings that are defined for the site, domain, or organizational unit.
  • Resources that are available on a member server are configured for access control.
  • Member server users have user rights assigned to them.
  • Member servers contain a local security account database, the Security Account Manager (SAM).

For information on domain controllers, see Domain controllers.


Stand-alone servers

A stand-alone server is a computer that is running Windows 2000 Server and is not a member of a Windows 2000 domain. If Windows 2000 Server is installed as a member of a workgroup, that server is a stand-alone server.

Stand-alone servers can share resources with other computers on the network, but they do not receive any of the benefits provided by Active Directory.


Changing server roles

A server within a domain can function in one of two roles: either as a domain controller or a member server.

As the needs of your computing environment change, you might want to change the role of a server. Using the Active Directory Installation wizard, you can promote a member server to a domain controller, or you can demote a domain controller to a member server.


Understanding Active Directory

Active Directory is an implementation of Internet standard directory and naming protocols. It uses a database engine for transactional support and supports a variety of application programming interface standards. This section covers:

  • Understanding domains
  • Understanding domain trees and forests
  • Domain and account naming
  • Understanding domain trusts
  • Explicit domain trusts
  • Sites
  • Active Directory user and computer accounts
  • Understanding Group Policy
  • Understanding DNS integration
  • Understanding groups
  • Active Directory directory service


Understanding domains

A domain provides several benefits:

  • Organizing objects.

    Using organizational units within a domain helps you manage the accounts and resources in the domain.

  • Publishing resources and information about domain objects.

    • Using multiple domains, you can scale the Active Directory directory service to accommodate your administrative and directory publishing requirements.

    A domain stores only the information about objects located in that domain, so by creating multiple domains, you are partitioning or segmenting the directory to better serve a disparate user base.

  • Applying a Group Policy object to the domain consolidates resource and security management.

    A domain defines a scope or unit of policy. A Group Policy object establishes how domain resources can be accessed, configured, and used. These policies are applied only within the domain and not across domains. For more information about applying Group Policy objects, see Group Policy.

  • Delegating authority eliminates the need for a number of administrators with sweeping administrative authority.

    Using delegated authority in conjunction with Group Policy objects and group memberships enables you to assign an administrator rights and permissions to manage objects in an entire domain or in one or more organizational units within the domain. For more information about delegating administrative control, see Delegating administration.

    For information about groups, see Understanding Groups

    Because a domain is a security boundary, administrative permissions for a domain are limited to the domain by default. For example, an administrator with permissions to set security policies in one domain is not automatically granted authority to set security policies within any other domain in the directory.

To create a domain, you must promote one or more computers running Windows 2000 Server to be domain controllers. A domain controller provides the Active Directory directory service to network users and computers, stores directory data, and manages user-domain interactions, including user logon processes, authentication, and directory searches. Every domain must contain at least one domain controller.

For more information about domain controllers, see Domain controllers. To promote a computer running Windows 2000 Server to a domain controller, see Install a domain controller.


Understanding domain trees and forests

Domain tree

Each domain in the directory is identified by a DNS domain name and requires one or more domain controllers. If your network requires more than one domain, you can easily create create multiple domains.

One or more domains that share a common schema and global catalog are referred to as a forest. If multiple domains in the forest have contiguous DNS domain names, as shown in the first illustration, then that structure is referred to as a domain tree.

If, as shown in the second illustration, multiple domains have noncontiguous DNS domain names, then they form separate domain trees within the forest. A forest can contain one or more domain trees. The first domain in a forest is referred to as the forest root domain.

Forest

You create a domain by installing the first domain controller for a domain. During installation of the first domain controller, the Active Directory Installation wizard uses information you provide to install the domain controller and create the domain within the existing context (if any) of relationships to other domains and domain controllers. This context may be the first domain in a new forest, the first domain in a new domain tree, or a child domain of an existing domain tree.

After you install the first domain controller for a domain, you can install additional domain controllers in an existing domain for fault tolerance and high availability of the directory.

Domain naming

Domains that form a single domain tree share a contiguous namespace (naming hierarchy). Following DNS standards, the fully qualified domain name for a domain that is part of a contiguous namespace is the name of that domain appended to the names of the parent and root domains using the dot (.) character format. For example, a domain with a NetBIOS name of "grandchild" that has a parent domain named parent.microsoft.com, would have a fully qualified DNS domain name of grandchild.parent.microsoft.com.

Domain trees associated in a forest share the same Active Directory schema and directory configuration and replication information, but do not share a contiguous DNS domain namespace.

The combination of domain trees and forests provides you with flexible domain naming options. Both contiguous and noncontiguous DNS namespaces can be included in your directory.

For more information about Active Directory and DNS, see Domain Name System (DNS).

Trust relationships

For Windows 2000 computers, account authentication between domains is enabled by two-way, transitive trusts based on the Kerberos V5 security protocol.

Trust relationships are automatically created between adjacent domains (parent and child domains) when a domain is created in a domain tree. In a forest, a trust relationship is automatically created between the forest root domain and the root domain of each domain tree added to the forest. Because these trust relationships are transitive, users and computers can be authenticated between any domains in the domain tree or forest.

When upgrading a Windows pre-Windows 2000 domain to Windows 2000, the existing one-way trust relationships between that domain and any other domains are maintained. This includes all trusts with pre-Windows 2000 domains. If you are installing a new Windows 2000 domain and want trust relationships with any pre-Windows 2000 domains, you must create external trusts with those domains.

For more information about trust relationships, see Domain trusts. For more information about external trusts, see External trusts.


Domain and account naming

Active Directory domain names are usually the full DNS name of the domain. However, for backward compatibility, each domain also has a pre-Windows 2000 name for use by computers running pre-Windows 2000 operating systems.

The pre-Windows 2000 domain name can be used to log on to a Windows 2000 domain from computers running pre-Windows 2000 operating systems using the domainname\username format. This same format can also be used to log on to a Windows 2000 domain from computers running Windows 2000. Users can also log on to computers running Windows 2000 using the user principal name associated with their user account.

User accounts

In Active Directory, each user account has a user logon name, a pre-Windows 2000 user logon name (security account manager account name), and a user principal name suffix. The administrator enters the user logon name and selects the user principal name suffix when creating the user account. Active Directory suggests a pre-Windows 2000 user logon name using the first 20 bytes of the user logon name. Administrators can change the pre-Windows 2000 logon name at any time.

In Active Directory, each user account has a user principal name based on IETF RFC 822, Standard for the Format of ARPA Internet Text Messages. The user principal name is composed of the user logon name and the user principal name suffix joined by the @ sign.

Note

  • Do not add the @ sign to the user logon name or to the user principal name suffix. Active Directory automatically adds it when it creates the user principal name. A user principal name that contains more than one @ sign is invalid.

The second part of the user principal name, referred to as the user principal name suffix, identifies the domain in which the user account is located. This user principal name suffix can be the DNS domain name, the DNS name of any domain in the forest, or it can be an alternative name created by an administrator and used just for logon purposes. This alternative user principal name suffix does not need to be a valid DNS name.

In Active Directory, the default user principal name suffix is the DNS name of the root domain in the domain tree. In most cases, this is the domain name registered as the enterprise domain on the Internet. Using alternative domain names as the user principal name suffix can provide additional logon security and simplify the names used to log on to another domain in the forest.

For example, if your organization uses a deep domain tree, organized by department and region, domain names can get quite long. The default user principal name suffix for a user in that domain might be sales.westcoast.microsoft.com. The logon name for a user in that domain would be user@sales.westcoast.microsoft.com. Creating a user principal name suffix of "microsoft" would allow that same user to log on using the much simpler logon name of user@microsoft. For more information about user accounts, see Active Directory user and computer accounts and Active Directory object names.

You can add or remove user principal name suffixes using Active Directory Domains and Trusts. For instructions, see Add user principal name suffixes.

Computer accounts

Each computer account created in Active Directory has a relative distinguished name, a pre-Windows 2000 computer name (security account manager account name), a primary DNS suffix, a DNS host name and a service principal name. The administrator enters the computer name when creating the computer account. This computer name is used as the LDAP relative distinguished name.

Active Directory suggests the pre-Windows 2000 name using the first 15 bytes of the relative distinguished name. The administrator can change the pre-Windows 2000 name at any time.

The primary DNS suffix defaults to the full DNS name of the domain to which the computer is joined. The DNS host name is built from the first 15 characters of the relative distinguished name and the primary DNS suffix. For example, DNS host name of the computer that is joined to the mydomain.microsoft.com domain, and that has the relative distinguished name of CN=MyComputer1234567890, would be mycomputer12345.mydomain.microsoft.com.

For more information, see Active Directory object names and Active Directory user and computer accounts.

The service principal name is built from the DNS host name. The service principal name is used in the process of mutual authentication between the client and the server hosting a particular service. The client finds a computer account based on the service principal name of the service to which it is trying to connect.

It is possible for administrators to change the way the service principal name is created. This security modification allows a computer to use primary DNS suffixes that are different than the domain to which the computer is joined. The same modification also allows Active Directory to use more than the first 15 bytes of the relative distinguished name when constructing the service principal name.

Computers with these modified computer names will register their names in DNS correctly but an additional procedure is required to enable correct registration of the DNS host name (dNSHostName) and service principal Name (servicePrincipalName) attributes of the computer object in Active Directory.

Caution

  • By modifying default security in this way, there is a possibility that a computer joined to the selected domain could be operated by a malicious user and may be able to advertise itself under a different name through the service principal name attribute.

For more information, see Allow a computer to use a different DNS name.


Understanding domain trusts

A domain trust is a relationship established between domains that enables users in one domain to be authenticated by a domain controller in the other domain. The authentication requests follow a trust path.

Trust path

A trust path is the series of trust relationships that authentication requests must follow between domains. Before a user can access a resource in another domain, Windows 2000 security must determine whether the trusting domain (the domain containing the resource the user is trying to access) has a trust relationship with the trusted domain (the user's logon domain). To determine this, the Windows 2000 security system computes the trust path between a domain controller in the trusting domain and a domain controller in the trusted domain. In the illustration, trust paths are indicated by arrows showing the direction of the trust:

Direction of trust path

All domain trust relationships have only two domains in the relationship: the trusting domain and the trusted domain. A domain trust relationship is characterized by whether it is:

  • Two-way
  • One-way
  • Transitive
  • Nontransitive

One-way trust

A one-way trust is a single trust relationship, where Domain A trusts Domain B. All one-way relationships are nontransitive and all nontransitive trusts are one-way. Authentication requests can only be passed from the trusting domain to the trusted domain. This means that if Domain A has a one-way trust with Domain B and Domain B has a one-way trust with Domain C, Domain A does not have a trust relationship with Domain C.

A Windows 2000 domain can establish a one-way trust with:

  • Windows 2000 domains in a different forest
  • Windows NT 4.0 domains
  • MIT Kerberos V5 realms (see Kerberos V5 authentication)

Because all Windows 2000 domains in a forest are linked by transitive trust, it is not possible to create one-way trusts between Windows 2000 domains in the same forest. For more information, see Explicit domain trusts.

Two-way trust

All domain trusts in a Windows 2000 forest are two-way transitive trusts.

When a new child domain is created, a two-way transitive trust is automatically created between the new child domain and the parent domain. In a two-way trust, Domain A trusts Domain B and Domain B trusts Domain A. This means that authentication requests can be passed between the two domains in both directions.

To create a nontransitive two-way trust, you must create two one-way trusts between the domains involved. For more information, see Explicit domain trusts.

Transitive trust

All domain trusts in a Windows 2000 forest are transitive. Transitive trusts are always two-way: Both domains in the relationship trust each other.

A transitive trust is not bounded by the two domains in the trust relationship. Each time you create a new child domain, a two-way transitive trust relationship is created implicitly (automatically) between the parent and new child domain. In this way, transitive trust relationships flow upward through the domain tree as it is formed, creating transitive trust between all domains in the domain tree.

Each time you create a new domain tree in a forest, a two-way transitive trust relationship is created between the forest root domain and the new domain (the root of the new domain tree). If no child domains are added to the new domain, the trust path is between this new root domain and the forest root domain. If child domains are added to the new domain (making it a domain tree), trust flows upward through the domain tree to the domain tree's root domain, extending the initial trust path created between the domain root and the forest root domain. Whether the new domain added to the forest is a single root domain (having no child domains) or a domain tree, the trust paths extend through the forest root domain to any other root domains in the forest. In this way, transitive trust relationships flow through all domains in the forest. Authentication requests follow these trust paths, so accounts from any domain in the forest can be authenticated at any other domain in the forest. With a single logon process, those accounts having the proper permissions can potentially access resources on any domain in the forest.

This illustration shows how transitive trusts flow through all of the domains in a forest.

A two-way transitive trust path connects all domains in a forest.

Because Domain 1 has a transitive trust relationship with Domain 2 and Domain 2 has a transitive trust relationship with Domain 3, users in Domain 3 (when granted the proper permissions) can access resources in Domain 1. Because Domain 1 has a transitive trust relationship with Domain A, and the other domains in Domain A's domain tree have transitive trust relationships with Domain A, users in Domain B (when granted the proper permissions) can access resources in Domain 3.

You can also explicitly (manually) create transitive trusts between Windows 2000 domains in the same domain tree or forest. These shortcut trust relations can be used to shorten the trust path in large and complex domain trees or forests. For more information, see Explicit domain trusts.

Note

  • Transitive trusts can only exist between Windows 2000 domains in the same forest. Due to the necessary flow of trust, it is not possible to have nontransitive trusts between domains in the same Windows 2000 forest.

Nontransitive trust

A nontransitive trust is bounded by the two domains in the trust relationship and does not flow to any other domains in the forest. In most cases, you must explicitly create nontransitive trusts (see Explicit domain trusts).

Note

  • All trust relationships between Windows 2000 domains and Windows NT domains are nontransitive. When upgrading from Windows NT to Windows 2000, all existing Windows NT trusts are preserved intact. In a mixed-mode environment, all Windows NT trusts are nontransitive.

Nontransitive trusts are one-way by default, although you can also create a two-way relationship by creating two one-way trusts. All trust relationships established between domains that are not both Windows 2000 domains in the same forest are nontransitive.

In summary, nontransitive domain trusts are the only form of trust relationship possible between:

  • A Windows 2000 domain and a Windows NT domain
  • A Windows 2000 domain in one forest and a Windows 2000 domain in another forest
  • A Windows 2000 domain and an MIT Kerberos V5 realm (see Kerberos V5 authentication)

Trust protocols

Windows 2000 authenticates users and applications using one of two protocols: Kerberos V5 or NTLM. The Kerberos V5 protocol is the default protocol for computers running Windows 2000 and computers with Windows 2000 client software installed. If any computer involved in a transaction does not support Kerberos V5, the NTLM protocol will be used.

With the Kerberos V5 protocol, the client requests a ticket from a domain controller in its account domain to the server in the trusting domain. This ticket is issued by an intermediary trusted by the client and the server. The client presents this trusted ticket to the server in the trusting domain for authentication. For more information, see Kerberos V5 authentication.

When a client tries to access resources on a server in another domain using NTLM authentication, the server containing the resource must contact a domain controller in the client's account domain to verify the account credentials.


Explicit domain trusts

Explicit trusts are trust relationships that you create yourself, as opposed to trusts created automatically during installation of a domain controller. You create and manage explicit trusts using Active Directory Domains and Trusts. There are two kinds of explicit trusts: external trusts and shortcut trusts. External trusts enable user authentication to a domain outside of a forest. Shortcut trusts shorten the trust path in a complex forest.

External trusts

One-way non-transitive trust

External trusts create trust relationships to domains outside the forest. The benefit of creating external trusts is to enable user authentication to a domain not encompassed by the trust paths of a forest. All external trusts are one-way non-transitive trusts, as shown in the figure. You can combine two one-way trusts to create a two-way trust relationship.

Important

  • In mixed-mode domains, external trusts should always be deleted from a Windows 2000 domain controller. External trusts to Windows NT 4.0 or 3.51 domains can be deleted by authorized administrators on the Windows NT 4.0 or 3.51 domain controllers. However, only the trusted side of the relationship can be deleted on Windows NT 4.0 or 3.51 domain controllers. The trusting side of the relationship (created in the Windows 2000 domain) is not deleted, and although it will not be operational, the trust will continue to display in Active Directory Domains and Trusts. To remove the trust completely, you will need to delete the trust from a Windows 2000 domain controller in the trusting domain.

    If an external trust is inadvertently deleted from a Windows NT 4.0 or 3.51 domain controller, you will need to recreate the trust from any Windows 2000 domain controller in the trusting domain.

Shortcut trusts

Before an account can be granted access to resources by a domain controller of another domain, Windows 2000 must determine whether the domain containing the desired resources (target domain) has a trust relationship with the domain in which the account is located (source domain). To make this determination for two domains in a forest, Windows 2000 computes a trust path between the domain controllers for these source and target domains. A trust path is the series of domain trust relationships that must be traversed by Windows 2000 security to pass authentication requests between any two domains. Computing and traversing a trust path between domain trees in a complex forest can take time, which can be reduced with shortcut trusts.

Shortcut trusts are two-way transitive trusts that enable you to shorten the path in a complex forest. You explicitly create shortcut trusts between Windows 2000 domains in the same forest. A shortcut trust is a performance optimization that shortens the trust path for Windows 2000 security to take for authentication purposes. The most effective use of shortcut trusts is between two domain trees in a forest.

Shortcut trusts in a Windows 2000 forest

As shown in the illustration, you can create a shortcut trust between mid-level domains in two domain trees to shorten the trust path between two Windows 2000 domains in a forest and optimize the Windows 2000 authentication process.

Note

  • You can create multiple shortcut trusts between domains in a forest if necessary.

Creating Explicit Trusts

To create an explicit trust, you must know the domain names and a user account with permission to create trusts in each domain. Each trust is assigned a password that must be known to the administrators of both domains in the relationship. For instructions about how to establish an explicit trust, see To create an explicit domain trust.

For more information about domain trusts, see Understanding domain trusts. For more information about the authentication process, see Authentication.


Sites

Several clients contained within a site that is defined as a subnet.

For convenience, think of sites as being defined by a set of computers in one or more IP subnets. This works well because, for efficient exchange of directory information, computers in a site need to be well-connected, a typical characteristic of computers within a subnet. If a site comprises multiple subnets, those subnets too must be well-connected for the same reason. Wide area networks (WANs) should employ multiple sites. If they do not, servicing requests or replicating directory information across WANs may be highly inefficient.

For more information about what it means for computers to be well-connected, see Bandwidth.

How do sites relate to domains?

Sites map the physical structure of your network whereas domains generally map the logical structure of your organization. Logical and physical structure are independent of each other, which has the following consequences:

  • There is no necessary correlation between your network's physical structure and its domain structure.
  • Active Directory allows multiple domains in a single site, as well as multiple sites in a single domain.
    • Different sites contained in a single domain, and different domains contained in a single site.
  • There is no necessary connection between sites and domain namespaces.

How are sites used?

Active Directory Sites and Services allows you to specify site information. Active Directory uses this information to determine how best to use available network resources. This makes the following types of operations more efficient:

  • Service requests

    • When a client requests a service from a domain controller, it directs the request to a domain controller in the same site, if one is available. Selecting a domain controller that is well-connected to the client that placed the request makes handling the request more efficient.

  • Replication

    • Sites streamline replication of directory information. Directory schema and configuration information is distributed throughout the forest and domain data is distributed among all domain controllers in the domain. By strategically reducing replication, the strain on your network can be similarly reduced. Active Directory replicates directory information within a site more frequently than among sites. This way, the best connected domain controllers, those most likely to need particular directory information, receive replications first. The domain controllers in other sites receive all changes to the directory, but less frequently, reducing network bandwidth consumption.

Many clients and servers exchange messages in a disorganized fashion. After being grouped into sites, clients and servers exchange information in a more efficient fashion.

If a deployment is not organized into sites, information exchange among domain controllers and clients can be chaotic. Sites improve the efficiency of network usage.

Site membership is determined differently for domain controllers and clients. A client determines what site it is in when it is turned on, so its site location will often be dynamically updated. A domain controller's site location is established by which site its Server object belongs to in the directory, so its site location will be consistent unless the domain controller's Server object is intentionally moved to a different site. If a domain controller or client has an address that is not included in any site, then the client or domain controller is contained within the initial site created(Default-First-Site). All activity is then handled as though the client or domain controller activity is a member of Default-First-Site, regardless of actual IP address or subnet location. Therefore, all sites will always have a domain controller associated, since the nearest domain controller associates itself with a site that has no domain controller (unless the site Default-First-Site is deleted).


Active Directory user and computer accounts

Active Directory user and computer accounts represent a physical entity such as a computer or person. User accounts and computer accounts (as well as groups) are called security principals. Security principals are directory objects that are automatically assigned security identifiers. Objects with security identifiers can log on to the network and access domain resources. A user or computer account is used to:

  • Authenticate the identity of the user or computer.
  • Authorize or deny access to domain resources.
  • Administer other security principals.
  • Audit actions performed using the user or computer account.

For example, the user and computer accounts that are members of the Enterprise Admins group are automatically granted permission to log on at all of the domain controllers in the forest.

User and computer accounts are added, disabled, reset, and deleted using Active Directory Users and Computers.

When a trust is established between a Windows 2000 domain in a particular forest and a Windows 2000 domain outside of that forest, security principals from the external domain can be granted access to resources in the forest. Active Directory creates a "foreign security principal" object to represent each security principal from the trusted external domain. These foreign security principals can become members of domain local groups, which can have members from domains outside of the forest. For more information about trusts, see Domain trusts.

Directory objects for foreign security principals are created by Active Directory and should not be manually modified. You can view foreign security principal objects from Active Directory Users and Computers by enabling Advanced Features. For information about enabling Advanced Features, see View advanced features.

When a trust is established between a Windows 2000 domain in a particular forest and a Windows 2000 domain outside of that forest, security principals from the external domain can be granted access to resources in the internal domain. Active Directory creates a "foreign security principal" object in the internal domain to represent each security principal from the trusted external domain. These foreign security principals can become members of domain local groups in the internal domain. (Domain local groups can have members from domains outside of the forest.) For more information about trusts, see Domain trusts.

Active Directory user accounts

An Active Directory user account enables a user to log on to computers and domains with an identity that can be authenticated and authorized for access to domain resources. Each user who logs on to the network should have his or her own unique user account and password. User accounts can also be used as service accounts for some applications.

Windows 2000 provides predefined user accounts that you can use to log on to a computer running Windows 2000. These predefined accounts are:

  • Administrator account
  • Guest account

Predefined accounts are default user accounts designed to let users log on to a local computer and access resources on the local computer. These are designed primarily for initial logon and configuration of a local computer. Each predefined account has a different combination of rights and permissions. The Administrator account has the most extensive rights and permissions while the Guest account has limited rights and permissions.

If predefined account rights and permissions are not modified or disabled by a network administrator, they could be used by any user or service to log on to a network using the Administrator or Guest identity. To obtain the security of user authentication and authorization, create an individual user account for each user who will participate on your network by using Active Directory Users and Computers. Each user account (including the Administrator and Guest account) can then be added to Window 2000 groups to control the rights and permissions assigned to the account. Using accounts and groups that are appropriate for your network ensures that users logging on to a network can be identified and can access only the permitted resources.

Active Directory user account options

Each Active Directory user account has a number of security related options that determine how someone logging on with that particular user account is authenticated on the network. Several of these options are specific to passwords:

  • User must change password at next logon
  • User cannot change password
  • Password never expires
  • Store passwords using reversible encryption

These options are self-explanatory except for Store passwords using reversible encryption. If you have users logging on to your Windows 2000 network from Apple computers, select this option for those user accounts.

Select the Account disabled option to prevent users from logging on with the selected account. Many administrators use disabled accounts as templates for common user accounts.

You can use the remaining options to configure security-specific information for Active Directory user accounts:

  • Smart card required for interactive logon
  • Account is trusted for delegation
  • Account is sensitive and cannot be delegated
  • Use DES encryption types for this account
  • Don't require Kerberos preauthentication

Select the Smart card required for interactive logon option to securely store public and private keys, passwords, and other types of personal information for this user account. There must be a smart card reader attached to the user's computer, and they must have a personal identification number (PIN) to be able to log on to the network.

Select the Account is trusted for delegation option to give a user the ability to assign responsibility for management and administration of a portion of the domain namespace to another user, group, or organization.

Select the Account is sensitive and cannot be delegated option if this account cannot be assigned for delegation by another account.

Select the Don't require Kerberos preauthentication option if the account uses another implementation of the Kerberos protocol. Not all implementations or deployments of the Kerberos protocol use this feature. The Kerberos Key Distribution Center uses ticket-granting tickets for obtaining network authentication in a domain. The time at which the Key Distribution Center issues a ticket-granting ticket is important to the Kerberos protocol. Windows 2000 uses other mechanisms to synchronize time, so using the Kerberos preauthentication option works well.

Select the Use DES encryption types for this account option if you need the Data Encryption Standard (DES). DES supports multiple levels of encryption, including MPPE Standard (40-bit), MPPE Standard (56-bit), MPPE Strong (128-bit), IPSec DES (40-bit), IPSec 56-bit DES, and IPSec Triple DES (3DES). For more information on any of these encryption types, see Windows 2000 Help.

Computer accounts

Every computer running Windows 2000 or Windows NT that joins a domain has a computer account. Similar to user accounts, computer accounts provide a means for authenticating and auditing the computer's access to the network, and access to domain resources. Each computer connected to the network should have its own unique computer account. Computer accounts are also created using Active Directory Users and Computers.

Note

  • Computers running Windows 98 and Windows 95 do not have the advanced security features of those running Windows 2000 and Windows NT, and cannot be assigned computer accounts in Windows 2000 domains. However, you can log on to a network and use Windows 98 and Windows 95 computers in Active Directory domains. For more information, see Active Directory clients.


Understanding Group Policy

Group Policy settings affect computer or user accounts and can be applied to sites, domains, or organizational units. It can be used to configure security options, manage applications, manage desktop appearance, assign scripts, and redirect folders from local computers to network locations.

Here are a few examples of how Group Policy settings can be used:

  • Set the minimum password length and the maximum length of time that a password will remain valid. This can be configured for an entire domain.
  • Administrators can automatically install an application on every computer in a particular domain or on all computers assigned to a particular group in a particular site. For example, you could automatically install Microsoft Outlook on every computer in the domain and automatically install Microsoft Excel only on those computers belonging to the Accounting group in a particular site.
  • Unique logon and logoff scripts can be assigned to the user accounts in each organizational unit.
  • If members of a particular group often use different computers, administrators can install the necessary applications on each of those computers.
  • Any user's My Documents folder can be redirected to a network location. Users can then gain access to their documents from any computer on the network.

For more information about Group Policy, see Group Policy.


Understanding DNS integration

While Active Directory is integrated with DNS and shares the same namespace structure, it is important to note the difference between them:

  • DNS is a name resolution service.

    • DNS clients send DNS name queries to their configured DNS server. The DNS server receives the name query and either resolves the name query through locally stored files or consults another DNS server for resolution. DNS does not require Active Directory to function.

  • Active Directory is a directory service

    • Active Directory provides an information repository and services to make information available to users and applications. Active Directory clients send queries to Active Directory servers using the Lightweight Directory Access Protocol (LDAP). In order to locate an Active Directory server, an Active Directory client queries DNS. Active Directory requires DNS to function.

Active Directory uses DNS as a locator service, resolving Active Directory domain, site, and service names to an IP address. To log on to an Active Directory domain, an Active Directory client queries their configured DNS server for the IP address of the LDAP service running on a domain controller for a specified domain. For more information on how Active Directory clients rely on DNS, see Active Directory clients.

Requirements of DNS servers for Active Directory

In order for Active Directory to function properly, DNS servers must provide support for Service Location (SRV) resource records described in RFC 2052, A DNS RR for specifying the location of services (DNS SRV). SRV resource records map the name of a service to the name of a server offering that service. Active Directory clients and domain controllers use SRV records to determine the IP addresses of domain controllers. Although not a technical requirement of Active Directory, it is highly recommended that DNS servers provide support for DNS dynamic updates described in RFC 2136, Observations on the use of Components of the Class A Address Space within the Internet.

The Windows 2000 DNS service provides support for both SRV records and dynamic updates. If a non-Windows 2000 DNS server is being used, verify that it at least supports the SRV resource record. If not, it must be upgraded to a version that does support the use of the SRV resource record. For example, Windows NT Server 4.0 DNS servers must be upgraded to Service Pack 4 or later to support SRV resource records. A DNS server that supports SRV records but does not support dynamic update must be updated with the contents of the Netlogon.dns file created by the Active Directory Installation wizard while promoting a Windows 2000 Server to a domain controller. The Netlogon.dns file is described in the following section.

DNS servers and the Active Directory Installation wizard

By default, the Active Directory Installation wizard attempts to locate an authoritative DNS server for the domain being configured from its list of configured DNS servers that will accept a dynamic update of an SRV resource record. If found, all the appropriate records for the domain controller are automatically registered with the DNS server after the domain controller is restarted.

If a DNS server that can accept dynamic updates is not found, either because the DNS server does not support dynamic updates or dynamic updates are not enabled for the domain, the following steps are taken to ensure that the installation process is completed with the necessary registration of the SRV resource records:

  1. The DNS service is installed on the domain controller and is automatically configured with a zone based on the Active Directory domain.

    2. For example, if the Active Directory domain that you chose for your first domain in the forest was example.microsoft.com, a zone rooted at the DNS domain name of example.microsoft.com is added and configured to use the DNS service on the new domain controller.

  2. A text file containing the appropriate DNS resource records for the domain controller is created.

    3. The file called Netlogon.dns is created in the %systemroot%\System32\config folder and contains all the records needed to register the resource records of the domain controller. Netlogon.dns is used by the Windows 2000 NetLogon service and to support Active Directory for non-Windows 2000 DNS servers.

If you are using a DNS server that supports the SRV resource record but does not support dynamic updates (such as a UNIX-based DNS server or a Windows NT Server 4.0 DNS server), you can import the records in Netlogon.dns into the appropriate primary zone file to manually configure the primary zone on that server to support Active Directory.


Understanding Groups

This section covers:

  • Group types
  • Group scope
  • Builtin and predefined groups
  • Special identities
  • Groups on Windows 2000 Professional and stand-alone servers
  • Nesting groups
  • Domain modes and groups
  • How groups impact network performance


Group types

There are two types of groups in Windows 2000:

  • Security groups
  • Distribution groups

Security groups are listed in discretionary access control lists (DACLs) that define permissions on resources and objects. Security groups can also be used as an e-mail entity. Sending an e-mail message to the group sends the message to all the members of the group.

Distribution groups are not security-enabled. They cannot be listed in DACLs. Distribution groups can be used only with e-mail applications (such as Exchange), to send e-mail to collections of users. If you do not need a group for security purposes, create a distribution group instead of a security group.

For specific group administration procedures, See Manage Groups.

Note

  • Although a contact can be added to a security group as well as to a distribution group, contacts cannot be assigned rights and permissions. Contacts in a group can be sent e-mail.

Converting between security and distribution groups

A group can be converted from a security group to a distribution group, and vice versa, at any time, but only if the domain is in native-mode. No groups can be converted while a domain is in mixed-mode.

For specific procedural information, see Convert a group to another group type.


Group scope

Each security and distribution group has a scope that identifies the extent to which the group is applied in the domain tree or forest. There are three different scopes: universal, global, and domain local.

  • Groups with universal scope can have as their members groups and accounts from any Windows 2000 domain in the domain tree or forest and can be granted permissions in any domain in the domain tree or forest. Groups with universal scope are referred to as universal groups.
  • Groups with global scope can have as their members groups and accounts only from the domain in which the group is defined and can be granted permissions in any domain in the forest. Groups with a global scope are referred to as global groups.
  • Groups with domain local scope can have as their members groups and accounts from a Windows 2000 or Windows NT domain and can be used to grant permissions only within a domain. Groups with a domain local scope are referred to as domain local groups.

If you have multiple forests, users defined in only one forest cannot be placed into groups defined in another forest, and groups defined in only one forest cannot be assigned permissions in another forest.

The following table summarizes the behaviors of the different group scopes.

Universal scope | Global scope | Domain local scope
In native-mode domains, can have as their members accounts from any domain, global groups from any domain and universal groups from any domain. | In native-mode domains, can have as their members accounts from the same domain and global groups from the same domain. | In native-mode domains, can have as their members accounts, global groups, and universal groups from any domain, as well as domain local groups from the same domain.
In native-mode domains, security groups with universal scope cannot be created. | In native-mode domains, can have as their members accounts from the same domain. | In native-mode domains, can have as their members accounts and global groups from any domain.
Groups can be put into other groups (when the domain is in native-mode) and assigned permissions in any domain. | Groups can be put into other groups and assigned permissions in any domain. | Groups can be put into other domain local groups and assigned permissions only in the same domain.
Cannot be converted to any other group scope. | Can be converted to universal scope, as long as it is not a member of any other group having global scope. | Can be converted to universal scope, as long as it does not have as its member another group having domain local scope.

Changing group scope

When creating a new group, by default, the new group is configured as a security group with global scope regardless of the current domain mode. Although changing a group scope is not allowed in mixed-mode domains, the following conversions are allowed in native-mode domains:

  • Global to universal. However, this is only allowed if the group is not a member of another group having global scope.
  • Domain local to universal. However, the group being converted cannot have as its member another group having domain local scope.

For specific procedural information, see To change group scope.


Builtin and predefined groups

Several default groups are installed in the Builtin and Users folders of the Active Directory Users and Computers console when you install a domain controller. These groups are security groups and represent common sets of rights and permissions that you can use to grant certain roles, rights, and permissions to the accounts and groups that you place into the default groups.

Default groups with domain local scope are located in the Builtin folder. Predefined groups with global scope are located in the Users folder. You can move the Builtin and predefined groups to other group or organizational unit folders within the domain, but you cannot move them to other domains.

Builtin groups

The default groups placed in the Builtin folder for Active Directory Users and Computers are:

  • Account Operators
  • Administrators
  • Backup Operators
  • Guests
  • Print Operators
  • Replicator
  • Server Operators
  • Users

These builtin groups have domain local scope and are primarily used to assign default sets of permissions to users who will have some administrative control in that domain. For example, the Administrators group in a domain has a broad set of administrative authority over all accounts and resources in the domain.

The following table shows the default rights held by these groups:

User right | Allows | Groups assigned this right by default
Access this computer from the network | Connect to the computer over the network. | Administrators, Everyone, Power Users
Back up files and file folders | Back up files and folders. This right supersedes file and folder permissions. | Administrators, Backup Operators
Bypass traverse checking | Move between folders to access files, even if the user has no permission to access the parent file folders. | Everyone
Change the system time | Set the time for the internal clock of the computer. | Administrators, Power Users
Create a pagefile | This right has no effect. | Administrators
Debug programs | Debug various low-level objects, such as threads. | Administrators
Force shutdown from a remote system | Shut down a remote computer. | Administrators
Increase scheduling priority | Boost the execution priority of a process. | Administrators, Power Users
Load and unload device drivers | Install and remove device drivers. | Administrators
Log on locally | Log on at the computer from the computer keyboard. | Administrators, Backup Operators, Everyone, Guests, Power Users, and Users
Manage auditing and security log | Specify the types of resource access (such as file access) that are to be audited, and view and clear the security log. This right does not allow a user to set system auditing policy. Members of the Administrators group can always view and clear the security log. | Administrators
Modify firmware environment variables | Modify system environment variables stored in nonvolatile RAM on computers that support this type of configuration. | Administrators
Profile single process | Perform profiling (performance sampling) on a process. | Administrators, Power Users
Profile system performance | Perform profiling (performance sampling) on the computer. | Administrators
Restore files and file folders | Restore backed-up files and file folders. This right supersedes file and directory permissions. | Administrators, Backup Operators
Shut down the system | Shut down Windows 2000. | Administrators, Backup Operators, Everyone, Power Users, and Users
Take ownership of files or other objects | Take ownership of files, folders, printers, and other objects on (or attached to) the computer. This right supersedes permissions protecting objects. For information about file and folder permissions, see Shared folder permissions. | Administrators

Predefined groups

The predefined groups placed in the Users folder for Active Directory Users and Computers are:

  • Group name
  • Cert Publishers
  • Domain Admins
  • Domain Computers
  • Domain Controllers
  • Domain Guests
  • Domain Users
  • Enterprise Admins
  • Group Policy Admins
  • Schema Admins

You can use these groups with global scope to collect the various types of user accounts in that domain (regular users, administrators, and guests) into groups. These groups can then be placed in groups with domain local scope in that domain and others.

By default, any user account you create in a domain is automatically added to the Domain Users group and any computer account you create is automatically added to the Domain Computers group. You can use the Domain Users and Domain Computers groups to represent all the accounts created in the domain. For example, if you want all the users in this domain to have access to a printer, you can assign permissions for the printer to the Domain Users group (or put the Domain Users group into a domain local group that has permissions for the printer). For more information on group usage strategies, see Strategies for using groups.

By default, the Domain Users group in a domain is a member of the Users group in the same domain.

The Domain Admins group can represent the users who have broad administrative rights in a domain. Windows 2000 Server does not place any accounts in this group automatically, but if you want an account to have sweeping administrative rights in a domain (and possibly other domains), you can put that account into Domain Admins. Because Windows 2000 Server supports delegation of authority, you should not have to grant these broad administrative rights to many users.

By default, the Domain Admins group in a domain is a member of the Administrators group in the same domain.

By default, the Domain Guests group is a member of the Guests group in the same domain, and automatically has as its member the domain's default Guest user account.


Special identities

In addition to the groups in the Builtin and Users folder, Windows 2000 Server includes several special identities. For convenience, these identities are generally referred to as groups. These special groups do not have specific memberships that you can modify, but they can represent different users at different times, depending on the circumstances. The three special groups are:

  • Everyone

    Represents all current network users, including guests and users from other domains. Whenever a user logs on to the network, they are automatically added to the Everyone group.

  • Network

    Represents users currently accessing a given resource over the network (as opposed to users who access a resource by logging on locally at the computer where the resource is located). Whenever a user accesses a given resource over the network, they are automatically added to the Network group.

  • Interactive

    Represents all users currently logged on to a particular computer and accessing a given resource located on that computer (as opposed to users who access the resource over the network). Whenever a user accesses a given resource on the computer to which they are currently logged on, they are automatically added to the Interactive group.

Although the special identities can be assigned rights and permission to resources, you cannot modify or view the memberships of these special identities. You do not see them when you administer groups and cannot place the special identities into groups. Group scopes do not apply to special identities. Users are automatically assigned to these special identities whenever they log on or access a particular resource.


Groups on Windows 2000 Professional and stand-alone servers

Some group features, such as universal groups, group nesting, and the distinction between security groups and distribution groups, are available only on Active Directory domain controllers and member servers. Group accounts on Windows 2000 Professional and Windows 2000 Server stand-alone servers work the same way as in Windows NT 4.0:

  • Only local groups are available to be created locally on the computer.
  • A local group created on one of these computers can be assigned permissions only on that one computer.

A Windows 2000 Professional computer that joins a Windows 2000 domain gets added benefits from the domain. Global groups and universal groups from that domain, as well as global groups and universal groups from all domains in the forest, can be displayed. You can assign permissions for the local computer to these groups or place them in the local computer groups.


Nesting groups

Using nesting, you can add a group as a member of another group. You can nest groups to consolidate group management by increasing the affected member accounts and to reduce replication traffic caused by replication of group membership changes.

Your nesting options depend on whether the domain is in native mode or mixed-mode. Groups in native-mode domains or distribution groups in mixed-mode domains have their membership determined as follows:

  • Groups with universal scope can have as their members: accounts, computer accounts, other groups with universal scope, and groups with global scope from any domain.
  • Groups with global scope can have as their members: accounts from the same domain and other groups with global scope from the same domain.
  • Groups with domain local scope can have as their members: accounts, groups with universal scope, and groups with global scope, all from any domain. They can also have as members other groups with domain local scope from within the same domain.

Security groups in a mixed-mode domain are restricted to the following types of membership:

  • Groups with global scope can have as their members only accounts.
  • Groups with domain local scope can have as their members other groups with global scope and accounts.

Security groups with universal scope cannot be created in mixed-mode domains because universal scope is supported only in Windows 2000 native-mode domains.


Domain modes and groups

The following table summarizes the effect of domain modes on groups. For more details, see Group types, Group scope, and Nesting groups.

Native-mode domains | Mixed-mode domains
Both security and distribution groups can have universal scope. | Only distribution groups can have universal scope.
Full group nesting is allowed. | For security groups, group nesting is limited to groups with domain local scope having as their members groups with global scope (Windows NT 4.0 rule). Full group nesting is allowed for distribution groups.
Groups can be converted freely between security groups and distribution groups. Groups having global or domain local scope can be converted to groups with universal scope. | No group conversions are allowed.

In both native-mode and mixed-mode domains, any group can have contacts, as well as accounts as members.


How groups impact network performance

When a user logs on to a Windows 2000 network, the Windows 2000 domain controller determines which groups the user belongs to. Windows 2000 creates a security token and assigns it to the user. The security token lists the user account ID and the security IDs of all the security groups the user belongs to. Group membership can impact network performance through:

  • Log on effects
  • Replication of groups with universal scope
  • Network bandwidth

Log on effects

Building the security token takes time, so the more security groups that a user belongs to, the longer it will take to build that user's security token and the longer it will take that user to log on to the network. The significance of this effect will vary depending upon network bandwidth as well as the configuration of the domain controller that handles the log on process.

Sometimes you may want to create a group for e-mail purposes only, with no intention of using that group to assign rights and permissions to its members. To improve logon performance, create such groups as distribution groups instead of security groups. Because distribution groups are ignored when Windows 2000 builds the user security token during the logon process, this reduces both the size of the token, and the time it takes to build it.

Universal group replication

Changes to the data stored in the global catalog are replicated to every global catalog in the forest. Groups having universal scope and their members are listed in the global catalog. Whenever one member of a group with universal scope changes, the entire group membership must be replicated to all global catalogs in the domain tree or forest.

Groups having global or domain local scope are also listed in the global catalog, but their members are not. This reduces the size of the global catalog, and dramatically reduces the replication traffic needed to keep the global catalog up to date. You can improve network performance by using groups with global or domain local scope for directory objects that will change frequently.

Network bandwidth

Each user's security token is sent to every computer that the user accesses so the target computer can determine whether the user has any rights or permissions at that computer by comparing all the security IDs contained in the token against the permissions listed for any resources at that computer. The target computer also checks whether any of the security IDs in the token belong to any local groups at the target computer.

The more groups a user belongs to, the larger their security tokens will be. If your network has a large number of users, the effect of these large security tokens on your network bandwidth and domain controller processing capability can be significant.

For example, suppose a particular domain contains 500 file shares, each with a corresponding assignment for a group with domain local scope used to grant read access. If most users have read access to most shares, then most employees will have about 500 group security IDs added to their token. This can take a significant amount of time and add considerable data traffic to the network.


Active Directory directory service

This section covers:

  • Active Directory object names
  • Active Directory clients
  • Directory data store
  • Global catalog
  • Directory access protocol
  • Single master operations
  • Replication
  • Understanding the Active Directory schema


Active Directory object names

Every object in Active Directory is an instance of a class defined in the Active Directory schema. Each class has attributes that ensure:

  • Unique identification of each object (instance of a class) in a directory data store
  • Backward compatibility with security IDs used in Windows NT 4.0 and earlier
  • Compatibility with LDAP standards for directory object names

For more information about schema, classes, and attributes, see Active Directory schema overview.

Each object in Active Directory can be referenced by several different names. Active Directory creates a relative distinguished name and a canonical name for each object based upon information that was provided when the object was created or modified. Each object can also be referenced by its distinguished name, which is derived from the relative distinguished name of the object and all of its parent container objects.

  • The LDAP relative distinguished name uniquely identifies the object within its parent container. For example, the LDAP relative distinguished name of a computer named my computer is CN=mycomputer.
  • The LDAP distinguished name is globally unique. For example, the distinguished name of a computer named mycomputer in the MyOrganizationalUnit organizational unit in the microsoft.com domain is CN=mycomputer, OU=MyOrganizationalUnit, DC=microsoft, DC=com.
  • The canonical name is constructed the same way as the distinguished name, but it is represented using a different notation. The canonical name of the computer in the previous example would be Microsoft.com/MyOrganizationalUnit/mycomputer.

Security principal objects are Active Directory objects that are assigned security identifiers and can be used to log on to the network and can be granted access to domain resources. An administrator needs to provide names for security principal objects (user accounts, computer accounts, and groups) that are unique within a domain.

Consider what occurs when a new user account is added to your directory. You provide a name the user must use to log on to the network, the name of the domain that contains the user account, and other descriptive data, such as first name, last name, telephone number and so on (called attributes). All this information is recorded in the directory.

The names of security principal objects can contain all Unicode characters except the special LDAP characters defined in RFC 2253. This list of special characters includes: a leading space; a trailing space; and any of the following characters: # , + " \ < > ;

Security principal names must conform to the following guidelines:

Type of account name | Maximum size | Special limitations
User account | 20 characters, or 20 bytes depending upon the character set; individual characters may require more than one byte. | A user account cannot consist solely of periods (.), spaces, or the at (@) sign. Any leading periods or spaces are cropped.
Computer account | 15 characters, or 15 bytes depending upon the character set; individual characters may require more than one byte. | A computer account cannot consist solely of numbers, periods (.), or spaces. Any leading periods or spaces are cropped.
Group account | 63 characters, or 63 bytes depending upon the character set; individual characters may require more than one byte. | A group account cannot consist solely of numbers, periods (.), or spaces. Any leading periods or spaces are cropped.

Note

  • If the administrator changes the default security settings, it is possible to use computer names containing more than 15 characters. For more information, see Domain and account naming.

From the information provided by the person who creates the security principal object, Active Directory generates a security ID, and a globally unique ID used to identify the security principal. Active Directory also creates an LDAP relative distinguished name, based on the security principal name. An LDAP distinguished name and a canonical name are derived from the relative distinguished name and the names of the domain and container contexts in which the security principal object is created.

If your organization has several domains, it is possible to use the same user name or computer name in different domains. The security ID, globally unique ID, LDAP distinguished name, and canonical name generated by Active Directory will uniquely identify each user, computer, or group in the forest. If the security principal object is renamed or moved to a different domain, the security ID, LDAP relative distinguished name, LDAP distinguished name, and canonical name will change, but the globally unique ID generated by Active Directory will not change.

Security principal objects, such as user accounts, may be renamed, moved, or contained within a nested domain hierarchy. To reduce the effect of renaming, moving, or assigning user account names within a nested domain hierarchy, Active Directory provides a method for simplifying user logon names. For information about user logon names, see Domain and account naming and Add user principal name suffixes, and Active Directory user and computer accounts.


Active Directory clients

The Active Directory client is network client software for computers connecting to Active Directory networks. A computer configured with the Active Directory client can log on to the network by locating a domain controller. The client can then fully benefit from the features of Active Directory.

Computers with Active Directory clients are:

  • Computers running Windows 2000 Server or Windows 2000 Professional.
  • Computers running Windows 98 or Windows 95 that have add-on Active Directory client software installed.

The Active Directory client is provided in a single upgrade pack in a Clients folder on the Windows 2000 Server compact disc.

Locating a domain controller

To logon to an Active Directory network, an Active Directory client must first locate an Active Directory domain controller for their domain. To locate a domain controller for a specified domain, an Active Directory client sends a DNS name query to its configured DNS server(s) with the following characteristics:

  • Query type: SRV (Service locator resource record)
  • Query name: _ldap._tcp.domain_name

For example, to logon to the domain microsoft.com, an Active Directory client sends a DNS name query of the type SRV for the name _ldap._tcp.microsoft.com.

The response from the DNS server contains the DNS names of the domain controllers and their IP addresses. From the list of domain controller IP addresses, the client attempts to contact each domain controller to ensure that it is operational. The first domain controller to respond is the domain controller that is used for the logon process.

For more details on this process and details of other types of queries made by Active Directory clients to locate other types of Active Directory servers, see the Windows 2000 Resource Kit.


Directory data store

Active Directory directory service uses a replicated data store. This data store is often simply referred to as the directory. The directory contains information about objects such as users, groups, computers, domains, organizational units, and security policies. This information can be published for use by users and administrators.

The directory is stored on domain controllers and can be accessed by network applications or services. A domain can have one or more domain controllers. Each domain controller has a copy of the directory for the domain in which it is located. Changes made to the directory are replicated from the originating domain controller to other domain controllers in the domain, domain tree, or forest. Because the directory is replicated, and because each domain controller has a copy of the directory, the directory is highly available to users and administrators throughout the domain.

Directory data is stored in the Ntds.dit file on an NTFS partition on the domain controller. Private data is stored securely, and public directory data is stored on a shared system volume where it can be replicated to other domain controllers in the domain.

There are three categories of directory data replicated between domain controllers:

  • Domain data

    • The domain data contains information about objects within a domain. This is the information typically thought of as directory information such as e-mail contacts, user and computer account attributes, and published resources that are of interest to administrators and users.

    For example, when a user account is added to your network, a user account object and attribute data are stored in the domain data. When changes to your organization's directory objects occur, such as object creation, deletion, or attribute modification, this data is stored in the domain data.

  • Configuration data

    • The configuration data describes the topology of the directory. This configuration data includes a list of all domains, trees, and forests, and the locations of the domain controllers and global catalogs.

  • Schema data

    • The schema is the formal definition of all object and attribute data that can be stored in the directory. Windows 2000 Server includes a default schema that defines many object types, such as user and computer accounts, groups, domains, organizational units, and security policies. Administrators and programmers can extend the schema by defining new object types and attributes, or by adding new attributes for existing objects. Schema objects are protected by access control lists, ensuring that only authorized users can alter the schema.

    For a more detailed discussion of the schema, see Active Directory schema.

Note

  • If the domain controller is also a global catalog, it stores a subset of the directory data for all other domains in the forest. For more information about domain controllers, see Domain controllers. For more information about the global catalog, see Global catalog.


Global catalog

By default, a global catalog is created automatically on the initial domain controller in the forest. It stores a full replica of all objects in the directory for its host domain and a partial replica of all objects contained in the directory of every other domain in the forest. The replica is partial because it stores some, but not all, of the property values for every object in the forest. The global catalog performs two key directory roles:

  • It enables network logon by providing universal group membership information to a domain controller when a logon process is initiated.
  • It enables finding directory information regardless of which domain in the forest actually contains the data.

When a user logs on to the network, the global catalog provides universal group membership information for the account sending the logon request to the domain controller. If there is only one domain controller in the domain, the domain controller and the global catalog are the same server. If there are multiple domain controllers in the network, the global catalog is hosted on the domain controller configured as such. If a global catalog is not available when a user initiates a network logon process, the user is only able to log on to the local computer.

Important

  • If a user is a member of the Domain Admins group, they are able to log on to the network even when a global catalog is not available.

The global catalog is designed to respond to user and programmatic queries about objects anywhere in the forest with maximum speed and minimum network traffic. Because a single global catalog contains information about objects in all domains in the forest, a query about an object can be resolved by a global catalog in the domain in which the query is initiated. Thus, finding information in the directory does not produce unnecessary query traffic across domain boundaries.

You can optionally configure any domain controller to host a global catalog, based on your organization's requirements for servicing logon requests and search queries.

After additional domain controllers are installed in the domain, you can change the default location of the global catalog to another domain controller using Active Directory Sites and Services.

Active Directory defines a base set of attributes for each object in the directory. Each object and some of its attributes (such as universal group memberships) are stored in the global catalog. Using Active Directory Schema, you can specify additional attributes to be kept in the global catalog. However, adding a new attribute to the global catalog causes a full synchronization of all of object attributes stored in the global catalog (for all of the domains in the forest). In a large, multi-domain forest, this one-time synchronization can cause significant network traffic.


Directory access protocol

Active Directory clients must communicate with computers running Active Directory during logon to the network and when searching for shared resources. Access to domain controllers and global catalogs is performed using the Lightweight Directory Access Protocol (LDAP).

Lightweight Directory Access Protocol

LDAP is a communication protocol designed for use on TCP/IP networks. LDAP defines how a directory client can access a directory server and how the client can perform directory operations and share directory data. LDAP standards are established by working groups of the Internet Engineering Task Force (IETF). Active Directory implements the LDAP attribute draft specifications and the IETF standards for LDAP versions 2 and 3.

As its name implies, LDAP is designed as an efficient method for accessing directory services without the complexity of other directory service protocols. Because LDAP defines what operations can be performed to query and modify information in a directory and how information in a directory can be securely accessed, you can use LDAP to find or enumerate directory objects and to query or administer Active Directory.

LDAP and interoperability

LDAP is an open Internet standard. By using LDAP, Active Directory enables interoperability with other vendor directory services. Active Directory support for LDAP includes an LDAP provider object as part of Active Directory Service Interfaces (ADSI). ADSI supports the C-binding application programming interfaces for LDAP specified by Internet standard RFC 1823. Other directory service applications can be easily modified to access information in Active Directory by using ADSI and LDAP.

For more information about LDAP see, the Internet Engineering Task Force at the The Internet Engineering Task Force (http://www.ietf.org/) Web site.


Single master operations

Active Directory supports multimaster replication of the directory data store between all domain controllers in the domain. Some changes are impractical to perform in multimaster fashion, however, so only one domain controller, called the operations master, accepts requests for such changes.

Because the operations master roles can be moved to other domain controllers within the domain or forest, these roles are sometimes referred to as flexible single master operations.

In any Active Directory forest, there are five operations master roles that are assigned to one or more domain controllers. Some roles must appear in every forest. Other roles must appear in every domain in the forest.

Forest-wide operations master roles

Every Active Directory forest must have the following roles:

  • Schema master
  • Domain naming master

These roles must be unique in the forest. This means that throughout the entire forest there can be only one schema master and one domain naming master.

Schema master

The schema master domain controller controls all updates and modifications to the schema. To update the schema of a forest, you must have access to the schema master. At any time, there can be only one schema master in the entire forest.

Domain naming master

The domain controller holding the domain naming master role controls the addition or removal of domains in the forest. There can be only one domain naming master in the entire forest at any time.

Domain-wide operations master roles

Every domain in the forest must have the following roles:

  • Relative ID master
  • Primary domain controller (PDC) emulator
  • Infrastructure master

These roles must be unique in each domain. This means that each domain in the forest can have only one relative ID master, PDC emulator, and infrastructure master.

Relative ID master

The relative ID master allocates sequences of relative IDs to each of the various domain controllers in its domain. At any time, there can be only one domain controller acting as the relative ID master in each domain in the forest.

Whenever a domain controller creates a user, group, or computer object, it assigns the object a unique security ID. The security ID consists of a domain security ID (that is the same for all security IDs created in the domain), and a relative ID that is unique for each security ID created in the domain.

To move an object between domains (using Movetree.exe), you must initiate the move on the domain controller acting as the relative ID master of the domain that currently contains the object.

PDC emulator

If the domain contains computers operating without Windows 2000 client software or if it contains Windows NT backup domain controllers (BDCs), the PDC emulator acts as a Windows NT primary domain controller. It processes password changes from clients and replicates updates to the BDCs. At any time, there can be only one domain controller acting as the PDC emulator in each domain in the forest.

In a Windows 2000 domain operating in native-mode, the PDC emulator receives preferential replication of password changes performed by other domain controllers in the domain. If a password was recently changed, that change takes time to replicate to every domain controller in the domain. If a logon authentication fails at another domain controller due to a bad password, that domain controller will forward the authentication request to the PDC emulator before rejecting the log on attempt.

Infrastructure master

The infrastructure master is responsible for updating the group-to-user references whenever the members of groups are renamed or changed. At any time, there can be only one domain controller acting as the infrastructure master in each domain.

When you rename or move a member of a group (and that member resides in a different domain from the group), the group may temporarily appear not to contain that member. The infrastructure master of the group's domain is responsible for updating the group so it knows the new name or location of the member. The infrastructure master distributes the update via multimaster replication.

There is no compromise to security during the time between the member rename and the group update. Only an administrator looking at that particular group membership would notice the temporary inconsistency.

For information about where single master operations are installed by default and about how to optimize their placement in your network, see Planning operations master locations. For information about transferring operations master roles, see Transferring operations master roles. For information about what to do when an operations master fails, see Responding to operations master failures.


Replication

To learn more about replication, see:

  • Replication goals and strategies
  • How directory partitions affect replication
  • How replication works
  • Replication options


Replication goals and strategies

Users and services should be able to access directory information at any time from any computer in the forest. To make this possible, additions, modifications, and deletions of directory data must be relayed to other domain controllers. For more information on what types of directory data are replicated to domain controllers as opposed to global catalogs, see How replication works.

For example, if you change your account's password in your organization's Seattle office, your new password must be valid when you log on with the same account at the Sydney office. This is made possible by replicating the directory changes to other domain controllers, including that in the Sydney office. For more information on where different types of directory information are distributed, see How replication works.

Directory information must be widely distributed, but this must be balanced with your need to optimize network performance. If directory updates are constantly distributed to all other domain controllers in the domain, they will consume your network resources. Although you can manually add or configure connections or force replication over a particular connection, normally you should allow replication to be automatically optimized by the Active Directory knowledge consistency checker based on information you provide to Active Directory Sites and Services about your deployment. For more information, see To manually add or configure connections and To force replication over a connection.

Windows 2000 uses sites and replication change control to optimize replication:

  • By occasionally re-evaluating which connections are used, Active Directory uses the most efficient network connections.
  • Active Directory uses multiple routes to replicate changes, providing fault tolerance.
  • Replication costs are minimized by only replicating changed information.

Replication between sites

Network connections are represented by site links. By creating site links and configuring their replication availability, cost, and replication frequency, you provide the Active Directory knowledge consistency checker with information about what Connection objects to create to replicate directory data. Active Directory uses site links as indicators for where it should create Connection objects, and Connection objects use the actual network connections to exchange directory information. Without site links, Connection objects that use network connections to connect sites will not be created, and domain controllers will be isolated within their sites: unable to send or receive directory updates to or from other domain controllers outside of their own site. To avoid this, create site links to connect multiple sites.

When you create a site, you may want to create more links to enable specific connections between sites and customize existing site links connecting the sites. Overlapping site links can be linked together into site link bridges, or you can bridge all site links, maximizing available site link connectivity. Such a site link configuration maximizes replication of directory information.

Creating site link bridges or bridging all site links maximizes replication, but errors will occur if there are domain controllers in a single site link or in bridged site links that span a firewall. Because all domain controllers in a site link or site link bridge attempt to send directory updates to other domain controllers in their site or site link, they may send updates to domain controllers that are on the opposite side of a firewall. If this occurs, those attempts will fail unless the sender is also the firewall proxy server. Therefore, if you have domain controllers on different sides of a firewall and the firewall is configured in such a way that allows packet transmission between specific computers only, do not place them all in one site, even if they are well-connected. Instead, add all domain controllers that are on the same side of a firewall to a site link and establish the firewall proxy as the preferred bridgehead server for the site link. By doing so, the firewall will not block replication.

Site links are not automatically generated. For more information, see To bridge all site links.

After the first domain controller is installed, all other domain controllers are automatically added to the same site as the original domain controller, unless one of the three following conditions is met:

  • You provide an alternative default site using Active Directory Sites and Services.
  • At the time you install the domain controller, its IP address falls within the subnet previously specified in an alternate site. The domain controller is then added to this alternate site.
  • You have already moved a domain controller from another site to the site to which you are adding the new domain controller. In this case, the new domain controller is added to the site that contains the previously moved domain controller.

    • Note

    • In general, you can install a domain controller into a site that has existing domain controllers. The exception to this rule is the first domain controller installed, which automatically creates the Default-First-Site site. You cannot create a first domain controller in any site but Default-First-Site, but you can create a domain controller in a site that has a previously existing domain controller and then move it to another site. Therefore, after the first domain controller has been installed, creating Default-First-Site, you can create other domain controllers in this site and then move them to alternative sites.

Active Directory automatically creates connections (Connection objects) within a site, but connections between sites are not automatically generated unless the site is in a site link and the site contains a domain controller. Connection objects are required for replication.

Notes

  • It is possible to change information (like the description) about connection objects that were automatically created by the knowledge consistency checker; however, the next time the connection object is automatically created, any changes you made to that object will be lost.
  • If network connections are available, you should use Active Directory Sites and Services to add site links that correspond to the network connections. For more information on adding site links, see To create a site link.

Example 1

Consider the following example of a deployment including sites in Seattle, Atlanta, Mexico City, and Sydney.

Four sites connected by site links. Sites are in Seattle, Atlanta, Mexico City, and Sydney. Seattle, Atlanta, and Mexico City are all directly connected to each other, and Sydney is connected to Mexico City.

In such a deployment, it makes sense to create sites according to geographic boundaries, since computers within any single geographical area are likely to be better connected than computers in different areas. In this example, the sites are connected with site link bridges.

  • Seattle and Mexico City are connected both directly, and through the Atlanta site. If either connection from Seattle to Mexico City becomes unavailable, the other connection can be used to maintain directory information exchange. This sort of redundancy will make the exchange of directory information more reliable. In this case, with multiple routes between sites, establish different site link costs to have one route used preferentially. For example, make the cost for the site link from Seattle to Mexico City high if the bandwidth is more limited than the connections from Seattle to Atlanta and from Atlanta to Mexico City.
  • Since Sydney is not connected directly to either Seattle or Atlanta, the Seattle and Atlanta sites can only exchange directory information with the Sydney site by replicating through the Mexico City site. Such a configuration makes sense only if there are no reliable direct connections from Seattle or Atlanta to Sydney.

Example 2

Consider the following example of two sites connected by a site link. This example presents a total of six domain controllers, two of which are bridgehead servers.

Two sites connected by a site link. Each site contains several servers, one of which is a preferred bridgehead server, meaning it is used preferentially for inter-site information exchange.
  • The two sites are connected by a site link bridge. More sites could be contained in this one site link bridge. Within the site link bridge there is a line representing the connection from each site's bridgehead servers.
  • The bridgehead servers are the preferred servers for replication, but the other domain controllers in the site could be configured to replicate directory changes.
  • After updates are replicated to bridgehead servers in the other site, the updates are then replicated to other domain controllers within the site through intra-site replication. Although a single domain controller receives the initial inter-site directory update, all domain controllers service client requests.

Replication within a site

Directory information within a site is replicated frequently and automatically. The configuration formed by the connections used to replicate directory information between domain controllers, called the replication topology, is automatically generated by Active Directory. Active Directory attempts to establish a topology that allows at least two connections to every domain controller, so if a domain controller becomes unavailable, directory information can still reach all online domain controllers through the other connection.

Active Directory automatically evaluates and adjusts the replication topology to meet the changing state of the network. For example, when a domain controller is added to a site, the replication topology is adjusted to incorporate this new addition efficiently.


How directory partitions affect replication

The information stored in the directory is partitioned into three categories. Each of these information categories is referred to as a directory partition. These directory partitions are the units of replication. The information contained in each directory partition is described as follows:

  • Schema information. This defines the objects that can be created in the directory and what attributes those objects can have. This information is common to all domains in the forest.
  • Configuration information. This describes the logical structure of your deployment, containing information such as domain structure or replication topology. This information is common to all domains in the forest.
  • Domain data. This describes all of the objects in a domain. This data is domain-specific and is not distributed to any other domains. For the purpose of finding information throughout the domain tree or forest, a subset of the properties for all objects in all domains is stored in the global catalog.

Schema and configuration information is replicated to all domain controllers in the forest. All of the domain data for a particular domain is replicated to every domain controller in that domain. All of the objects in every domain, and a subset of the properties of all objects in the forest, are replicated to the global catalog.

A domain controller stores and replicates:

  • The schema information for the forest
  • The configuration information for all domains in the forest
  • All directory objects and properties for its domain. This data is replicated to any additional domain controllers in the domain.

For more information about domain controllers, see Domain controllers.

A global catalog is hosted on a domain controller. Every forest has at least one global catalog. The initial global catalog is automatically created during installation of the first domain controller in the forest. You must enable at least one domain controller as a global catalog in every site, since a global catalog is necessary to complete the logon authentication process (the global catalog is used to determine an account's group membership).

A global catalog stores and replicates:

  • The schema information for the forest
  • The configuration information for all domains in the forest
  • A subset of the properties for all directory objects in the forest (replicated between global catalogs only)
  • All directory objects and all their properties for the domain in which the global catalog is located

You can add new attributes to the global catalog. Adding a new attribute to the global catalog causes a full synchronization of all of the domain data from all of the domains in the forest. In a large, multi-domain forest, this synchronization can cause significant network traffic. For more information, see To add an attribute to the global catalog and Active Directory schema overview.

The following illustration represents how directory information is exchanged between global catalogs in different domains:

Each global catalog has all schema and configuration data for the forest, all directory objects and their properties for its domain, and a subset of objects and their properties from other domains.

For more information about global catalogs, see Global catalog. When deciding where to place global catalogs, see Global catalog and infrastructure master.

Replication and network sizing

As you expand your deployment from the first domain controller to multiple domain controllers in multiple domains, the directory information that is replicated changes. The increase in complexity develops in the following way:

  • The first domain controller in a domain. The domain controller is also a global catalog. No replication occurs.

    The first domain controller is deployed in a single domain. Because this is the first domain controller, it is also the global catalog. No replication occurs between domain controllers at this point because there are no other domain controllers to which to replicate.

  • Two domain controllers in one domain. One of the domain controllers is a global catalog. The two domain controllers replicate schema, configuration, and all domain data between each other.

    A second domain controller, that does not host a global catalog, is added to the deployment. Replication of directory data directly between the two domain controllers begins. Because the two domain controllers are in the same domain, all directory objects and properties for the domain, as well as the forest's schema and configuration information are replicated between the two computers.

  • Three domain controllers in one domain. One of the domain controllers is a global catalog. The three domain controllers replicate schema information, configuration information, and all domain data between each other.

    A third domain controller, that does not host a global catalog, is added to the deployment. Because the three domain controllers are in the same domain, all directory objects and properties for the domain, as well as the forest's schema and configuration information are replicated between the three computers.

  • Two domains, each containing three domain controllers. Within each domain, the three domain controllers replicate schema, configuration, and all domain data between each other. One domain controller in Domain A is a global catalog, receiving a subset of the directory objects and properties from Domain B.

    A second domain is added. The new domain contains three domain controllers, one of which hosts a global catalog. Within each of the two domains, the three domain controllers replicate between each other all directory objects and properties for the domain, as well as the forest's schema and configuration information. The only global catalog in the forest is in Domain A, so a subset of the directory objects and properties from Domain B is replicated to the global catalog in Domain A.

  • Two domains, each containing three domain controllers. In each domain, one of the domain controllers hosts a global catalog. Within each domain, the three domain controllers replicate schema, configuration, and domain data between each other. Between domains, only a subset of the domain data is replicated to the corresponding global catalog.

    A domain controller in Domain B is configured to host a global catalog. Both domains contain three domain controllers, and in both domains, one of the domain controllers hosts a global catalog. Within each of the two domains, the three domain controllers replicate between each other all directory objects and properties for the domain, as well as the forest's schema and configuration information. Between the two domains, the forest's schema and configuration information and a subset of the directory objects and properties for each domain are replicated to the corresponding (other domain) global catalog.


How replication works

To illustrate Active Directory replication, imagine a hypothetical organization with one domain that spans a multi-site wide area network (WAN). This WAN is comprised of one site in London and one in New York, each with one domain controller.

Domain controllers keep track of how many changes they have made to their copy of the directory, as well as how many changes they have received from domain controllers that are their replication partners. If the London domain controller finds it does not have all the changes from the New York domain controller, the London domain controller can request the new changes, and only the new changes, from the New York domain controller.

This makes updating a domain controller that has been disconnected from the network easy, because it is clear which directory information has changed and therefore needs to be replicated. Because changes are tracked by a numerical sequence, not by time, the need for synchronized clocks is eliminated in all but the most unusual cases, such as when resolving conflicting changes.

Preventing unnecessary replication

Active Directory replicates data through automatically or manually created network connections specified in the directory. This provides fault tolerance, but Active Directory must also ensure that a single change is not replicated multiple times to the same domain controller by different sets of connections. For example, once the London domain controller has applied a change received from the New York domain controller, the London domain controller must indicate that its new information should not be replicated back to the source of the change, the New York domain controller. If not prevented, a cycle of replication like this would continue indefinitely and overwhelm your network.

Active Directory prevents such a scenario by tracking which attribute changed in the updated object and how many times the object's Originating Write property has been incremented. A change that increments an Originating Write property indicates a change a client made to the object, as opposed to a change made by Active Directory when replicating updated directory information. When the New York domain controller is notified that an object in the London directory has changed, it checks to see whether the change set the Originating Write property. If it is not set, no replication change is necessary for the New York directory.

Resolving conflicting changes

It is possible for two different users to make changes to the exact same object property and to have these changes applied at two different domain controllers that are in the same domain before replication of either change can be completed. In such a case, both changes are replicated as new changes to domain controllers and both have their Originating Write property incremented. To resolve this, the domain controller that receives conflicting changes examines the timestamp on each change and accepts the change with the most recent timestamp, discarding the change with the older timestamp. If the timestamps conflict, the change with the highest globally unique identifier (GUID) is accepted.

For more information about the details of conflict resolution and replication, see the Windows 2000 Resource Kit.

Inter-site and intra-site data exchange formats

Inter-site directory updates use data compression to reduce demands on network resources. Compressed data can be transmitted more rapidly, but requires more computing power to compress before sending and decompress upon receipt. Intra-site directory updates are optimized to reduce demands on the processing power of domain controllers, so these exchanges are not compressed. Uncompressed exchanges require more network resources but less processing power.

For more information about replication, see Replication goals and strategies.


Replication options

Replication characteristics are broadly determined by the protocols supported and the configuration of the site links.

Replication protocols

Directory information can be exchanged using different network protocols such as IP or SMTP.

  • SMTP replication. SMTP replication is only used for replication over site links (inter-site), and not for replication within a site (intra-site). Because SMTP is asynchronous, it typically ignores all schedules. Therefore, do not configure site link replication availability on SMTP site links unless the following is true:

    • The site links use scheduled connections.
    • The SMTP queue is not on a schedule.
    • Information is being exchanged directly from one server to another, and not through intermediaries as is the case, for example, on a network Ethernet backbone.

    If your network's SMTP connections meet these conditions, synchronize your SMTP site link replication schedule with the times your network's SMTP connections are available.

    If you choose to use SMTP over site links, you must install and configure an enterprise certification authority. The certification authority (CA) signs SMTP messages that are exchanged between domain controllers, ensuring the authenticity of directory updates. SMTP replication uses 56-bit encryption.

    For more information, see Installing and configuring a certification authority.

  • IP replication. IP replication uses remote procedure calls (RPC) for replication over site links (inter-site) and within a site (intra-site). By default, inter-site IP replication does adhere to replication schedules, although you may configure Active Directory replication to ignore schedules.

    IP replication does not require a CA.

    For more information, see To ignore schedules.

Site link attributes

You should provide availability, cost, and frequency information for all site links as part of the process of providing Active Directory with information about available inter-site connections.

  • Replication availability. Configure site link replication availability to designate when a site link will be available for replication.

    For more information, see To configure site link replication availability.

  • Cost. Configure site link cost to assign a value for the cost of each available connection used for inter-site replication.

    If you have multiple redundant network connections, establish site links for each connection, and then assign costs to these site links that reflect their relative bandwidth. For example, if you have a high speed T-1 line and a dial-up network connection in case the T-1 line is unavailable, configure a lower cost for the T-1 line and a higher cost for the dial-up network connection. Active Directory always chooses the connection on a per-cost basis, so the cheaper connection will be used as long as it is available. Cost does not correspond to a specific unit of measure such as minutes, but is evaluated in comparison to other costs. The cost of a site link only has meaning as it relates to other site links.

    A client should always find a domain controller in its site. If a site does not contain a domain controller, the site link costs for that domain are evaluated by all replication processes. The domain controllers in the closest site are then used to service the site containing that domain.

    For more information, see Bandwidth and To configure site link cost.

    The cost of a site link bridge is the sum of the costs of all links included in the bridge. For example, if a site link bridge contains two site links, one with a cost of three and another with a cost of four, the cost of the site link bridge is seven.

  • Replication frequency. Configure site link replication frequency for site links by providing an integer value that tells Active Directory how many minutes it should wait before using a connection to check for replication updates. The replication interval must be at least 15 and no more than 10,080 minutes (equal to one week). A site link must be available for any replication to occur, so if a site link is scheduled as unavailable when the number of minutes between replication updates has passed, no replication will occur.

    For more information, see To configure site link replication frequency.

Replication over a virtual private network

To enable a steady flow of updated directory information, domain controllers should have a connection constantly available. Such a connection may not be available (such as for smaller branch offices) in which case directory updates can be exchanged through a virtual private network (VPN) established using an Internet Service Provider (ISP). If such a VPN is used to connect to another site, all replication should occur between the domain controllers in the two sites at once, so the connection can be closed when it is no longer needed. This is called reciprocal replication.

When using reciprocal replication between a branch office site's domain controller and a main office site's domain controller, after a VPN is established through an ISP, the branch site domain controller that initiated the connection requests all directory updates from the main site domain controller. After the branch site domain controller receives all updates, it sends a change notification to the main site domain controller, causing the main site domain controller to request all updates, which the branch site domain controller then sends. Since all directory information is current, the ISP connection is closed. Replication does not take place when the connection is not available. This maximizes the efficiency of directory information exchange, while minimizing connection time and eliminating timeout errors that would occur if the main site domain controller tried to request changes from the branch site domain controller when the connection was not available.


Understanding the Active Directory schema

This section covers:

  • Schema changes
  • Schema objects
  • Schema object names
  • Attribute definitions
  • Class types
  • Class definitions
  • Object identifiers
  • Schema cache


Schema changes

When considering changes to the schema, it is very important to remember two key points:

  • Schema changes are global.
  • Schema extensions are not reversible (However, some attributes may be modified after creation).

The entire forest shares a common schema. A copy of the schema exists on every domain controller in the forest. When you extend the schema, you extend the schema for the entire forest because any changes to the schema are replicated to every domain controller in every domain in the forest. One domain controller, the schema operations master, controls modification and extension of the schema. For more information about the schema master, see Single master operations.

Once a new class or attribute has been added to the schema, it can be deactivated, but it cannot be removed. Deactivating a class or attribute prevents new instances from being created. You cannot deactivate an attribute if it is included in any class that is not deactivated. To deactivate a class or attribute, see Deactivate a class or attribute.

For basic information about the schema, see Active Directory schema overview.


Schema objects

There are two types of schema objects, Class Schema objects that define a class, and Attribute Schema objects that define an attribute. So, for each class in the schema, there is a Class Schema object that specifies the class, and for each attribute in the schema, there is an Attribute Schema object that specifies the attribute and enforces constraints on objects that are instances of a class using this attribute.

Some Class Schema object constraints are:

  • A list of mandatory attributes (Must Contain) that must be defined for any object that is an instance of this class.
  • A list of attributes that may be defined (May Contain) for any object that is an instance of the particular class.
  • Hierarchy rules that determine the possible parent Active Directory objects (Poss Superiors) of an object that is an instance of this class.

An object that is an instance of a particular object class can have attributes that belong to either the Must Contain or the May Contain list defined for the class of which that object is an instance. The list of attributes can be explicitly specified for that class or inherited from the parents of that class.

For basic information about the schema, see Active Directory schema overview. For more information about inheritance and the Class Schema object, see Class definitions.


Schema object names

Classes and attributes are schema objects. Each schema object can be referenced in several ways:

  • LDAP display name
  • Common name
  • Object identifier

LDAP display name

Active Directory Schema and other Windows 2000 administrative tools display the LDAP display name of objects. Programmers and system administrators use the LDAP display name to reference the object programmatically. This name is guaranteed to be unique for each object.

The LDAP display name usually consists of two or more words combined. When the name consists of multiple words, the subsequent words in the name are identified using capitalization. For example, the LDAP display names of two attributes are mailAddress and machinePasswordChangeInterval. For more information about LDAP, see the Internet Engineering Task Force (http://www.ietf.org/) Web site.

Common name

The common name is a slightly more "friendly" version of the LDAP display name. It is also guaranteed to be unique. The common names of the two attributes used in the previous example are SMTP-Mail-Address and Machine-Password-Change-Interval.

Object identifier

An object's object identifier is a number issued by an issuing authority such as the International Organization for Standardization (ISO) and the American National Standards Institute (ANSI). For example, the object identifier for the SMTP-Mail-Address attribute is 1.2.840.113556.1.4.786. Every object identifier is guaranteed to be unique.

Schema object naming rules

To help standardize schema naming conventions, Microsoft requires anyone extending the schema to adhere to naming rules for both the LDAP-Display-Name and the Common-Name. Naming rules are a Windows 2000 certification requirement for applications that extend the schema. For detailed information regarding these naming rules, please see the Active Directory chapter of the Windows 2000 Logo document.

For more information about schema object naming rules, see The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/). For basic information about the schema, see Active Directory Schema overview.


Attribute definitions

Attributes describe objects. Each attribute has its own definition that describes the type of information that can be specified for that attribute. Each attribute in the schema is specified in the Attribute-Schema class, which determines the information that each attribute definition must contain.

The list of attributes that can be applied to a particular object are determined by the class of which the object is an instance and by any superclasses of that object's class. Attributes are defined only once and potentially used many times. This ensures consistency across all classes that share a particular attribute.

This does not mean that the value of the attribute will be the same across all instances of a particular class, but that the definition of the attribute will be the same. For example, the Description attribute is defined as a string of characters that can be from 0 (zero) to 1024 characters long. This means that every instance of every class that includes the Description attribute can have a description that is a string of characters from 0 to 1024 characters long. The actual content of that string can be unique for every instance of every class.

Attributes can be single-valued or multivalued. An example of a multivalued attribute is Object-Class. The Object-Class attribute is multivalued because it lists multiple classes: the specific class of the object, and the classes from which the specific class was derived.

All attributes have a syntax that determines the kind of data that the attribute can store. There are a fixed number of syntaxes allowed in the schema. You cannot add additional syntaxes. Some examples of attribute syntaxes are:

  • Boolean: True or false
  • Integer: A number between 0 (zero) and 4,294,967,295
  • NumericString: A character string that contains only numbers

Attributes can have length or range constraints. For attributes with numeric syntax the range specifies the minimum and maximum value. For attributes with string syntax the range specifies the minimum and maximum length. For more information about attribute syntax, see The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/).

Indexed attributes

Attributes can be indexed. Indexing an attribute can help queries more quickly find objects having that attribute. When you mark an attribute as indexed, all instances of the attribute are added to the index, not just the instances that are members of a particular class. To mark an attribute to be indexed in Active Directory, see Index an attribute in Active Directory.

Attributes included in the global catalog

Attributes can also be included in the global catalog. The global catalog contains a subset of attributes for every object in the entire forest. Applications and users use the global catalog to locate objects. Attributes that may be appropriate to include in the global catalog are:

  • Globally useful: The attribute is needed for locating objects that may occur anywhere in the forest, or read access to the attribute is valuable even when the object itself is not accessible.
  • Not volatile: Attributes in a global catalog are replicated to all other global catalogs in the forest. If the attribute changes often, significant replication traffic will result.
  • Small: Attributes in a global catalog are replicated to every global catalog in the forest. The smaller the attribute the lower the impact of that replication. This is a very subjective decision. If the attribute is large but very seldom changes, it will have a smaller replication impact than a small attribute that changes very often.

Attributes that are frequently queried and referenced by users across the enterprise, such as employee names and phone numbers, are good candidates for inclusion in the global catalog. When deciding whether or not to include an attribute in the global catalog, remember that you are trading increased replication and increased disk storage on global catalogs for potentially faster query performance.

For basic information about the schema, see Active Directory Schema overview. For more information about attribute definitions, see The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/). To include an attribute in the global catalog, see Add an attribute to the global catalog.


Class types

The Active Directory schema includes three types of classes:

  • Structural class: This is the only class type from which Active Directory objects can actually be created. Structural classes can be derived from either a structural class or an abstract class. A structural class can include any number of auxiliary classes in its definition.
  • Abstract class: Abstract classes are templates used to create new abstract, auxiliary and structural classes.
  • Auxiliary class: An auxiliary class is a list of attributes. Adding the auxiliary class to the definition of a structural or abstract class adds the auxiliary class's attributes to the structural or abstract class. Auxiliary classes can be derived from existing auxiliary or structural classes.

Active Directory can also include a fourth special class, the 88 class. Object classes are currently required to be classified as one of the three class types previously mentioned (structural, abstract, or auxiliary). However, classes defined before 1993, in the 1988 X.500 specification, are not required to follow these classifications. Classes defined in the 1988 specification are referred to as belonging to a special category, that of 88.

For basic information about the schema, see Active Directory Schema overview. For more information about class types, see The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/).


Class definitions

Every object in Active Directory is an instance of a particular class. A class defines the attributes available to an instance of that particular class. Each class is derived from a parent class or superclass. Each class's attributes are either inherited from its superclasses or explicitly defined for that particular class.

Each class definition specifies the following:

  • Structure rules that determine the class's superclass or parent class
  • The list of attributes that can be present in an instance of that class
  • Which of the attributes are mandatory (Must Contain)
  • Which of the attributes are optional (May Contain)

To view the definition of a particular class using Active Directory Schema, see View a class definition.

Attribute inheritance

All classes in the schema are ultimately derived from the special class Top. With the exception of Top, all classes are subclasses of some other class. Inheritance enables you to build new classes from existing classes. The original class becomes a superclass or parent of the new class. A subclass inherits the attributes of the superclass, including structure rules and content rules. A class can inherit attributes from more than one superclass.

Structure rules define the possible hierarchical relationships between objects. The structure rules are completely expressed by each Class Schema object's Poss Superiors attribute. This attribute lists all of the possible superclass objects from which that particular object can inherit attributes.

The possible attributes that instances of a particular class can have are defined by content rules. The content rules are expressed by the Must Contain and May Contain attributes of the schema definitions for each class. A particular instance of a class must have all of the Must Contain attributes and may have any of the May Contain attributes.

Inheritance is recursive. This means that a subclass can inherit all of the attributes of all of its superclasses. For example, suppose Contact is a subclass of Organizational Person, Organizational Person is a subclass of Person, and Person is a subclass of Top. So, the Contact class can inherit all of the attributes from the Top, Person, and Organizational Person classes. This means that every object in the directory that is an instance of a particular subclass can be described by all of the attributes inherited from all of its superclasses.

For example, you could create a new Salesperson class that defines information about the salespeople in your company, including specialized information such as commission rate and travel route. You could specify that the Salesperson class is a subclass of the User class. Because the Salesperson class would inherit all the Must Contain and May Contain attributes of the User class as well as the attributes of all of the superclasses of the User class, you would not have to define these attributes for the Salesperson class. The only attributes you would need to define would be the Commission Rate and Travel Route attributes, which would be unique for all instances of the Salesperson class.

To view an attribute definition using Active Directory Schema, see View an attribute definition. For basic information about the schema, see Active Directory Schema overview. For more information about class definitions, see The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/).


Object identifiers

An object identifier is a number that unambiguously identifies an object class or attribute in a directory or any combination of directories. Object IDs are issued by issuing authorities and form a hierarchy. An object ID is represented as a dotted decimal string (for example, 1.2.3.4).

Object IDs are guaranteed to be unique across all networks worldwide. They are used to ensure that objects defined by different entities do not conflict. Object IDs are issued by the International Standards Organization (ISO) issuing authority or by a national registration authority in various countries. The International Standards Organization recognizes national registration authorities and maintains a list of contacts on the International Standards Organization (http://www.iso.ch/) Web site.

Most countries in the world have an identified national registration authority responsible for issuing object IDs. The national registration authority in the United States is the American National Standards Institute (ANSI).

Organizations (and individuals) can obtain a root object ID from an issuing authority and use it to allocate additional object IDs. For example, Microsoft has been issued the root object ID of 1.2.840.113556. Microsoft manages further branches from this root internally. One of these branches is used to allocate object IDs for Active Directory schema classes, and another for attributes.

Once you have received a root object ID, you can extend this identifier within your organization as needed (within the constraints of the object ID structure). You might subdivide the root object ID by appending dotted decimal numbers to the assigned root number and assigning these subspaces to your various internal divisions or departments. Each division or department, can further subdivide this subspace, and so on.

For example, a company with the object ID space number 1.2.333.444444 could grant the number 1.2.333.444444.5 to one of its divisions. That division might then decide to use 1.2.333.444444.5.1 as the base number for classes it creates, and 1.2.333.444444.5.2 for attributes it creates. Any class this division creates would then have an object ID of 1.2.333.444444.5.1.x, where x is a decimal number less than 268,435,455.

The national registration authority issues root object IDs. An organization can register a name for the object ID as well. There is a fee associated with both root object IDs and registered names. Contact the national registration authority for your country for details.

An example of an object ID in Active Directory is 1.2.840.113556.1.5.4, which identifies the Builtin Domain class and can be parsed as follows.

Number | Identifies
1 | ISO issued 1.2 to ANSI
2 | ANSI issued 1.2.840 to the USA
840 | USA issued 1.2.840.113556 to Microsoft
113556 | Microsoft internally manages several branches under 1.2.840.113556.
1 | Microsoft Active Directory
5 | Active Directory classes
4 | The schema class, Builtin Domain

For basic information about the schema, see Active Directory schema overview. For more information about object IDs, see The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/). For information about obtaining object IDs, see Obtaining valid object identifiers.


Schema cache

Active Directory maintains a schema cache, that contains all the class-definition and attribute-definition objects currently in the schema. It is kept in RAM on the domain controller to increase the performance of schema lookup operations.

When the domain controller starts, it loads the schema from the schema information on hard disk into the schema cache in memory. If you change the schema, Active Directory will refresh the schema cache from the new data on disk within five minutes. Alternatively, you can force a schema update. For more information, see Updating the schema cache.

For information about accessing the schema programmatically, see The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/). For basic information about the schema, see Active Directory Schema overview.


Planning for Active Directory

This section covers:

  • Planning the upgrade from previous domain models
  • Planning your DNS structure
  • Planning your domain structure
  • When to create a domain controller
  • Planning your delegation model
  • Planning organizational unit structure
  • Planning operations master locations
  • Planning site structure
  • Strategies for using groups
  • Planning to extend the schema


Planning the upgrade from previous domain models

Generally, organizations have used one or more of the following recommended domain models for Windows NT Server:

  • Single domain
  • Master domain
  • Multiple-master domain
  • Complete trust

Each of these models was based on the concepts of master domains (or account domains) and resource domains. The difference between these domain types was not built into the software, but instead was based on how they were used. Master domains generally held user and group accounts, while resource domains held network resources, such as file shares and printers.

For more information about these four domain models, see the documentation for your version of Windows NT Server.

If your current domain model is anything but a single domain, you can use the new features of Windows 2000 and Active Directory to reduce the number of domains on your network. This gives you the following major benefits:

  • There are fewer domains to manage. Windows 2000 domains are easier to manage than Windows NT domains, because secure transitive trusts reduce the number of trust relationships that need to be manually administered.
  • By merging resource domains and a master domain into a single domain, with a structure of organizational units to retain the current container structure, you group all accounts and resources (users, computers groups, file shares, and printers) together in the one domain where they logically belong. This is different from the previous domain models, in which the resources generally existed in a resource domain while the users accounts were located in an account domain.
  • Potentially reduced hardware costs. Because you will have fewer domains, you may not require as many domain controllers.

The following topics provide suggestions about how to upgrade, depending on which domain model is being upgraded.

Single domain model

When you upgrade to Windows 2000 Server, a single domain model will result in a single domain in Active Directory. You can use many new features of Active Directory to add functions not previously used in the single domain model, such as creating a hierarchy of organizational units to organize the accounts and resources and to which you can delegate administrative authority.

Master domain model

The upgrade from a particular master domain model to Active Directory typically starts from the top down because you have to create a root domain. The master domain is the first domain to be upgraded, followed by upgrades of the resource domains.

However, if your organization has a centralized structure, you may want to upgrade the whole network into one domain, to lessen the administrative work of maintaining multiple domains. You can retain the organizational structure of existing multiple domains by creating a tree of organizational units in the Windows 2000 domain. The tree of organizational units can mirror the old domain structure or can add structures to organize the network into greater levels of detail than before, without the administrative burden of more domains and more trust relationships.

In a centralized organization, the advantages of moving from a master domain model to a single Windows 2000 domain are:

  • Fewer domains to manage.
  • Querying for information is faster and more efficient with directory objects in one domain.
  • You can use organizational units to create a detailed organizational structure without adding more administrative responsibilities, such as trust relationship management.
  • By delegating administrative authority to one or more organizational units, you can assign administrative work on the basis of efficiency, without compromising network security.

In a decentralized organization, you can use the flexibility of domain trees, keeping the resource domains, but making them full-fledged domains that contain users and resources. This way, you can move user accounts to the domains containing the resources these people use, rather than putting them in the central master domain.

Many organizations also need to accommodate business units in their domain models, treating them much as separate organizations, but maintaining a logical, integrated network structure. For these companies, a forest with domain trees is a very good solution.

Multiple master domain model

If your company has a multiple master domain model, it probably does so for one of the following reasons:

  • Your network is so large that all users and groups do not fit in one domain database.
  • Your network has several main geographical sites, each with its own sets of users and resources. The sites are linked by slow connections, and you do not want replication traffic across these connections.
  • The domain model mimics your business structure, in which different business units must have control over their own users and resources.

Active Directory addresses the first and second points directly. Active Directory is scalable and can support replacement of multiple domains. If you use the Windows NT multiple master domain model solely because of the number of users you have, you can consolidate them into one Active Directory domain.

Active Directory also enables you to arrange your computers in geographical sites, and schedule inter-site replication as you want. If the links between your large sites are fast enough to handle occasional replication, you may be able to consolidate domains. However, if your business structure also mirrors your geographical locations, you may want to retain separate domains in the different sites.

If you are able to move to a single domain (or at least fewer domains), you gain the benefits described in Master domain model.

If your business model requires separate master domains, you can benefit from Active Directory by upgrading each current master domain as the root domain of a Windows 2000 Server domain tree. Any authorized users can access resources in any domain in the forest. The forest also enables each domain tree to share a common schema, configuration context, and a common global catalog. Consider this plan if your organization's DNS namespace has more than one root name.

Complete trust model

The complete trust model is primarily used by very decentralized organizations. In Windows NT Server, this model provided flexibility, but also required the most maintenance.

With Active Directory, you can still retain this independence by setting up each current domain as a domain tree or forest. If you choose this method, the administrative burden of trust relationships is reduced, because all domains in the domain tree or forest automatically use transitive trust relationships.

You should establish separate forests only if your organization requires absolute autonomy between sets of domains, with no sharing of resources.

Active Directory also supports one-way trust relationships, similar to those in Windows NT Server 4.0. You can use one-way trusts to external domains (domains not in the forest). One-way trusts are designed primarily for communication between external partners, not as the basis for a single organization's network.

You can also use Active Directory as the basis for centralizing your network and building a domain tree or trees. The structured, logical networks in many companies were not planned and established in an organized fashion, but are the result of islands that started deploying Windows NT Server and that grew together as Windows NT Server deployments increased.


Planning your DNS structure

Because Active Directory and the Domain Name System (DNS) namespace have an identical structure, proper planning of the namespace is crucial to a smooth deployment of Active Directory.

For information about DNS namespace planning and its relation to Active Directory, see Namespace planning for DNS.


Planning your domain structure

The easiest domain structure to administer is a single domain. When planning, you should start with a single domain and only add additional domains when the single domain model no longer meets your needs.

One domain can span multiple sites and contain millions of objects. Site structure and domain structure are separate and flexible. A single domain can span multiple geographical sites, and a single site can include users and computers belonging to multiple domains.

You do not need to create separate domain trees merely to reflect your company's organization of divisions and departments. Within a domain, you can use organizational units for this purpose. You can then assign Group Policy settings and place users, groups, and computers into the organizational units. For more information, see Planning organizational unit structure.

Some reasons to create more than one domain are:

  • Different password requirements between departments or divisions
  • Massive numbers of objects
  • Different Internet domain names
  • More control of replication
  • Decentralized network administration

Planning for multiple domains

Although using a single domain for an entire network has several advantages, to meet additional scalability, security, or replication requirements you may consider creating one or more domains for your organization. Understanding how directory data is replicated between domain controllers will help you plan the number of domains needed by your organization. For more information about replication, see How replication works.

You may need multiple domains if you have a decentralized network in which different divisions are managed by completely separate, autonomous administrators. With separate domains, each group of administrators can establish their own security policies independent of those in other domains. In addition, international organizations may find it easier for each country's users and resources to be administered in the local language.

All domains in a forest share the same global catalog, and authorized users from each domain can access resources in other domains in the forest.

Domain trees are useful primarily for establishing separate namespaces. All domains in a domain tree have a contiguous DNS namespace. If your current network lends itself to a contiguous DNS namespace, you may want to set up all your domains in a single domain tree.

You can also combine organizations with unique domain names in a forest. Each domain tree in the forest has its own unique namespace. For more information, see Understanding domain trees and forests.


When to create a domain controller

The act of promoting a Windows 2000 Server computer to a domain controller either creates a domain or adds additional domain controllers to an existing domain. Create a domain controller to:

  • Create the first domain in your network.
  • Create additional domains in a forest.
  • Improve network availability and reliability.
  • Improve network performance between sites.

To create a Windows 2000 domain, you must create at least one domain controller in that domain. The act of creating the domain controller also creates the domain. It is not possible to have a domain without a domain controller.

If you decide that your organization requires more than one domain, you must create at least one domain controller for each additional domain. Additional domains in a forest can be either:

  • A new child domain.
  • The root of a new domain tree.

Create a new child domain when you want to create a domain that shares a contiguous namespace with one or more domains. This means that the name of the new domain contains the full name of the parent domain. For example, sales.microsoft.com would be a child domain of microsoft.com. Use this domain tree structure to hierarchically organize domains within your organization.

Create the root of a new domain tree to create a domain whose name is not related to the other domains in the forest. Create new domain trees to include domains for various branches of your organization in the same forest and allow them to retain their own unique Internet domain names.

If you already have one domain controller in a particular domain, you can add additional domain controllers to that domain to improve the availability and reliability of network services. Having more than one domain controller in a domain makes it possible for the domain to continue to function if one domain controller fails or must be disconnected for some reason. Multiple domain controllers can also improve performance by making it easier for a Windows 2000 client to connect to a domain controller when logging on to the network.

If your network is divided into sites, it is often good practice to put at least one domain controller in each site. When network clients log on to the network, they must contact a domain controller as part of the logon process. If the clients must connect to a domain controller over a slow network connection, the logon process may take an unacceptably long time. Placing a domain controller in each site, allows client logon processes to be handled within the site without using the slower network connection between sites.


Planning your delegation model

You can delegate authority down to the lowest level of your organization by creating a tree of organizational units within each domain and delegating authority for parts of the organizational unit subtree to other users or groups.

By delegating administrative authority, you can eliminate the need to have people who regularly log on to accounts that have sweeping authority over an entire domain. Although you will still have an Administrator account and a Domain Admins group with administrative authority over the entire domain, you can keep these accounts reserved for occasional use by a very limited number of highly trusted administrators.

When you decide how to structure your organizational units and in which organizational units to put each user, consider the hierarchy of administration. For example, you may want to create an organizational unit tree that enables you to grant to a user the administrative rights for all branches of a single organizational department, such as a Human Relations department. Alternatively, you may want to grant administrative rights to a subunit within an organizational unit, such as the Recruiting unit of a Human Relations organizational unit. Another possible delegation of administrative rights would be to grant to an individual the administrative rights for the Human Relations organizational unit, but not to any organizational units contained within the Human Relations organizational unit.


Planning organizational unit structure

You can create a hierarchy of organizational units in a domain. Organizational units can contain users, groups, computers, printers and shared folders, as well as other organizational units.

Organizational units are directory Container objects. They are visually represented as folders in Active Directory Users and Computers.

Organizational units simplify the view of directory objects in a domain, as well as the administration of those objects. Administrative control of each organizational unit can be delegated to specific individuals. This allows you to distribute domain administration among administrators, managing administrative responsibilities in a manner that more closely resembles assigned organizational responsibilities.

Generally, you should create organizational units that mirror your organization's functional or business structure. For example, you might create top-level organizational units such as Human Relations, Facilities Management, and Marketing. Within the Human Relations organizational unit, you might create additional, nested organizational units such as Benefits and Recruiting. Within the Recruiting organizational unit, you might create another level of nested organizational units such as Internal Recruiting and External Recruiting organizational units. In short, organizational units enable you to model your organization in a meaningful and manageable way, and assign an appropriate local authority as administrator at any hierarchical level.

Each domain can implement its own organizational unit hierarchies. If your enterprise contains several domains, you can create organizational unit structures within each domain, independent of the structures in the other domains.

Administering organizational units

Organizational units are the smallest scope to which you can delegate administrative authority (the others are sites and domains). This gives you a way to delegate local administration of users and resources. Examples of resource administration include granting the ability to manage printer queues and file resources located within an organizational unit to an individual whose account is also located within that organizational unit. You can also grant an individual the authority to create and delete user accounts in an entire subtree of organizational units. For more information, see Delegating administration.

Policies and security

Organizational units are also the smallest scope to which you can assign Group Policy settings (the others are sites and domains). This enables you to determine access, configurations and use of resources for the organizational unit and any or all of its child objects (including other organizational units). For more information, see Group Policy.

Organizational units are not security principals and do not have members. Their purpose is solely to organize and contain directory objects. Use group assignments to grant rights and permissions to users. Assigning group memberships should be your first step in account management. You can then use organizational units to contain the Group objects and assign Group Policy settings.

Domains or organizational units

You may need to make a decision on whether to split a particular part of your network into separate domains or separate organizational units. Use the following recommendations as guidelines:

  • Split the network into separate domains if you have a decentralized organization in which different users and resources are managed by completely different sets of administrative personnel.
  • Split the network into separate domains when two parts of your network are separated by a link so slow that you never want complete replication traffic to cross it. (For slow links that can still handle replication traffic on a less frequent schedule, you can configure a single domain with multiple sites.)
  • Split a domain into organizational units to reflect the structure or your organization.
  • Split a domain into organizational units to delegate administrative control over smaller groups of users, groups, and resources. The amount of administrative control you grant can be complete (such as creating users and changing passwords) or limited (such as maintaining print queues).
  • Split a domain into organizational units if this particular organizational structure in your company is likely to change later. When possible, organize domains so that they will not have to be moved or split often in the future.

By creating organizational units within domains, you have two types of hierarchies within a domain tree: the hierarchy of the domains in a domain tree, and the hierarchies of organizational units within a domain.

This two-tiered hierarchy allows a great deal of flexibility in the administration of domain trees. For example, consider an enterprise whose network is managed by a central group of administrators. In this example, the administrators are named the information technology (IT) team. The IT team can create organizational units that represent accounts and resources within each domain in the enterprise (each domain can have an IT organizational unit that contains the IT user accounts in the domain). The central IT team can delegate administrative authority to each of these organizational units, while retaining administrative control over these organizational units as a whole.

The flexibility in the logical architecture lets you create an environment based on an organizational model that is centralized, decentralized, or a combination of the two.

For more detailed information about planning organizational unit structure, see the Windows 2000 Resource Kit.


Planning operations master locations

In a small Active Directory forest with only one domain and one domain controller, that domain controller owns all the operations master roles. When you create the first domain in a new forest, all of the single master operations roles are automatically assigned to the first domain controller in that domain.

When you create a new child domain or the root domain of a new domain tree in an existing forest, the first domain controller in the new domain is automatically assigned the following roles:

  • Relative identifier master
  • Primary domain controller (PDC) emulator
  • Infrastructure master

Because there can be only one schema master and one domain naming master in the forest, these roles remain in the first domain created in the forest.

Default operations master locations in a multi-domain forest.

This illustration, shows how the operations master roles are distributed throughout a forest by default. In the illustration, Domain A was the first domain created in the forest (also called the forest root domain). It holds both of the forest-wide operations master roles. The first domain controller in each of the other domains is assigned the three domain-specific roles.

The default operations master locations work well for a forest deployed on a few domain controllers in a single site. In a forest with more domain controllers, or in a forest that spans multiple sites, you might want to transfer the default operations master role assignments to other domain controllers in the domain or forest.

Planning the operations master role assignments by domain

If a domain has only one domain controller, that domain controller will hold all of the domain roles. Otherwise, choose two domain controllers that are direct replication partners and well-connected. Make one of the domain controllers the operations master domain controller. Make the other the standby operations master domain controller. The standby operations master domain controller is used in case of failure of the operations master domain controller.

In typical domains, assign both the relative identifier master and primary domain controller (PDC) emulator roles to the operations master domain controller. In a very large domain, you can reduce the peak load on the PDC emulator by placing these roles on separate domain controllers, both of which are direct replication partners of the standby operations master domain controller. Keep the two roles together unless the load on the operations master domain controller justifies separating the roles.

Assign the infrastructure master role to any domain controller in the domain that is not a global catalog, but that is well connected to a global catalog (from any domain) in the same site. If the operations master domain controller meets these requirements, use it unless the load justifies the extra management burden of separating the roles.

Planning the operations master roles for the forest

Once you have planned all of the domain roles for each domain, consider the forest roles. The schema master and the domain naming master roles should always be assigned to the same domain controller. For best performance, assign them to a domain controller that is well connected to the computers used by the administrator or group responsible for schema updates and the creation of new domains. The load of these operations master roles is very light, so, to simplify management, place these roles on the operations master domain controller of one of the domains in the forest.

Planning for growth

Normally, as your forest grows, you will not need to change the locations of the various operations master roles. But when you are planning to decommission a domain controller, change the global catalog status of a domain controller, or reduce the connectivity of parts of your network, you should review your plan and revise the operations master role assignments as necessary.

For general information about operations masters, see Single-master operations. For information about transferring operations master roles, see Transferring operations master roles. Special conditions can affect the hosting of the global catalog on a domain controller that is also acting as the infrastructure master. For more information on this, see Global catalog and infrastructure master.


Planning site structure

This section covers:

  • Bandwidth
  • When to establish a single site
  • When to establish separate sites
  • Domain controller and global catalog placement
  • Global catalog and infrastructure master


Bandwidth

Bandwidth is the most important practical consideration affecting intra-site replication on your network. Although sites are conveniently defined by subnets, it is important to understand that the reason for this choice is that subnets are typically well-connected. This means that subnets are generally, but not always, an effective way to determine sites.

To organize your sites effectively, consider replication requirements and available connectivity. Find a balance that ensures domain controllers in the same site are sufficiently well-connected to handle the frequent exchange of directory information, while not exacting what you consider to be excessive costs (such as high financial expense or compromised network performance).

When considering bandwidth, you may want to combine several subnets into one site, or split one subnet among several sites, such as in the following instances:

  • One large subnet (172.16.32.0/19) representing an entire building split into three smaller subnets (172.16.32.128/25, 172.16.33.0/25, and 172.16.33.128/25), each representing a separate floor of the building. You have very poorly connected computers, including several domain controllers in one subnet. Create several smaller subnets that are better connected than they were as one large subnet. For this to be effective, each new subnet should contain a domain controller.
  • Several small subnets combined into fewer, larger subnets. You have several subnets that are all well-connected or you have fewer domain controllers than subnets, but you want several subnets to be in a single site. To do this, add multiple subnets to one site.

For more information on how bandwidth may affect the way you configure your sites and services, see When to establish separate sites.


When to establish a single site

When planning for replication of the directory, start with a single site structure, then add sites as the constraints of bandwidth and connectivity dictate. Designing a site structure for a network that consists of a single local area network (LAN) is simple. Since local area connections are typically fast, the entire network can be a single site.

It is possible to define multiple sites within one, well-connected location (such as a single LAN), but there are potential drawbacks to this choice, including higher administration costs and less information exchange between domain controllers in the other well-connected sites. If a client is in a site that has no domain controllers, the client uses the site to which it is best connected that contains a domain controller. The best connected site is determined based on which site link has the lowest cost.

If you want a particular client to log on to a particular set of domain controllers, you may want to define your sites so that only those domain controllers, and not others in the same relative physical location, are in the same site as that client.

A fast, reliable connection is more common when computers are in close proximity. Having computers in the same subnet suggests that those computers are well-connected and that they should be in the same site. However, regardless of physical locations, computers in different subnets could still be well-connected by high bandwidth connections. In such a case, subnets and physical proximity should not necessarily determine the site assignment.

Note

  • A multihomed computer (a computer with more than one one IP address) with subnet addresses in different sites can belong only to one of the sites, not all of them. It is a good idea to assign all the addresses for a multihomed computer to the same site.


When to establish separate sites

Establishing separate sites provides the following benefits:

  • Partitions client use of the network
  • Further optimizes the exchange of directory information
  • Facilitates administration by centralizing resources such as configuration information
  • Fine tunes replication behavior

Establish a separate site with its own domain controllers when you feel domain controllers are not responding fast enough to meet the needs of your users. Determining what is fast enough depends on your criteria for network performance. Inadequate performance is more common when deployments span a wide geographic range.

For example, suppose you have an organization with headquarters in New York and a branch office in Los Angeles. These locations can be connected in many different ways, such as by a slow dial-up connection, a 64-kilobit-per-second (Kbps) Frame Relay connection, or a high-speed connection.

First, you must decide whether the branch office needs a domain controller at all. If it does not have a domain controller, there will be no replication traffic to the branch office. Clients could use one of the network connections to the main office to log on to the network. This is acceptable if a fast, reliable network connection is available. More often, a network connection to a distant domain controller is relatively slow. Having no domain controller in a distant location is only acceptable for very small branch offices (one to five computers, for example) where the performance impact affects limited users. Larger branch offices are better configured as separate sites, containing one or more local domain controllers.

For more information on whether or not to install a domain controller, see When to create a domain controller.

If replication between all domain controllers must take place on the same schedule, it may seem to make sense to assign all those domain controllers to the same site. This will achieve a uniform replication schedule, but it limits your ability to adjust directory replication behavior. By creating separate sites, you can fine-tune replication according to site conditions. For example, you may have a high-speed line as the default network connection, and a dial-up network connection in case the line is unavailable. In the case of multiple redundant network connections, Active Directory always chooses the connection on a per-cost basis, so the cheaper connection will be used, as long as it is available, and if the cheaper connection becomes unavailable, Active Directory will use the alternate connection to ensure reliability.

If you have good connectivity between a group of servers and clients, create sites and establish bridgehead servers in each site to provide load balancing. You can divide the potential for client requests between servers by establishing separate sites. Even though one site may be well connected to other sites, this reduces replication since the server or servers in the site handle all requests for clients within the site.

When planning your sites, consider which domain controllers each computer should use for the logon process. During the logon process, a client attempts to find a domain controller in its local site. To ensure this happens efficiently and reliably, your fast network connections need to map directly to low-cost site links in your site topology. Associating client subnets to sites they are in ensures efficient client access to resources because the clients will have good connectivity to the resources.

Within a site, each domain controller has the potential to act as a bridgehead server if needed. If you specify one or more computers to be preferred bridgehead servers, only a single domain controller acts as the bridgehead server at any given time. Although Active Directory does select another preferred bridgehead server for use in the event of failure, while this rerouting takes place, there is a period of time in which no inter-site replication will occur.

To mitigate the network effects resulting from failure of the bridgehead server, particularly large, well-connected sites may be split into smaller sites so that replication is affected only between the site containing the failed bridgehead server and the site or sites containing its replication partners. With a single large site, if the bridgehead is unavailable, the resulting halt in inter-site replication has a wider effect. By having a number of smaller sites available, the loss of inter-site replication (while a new bridgehead server is selected) is contained within the single smaller site. For more information, see Using preferred bridgehead servers.

Working with links between sites

If you establish multiple sites, you need to consider how information should be exchanged between sites and then review, fine-tune, or supplement your current site link configuration.

To supplement your network's inter-site replication topology, create site links or link a set of site links together by creating a site link bridge. Although a single site link is sufficient to connect a site to other sites, to create a more reliable, fault tolerant replication configuration, add further site links representing connections to the other sites.

For more information about supplementing your network's inter-site replication topology, see Checklist: Optimizing inter-site replication, To create a site link, To create a site link bridge. For information on configuring site link options, including replication availability, cost and frequency, see Replication options.


Domain controller and global catalog placement

Access to a global catalog is required for successful logon attempts. A global catalog is necessary to determine group memberships during the logon process. If your network has any slow or unreliable links, enable at least one global catalog on each side of the link for maximum availability and fault tolerance.

Most of your Active Directory network traffic will be query-related: users, administrators, and programs requesting information about directory objects. Updates to the directory, causing directory replication traffic, should occur much less frequently. To get the best network performance, place at least one domain controller in each site. With a domain controller in each site, all users can access a server that can service query requests over the fastest links available.

To help optimize network traffic, at sites connected by slow links, you can also configure domain controllers to receive directory replication updates only during off-peak hours.

The best network performance comes when the domain controller at a site is also a global catalog. That way, that server can fulfill queries about objects in the entire forest. However, enabling many domain controllers as global catalogs can increase the replication traffic on your network.

In domains with more than one domain controller, do not enable the domain controller holding the infrastructure master role as a global catalog. For more information, see Global catalog and infrastructure master.


Global catalog and infrastructure master

The infrastructure master is responsible for updating references from objects in its domain to objects in other domains. The infrastructure master compares its data with that of a global catalog. Global catalogs receive regular updates for objects in all domains through replication, so the global catalog's data will always be up-to-date. If the infrastructure master finds data that is out-of-date, it requests the updated data from a global catalog. The infrastructure master then replicates that updated data to the other domain controllers in the domain.

Important

  • Unless there is only one domain controller in the domain, the infrastructure master role should not be assigned to the domain controller that is hosting the global catalog. If the infrastructure master and global catalog are on the same domain controller, the infrastructure master will not function. The infrastructure master will never find data that is out of date, so will never replicate any changes to the other domain controllers in the domain.

    • If all of the domain controllers in a domain are also hosting the global catalog, all of the domain controllers will have the current data and it does not matter which domain controller holds the infrastructure master role.

For more information about operations master roles see Single master operations. For information about transferring operations master roles see Transferring operations master roles.


Strategies for using groups

Planning group strategies is an essential part of preparing to deploy Active Directory. Determine the number of Windows 2000 domains on your network and their domain modes (mixed-mode or native-mode) before deciding what groups to create.

The domain mode determines the group types and scope you can use. A mixed-mode domain can support security groups only for domain local and global scopes. It cannot support the universal scope introduced with Windows 2000. Once the domain is converted to native-mode, you can create security groups with universal scope or convert existing groups to universal scope.

For more information, see:

  • Where groups can be created
  • When to use groups with domain local scope
  • When to use groups with global scope
  • When to use groups with universal scope


Where groups can be created

In Active Directory, groups are created in domains. You use Active Directory Users and Computers to create groups. With the necessary permissions, and by correctly targeting Active Directory Users and Computers, groups can be created at the root domain of the forest, any other domain in the forest, or in an organizational unit.

Besides the domain in which it is created, a group is also characterized by its scope. The scope of a group determines:

  • The domain from which members can be added
  • The domain in which the rights and permissions assigned to the group are valid

For more information about group scopes, see Group scope.

Choose the particular domain or organizational unit where you create a group based on the administration required for the group. For example, if your directory has multiple organizational units, each of which has a different administrator, you may want to create groups with global scope within those organizational units so those administrators can manage group membership for users in their respective organizational units. If groups are required for access control outside the organizational unit, the groups within the organizational unit can be nested into groups with universal scope (or other groups with global scope) that can be used elsewhere in the forest.

If a native-mode domain contains a hierarchy of organizational units and administration is delegated to administrators at each organizational unit, it may be more efficient to nest groups with global scope. For example, if the organizational unit OU1 contained organizational units OU2 and OU3, a group with global scope in OU1 could have as its members groups with global scope in OU2 and OU3. In OU1, the administrator could add or remove group members from OU1, and the administrators of OU2 and OU3 could add or remove group members for accounts from their own organizational units without having administrative rights for the group with global scope in OU1.

Note

  • Groups can be moved within a domain. However, only groups with universal scope can be moved from one domain to another. The rights and permissions assigned to a group with universal scope are lost when the group is moved to another domain and new assignments must be made. Domains are security boundaries.
For information about the tools used to move groups between domains, see Windows 2000 Resource Kit.


When to use groups with domain local scope

Groups with domain local scope help you define and manage access to resources within a single domain. These groups can have as their members:

  • Groups with global scope
  • Groups with universal scope
  • Accounts
  • Other groups with domain local scope
  • A mixture of any of the above

For example, to give five users access to a particular printer, you could add all five user accounts in the printer permissions list. If, however, you later want to give the five users access to a new printer, you would again have to specify all five accounts in the permissions list for the new printer.

With a little planning, you can simplify this routine administrative task by creating a group with domain local scope and assigning it permission to access the printer. Put the five user accounts in a group with global scope and add this group to the group having domain local scope. When you want to give the five users access to a new printer, assign the group with domain local scope permission to access the new printer. All members of the group with global scope automatically receive access to the new printer.


When to use groups with global scope

Use groups with global scope to manage directory objects that require daily maintenance, such as user and computer accounts. Because groups with global scope are not replicated outside of their own domain, accounts in a group having global scope can be changed frequently without generating replication traffic to the global catalog. For more information about groups and replication, see How groups impact network performance.

Although rights and permissions assignments are valid only within the domain in which they are assigned, by applying groups with global scope uniformly across the appropriate domains, you can consolidate references to accounts with similar purposes. This will simplify and rationalize group management across domains. For example, in a network with two domains, Europe and NorthAmerica, if there is a group with global scope called GLAccounting in the NorthAmerica domain, there should also be a group called GLAccounting in the Europe domain (unless the accounting function does not exist in the Europe domain).


When to use groups with universal scope

The membership of a group with universal scope should not change frequently, since any changes to these group memberships cause the entire membership of the group to be replicated to every global catalog in the forest. For more information about groups and replication, see How groups impact network performance.

Use groups with universal scope to consolidate groups that span domains. To do this, add the accounts to groups with global scope and nest these groups within groups having universal scope. Using this strategy, any membership changes in the groups having global scope do not affect the groups with universal scope.

For example, in a network with two domains, Europe and NorthAmerica, and a group having global scope called GLAccounting in each domain, create a group with universal scope called UAccounting to have as its members the two GLAccounting groups, NorthAmerica\GLAccounting and Europe\GLAccounting. The UAccounting group can then be used anywhere in the enterprise. Any changes in the membership of the individual GLAccounting groups will not cause replication of the UAccounting group.


Planning to extend the schema

This section covers:

  • Issues in extending the schema
  • When to extend the schema
  • Before extending the schema
  • Obtaining valid object identifiers
  • Extending the schema
  • Deactivating a class or attribute
  • Updating the schema cache


Issues in extending the schema

You need to consider the following issues when planning to extend the schema:

  • Concurrency control
  • Handling invalid object instances
  • Replication issues
  • Extending the administrative tools

Concurrency control

When designing an application installation routine that must extend the schema, the installation routine should be in two distinct phases. The first phase performs the necessary schema modifications. The second phase verifies that the schema modifications have successfully taken place and performs the actual application installation.

Handling invalid object instances

A schema update can make an existing object invalid. For example, suppose My object is an instance of Our class. Our class has an attribute, Age, in its May-Contain list. Since My object is an instance of Our class, suppose as well that My object is using the Age attribute.

If a schema update deletes Age from the May-Contain list of Our class, My object will be invalid, since My object now has an Age attribute that is not in accordance with its class definition.

In this case, Active Directory allows the now-invalid object to remain in the directory and ensures that it does not cause any schema conflicts. Active Directory does not automatically clean up invalid objects, but invalid Active Directory objects and attributes appear in searches and can be deleted manually.

Replication issues

A schema update performed at the schema master is replicated to all other domain controllers in the forest, guaranteeing a consistent schema. However, because of the time required for replication to complete, there can be temporary inconsistencies.

For example, if a new class is created, and subsequently an object of that class is created, the related schema updates may be sent separately to the other domain controllers. The update for the new object may reach another domain controller before the update for the new class. This causes an error, since the class does not yet exist on that domain controller.

Active Directory solves this issue by replicating the schema Container object from the originating domain controller when failures occur. In addition, this triggers an immediate schema cache update on the target domain controller. Active Directory then again attempts to replicate the failed schema update for the new object. Because the schema on the target domain controller now contains the class definition, the operation succeeds.

Extending the administrative tools

The administrative tools shipped with Windows 2000 Server are designed to manage the default schema. New classes and new attributes may not appear correctly in these tools. The Active Directory administrative tools can be programmatically extended to manage the new schema extensions you make, although this is a task best handled by an experienced programmer or network administrator.

For more information about extending the Active Directory administrative tools and other issues involved in extending the schema, see The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/). For basic information about the schema, see Active Directory schema overview.


When to extend the schema

Extending the schema is a highly sensitive operation, with implications potentially throughout your network. Schema extension is best handled programmatically, and only when absolutely necessary. Improper schema modifications can impair or disable Windows 2000 Server and possibly your entire network.

Extend the schema only if no existing object class meets your needs. Schema changes are replicated to every domain controller in the forest. Consider your needs carefully and assess whether an extension is really necessary.

The schema can be extended in two ways:

  • Derive a new subclass from an existing class. The subclass has all of the attributes of the superclass and any additional attributes you specify. This is the preferred mechanism for adding attributes to an existing class.
  • Add additional attributes to an existing class or add additional parents for the class.

Derive a new subclass from an existing class when:

  • The existing class needs additional attributes, but otherwise meets your needs.
  • You do not require the ability to transform existing objects of the class into your new class. It is not possible to add a subclass to an existing schema object.
  • You want to use Active Directory Schema to manage the extended attributes of the objects without having to modify Active Directory Schema to incorporate the additional class.

You should avoid modifying an existing class. It is necessary only when your application requires the ability to extend existing objects of the class. For instance, to add application-specific information to the User object, you would normally extend the class User, because you need to deal with existing User objects not just special User objects created by your application.

When you create a subclass of an existing class or extend an existing class, you will need to configure tools like Active Directory Users and Computers to manage the extended attributes of the instances of the new class.

You should only create a completely new class (a subclass of the superclass Top) when no existing class meets your needs.

For more information about when to extend the schema, and how to modify the Active Directory Administrative tools to handle your schema extensions, see The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/). For basic information about the schema, see Active Directory Schema overview.


Before extending the schema

Modifying the Active Directory schema is an advanced operation best performed programmatically by experienced programmers and system administrators. For detailed information about modifying the Active Directory schema, see The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/).

For developmental and testing purposes, it is possible to modify the schema using Active Directory Schema. The safest way to develop and test schema extensions is on an isolated network in a lab environment. This prevents schema changes from replicating throughout your forest before they have been thoroughly tested.

Before you can modify the schema using Active Directory Schema, you must:

  1. Be a member of the Schema Admins group.
  2. Install the Active Directory Schema snap-in on the computer holding the schema operations master role.
  3. Select the check box in Active Directory Schema that allows the schema to be modified from the current computer.
  4. Disconnect the schema master domain controller from the network.

Isolating the schema master domain controller from the rest of the network allows you to experiment with schema changes without being concerned about how those changes impact the rest of your network. For more information about the schema master role and single master operations, see Single master operations.

Note

  • If the existing schema master is unavailable, you can manually seize the schema master role to any domain controller in the forest. However, any recent schema changes made at the old schema master may not have been propagated to the new one and may be lost. For more information about seizing the schema master role, see Responding to operations master failures.


Obtaining valid object identifiers

An object identifier is a number that unambiguously identifies an object class or attribute in a directory. Object IDs are issued by issuing authorities and form a hierarchy. An object ID is represented as a dotted decimal string (for example, 1.2.3.4).

Object IDs are guaranteed to be unique across all networks worldwide. They are used to ensure that objects defined by different entities do not conflict. Object IDs are issued by the International Standards Organization (ISO) issuing authority or by the national registration authority in various countries. The International Standards Organization recognizes national registration authorities and maintains a list of contacts on the International Standards Organization (http://www.iso.ch/) Web site.

Most countries in the world have an identified national registration authority responsible for issuing object IDs. The national registration authority in the United States is the American National Standards Institute (ANSI).

The national registration authority issues root object IDs. An enterprise can register a name for the object ID as well. There is a fee associated with both root object IDs and registered names. Contact the national registration authority for your country for details.

You can also receive object IDs from Microsoft by sending e-mail to oids@microsoft.com. In your e-mail, include your organization's naming prefix, and the following contact information:

  • Contact name
  • Contact address
  • Contact telephone number

For information about determining your organization's naming prefix, see the Active Directory chapter of the Windows 2000 Logo document. For more information about object IDs, see Object identifiers and The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/). For basic information about the schema, see Active Directory Schema overview.


Extending the schema

Extending the Active Directory schema is an advanced operation intended to be performed by experienced programmers and system administrators. For developmental and testing purposes, it is possible to modify the schema using Active Directory Schema. Before modifying the schema, see Checklist: Before extending the schema and The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/).

There are three ways to extend the schema:

  • Using LDAP Data Interchange Format (LDIF) scripts (preferred)
  • Programmatically
  • Using the Active Directory Schema snap-in

See The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/) for detailed information about each method of extending Active Directory schema as well as sample scripts and examples of programming code.

Warning

  • Extending the schema is a highly sensitive operation, with implications potentially throughout your network. Schema extension is best handled programmatically, and only when absolutely necessary. Improper schema modifications can impair or disable Windows 2000 Server and possibly your entire network.

    No one should consider extending the Active Directory schema without first referencing The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/).


Deactivating a class or attribute

Active Directory does not permit deletion of classes or attributes; however, you can deactivate them. Deactivation is also referred to as making the class or attribute defunct. Deactivating a class or attribute gives you most of the effects of deleting it, and has the added benefit of being easily reversible.

Before deactivating a class, consider the following:

  • You can deactivate a class only if that class is not specified as a Sub Class Of, Auxiliary Class Of, or Poss Superior of any existing active class.
  • When a class is deactivated, you can no longer create objects that are instances of the class. Any attempt to do so returns an error identical to the error that would result if the class had never existed.

Before deactivating an attribute, consider the following:

  • You can deactivate an attribute only if the attribute is not specified as a System Must Contain, Must Contain, System May Contain, or May Contain of any existing active class.
  • When an attribute is deactivated, you cannot use it in definitions of new classes, and you cannot add it to existing class definitions.

Because a deactivated class or attribute still exists in the schema, you cannot create new classes or attributes with the same Common Name, object identifier, or LDAP Display Name as a deactivated class or attribute.

Classes and attributes can be deactivated programmatically (recommended) or by using Active Directory Schema. To deactivate a class or attribute using Active Directory schema, see Deactivate a class or attribute. For information about programmatically deactivating classes and attributes, see The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/).


Updating the schema cache

On every domain controller, there are always two copies of the schema, one on the hard disk and one in RAM. The copy in RAM is called the schema cache. It contains a copy of all the class and attribute objects currently in the schema.

When the schema is extended, the changes are immediately made to the schema data on the hard disk of the schema operations master. However, for performance reasons, Active Directory waits for approximately 5 minutes after the last schema update before copying the data store to the schema cache.

During the time immediately after you add a new class or modify an existing class, and before the update is copied to the schema cache, any attempt to add an object belonging to the new or modified class will return an error. This is because any schema change you make is not reflected in the schema cache for about 5 minutes.

Active Directory provides a method to force immediate schema cache updates when delays are not acceptable. You can force a schema cache update programmatically or with Active Directory Schema. To force a schema cache update, see Reload the schema. You should force an immediate reload of the schema cache only once, after all schema updates that need to be made current are finished.

For basic information about the schema, see Active Directory Schema overview. For more detailed information about extending the schema, see The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/).


Using Active Directory

This section covers:

  • Deploying Active Directory
  • Upgrading to Active Directory
  • Interoperating with other directory services
  • Administering Active Directory


Deploying Active Directory

The following topics introduce the issues that must be considered when deploying Active Directory. For help with planning large installations, please see the Windows 2000 Deployment Guide.
  • Installing Windows 2000 Server
  • Promoting domain controllers
  • Using Group Policy
  • Defining sites


Installing Windows 2000 Server

Windows 2000 Server can be installed as the first operating system on a new computer, as an upgrade to an existing version of Windows NT Server, or in a dual-boot configuration with other Windows operating systems.

For information about the various roles for which Windows 2000 Server can be configured, see Server Roles.

For information about planning for and performing a new installation of Windows 2000 Server or upgrading an existing version of Windows NT Server to Windows 2000 Server, see Installing Windows 2000 Server. For information about running Windows 2000 Server and another operating system on the same computer, see Deciding whether a computer will contain more than one operating system.

After you have installed Windows 2000 Server, you can make the new server a domain controller. Before promoting a Windows 2000 Server computer to a domain controller, see Checklist: Installing a domain controller. To promote a Windows 2000 Server computer to a domain controller, see Install a domain controller.


Promoting domain controllers

Any member server or stand-alone server can be promoted to be a domain controller using the Active Directory Installation wizard. For factors to consider before promoting a domain controller, see Checklist: Installing a domain controller.

Select the security level

To maximize security, by default, Windows 2000 Active Directory does not allow accounts logged on with Anonymous access the ability to view group memberships and other user and group information. Windows NT 4.0 did allow this degree of access. Several existing applications, including Microsoft BackOffice applications like SQL Server as well as some third party applications, depend on this type of access to function correctly.

To allow you to choose between the stronger security provided by Windows 2000 and the ability to continue to use the security required for legacy applications, Windows 2000 includes the builtin local security group Pre-Windows 2000 Compatible Access. Adding or removing the special group Everyone as a member of this group and then rebooting the domain controllers in that domain allows you to operate your network either with pre-Windows 2000 security levels or with the greater security provided by Windows 2000.

To provide a clean and simple upgrade path from Windows NT, the Active Directory Installation wizard offers you the choice between Permissions compatible with pre-Windows 2000 servers, which provides the security level compatible with some pre-Windows 2000 applications and Permissions compatible only with Windows 2000 server. For more information about the Active Directory Installation wizard, see Install a domain controller.

Note

  • If you choose Permissions compatible only with Windows 2000 server while promoting a domain controller, and find that your applications are not functioning correctly, try resolving the problem by adding the special group Everyone to the Pre-Windows 2000 Compatible Access security group and rebooting the domain controllers in the domain. Once you have upgraded to Windows 2000 compatible applications, you should return to the more secure Windows 2000 configuration by removing Everyone from the Pre-Windows 2000 Compatible Access security group and rebooting the domain controllers in the affected domain.

For additional information, see:

  • Install a domain controller
  • Domain controllers


Using Group Policy

Group Policy can be used to define default settings that will be automatically applied to users and computers. These settings can determine security options and control what software can be installed on particular computers and what software is available to particular groups of users.

Policy settings are stored in Group Policy objects. Group Policy objects can control settings for users and computers in sites, domains and organizational units. To create or edit Group Policy objects, use the Group Policy snap-in. For more information, see Using Group Policy.

Group Policy settings from more than one Group Policy object can be applied to a particular site, domain, or organizational unit. For example, if a site contains three domains, one Group Policy object could control computer configurations for the entire site. A separate policy for each domain could determine specific security settings for the computers in each domain. If each domain contains an Accounting and a Marketing organizational unit, additional Group Policy objects could determine what software is installed on the computers used by the Accounting and Marketing groups throughout the entire site. This ability to automatically configure and secure computers throughout your organization by selectively applied Group Policy objects is a very powerful administrative tool. For more information about controlling software installation with Group Policy, see Software installation. For more information about administering Group Policy, see Administering Group Policy.

Computers and users in Windows 2000 domains can belong to security groups. These security groups can be used to filter how Group Policy settings are applied to collections of users and computers belonging to a particular site, domain, or organizational unit. For more information about filtering the application of Group Policy settings, see Work with Group Policy object properties. For more information about security groups see Understanding groups. For general information about Group Policy, see Group Policy.


Defining sites

This section covers:

  • Entering subnet information
  • Using preferred bridgehead servers


Entering subnet information

You must associate one or more subnets with each site. Subnets are derived from the IP address and subnet mask of a computer in the subnet. If you do not already know the subnet mask and IP address of your subnet, get it from your network administrator, or see Viewing configuration by using Ipconfig /all.

When you know the subnet mask and IP address, see To create a subnet to enter this information and establish a site. For more information about determining subnets, see IP addressing or Subnet masks.


Using preferred bridgehead servers

Bridgehead servers are the contact point for exchange of directory information between sites. You can specify a preferred bridgehead servers if you have a computer with appropriate bandwidth to transmit and receive information. If there's typically a high level of directory information exchange, a computer with more bandwidth can ensure these exchanges are handled promptly. Matching the demands of your Active Directory deployment with a domain controller having the capacity to handle those demands will enable efficient updates of directory information.

For more information on designating preferred bridgehead servers, see To designate a preferred bridgehead server.

You can specify multiple preferred bridgehead servers, but only one will be the active preferred bridgehead server at any time. If the active preferred bridgehead server fails, Active Directory will select another preferred bridgehead server to be the active preferred bridgehead server from the set you designate. If no active preferred bridgehead server is available and there are no other preferred bridgehead servers available for Active Directory to select, it will select another domain controller in the site to be the preferred bridgehead server. This can be problematic if the domain controller Active Directory selects does not have the bandwidth to efficiently handle the increased requirements posed by being a preferred bridgehead server.

You must specify a preferred bridgehead server if your deployment uses a firewall to protect a site. Establish your firewall proxy server as the preferred bridgehead server, making it the contact point for exchanging information with servers outside the firewall. If you do not do this, directory information may not be successfully exchanged.

Directory information is exchanged between sites over a site link. IP and SMTP are the default transport protocols for which you can add site links. Any domain controller can use the site link protocol of the site link to exchange the information. If there are multiple servers in a site, and one of the servers is a preferred bridgehead server for a protocol used in a site link, that server will be the preferred bridgehead server for inter-site exchange of directory information.

Establishing a preferred bridgehead designates that server as the pre-eminent server for information exchange over the protocol for which the site link is established. Other domain controllers could still exchange directory information if a need arises, but under normal conditions, the bridgehead server will be used as the first choice to receive and send all directory traffic.

In summary, a site link directs information arbitrarily to any domain controller in a site. Establishing a bridgehead server provides some ranking or criteria for choosing which domain controller should be preferred as the recipient for inter-site replication. This bridgehead server then subsequently distributes the directory information via intra-site replication.


Upgrading to Active Directory

The Active Directory directory service is compatible with Windows NT and supports a mixed-mode of operation using both Windows 2000 Server domain controllers and Windows NT Server 4.0 domain controllers. Because Active Directory supports mixed-mode, you can upgrade domains and computers at your own pace, based on your organization's needs.

Active Directory supports the NTLM protocol used by Windows NT. This enables authorized users and computers from a Windows NT domain to log on and access resources in Windows 2000 domains. To Windows NT clients and Windows 95 or Windows 98 clients that are not running Active Directory client software, a Windows 2000 domain appears to be a Windows NT Server 4.0 domain.

The upgrade to Active Directory can be gradual and performed without interrupting operations. If you follow domain upgrade recommendations, it should never be necessary to take a domain offline to upgrade domain controllers, member servers, or workstations. When upgrading a Windows NT domain, you must upgrade the primary domain controller first. You can upgrade member servers and workstations at any time after this.

Active Directory allows upgrading from any Windows NT 4.0 domain model and supports both centralized and decentralized models. The typical master or multiple-master domain model can be easily upgraded to an Active Directory forest.

For more information about planning and performing an upgrade, see:

  • Upgrading a Windows NT domain
  • Merging resource domains into master domains
  • Converting groups to Windows 2000


Upgrading a Windows NT domain

This section explains the recommended steps for upgrading a Windows NT domain to Windows 2000 and Active Directory.

Plan and implement a namespace and DNS infrastructure

Because the Domain Name System (DNS) is required for Active Directory, ensure that you have designed a DNS and Active Directory namespace and have either configured DNS servers or are planning on having the Active Directory Installation wizard automatically install the Windows 2000 DNS service on the domain controller. For more information, see:

  • Integration with DNS
  • Understanding DNS integration
  • Planning your DNS structure
  • Planning your domain structure

Upgrade the Windows NT primary domain controller

The first Windows NT server you must upgrade is the Windows NT primary domain controller (PDC). Upgrading the Windows NT PDC is required for successful upgrade of a Windows NT domain to a Windows 2000 domain.

Install Active Directory on the Windows NT PDC

During the Windows 2000 Server upgrade, the Active Directory Installation wizard requires that you choose to join an existing domain tree or forest, or start a new domain tree or forest. If you decide to join an existing domain tree, you must provide a reference to the desired parent domain. For more information, see Checklist: Installing a domain controller.

Running the Active Directory Installation wizard installs all necessary components on the domain controller, such as the directory data store and the Kerberos V5 protocol authentication software.

The existing Security Account Manager (SAM) objects will be copied from the registry to the new data store. These objects are the security principals (user accounts, local and global groups and computer accounts).

Once the Kerberos V5 protocol is installed, the installation process starts the authentication service and the ticket granting service, and if this is a new child domain, establishes a transitive trust relationship to the parent domain. Eventually, the domain controller from the parent domain copies all schema and configuration information to the new child domain controller.

The upgraded domain controller is a fully functional member of the Active Directory forest. The new domain is added to the domain and site structure, and all domain controllers receive the notification that a new domain has joined the forest.

Computers running Active Directory client software (Windows 2000 Professional, Windows 98 and Windows 95) can use Active Directory features, such as authentication, for access to resources in the domain tree or forest, and for directory queries. Clients benefit from the transitive trust relationships that exist within the forest, enabling authorized users to access resources in any domain.

Computers running previous versions of Windows access the domain as if it were a Windows NT domain, finding only those resources available through Windows NT one-way trusts. While the domain is in mixed-mode, the domain controller exposes to clients using previous versions of Windows only resources in domains that have older, established Windows NT explicit trusts. This creates a consistent environment in that the previous version clients can access only resources in domains with explicit trusts, regardless of whether the client is using a Windows 2000 domain controller or a Windows NT back-up domain controller.

After the PDC upgrade, the Windows 2000 domain controller uses the Active Directory data store, which is compatible with any remaining Windows NT backup domain controllers(BDCs).

The upgraded Windows 2000 domain controller can synchronize security principal changes to remaining Windows NT Server 4.0 BDCs. It is recognized as the domain master by the Windows NT Server 4.0 BDCs.

If the Windows 2000 domain controller goes offline or otherwise becomes unavailable and no other Windows 2000 domain controllers exist in the domain, a BDC running Windows NT Server can be promoted to be a Windows 2000 domain controller.

Once you have upgraded the Windows NT PDC, you can proceed to either:

  • Upgrade all other servers to Windows 2000 Server

    During the upgrade process, you should maintain a BDC running your current version of Windows NT Server to guarantee a backup if any problems develop.

  • Install Windows 2000 Server on only one domain controller, leaving all other domain controllers configured with Windows NT Server.

Implement your domain organization

After upgrading to Windows 2000 and configuring the domain controller using the Active Directory Installation wizard, use the Active Directory administration tools to create the new directory objects, (such as organizational units and Group Policy objects) needed to implement the organization you have planned for the domain.

For more information, see Planning your domain structure, Planning organizational unit structure and Group Policy.

Upgrade any remaining backup domain controllers

The next stage of the upgrade process is to upgrade any remaining Windows NT backup domain controllers to Windows 2000 Server and Active Directory.

When upgrading Windows NT domains only one Windows 2000 domain controller can create security principals (users, groups, and computer accounts). This single domain controller is configured as a PDC emulator operations master. The PDC operations master emulates a Windows NT PDC.

The domain controller emulating the Windows NT PDC controls unique resource identifiers assigned to security principals. Resource identifiers are used to create the Windows 2000 security identifier that identifies User and Group objects.

The domain controller that is emulating the Windows NT PDC supports two authentication protocols:

  • the Kerberos V5 protocol
  • the NTLM protocol

Complete the upgrade of the domain

After you have upgraded all existing Windows NT primary and back-up domain controllers to Windows 2000 Server and Active Directory and have no plans to use Windows NT domain controllers, you can switch the domain from a mixed-mode to native-mode. The change from mixed-mode to native-mode is manually done by an administrator using the Active Directory Domains and Trusts snap-in.

Several things happen when you change to native mode:

  • Domain controllers no longer support NTLM replication.
  • The domain controller that is emulating the PDC operations master can not synchronize data with a Windows NT BDC.
  • Windows NT domain controllers can not be added to the domain. (You can of course add new Windows 2000 domain controllers.)
  • Users and computers using previous versions of Windows begin to benefit from the transitive trusts of Active Directory and (with the proper authorization) can access resources anywhere in the forest. Although previous versions of Windows do not support the Kerberos V5 protocol, the pass-through authentication provided by the domain controllers allows users and computers to be authenticated in any domain in the forest. This enables users or computers to access resources in any domain in the forest for which they have the appropriate permissions.

Other than the enhanced access to any other domains in the forest, clients will not be aware of any changes in the domain.

Upgrading Active Directory

When a Windows NT PDC or BDC is upgraded to Windows 2000 the upgrade process creates domain and site objects used by Active Directory, as well as creating user and computer accounts and groups from the Windows NT directory (also referred to as the Security Accounts Manager database).

During upgrade, objects are created to contain the accounts and groups from the Windows NT PDC or BDC. These Container objects are named Users, Computers and Builtin, and are displayed as folder in the Active Directory Users and Computers console. These objects contain the users, computers, and groups from the Windows NT directory. User accounts and pre-defined groups are placed in the Users folder. Computer accounts are placed in the Computers folder. Built-in groups are placed in the Builtin folder.

Note

  • These special Container objects are not organizational units. They cannot be moved, renamed or deleted.

During upgrade the existing Windows NT groups are placed into different containers depending on the nature of the group. Windows NT built-in local groups (such as Administrators and Server Operators) are put into the Builtin container. Windows NT global groups (such as Domain Admins) and any user-created local groups and global groups are placed in the Users container.

Models for conservative upgrade

Two other models exist to allow upgrade flexibility. Both models require upgrading the primary domain controller first.

Model 1: Save a pre-Windows 2000 backup domain controller (BDC)

For this model, you either install a new BDC that runs your current version of Windows NT Server, or, if you currently have more than one BDC, use one of them. This BDC will store a secure copy of your current domain database. Remove the BDC from the network before beginning the process.

If any problems arise during migration, you can remove all Windows 2000 computers from the production environment, then bring the BDC back into your network and make it the new PDC. This new PDC then replicates its data to all BDCs, and the domain is returned to its previous state.

The only drawback of this method is that all changes that were made while the safe BDC was offline are lost. To minimize this loss, you could periodically turn the safe BDC on and off again (when the domain is in a stable state) during the migration process, to update its safe copy of the directory.

Model 2: Remove the primary domain controller (PDC) from the network first

You can also remove the PDC from the network before starting the migration. If you intend to create multiple domains, you can bring all PDCs into an environment that is not part of the production network. You can then upgrade the PDCs and form the domain tree or trees while disconnected from the production environment. The result is the creation of a fully functional forest, without affecting production.

Once a forest is formed, you can add workstations and BDCs to it. If the migration continues smoothly, the PDCs can be returned to the production environment and turned on. The forest continues to work, and the rest of the servers can be updated to Windows 2000 Server; or the new client access software can be installed on the pre-Windows 2000 clients.

If a forest already exists, you can bring one domain controller from the existing forest to the established lab environment and use it to add to the forest all the PDCs being upgraded. The domain controller from the existing forest can replicate the directory schema and configuration data to the new domain controllers.

When you use this method, the production environment remains uninfluenced until the new domain controllers and the forest have proven sufficiently stable. The main disadvantage of this method is that it is not possible to make changes in the directory until the new domain controllers go online in the production environment.


Merging resource domains into master domains

The current domain structures of many companies include master domains, containing users and groups, and resource domains containing network resources. Because Active Directory eliminates the need for this type of model, you can merge existing resource domains into the master domains. If necessary, you can create an organizational unit structure in the master domain that mirrors the previous resource domain structure.

The following topics provide guidelines for how to merge resource domains into master domains.

Ensuring that access rights are preserved

Organizations that use the master domain model usually create only local groups in the resource domains, not global groups or user accounts.

These organizations generally assign permissions for resources in second-tier domains in the following ways:

  • Assign the permissions to global groups from the master domain.
  • Assign the permissions to local groups created on member servers in the resource domain.
  • Assign the permissions to local groups created in the resource domain.

When a resource domain is merged into a master domain, permissions that use the first two methods are automatically preserved. In the final method, permissions assigned to the resource domain's local groups are not automatically preserved, but you can preserve them by following a few simple steps:

Note

  • Before you merge the domains, to ensure that permissions are preserved, you should copy the resource domain's local groups to the master domain.

Step 1: Upgrade the master domain.

Upgrade the master domain to Windows 2000 Server and install Active Directory on the domain's primary domain controller (PDC).

Step 2: Add organizational units.

If you are dissolving resource domains into organizational units in the master domain, you must create the organizational units first.

During the upgrade, the new organizational unit containers are displayed only on Active Directory clients. Pre-Windows 2000 clients can still access resources that are in organizational units in the domain, but they cannot see the organizational unit structure. To these clients, it looks as if there were no changes in the domain.

Once the organizational units are created, you can use them to distribute the directory objects across a hierarchical namespace. You can move users and groups from the Users folder into organizational units.

Step 3: Upgrade resource domain PDCs to Windows 2000 Server.

Because both domains must use Active Directory to move security principals between domains, during this step of the process keep these servers in their current resource domain. Do not yet move them into the master domain.

Step 4: Move security principals and servers to the master domain.

When you move member servers from the resource domains to organizational units in the master domain, the computer account for each server is moved along with it.

Any local groups created on the member server are also moved with the server and continue functioning.

The administrator of the master domain can then use both NetBIOS and Active Directory publishing to make the existence of a resource known. This allows Active Directory clients to use the extended query mechanism of the directory to find resources and to connect to them. As long as pre-Windows 2000 clients exist in the network, the NetBIOS advertisement should be used as well. (The resource is automatically published in the Active Directory.) When all clients are upgraded with the new Active Directory client software, NetBIOS can be disabled.

Do not remove the PDC from the second-tier domains and dissolve the domains yet. Those domains are still responsible for resolving security identifiers that they have issued.

Step 5: Move the resource domain local groups to the master domain.

Move any domain local groups from the resource domain that you want to preserve to the master domain.

The moved groups appear as normal groups in the master domain. No further changes to permissions need to be made.

Step 6: Move all workstations to the master domain.

Move workstations from the resource domains to the master domain. For computers running Windows 98 or Windows 95, you need only change the computer's workgroup name.

For computers running Windows NT Workstation, you must remove them from the old domain and then add them to the master domain. The master domain will create new computer accounts.

For computers running Windows 98 or Windows 95, the domain move can be done at the same time as the Active Directory client software installation. This client software client software (included with Windows 2000 Server) must be installed to use Active Directory.

To participate in Active Directory, computers running Windows NT Workstation must be upgraded to Windows 2000 Professional. If you use an automated setup script for the upgrade, the domain change can be performed automatically in the script.

Step 7: Eliminate the resource domains.

You can now eliminate the resource domains. You can do this either by disabling all domain controllers in the resource domain, or by moving the domain controllers to the master domain.


Converting groups to Windows 2000

When you upgrade a primary domain controller running Windows NT Server to Windows 2000 Server, existing Windows NT groups are converted in the following ways:

  • Windows NT local groups are converted to Windows 2000 domain local groups.
  • Windows NT global groups are converted to Windows 2000 global groups.

Domain member computers running Windows NT can continue to display and access the converted groups. The groups appear to these clients as Windows NT 4.0 local and global groups. However, a Windows NT client cannot display members of groups or modify the member properties when that membership violates Windows NT group rules. For example, when a Windows NT client views the members of a Windows 2000 Server global group, it does not view any other groups that are members of that global group.

Converted groups and Microsoft Exchange

Exchange allows users to arrange e-mail addresses in groups and distribution lists. When Exchange servers are upgraded to Active Directory, the Exchange distribution lists are converted to distribution groups with universal scope. The administrator can convert the group to a security group later, if desired, by using Active Directory Users and Computers to change the group properties. The messaging application programming interface (MAPI) enables computers running previous-version Exchange clients to view the converted distribution group.

Using converted groups with Windows NT

Client computers that do not run Active Directory client software identify Windows 2000 groups with universal scope as having global scope instead. When viewing the members of a group with universal scope, the Windows NT client can only view and access group members that conform to the membership rules of Windows NT global groups.

In a Windows 2000 native-mode domain, all the domain controllers must run Windows 2000 Server. However, the domain can contain member servers that run Windows NT Server 4.0. These servers view groups with universal scope as having global scope and can assign groups with universal scope rights and permissions and place them in local groups.

In a Windows 2000 domain, a Windows NT Server 4.0 member server running Windows NT administrative tools cannot access domain local groups. However, you can work around this by using a computer running Windows 2000 Server and using its administrative tools to access the server running Windows NT Server 4.0. You can use these Windows 2000 Server tools to display the domain local groups and assign to them permissions to resources on the server running Windows NT Server 4.0.


Interoperating with other directory services

Directory services can support a large spectrum of features and capabilities. Some directory services are integrated with an operating system, and some are applications such as e-mail directories. Operating system directory services, such as Active Directory, provide user, computer, and shared resource management. Directory services that are e-mail applications, such as Microsoft Exchange, enable users to look up other users and send e-mail.

For information about synchronizing Active Directory with other directory services, see:

  • Importing and exporting directory information
  • Using Active Directory with Exchange


Importing and exporting directory information

Two command line utilities are provided to support importing and exporting of directory information:

  • LDIFDE

    Used to export and import data in Active Directory.

  • CSVDE

    Used to export and import data from files that are compatible with the comma-separated variable (CSV) format used in applications such as Microsoft Excel.

LDIFDE

Batch operations you can perform using LDIFDE include add, delete, rename, and modify. These operations enable you to export Active Directory data to other applications or services. Alternatively, you can populate Active Directory with information obtained from other sources, such as other directory services.

To use LDIFDE, at the command prompt, type LDIFDE followed by one or more parameters.

LDIFDE parameter summary

Parameter | Description
-i | Specifies import mode. If not specified, the default mode for LDIFDE is export.
-f filename | Identifies the import or export file name.
-s server name | Specifies the domain controller to perform the import or export operation.
-c string1 string2 | Replace all occurrences of string1 with string2. This is generally used when importing data from one domain to another and the distinguished name of the export domain needs to be replaced with that of the import domain.
-v | Sets verbose mode.
-j path | Use to set the log file location. The default is the current path.
-t port number | Use to specify a LDAP port number. The default LDAP port is 389. The global catalog port is 3268.
-d baseDN | Use to set the distinguished name of the search base for data export.
-r LDAP-filter | Use to create a LDAP search filter for data export. For example, to export all users with your surname, the following filter could be used: -r "(&(objectClass=user)(sn=yoursurname))"
-p scope | Set the search scope. May be either Base, OneLevel or SubTree.
-l LDAP-attribute-list | Set the list of attributes to return in the results of an export query. If this parameter is omitted, all attributes are returned. For example, to retrieve only the distinguished name, common name, first name, surname, and telephone number of the returned objects, the following attribute list would be specified: -l "distinguishedName, cn, givenName, sn, telephone"
-o | List of attributes to be omitted from the results of an export query. This is typically used when exporting objects from Active Directory and then importing them into another LDAP-compliant directory. There may be some attributes that are not supported by the other directory, so these attributes can be omitted from the result set using this option. For example, to omit the objectGUID, whenChanged and whenCreated attributes, the following omission would be specified: -o "whenCreated, whenChanged, objectGUID"
-g | Do not perform paged searches.
-m | Omit attributes that only apply to Active Directory objects such as the ObjectGUID, objectSID, pwdLastSet and samAccountType attributes.
-n | Do not export binary values.
-k | Skip errors during the import operation and continue processing. Typical errors that may be skipped include those where the object already exists.
-a user-distinguished-name password | Sets the command to run using the supplied user distinguished name and password. (The default is to run using the credentials of the currently logged on user.) For example: a cn=yourname,dc=yourcompany,dc=com password
-b username domain password | Sets the command to run as username domain password. (The default is to run using the credentials of the currently logged on user.)For example: b yourusername yourcompanydomain password
-? | Use to display online Help.

For more information about LDIFDE see the LDIFDE online help.

CSVDE

Data may be imported and exported from Active Directory using files that store data in the comma-separated variable (CSV) format. Applications such as Microsoft Excel are capable of reading and saving data in the CSV format. In addition, the Microsoft Exchange Server administration tools are also capable of importing and exporting data using the CSV format, as are many other third party tools.

The CSV format consists of one or more lines of data, with each value separated by a comma. The first line (sometimes referred to as the header) of the CSV file must contain the names of each attribute in the same order as the data in any line following the first line. For example:
Cn,Firstname,Surname,Description
1stuserlogonname,1stuserfirstname,1stusersurname,Manager
2nduserlogonname,2nduserfirstname,2ndusersurname,President

A utility command line program called CSVDE is included in Windows 2000 to support batch operations based on the CSV file format standard.

To use CSVDE, at the command prompt, type CSVDE followed by one or more parameters.

CSVDE Parameter summary

Parameter | Description
-i | Specifies import mode. If not specified, the default mode is export.
-f filename | Identifies the import or export file name.
-s server name | Specifies the domain controller to perform the import or export operation.
-c string1 string2 | Replace all occurrences of string1 with string2. This is generally used when importing data from one domain to another and the distinguished name of the export domain needs to be replaced with that of the import domain.
-v | Sets verbose mode.
-j path | Use to set the log file location. The default is the current path.
-t port number | Use to specify a LDAP port number. The default LDAP port is 389. The global catalog port is 3268
-d baseDN | Use to set the distinguished name of the search base for data export.
-r LDAP-filter | Use to create a LDAP search filter for data export. For example, to export all users with your surname, the following filter could be used: -r "(&(objectClass=user)(sn=yoursurname))"
-p scope | Set the search scope. May be one of Base, OneLevel or SubTree.
-l LDAP-attribute-list | Set the list of attributes to return in the results of an export query. If this parameter is omitted, all attributes are returned. For example, to retrieve only the distinguished name, common name, first name, surname and telephone number of the returned objects, the following attribute list would be specified: -l "distinguishedName, cn, givenName, sn, telephone"
-o | List of attributes to be omitted from the results of an export query. This is typically used when exporting objects from the Active Directory and then importing them into another LDAP-compliant directory. There may be some attributes that are not supported by the other directory, so these attributes may be omitted from the result set using this option. For example, to omit the objectGUID, whenChanged and whenCreated attributes the following omission would be specified: -o "whenCreated, whenChanged, objectGUID"
-g | Do not perform paged searches.
-m | Omit attributes that only apply to Active Directory objects such as the ObjectGUID, objectSID, pwdLastSet and samAccountType attributes.
-n | Do not export binary values.
-k | Skip errors during the import operation and continue processing. Typical errors that may be skipped include those where the object already exists.
-a user-distinguished-name password | Sets the command to run using the supplied user distinguished name and password. (The default is to run using the credentials of the currently logged on user.) For example: a cn=yourname,dc=yourcompany,dc=com password
-b username domain password | Sets the command to run as username domain password. (The default is to run using the credentials of the currently logged on user.)For example: b yourlogonname yourcompanydomain password
-? | Use to display online Help.

For more information about CSVDE see the CSVDE online help.


Using Active Directory with Exchange

Information about users in Microsoft Exchange can be synchronized with Active Directory to reduce the cost of administering multiple directories. When Exchange is installed, the Active Directory schema is extended with Exchange objects. The Active Directory Connector synchronizes data between Active Directory and Exchange. You can then manage the information using the Active Directory snap-ins.

For more information about synchronizing information and extending Active Directory for use with Exchange directory services, see:

  • Using Active Directory Connector
  • Using the Exchange extensions to Active Directory Users and Computers


Administering Active Directory

This section covers:

  • Administering other domains
  • Delegating administration
  • Transferring operations master roles
  • Responding to operations master failures
  • Service publication
  • Managing security
  • Publishing resources
  • Finding directory information
  • Programming interfaces
  • Active Directory administrative tools
  • Active Directory support tools


Administering other domains

In an organization with more than one domain, it is often necessary to administer a domain other than the one to which you are currently logged on. For example, when creating trusts, the trust must be created in both the trusting and the trusted domain. You can do this through:

  • Cooperation with those who have administrative permissions in another domain
  • Logging on with a user account with the necessary permissions
  • Using the Run as command to run an administrative tool targeted on the particular domain (recommended)

A secure method of controlling administrative access to a particular domain is to very tightly control the number of accounts with administrative permissions for that domain and the number of people aware of those accounts. Only the people who know the account name and password can make administrative changes to the domain. For example, if an administrator in another domain wanted to establish a shortcut trust with a tightly controlled domain, the only way that administrator could establish the trust relationship would be by communicating with the administrator of the tightly controlled domain, agreeing on a common password for the trust, and having the administrator of the tightly controlled domain create the trust in that domain.

A more convenient method of administering more than one domain is to log on with a user account that has administrative permissions in both domains. For example, user accounts that are members of the Enterprise Admins security group, have permission to administer every domain in the forest. Using accounts with sweeping privileges is not recommended. For more information, see Why you should not run your computer as an administrator

Note

  • It is good practice to never log on with an account that has more permissions than you need for the task you are currently performing.
  • It is also good practice to limit the scope of a particular administrator's permissions to include only those tasks that the administrator commonly performs.

The Run as command allows you to execute operations in a security context that is different from that of the current account, thereby performing tasks that require a particular set of permissions. The Run as command starts the particular application or administrative tool with the permissions of the specified user account. For example, using the Run as command, you can run two instances of a particular administrative tool, each one targeted at a different domain and with the necessary administrative permissions in each domain.

To use the Run as command, you must know the user name and password of an account with the necessary permissions.

Important

  • The Run as command, when used with the appropriate user name and password, can also be used to administer domains in a different forest.

For more information about the Run as command, see Runas.


Delegating administration

You can delegate administrative control to any level of a domain tree by creating organizational units within a domain and delegating administrative control for specific organizational units to particular users or groups.

To decide what organizational units you want to create, and which organizational units should contain accounts or shared resources, consider the structure of your organization. For example, you may want to create an organizational unit that enables you to grant to a user the administrative control for all user and computer accounts in all branches of a single organizational department, such as a Human Relations department. You may instead want to grant to a user administrative control only to some resources within a department, for example, computer accounts. Another possible delegation of administrative control would be to grant to a user the administrative control for the Human Relations organizational unit, but not to any organizational units contained within the Human Relations organizational unit.

By delegating administrative responsibilities, you can eliminate the need for multiple administrative accounts that have broad authority (such as, over an entire domain). Although you likely will still use the predefined Domain Admins group for administration of the entire domain, you can limit the accounts that are members of the Domain Admins group to highly trusted administrative users.

Windows 2000 defines many very specific permissions and user rights, that can be used for the purposes of delegating or restricting administrative control. Using a combination of organizational units, groups and permissions, you can define the most appropriate administrative scope for a particular person: an entire domain, all organizational units within a domain, or even a single organizational unit.

Administrative control can be granted to a user or group by using the Delegation of Control wizard. The Delegation of Control wizard allows you to select the user or group to which you want to delegate control, the organizational units and objects you want to grant those users the right to control, and the permissions to access and modify objects. For example, a user can be given the right to modify the Owner Of Accounts property, without being granted the right to delete accounts in that organizational unit.

Customizing MMC consoles for specific groups

You can use MMC console options to create a limited-use version of a snap-in such as Active Directory Users and Computers. This allows administrators to control the options available to groups to whom you have delegated administrative responsibilities by restricting access to operations and areas within that customized console.

For example, suppose you delegate the Manage Printers right to the PrintManagers group in the Manufacturing organizational unit. To simplify administration, you can create a custom console for use by members of the PrintManagers group containing only the Manufacturing organizational unit and restrict the scope of the console using MMC console modes.

For more information on customizing a console and using console modes, see see Using custom consoles and Console access options.

This type of delegation is also enhanced by the Group Policy settings available for MMC. These settings enable the administrator to establish which MMC snap-ins can be run by the affected user. The settings can be inclusive, allowing a set of snap-ins to run, or exclusive, restricting the set of snap-ins to run. For more information about Group Policy settings for MMC, see Setting Group Policy in MMC.

Using Group Policy to publish and assign customized consoles

Using Group Policy you can distribute a customized console to specific groups in one of two modes: publishing or assigning. Publishing a customized console advertises the console to the members of a group specified in the Group Policy setting by adding the console to the list of available programs in Add/Remove Programs. The next time the members of the group open Add/Remove Programs they have the option to install the new console. Assigning (as opposed to publishing) a console forces the console to be automatically installed for all specified accounts.

To publish or assign a console, create or modify a Group Policy object and apply it to the appropriate group of users. Then use the Software Installation extension of the Group Policy snap-in to either publish or assign the console.

For more information on creating Group Policy objects and applying these to accounts, see To Create a new Group Policy Object, Delegating control of Group Policy and To filter the scope of Group Policy according to security group membership.

For more information on publishing and assigning, see Software Installation, To Publish an Application and To Assign an Application.

Important

  • The console must be packaged before using the Software Installation snap-in. You can use a tool such as Windows Installer to package the customized console. Once this has been accomplished you can configure the Software Installation snap-in to publish or assign the newly created package. For more information on how to package an application see the Windows 2000 Server SDK and Resource Kit.
  • If the customized console you are packaging uses a snap-in that is not installed on the destination workstation or server for the published or assigned user, you will need to include the snap-in file and the registration of the file in the package. You can either create a separate package that contains the snap-in or add the snap-in during the creation of the customized console package so that it will be properly installed on the computer every time a user installs the console package.

Note

  • If a user is logged on to their computer at the time that a Group Policy object is applied to their account, the user will not see the published or assigned console until they log off and then log on again.

For more information about other Active Directory security issues, see Security model.


Transferring operations master roles

Transferring an operations master role means moving it from one domain controller to another, with the cooperation of the original role holder. Depending upon the operations master role to be transferred, you perform the role transfer using one of the three Active Directory snap-ins.

Role | Snap-in
Schema master | Active Directory Schema
Domain naming master | Active Directory Domains and Trusts
Relative identifier master | Active Directory Users and Computers
PDC emulator | Active Directory Users and Computers
Infrastructure master | Active Directory Users and Computers

For general information about operations master roles, see Single master operations.

For procedures describing the transfer of operations master roles, see:

  • Transfer the schema master role
  • Transfer the domain naming master role
  • Transfer the relative ID master role
  • Transfer the PDC emulator role
  • Transfer the infrastructure master role


Responding to operations master failures

Some of the operations master roles are crucial to the operation of your network. Others can be unavailable for quite some time before their absence becomes a problem. Generally, you will notice that a single master operations role holder is unavailable when you try to perform some function controlled by the particular operations master.

If an operations master is not available due to computer failure or network problems, you can seize the operations master role. This is also referred to as forcing the transfer of the operations master role.

Before forcing the transfer, first determine the cause and expected duration of the computer or network failure. If the cause is a networking problem or a server failure that will be resolved soon, wait for the role holder to become available again. If the domain controller that currently holds the role has failed, you must determine if it can be recovered and brought back online.

In general, seizing an operations master role is a drastic step that should be considered only if the current operations master will never be available again. The decision depends upon the role and how long the particular role holder will be unavailable. The impact of various role holder failures is discussed in the following topics.

Schema master failure

Temporary loss of the schema operations master is not visible to network users. It will not be visible to network administrators either, unless they are trying to modify the schema or install an application that modifies the schema during installation.

If the schema master will be unavailable for an unacceptable length of time, you can seize the role to the standby operations master. However, seizing this role is a drastic step that you should take only when the failure of the schema master is permanent.

Important

  • A domain controller whose schema master role has been seized must never be brought back online.

For procedures on how to seize the schema master role, see Seize the schema master role.

Domain naming master failure

Temporary loss of the domain naming master is not visible to network users. It will not be visible to network administrators either, unless they are trying to add a domain to the forest or remove a domain from the forest.

If the domain naming master will be unavailable for an unacceptable length of time, you can seize the role to the standby operations master. However, seizing this role is a drastic step that you should take only when the failure of the domain naming master is permanent.

Important

  • A domain controller whose domain naming master role has been seized must never be brought back online.

For procedures on how to seize the domain naming master role, see Seize the domain naming master role.

Relative ID master failure

Temporary loss of the relative identifier operations master is not visible to network users. It will not be visible to network administrators either, unless they are creating objects and the domain in which they are creating the objects runs out of relative identifiers.

If the relative identifier master will be unavailable for an unacceptable length of time, you can seize the role to the operations master. However, seizing this role is a drastic step that you should take only when the failure of the relative identifier master is permanent.

Important

  • A domain controller whose relative identifier master role has been seized must never be brought back online.

For procedures on how to seize the relative identifier master role, see Seize the relative ID master role.

PDC emulator failure

The loss of the primary domain controller (PDC) emulator affects network users. Therefore, when the PDC emulator is not available, you may need to immediately seize the role.

If the current PDC emulator master will be unavailable for an unacceptable length of time and its domain has clients without Windows 2000 client software, or if it contains Windows NT backup domain controllers, seize the PDC emulator master role to the standby operations master. When the original PDC emulator master is returned to service, you can return the role to the original domain controller.

For procedures on how to seize the PDC emulator role, see Seize the PDC emulator role.

Infrastructure master failure

Temporary loss of the infrastructure master is not visible to network users. It will not be visible to network administrators either, unless they have recently moved or renamed a large number of accounts.

If the infrastructure master will be unavailable for an unacceptable length of time, you can seize the role to a domain controller that is not a global catalog but is well connected to a global catalog (from any domain), ideally in the same site as the current global catalog. When the original infrastructure master is returned to service, you can transfer the role back to the original domain controller.

For procedures on how to seize the infrastructure master role, see Seize the infrastructure master role.

For general information about operations masters, see Single master operations.


Service publication

The following topics describe some types of service information that may be useful to publish to the directory. The qualities that make a service appropriate for publishing may be better understood by understanding how Active Directory uses services.

Categories of service information

Binding and configuration information are the two types of information frequently published using Active Directory:

  • Binding information allows clients to connect to services that do not have well known bindings and that conform to a service-centric model. By publishing the bindings for these kinds of services, Windows 2000 can automatically establish connections with services. Machine-centric services are typically handled on a service-by-service basis and should not be published to the directory.
  • Configuration information can be common across client applications. Publishing this sort of information allows you to distribute current configuration information for these applications to all clients in the domain. The configuration information is accessed by client applications as needed. This eases application configuration for users and gives you more control over application behaviors.

Characteristics of service information

Service information that you publish to the directory is most effective if it has the following characteristics:

  • Useful to many clients. Information that is useful to a small set of clients or that is useful only in certain areas of the network should not be published. If not widely used, this information wastes network resources, since it is published to every domain controller in the domain.

  • Relatively stable and unchanging. Although there may be exceptions to this rule, it generally makes sense to publish only service information that changes less frequently than two replication intervals. For intra-site replication, the maximum replication period is fifteen minutes, and for inter-site replication, the maximum replication period is configured based on the replication interval of the site link used for the replication. Object properties that change more frequently create excessive demands on network resources. Property values may be out-of-date until updates are published, which can take as long as the maximum replication period. Consequently, having properties out-of-date for that period of time must not create unacceptable conditions.

    For example, some network services select a valid TCP port for use each time they are started. After selecting the port, the service updates Active Directory with this information, which is stored as the service connection point. Clients access the service connection point when they want to use the service, but if the new service connection point has not been replicated when the client requests it, the client will receive an outdated port, rendering the service temporarily inaccessible.

  • Well-defined, reasonable properties. Information that is of a consistent form is easier for services to use. The information should be relatively small in size.

As an example of service publication using Active Directory Sites and Services, see To set security permissions and delegate control of certificate templates. For more information about what services to publish and how to publish them, see the Service Publication section in The Active Directory Programmer's Guide (http://www.microsoft.com.


Managing security

Windows 2000 introduces several new security features to help you implement the level of security that your organization needs.

In its simplest form, security ensures that the people logging on to your network are who they say they are. When you create trust relationships between Windows domains or Kerberos V5 realms, Windows security can limit access to sensitive data or specific resources to only those people to whom you want to grant access, both within and outside your organization.

Windows 2000 security can also ensure that the data you store on disk, or send over private or public networks is protected from unauthorized access. You can use Encrypting File System to protect data stored on disk. IP security and PPTP encryption can protect data on your network as well as data transmitted over the Internet.

For more information about implementing and using Windows 2000 security, see Security.


Publishing resources

You need to be able to provide secure and selective publication of network resources to network users and make it easy for users to find information. The directory stores this information for rapid retrieval and integrates Windows 2000 security mechanisms to control access.

Resources that can be published in the directory include objects such as users, computers, printers, files, and network services.

Publishing users and computers

User and computer accounts are added to the directory using Active Directory Users and Computers. Information about the accounts that is useful for other network users can be published. Other information, such as account security information, is made available only to administrators.

Publishing shared resources

Publishing information about shared resources such as printers and file folders makes it easy for users to find these resources on the network. Information about Windows NT printers and shared folders can be published in the directory using Active Directory Users and Computers. (Windows 2000 network printers are automatically published in the directory when installed.)

Publishing network services

Network-enabled services, such as Certificate Services, can be published in the directory so administrators can find and administer them using Active Directory Sites and Services.

By publishing a service, rather than computers or servers, administrators can focus on managing the service regardless of which computer is providing the service or where the computer is located.

Additional services or applications can be published in the directory using Active Directory programming interfaces. For a description of these, see Programming interfaces. For detailed information about developing an application that publishes information in the directory, see the Active Directory Programmer's Guide.


Finding directory information

Active Directory is designed to provide information to queries about directory objects from both users and programs. Administrators and users can easily search for and find information in the directory by using the Search command on the Start menu, My Network Places on the desktop, or the Active Directory Users and Computers snap-in. Client programs can access information in Active Directory by using Active Directory Service Interfaces (ADSI).

One of the principal benefits of Active Directory is its rich store of information about network objects. Information published in Active Directory about users, computers, files, and printers is available to network users. This availability is controlled by security permissions to view information.

Everyday tasks on a network involve communication with other users and connection to published resources. These tasks require finding names and addresses to send mail or connect to shared resources. In this respect, Active Directory functions as a shared address book for the enterprise.

Additionally, administrators can use the advanced Find dialogs in Active Directory Users and Computers to perform management tasks with greater efficiency and to easily customize and filter data retrieved from the directory. For how to find and publish directory information like users, computers, groups, shared folders, and printers, see Manage Published Resources.


Programming interfaces

Active Directory Service Interfaces (ADSI) provides a simple, powerful, object-oriented interface to Active Directory. ADSI makes it easy for programmers and administrators to create directory programs by using high-level tools such as Microsoft Visual Basic, Java, C, or Visual C++ without having to worry about the underlying differences between the different namespaces.

ADSI enables you to build or buy programs that give you a single point of access to multiple directories in your network environment, whether those directories are based on LDAP or another protocol. ADSI is fully scriptable for ease of use by administrators.

For more information about ADSI, see the Windows 2000 Resource Kit

Active Directory also provides support for Messaging Application Programming Interface (MAPI), so legacy MAPI programs will continue to work with Active Directory.

In addition, Active Directory supports the LDAP C API, defined in RFC 1823, as a lower-level interface for C programmers. For more information, see the Platform Software Developers Kit (SDK).


Active Directory administrative tools

The Active Directory administrative tools that are included with Windows 2000 Server simplify directory service administration. You can use the standard tools or, using Microsoft Management Console (MMC), create custom tools that focus on single management tasks. You can combine several tools into one console. You can also assign custom tools to individual administrators with specific administrative responsibilities. For information about MMC, see Creating and opening MMC consoles.

The Active Directory administrative tools can only be used from a computer with access to a Windows 2000 domain. The following Active Directory administrative tools are available on the Windows 2000 Server Administrative Tools menu of all Windows 2000 domain controllers:

  • Active Directory Users and Computers
  • Active Directory Domains and Trusts
  • Active Directory Sites and Services

You can also administer Active Directory remotely, from a computer that is not a domain controller. To use the Active Directory administrative tools remotely, from a computer that is not a domain controller, such as one running Windows 2000 Professional, you must install the Windows 2000 Administrative Tools. For more information, see Managing servers remotely.

The Active Directory Schema snap-in is another Active Directory administrative tool. It is not available on the Windows 2000 Server Administrative Tools menu. You must install the Windows 2000 Administration Tools from the Windows 2000 Server compact disc and add it to an MMC console. For more information, see Install the Active Directory Schema snap-in.

For advanced administrators and network support specialists, there are many command line tools that can be used to configure, manage, and troubleshoot Active Directory. For more information, see Active Directory support tools

You can also create scripts that use Active Directory Service Interfaces (ADSI). Several sample scripts are supplied on the Windows 2000 Server compact disc. For more information about the sample scripts, see Windows 2000 Resource Kit. For more information about using ADSI, see Programming interfaces.


Active Directory support tools

Several additional tools that can be used to configure, manage and debug Active Directory are available as command line tools. These tools are known as the Support Tools and are available on the Windows 2000 Server compact disc in the \SUPPORT\TOOLS folder.

List and description of tools

Tool | Description
MoveTree | Move objects from one domain to another.
SIDWalker | Set the access control lists on objects previously owned by accounts that were moved, orphaned, or deleted.
ESEUtil | Repair, check, compact, move, and dump the directory database files. (Many of these functions are called by NTDSUTIL.)
NTDSUtil | Repair, check, compact, move, and dump the directory database files. List site, domains and server information, manage operations masters, perform authoritative restore, create domains.
LDP | Allows LDAP operations to be performed against Active Directory. This tool has a graphical user interface.
DNSCMD | Check dynamic registration of DNS resource records including Secure DNS update, as well as deregistration of resource records.
DOMMAP | Check the replication topology and site and domain relationships.
DSACLS | View or modify the access control lists of directory objects.
NETDOM5 | Batch management of trusts, joining computers to domains, verifying trusts and secure channels.
NETTest | Check end to end network and distributed services functions.
NLTest | Check that the locator and secure channel are functioning.
REPAdmin | Check replication consistency between replication partners, monitor replication status, display replication metadata, force replication events and knowledge consistency checker recalculation.
REPLMon | Display replication topology, monitor replication status (including group policies), force replication events and knowledge consistency checker recalculation. This tool has a graphical user interface.
DSAStat | Compare directory information on domain controllers and detect differences.
ADSIEdit | A Microsoft Management Console (MMC) snap-in used to view all objects in the directory (including schema and configuration information), modify objects and set access control lists on objects.
SDCheck | Check access control list propagation and replication for specified objects in the directory. This tool enables an administrator to determine if access control lists are being inherited correctly and if access control list changes are being replicated from one domain controller to another.
ACLDiag | Determine whether a user has been granted or denied access to a directory object. It can also be used to reset access control lists to their default state.
DFSCheck | Command line utility for managing all aspects of Distributed File System (DFS), checking the configuration concurrency of DFS servers, and displaying the DFS topology.

For more information about the Active Directory support tools, see Windows 2000 Resource Kit.


Resources

Links to information on Microsoft Web sites

  • Windows 2000 Resource Kit
  • The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/).

Links to information on other Web sites

  • International Standards Organization (http://www.iso.ch/)
  • The Internet Engineering Task Force (http://www.ietf.org/)


Troubleshooting

What problem are you having?

Cannot add or remove a domain.

Cause: The domain naming master is not available. This may be caused by a network connectivity problem. It may also be due to a failure of the computer holding the domain naming master role.

Solution: Resolve the network connectivity problem.
Or repair or replace the domain naming master computer. It may be necessary to seize the domain naming master role.

See also: Diagnose connections; Single master operations; Responding to operations master failures; Transfer the domain naming master role; Seize the domain naming master role

Cannot create objects in Active Directory.

Cause: The relative ID master is not available. This may be caused by a network connectivity problem. It may also be due to a failure of the computer holding the relative ID master role.

Solution: Resolve the network connectivity problem.
Or, repair or replace the computer holding the relative ID master role. It may be necessary to seize the relative ID master role.

See also: Diagnose connections; Single master operations; Responding to operations master failures; Transfer the relative ID master role; Seize the relative ID master role

Cannot modify the schema.

Cause: The schema master is not available. This may be caused by a network connectivity problem. It may also be due to a failure of the computer holding the schema master role.

Solution: Resolve the network connectivity problem.
Or, repair or replace the computer holding the schema master role. It may be necessary to seize the schema master role.

See also: Diagnose connections; Single master operations; Responding to operations master failures; Transfer the schema master role; Seize the schema master role

Changes to group memberships are not taking effect.

Cause: The infrastructure master is not available. This may be caused by a network connectivity problem. It may also be due to a failure of the computer holding the infrastructure master role.

Solution: Resolve the network connectivity problem.
Or, repair or replace the computer holding the infrastructure master role. It may be necessary to seize the infrastructure master role.

See also: Diagnose connections; Single master operations; Responding to operations master failures; Transfer the infrastructure master role; Seize the infrastructure master role

Clients without Active Directory client software installed cannot log on.

Cause: The primary domain controller emulator is not available. This may be caused by a network connectivity problem. It may also be due to a failure of the computer holding the primary domain controller emulator role.

Solution: Resolve the network connectivity problem.
Or, repair or replace the computer holding the primary domain controller emulator role. It may be necessary to seize the primary domain controller emulator role.

See also: Diagnose connections; Single master operations; Responding to operations master failures; Transfer the PDC emulator role; Seize the PDC emulator role

Clients are unable to access resources in another domain.

Cause: There has been a failure of the trust between the domains.

Solution: Reset and verify the trust between the domains.
The PDC emulator must be available for a trust to be successfully reset.

See also: Verify a trust; Single master operations

Receiving "Domain not found," "Server not available," or "RPC server is unavailable" messages.

Cause: Name registration or name resolution is not functioning correctly. This could be caused by a NetBIOS or DNS name registration or resolution problem, or a network connectivity problem.

Solution: Run Netdiag /debug on the server that is experiencing the problem. This command-line tool will evaluate NetBIOS, DNS, registration, and services.

See also: Windows 2000 Resource Kit

User is unable to log on locally to a domain controller.

Cause: Policy defines log on locally access rights for users. By default, users are not allowed to log on locally to a domain controller.

Solution: To allow one or more users to log on locally to a domain controller (generally not a recommended practice) this policy must be enabled from the Default Domain Controllers Policy.

See also: Group Policy

Trust errors between servers or workstations.

Cause: Incorrect time synchronization between domain controllers or workstations, the server could be down, or the trust relationship could be broken.

Solution: Run Netdom5 to verify, reset, or establish trust between computers. This command-line tool performs batch management of trusts, verifies trusts and secures channels between computers, and can join computers to domains.

See also: Windows 2000 Resource Kit

Cannot enable auditing.

Cause: In Windows 2000, auditing must be enabled in the Group Policy object.

Solution: Run GPEdit.msc to enable auditing or monitoring of system events.

See also: Group Policy


Administering Active Directory

This section covers:

  • Active Directory administrative tools
  • Active Directory support tools
  • Administering other domains


Best practices

  • Do not log on with administrative rights. Run as a normal user and use Run as when performing administrative tasks.

    Using the Run as command, you can run administrative tools with administrative rights and permissions while logged on as a normal user. You can also build shortcuts to run tools with administrative rights.

    For more information, see:

    • Why you should not run your computer as an administrator
    • Use Run as to start a program as an administrator
    • Create a shortcut using Run as command parameters

    For details about the Run as command, see: Runas.

  • When your forest contains domain trees with many domains, you can optimize the trust paths between domains by creating shortcut trusts between domains at mid-level in the domain trees.

    For more information, see Explicit domain trusts.


Active Directory Domains and Trusts Overview

Active Directory Domains and Trusts helps you manage trust relationships between domains. These domains can be Windows 2000 domains in the same forest, Windows 2000 domains in different forests, pre-Windows 2000 domains, and even Kerberos V5 realms.

Using Active Directory Domains and Trusts you can:

  • Provide interoperability with other domains (such as pre-Windows 2000 domains or domains in other Windows 2000 forests) by managing trusts.
  • Change the mode of operation of a Windows 2000 domain from mixed-mode to native-mode.
  • Add and remove alternate UPN suffixes used to create user logon names.
  • Transfer the domain naming operations master role from one domain controller to another.

Before using Active Directory Domains and Trusts, you should be familiar with the following:

  • Domains overview
  • Introducing domain trees and forests
  • Domain trusts


Concepts

This section provides information about managing Active Directory objects using Active Directory Domains and Trusts.

  • Active Directory Domains and Trusts Overview
  • Understanding Active Directory Domains and Trusts
  • Using Active Directory Domains and Trusts
  • Resources


Understanding Active Directory Domains and Trusts

This section covers:

  • Understanding domains
  • Understanding domain trees and forests
  • Domain and account naming
  • Understanding domain trusts
  • Explicit domain trusts


How to...

  • Add user principal name suffixes
  • Change the domain mode
  • Create an explicit domain trust
  • Verify a trust
  • Revoke a trust
  • Identify the domain naming master
  • Transfer the domain naming master role


New ways to do familiar tasks

The following table lists common tasks performed using Active Directory Domains and Trusts. For users of Windows NT Server, the table also shows where these tasks are performed when using the management tools provided with Windows NT Server 4.0.

If you want to | In Windows NT 4.0 use | In Windows 2000 use
Create or manage trust relationships | User Manager | Active Directory Domains and Trusts For more information, see Active Directory Domains and Trusts.
Manage account policy | User Manager | Active Directory Users and Computers For more information, see Account Policies
Manage user rights | User Manager | Active Directory Users and Computers Edit the Group Policy object for the domain or organizational unit that contains the computers the user rights apply to. For more information see, Work with Group Policy objects
Manage audit policy | User Manager | Active Directory Users and Computers Edit the Group Policy object for the Domain Controllers organizational unit. For more information see, Work with Group Policy objects


Active Directory Domains and Trusts

Use Active Directory Domains and Trusts to administer domain trusts, user principal name suffixes, and change the domain mode.

  • New ways to do familiar tasks
  • Best practices
  • How to...
  • Concepts
  • Troubleshooting


Troubleshooting

What problem are you having?

Receiving "Domain not found", "Server not available", or "RPC server is unavailable" error messages.

Cause: Name registration or name resolution problem

Solution: Verify that DNS is available and functioning correctly. Run the Netdiag /debug command on the server in question. This will evaluate the registration of NetBIOS, DNS, and services.

User is unable to log on locally to a Domain Controller

Cause: The ability to log on locally to a domain controller is controlled by security policies (established in Group Policy settings). By default, only administrators are granted the ability to log on locally to domain controllers.

Solution: In the default Domain Controller Policy object, grant the particular user or group the right to logon locally.


View advanced features

To view advanced features

  1. Open Active Directory Users and Computers.
  2. In the console tree, click the domain node.
  3. On the View menu, click Advanced Features.

Note

Related Topics


Checklists

  • Checklist: Adding a member to a group
  • Checklist: Creating a group
  • Checklist: Upgrading a group


Active Directory Users and Computers overview

Active Directory Users and Computers enables you to add, modify, delete, and organize the Windows 2000 user accounts, computer accounts, security and distribution groups, and published resources in your organization's directory.

Active Directory Users and Computers is a directory administration tool installed on computers configured as domain controllers. It is also available with the optional Administration Tools package. This package can be installed on Windows 2000 Professional computers to enable you to administer Active Directory from a computer that is not a domain controller.

Starting Active Directory Users and Computers

To use Active Directory Users and Computers you must be logged on to a Windows 2000 domain (not the local computer) and have sufficient privileges to perform the particular operation. Members of the Users group have some privileges by default, while members of other groups may have additional privileges. Members of the Account Operators group, for example, can create and delete user accounts. Members of the Administrators group have additional privileges. For more information about groups, see Groups. For more information about delegating administrative authority, see Delegating administration.

Before using Active Directory Users and Computers, you should be familiar with the following:

  • Domains overview
  • Introducing domain trees and forests


Understanding Active Directory Users and Computers

This section describes the Active Directory features and functions you manage using Active Directory Users and Computers.

  • Active Directory user and computer accounts
  • Understanding domains
  • Domain and account naming
  • Understanding domain trees and forests
  • Domain controllers
  • Global catalog
  • Organizational units
  • Groups
  • Understanding Group Policy
  • Understanding groups


Advanced view

You can change how directory objects display in Active Directory Users and Computers by selecting commands on the console View menu. Menu commands include the ability to toggle on/off features such as the console tree, description bar, status bar, large icons, small icons, and so on.

Advanced Features

When you start Active Directory Users and Computers and expand the domain node, several folders display in the console tree view. If you have just installed a domain controller, the folders that display by default are:

  • Builtin
  • Computers
  • Domain controllers
  • Users

When you select Advanced Features on the View menu, two additional folders are displayed in the console:

  • LostAndFound
  • System

Filters

Filter options allow you to show all objects, show only selected objects, or create custom filters using object attributes and LDAP queries.


Best practices

  • Do not log on with administrative privileges. Instead, log on as a normal user and use the Run as command when performing administrative tasks.

    Using the Run as command, you can run administrative tools with administrative rights and permissions while logged on as a normal user. You can also build shortcuts to run tools with administrative rights.

    For more information, see:

    • Why you should not run your computer as an administrator
    • Use Run as to start a program as an administrator
    • Create a shortcut using Run as command parameters

    For details about the Run as command, see: Runas.


Concepts

This section provides information about the Active Directory objects you can manage using Active Directory Users and Computers.

  • Active Directory Users and Computers overview
  • Understanding Active Directory Users and Computers
  • Using Active Directory Users and Computers
  • Resources


Using Active Directory Users and Computers

This section covers:

  • Planning organizational unit structure
  • Advanced view
  • Delegating administration
  • Publishing resources
  • Finding directory information
  • Command-line options
  • Programming interfaces
  • Strategies for using groups
  • Administering Active Directory


Manage domain controllers

  • Find a domain controller
  • Manage a different domain
  • Manage the domain using a different domain controller
  • Delegate control
  • Modify domain controller properties
  • Manage single master operations


Select view filter options

To select view filter options

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Filter Options.
  3. In the Filtering Options dialog box, select one of the following three options:
    • Show all types of objects
    • Show only the following types of objects
    • Create custom filter
  4. Optionally, type the maximum number of objects that you want to display in the console in Maximum number of items displayed per folder.

Notes

  • Show all types of objects is the default filter option. If you select Show only the following types of objects, you can select the objects for display in the associated listing. If you select Create custom filter, you can find objects and select the specific attributes that you want to display in the console.
  • The default maximum number of objects displayed in the console is 2,000 objects.

Related Topics


How to...

  • Manage Domain Controllers
  • Manage User Accounts
  • Manage Computer Accounts
  • Manage Groups
  • Manage Organizational Units
  • Manage Published Resources
  • Change Views


Manage single master operations

  • Identify the relative ID master
  • Identify the PDC emulator
  • Identify the infrastructure master
  • Transfer the relative ID master role
  • Transfer the PDC emulator role
  • Transfer the infrastructure master role


New ways to do familiar tasks

The following table lists common tasks performed using Active Directory Users and Computers. For users of Windows NT Server, the table also shows where these tasks are performed when using the management tools provided with Windows NT Server 4.0.

If you want to | In Windows NT 4.0 use | In Windows 2000 use
Manage user accounts | User Manager | Active Directory Users and Computers For more information, see Manage user accounts.
Manage groups | User Manager | Active Directory Users and Computers For more information, see Manage groups.
Manage computer accounts | Server Manager | Active Directory Users and Computers For more information, see Manage computer accounts.
Add a computer to a domain | Server Manager | Active Directory Users and Computers For more information, see Manage computer accounts.
Manage account policy | User Manager | Active Directory Users and Computers For more information, see Account Policies
Manage user rights | User Manager | Active Directory Users and Computers Edit the Group Policy object for the domain or organizational unit that contains the computers that the user rights apply to. For more information see, Work with Group Policy objects
Manage audit policy | User Manager | Active Directory Users and Computers Edit the Group Policy object for the Domain Controllers organizational unit. For more information see, Work with Group Policy objects


Active Directory Users and Computers

Active Directory Users and Computers is the management console you use to administer and publish information in the directory.

  • Checklists
  • New ways to do familiar tasks
  • Best practices
  • How to...
  • Concepts
  • Troubleshooting


Troubleshooting

What problem are you having?

Cannot create objects in Active Directory.

Cause: The relative ID master is not available. This may be caused by a network connectivity problem. It may also be due to a failure of the computer holding the relative ID master role.

Solution: Resolve the network connectivity problem.
Or, repair or replace the relative ID master computer. It may be necessary to seize the relative ID master role.

See also: Diagnose connections; Single master operations; Responding to operations master failures; Transfer the relative ID master role; Seize the relative ID master role

Clients without Active Directory client software installed cannot log on.

Cause: The primary domain controller emulator is not available. This may be caused by a network connectivity problem. It may also be due to a failure of the computer holding the primary domain controller emulator role.

Solution: Resolve the network connectivity problem.
Or, repair or replace the primary domain controller emulator computer. It may be necessary to seize the primary domain controller emulator role.

See also: Diagnose connections; Single master operations; Responding to operations master failures;Transfer the PDC emulator role; Seize the PDC emulator role

Changes to group memberships are not taking effect.

Cause: The infrastructure master is not available. This may be caused by a network connectivity problem. It may also be due to a failure of the computer holding the infrastructure master role.

Solution: Resolve the network connectivity problem.
Or, repair or replace the infrastructure master computer. It may be necessary to seize the infrastructure master role.

See also: Diagnose connections; Single master operations; Responding to operations master failures; Transfer the infrastructure master role; Seize the infrastructure master role


Manage user accounts

  • Add a user account
  • Copy a user account
  • Disable a user account
  • Enable a disabled user account
  • Delete a user account
  • Find a user account
  • Find a contact
  • Modify user account properties
  • Move a user account
  • Rename a user account
  • Reset a user password
  • Map a certificate to a user account in Active Directory
  • Change a user's primary group


Change views

  • Select view of advanced features
  • Select view filter options


Checklists

  • Checklist: Configuring a site
  • Checklist: Optimizing inter-site replication


Configure server settings

  • Create a Server object
  • Select a query policy
  • Enable or disable a global catalog
  • Designate a preferred bridgehead server
  • Move a domain controller between sites
  • Remove an inoperative server from a site
  • Connect to a forest
  • Connect to a domain controller
  • Check the replication topology
  • Reveal the services node
  • Set security permissions and delegate control of certificate templates


Active Directory Sites and Services

Use Active Directory Sites and Services to administer the replication of directory data.

  • Checklists
  • Best practices
  • How to...
  • Concepts
  • Troubleshooting


Seizure of the domain naming master

The domain controller currently acting as the domain naming master is not available. This could be caused by network problems or by a failure of the domain naming master computer.

Temporary unavailability of the domain naming master is not visible to network users. Seizing of the domain naming master role is a drastic step that should be considered only if the current domain naming master will never be brought back online.

Before proceeding with the role seizure, you must permanently disconnect the current domain naming master from the network. Use the Repadmin command line tool to perform the seizure.

Important

  • After the domain naming master role has been seized, the boot drive for the original domain naming master must be completely reformatted and Windows 2000 Server reinstalled before that computer can be returned to the network.

For more information about operations master roles, see Single master operations.


Seizure of the infrastructure master

The domain controller currently acting as the infrastructure master is not available. This could be caused by network problems or by a failure of the infrastructure master computer.

There should be an infrastructure master in each domain in a forest. Temporary unavailability of an infrastructure master is not visible to network users. Seizing of the infrastructure master role is a drastic step that should be considered only if the current infrastructure master will never be available again.

Before proceeding with the role seizure, you must permanently disconnect the current infrastructure master from the network.

Important

  • After the infrastructure master role has been seized, the boot drive for the original infrastructure master must be completely reformatted and Windows 2000 Server reinstalled before that computer can be returned to the network.

For more information about operations master roles, see Single master operations.


Seizure of the PDC emulator

The domain controller currently acting as the primary domain controller (PDC) emulator is not available. This could be caused by network problems or by a failure of the operations master computer.

You can seize the PDC emulator role and force the role to transfer to another domain controller in the same domain. There should be a PDC emulator in each domain. Because the loss of the PDC emulator role can impact the usability of your network, you should forcefully transfer the PDC emulator role when you know that the current PDC emulator will not be available for an unacceptable length of time.

When the original PDC emulator becomes available again, you can transfer the role back to it.

For more information about operations master roles, see Single master operations.


Seizure of the relative ID master role

The domain controller currently acting as the relative ID master is not available. This could be caused by network problems or by a failure of the relative ID master computer.

There should be a relative ID master in each domain. Temporary unavailability of a relative ID master is not visible to network users. Seizing of the relative ID master role is a drastic step that should be considered only if the current relative ID master will never be available again.

Before proceeding with the role seizure, you must permanently disconnect the current relative ID master from the network.

Important

  • After the relative ID master role has been seized, the boot drive for the original relative ID master must be completely reformatted and Windows 2000 Server reinstalled before that computer can be returned to the network.

For more information about operations master roles, see Single master operations.


Seizure of the schema master role

The domain controller currently acting as the schema master is not available. This could be caused by network problems or by a failure of the schema master computer.

Temporary unavailability of the schema master is not visible to network users. Seizing of the schema master role is a drastic step that should be considered only if the current schema master will never be available again.

Before proceeding with the role seizure, you must permanently disconnect the current schema master from the network.

Important

  • After the schema master role has been seized, the boot drive for the original schema master computer must be completely reformatted and Windows 2000 Server reinstalled before that computer can be returned to the network.

For more information about operations master roles, see Single master operations.


Using Active Directory Domains and Trusts

The following topics discuss information that you must consider when planning and installing or upgrading Active Directory domains:

  • Planning the upgrade from previous domain models
  • Planning your DNS structure
  • Planning your domain structure
  • Upgrading to Active Directory
  • Administering Active Directory


Command-line options

Active Directory Users and Computers has command line options that allow you to start the snap-in focused on a particular domain or domain controller. The command line options support both fully qualified domain names and NetBIOS names

The command line options are:

  • /domain=fully_qualified_domain_name
  • /domain=NetBIOS_domainName
  • /server=fully_qualified_domain_controller_name
  • /server=NetBIOS_domain_controller_name

You can use these command line options to run Active Directory Users and Computers directly from the command line or you can create a shortcut to start the snap-in and add the command line options to the shortcut. You can use the command line options with the standard Active Directory Users and Computers console file (dsa.msc) and with any custom console files that you create. For more information about creating and saving console files, see Microsoft Management Console.

For example:

  • To start Active Directory Users and Computers focused on microsoft.com, type dsa.msc /domain=microsoft.com
  • To start Active Directory Users and Computers focused on server1, type dsa.msc /server=server1.

Note

  • You can use these command line options to specify either the domain or the domain controller focus. Do not use both command line options at the same time.


Incorrect security credentials

This error occurred because your current security credentials do not match the task you are trying to perform. You are logged on as a local user of this computer and you are attempting an Active Directory management task.

To manage users and groups for this computer, click Start, point to Programs, point to Administrative Tools, and then click Computer Management.

To perform Active Directory management tasks, you must be logged on as a member of a domain (for example, yourname@microsoft.com).

To manage Active Directory users, groups, and computers, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

For more information about Active Directory, see Active Directory.

For more information about managing your local computer, see Local Users and Groups.


Best practices

  • Do not log on with administrative rights. Log on as a normal user and use Run as when performing administrative tasks.

    Using the Run as command, you can run administrative tools with administrative rights and permissions while logged on as a normal user. You can also build shortcuts to run tools with administrative permissions.

    For more information, see:

    • Why you should not run your computer as an administrator
    • Use Run as to start a program as an administrator
    • Create a shortcut using Run as command parameters

    For details about the Run as command, see: Runas.

  • Do not casually modify the schema.

    Modifying the schema is an advanced and complex operation best handled programmatically. Developers may decide to modify the schema as part of the process of developing an application that will itself modify the schema. Advanced administrators may decide to modify the schema while troubleshooting an application that they suspect has itself incorrectly modified the schema. For information about modifying or extending the schema, see The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/).

  • Before developing and testing a schema modification, remove the schema operations master from the network or set up an isolated test network.

    If the domain controller is not connected to your primary network, you can test and troubleshoot any problems you may encounter before schema updates are replicated to all of the other domain controllers in the forest.

  • Refer to The Active Directory Programmer's Guide.

    The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/) is the best source of information about modifying the schema. No one should contemplate modifying their schema without first consulting this document.


Concepts

This section covers:

  • Active Directory Schema overview
  • Understanding Active Directory Schema
  • Using Active Directory Schema
  • Resources


How to...

  • Install the Active Directory Schema snap-in
  • Add a member to the Schema Admins group
  • Remove a member from the Schema Admins group
  • Modify schema permissions
  • View a class definition
  • View an attribute definition
  • Add an attribute to the global catalog
  • Index an attribute in Active Directory
  • Enable this computer to extend the schema
  • Deactivate a class or attribute
  • Reload the schema
  • Identify the schema master
  • Transfer the schema master role
  • Seize the schema master role


Troubleshooting

What problem are you having?

Unable to modify or extend the schema

Cause: The schema operations master is not available. The domain controller that currently holds the schema master role is offline or network connectivity between you and the schema master is inoperable.

Solution: Restore the availability of the schema master by fixing the network connectivity problem or by transferring or seizing the schema master role.

See also: Diagnose connections; Single master operations; Transfer the schema master role; Seize the schema master role

Cause: The safety interlocks are not properly set on the domain controller.

Solution: In Active Directory Schema, select The schema may be modified on this server check box. This allows schema changes to be made from the current computer.

See also: Enable this computer to extend the schema

Cause: The user trying to modify the schema does not belong to the Schema Admins group.

Solution: Add the correct user account to the Schema Admins group.

See also: Add a member to the Schema Admins group

Cause: There are syntax errors in the LDAP import format (LDIF) script.

Solution: Debug and fix the LDIF script then try the modification again.

See also: The Active Directory Programmer's Guide at the Microsoft Web site http://www.microsoft.com/; The Internet Engineering Task Force Web site (http://www.ietf.org/).

Note


Using Active Directory schema

Using the Active Directory schema

This section covers:

  • Issues in extending the schema
  • When to extend the schema
  • Before extending the schema
  • Obtaining valid object identifiers
  • Extending the schema
  • Deactivating a class or attribute
  • Updating the schema cache


The Active Directory Schema snap-in is not available

You are trying to run the Active Directory Schema snap-in. You must install Windows 2000 Administration Tools before you can run this snap-in.

Windows 2000 Administration Tools contains Microsoft Management Console (MMC) snap-ins and other administrative tools used to manage computers running Windows 2000 Server. You must have administrative permissions on this computer to install and use Windows 2000 Administration Tools.

To install Windows 2000 Administration Tools on this computer, obtain the applicable Windows 2000 Server compact disc, open the I386 folder, and then double-click the Adminpak.msi file. Follow the instructions that appear in the Windows 2000 Administration Tools Setup wizard.

For more information, see To install the Active Directory Schema snap-in.


Best practices

Active Directory Sites and Services optimizes directory information availability and replication. To take best advantage of this:

  • Do not log on with administrative rights. Run as a normal user and use the Run as command when performing administrative tasks.

    Using the Run as command, you can run administrative tools with administrative rights and permissions while logged on as a normal user. You can also build shortcuts to run tools with administrative permissions.

    For more information, see: Why you should not run your computer as an administrator, Use Run as to start a program as an administrator, To create a shortcut using Run as command parameters

    For details about the Run as command, see: Runas.

  • Every geographic area that requires fast access to the latest directory information should be established as a site.

    Establishing areas that require immediate access to up-to-date directory information as separate sites will provide the resources required to meet your needs.

    For more information, see: To create a site

  • Place at least one domain controller in every site, and create a global catalog on at least one domain controller in each site.

    Sites that do not have their own domain controllers and at least one global catalog are dependent on other sites for directory information, making the utilization of network bandwidth between sites less efficient.

    For more information, see: To install a domain controller, To enable or disable a global catalog

  • All sites must be associated with at least one subnet and in at least one site link, or they will not be usable.

    • For more information, see: To associate a subnet with a site, To add a site to a site link

  • Bridge all site links and ignore schedules for replication.

    Doing so maximizes available connections between sites and the times the connections can be used.

    For more information, see: To bridge all site links, To ignore schedules

  • Establish a preferred bridgehead server if you are using a firewall or if you want to dedicate a computer to inter-site replication.

    A bridgehead server is a proxy for communications with other sites outside of a firewall.

    For more information, see: To designate a preferred bridgehead server, Using preferred bridgehead servers

  • Install an enterprise certification authority (CA) if any of your site links will use SMTP.

    If you choose to use SMTP over site links, you must install an enterprise CA. The CA signs SMTP messages that are exchanged between domain controllers, ensuring the authenticity of directory updates.

    For more information, see: Installing and configuring a certification authority


Services

Windows 2000 uses Active Directory to publish a wide range of information. Domain controllers, in general, are designed to publish directory information and respond to service requests, but Windows 2000 also uses Active Directory to publish service-centric configurations or bindings. Publishing this sort of information makes the service more accessible to clients and more manageable for administrators.

Client requests and receives service information from a domain controller. This service information is then used to access a service being provided on a network server. Applications can get information from the directory. This information is then used to access services provided on network servers. There is a set of services that are published in the directory by default, but you can extend this list to meet the needs of your network environment.

Publishing services to the directory provides a number of benefits:

  • Resource availability. A service-centric model makes accessing distributed network services a simpler task for clients. Because the services are published to the directory, clients do not need to store the resource's location. Potentially, any published service can be available from any computer that is running Windows 2000.
  • Administration. Publishing service bindings enables you to modify those bindings or resolve configuration issues centrally, rather than from individual computers. This ensures that all services employ the latest configuration information.

For recommendations about the sorts of service information to publish, see Service publication.

By default, Active Directory Sites and Services does not display the Services node, although you can choose to display it. For more information, see To reveal the services node.


Understanding Active Directory Sites and Services

This section covers:

  • Sites
  • Services
  • Bandwidth
  • Replication


Concepts

This section covers:

  • Active Directory Sites and Services overview
  • Understanding Active Directory Sites and Services
  • Using Active Directory Sites and Services
  • Resources


How to...

  • Configure Server Settings
  • Configure Site Settings
  • Configure Replication


Troubleshooting

This topic describes problems you may encounter that relate to Active Directory Sites and Services. Most problems that can be remedied with Active Directory Sites and Services involve poor directory information. This can mean that:

  • New directory information is not distributed in a timely fashion.
  • Service requests are not handled in a timely fashion.

Ineffective replication can result in declining Active Directory performance, such as new users not being recognized. Ineffective replication or request handling primarily results in out-of-date directory information or unavailable domain controllers. Each problem cause has one or more possible solutions. In general, the steps described in Checklist: Optimizing inter-site replication may be useful in addressing these problems.

The following table describes a possible scenario that may cause replication of directory information to stop:

Cause | Solution
The sites containing the clients and domain controllers are not connected by site links to domain controllers in other sites in the network. This results in a failure to exchange directory information between sites. | Create a site link from the current site to a site that is connected to the rest of the sites in the network. To create a site link

The following table describes scenarios that can slow replication but should not cause it to stop entirely:

Cause | Solution
Although all sites are connected by site links, your inter-site replication structure is not as complete as it might be. Directory information is replicated to all domain controllers if they are all connected by site links, but this is not optimal. If there are site links but no site link bridges, changes made to domain controllers may take an unacceptably long time to be distributed to other domain controllers that are not closely linked. | Make sure Active Directory has been configured appropriately. Spanning multiple site links and creating site link bridges may provide more efficient replication. To bridge all site links; To create a site link bridge
The current network resources are insufficient to handle the amount of replication traffic. This can affect services unrelated to Active Directory, since the exchange of directory information is consuming an inordinate amount of network resources. | The solutions to this performance problem require increasing the proportion of available network resources relative to directory traffic. This can be achieved by decreasing the frequency in the replication schedule or increasing the site link cost so a site link corresponding to a higher bandwidth network connection is used. To configure site link replication availability; To configure site link cost Making network connections with more bandwidth available to Active Directory be adding site links or site link bridges may also solve this problem. To create a site link; To create a site link bridge
Directory information changed at domain controllers in one site is not being updated in domain controllers in other sites in a timely fashion because inter-site replication is scheduled too infrequently. | Increasing the frequency of replication may make up-to-date information available. If the replication is occurring over a site link bridge, check which site link is restricting replication. Increase the time range during which replication can occur or the frequency of replication within the time frame for that site link. To configure site link replication availability; To configure site link replication frequency
Clients are having to request authentication, information, and services from a domain controller with a low-bandwidth connection. This may result in clients receiving a slow response for authentication, directory information, or other services. | If there is a site that will serve a client's subnet well, associate that subnet with the site. If a client who is experiencing poor service is isolated from domain controllers, and you plan to create another site that will include the client, create a new site with its own domain controller. You can also install a connection with more bandwidth. To associate a subnet with a site; Checklist: Configuring a site


Using Active Directory Sites and Services

This section covers:

  • When to establish a single site
  • When to establish separate sites
  • Using preferred bridgehead servers
  • Service publication
  • Entering subnet information


Active Directory Schema

This section covers:

  • Checklist: Before extending the schema
  • Best practices
  • How To...
  • Concepts
  • Troubleshooting