Understanding Active Directory

My Collection
This document is provided "as-is". Information and views expressed in this document, including URL and other Internet Web site references, may change without
notice. This document does not provide you with any legal rights to any intellectual property in any Microsoft product or product name. You may copy and use
this document for your internal, reference purposes. You may modify this document for your internal, reference purposes. 2013 Microsoft. All rights reserved.
Terms of Use (http://technet.microsoft.com/cc300389.aspx) | Trademarks (http://www.microsoft.com/library/toolbar/3.0/trademarks/en-us.mspx)
Table Of Contents
Chapter 1
Understanding Active Directory
Active Directory Concepts
Chapter 1

Updated: January 21, 2005
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

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:
Securing Active Directory

Access control in Active Directory
Active Directory naming
Directory data store
Directory access protocol
User and computer accounts
Object names
Organizational units
Active Directory server roles
Active Directory clients
Understanding Domains and Forests
Understanding Groups
Understanding Trusts
Understanding Sites and Replication
Understanding the Global Catalog
Interoperating with DNS and Group Policy
Understanding Schema
2014 Microsoft. All rights reserved.

Updated: May 1, 2010

Active Directory provides a secure directory environment for your organization using built-in logon authentication and user authorization. To further secure Active Directory
once it has been deployed, consider the following precautions and recommendations.
For general security information about Active Directory, see Security information for Active Directory.
For more information about authentication, see "Logon and Authentication" at the Microsoft Windows Resource Kits Web Site. For more information about authorization,
see "Authorization and Access Control" at the Microsoft Windows Resource Kits Web Site.
Important
Physical access to a domain controller can provide a malicious user unauthorized access to encrypted passwords. Therefore, it is recommended that all domain
controllers be locked in a secured room with limited public access. In addition, you should limit membership in the Enterprise Admins, Domain Admins, Account
Operators, Server Operators, Print Operators, and Backup Operators groups to trusted personnel in your organization. For more information about domain
controllers and groups, see Domain controllers and Default groups.
To
Use
Manage the security relationship between two forests and simplify security administration and
authentication across forests.
Forest trusts
See Forest trusts.
Force domain users to use strong passwords.
Group Policy
See Strong passwords.
Enable audit policy. Auditing event logs can notify you of actions that could pose a security
risk.
Group Policy
See Auditing Policy.
Assign user rights to new security groups so you can specifically define a user's administrative
role in the domain.
Group Policy
See Group types.
Enforce account lockouts on user accounts and decrease the possibility of an attacker
compromising your domain through repeated logon attempts.
Group Policy
See User and computer accounts.
Enforce password history on user accounts and decrease the possibility of an attacker
compromising your domain.
Group Policy
See Enforce password history.
Enforce minimum and maximum password ages on user accounts and decrease the possibility
of an attacker compromising your domain.
Group Policy
See Minimum password age, Maximum password age.
Verify and authenticate the validity of each user through the use of public key cryptography.
Public key infrastructure

See Deploying a Public Key Infrastructure.
Promote a secure operating environment by running your computer without administrative

credentials except when required.
Run as
See Using Run as.
Restrict user, group, and computer access to shared resources and filter Group Policy settings.
Security groups
See Group types.
Prevent attacks from malicious users who might try to grant elevated user rights to another
user account.
SID filtering
See "Using Security Identifier (SID) Filtering to Prevent Elevation of
Privilege Attacks" at the Microsoft Web Site.
Provide tamper-resistant user authentication and e-mail security.
Smart cards
See Smart cards overview.
Use strong encryption techniques to secure account password information on local computers,
member servers, or domain controllers.
Syskey
See The system key utility.


Administrators can use access control to manage user access to shared resources for security purposes. In Active Directory, access control is administered at the object
level by setting different levels of access, or permissions, to objects, such as Full Control, Write, Read, or No Access. Access control in Active Directory defines how different
users can use Active Directory objects. By default, permissions on objects in Active Directory are set to the most secure setting.
The elements that define access control permissions on Active Directory objects include security descriptors, object inheritance, and user authentication.
Security descriptors
Access control permissions are assigned to shared objects and Active Directory objects to control how different users can use each object. A shared object, or shared
resource, is an object that is intended to be used over a network by one or more users and includes files, printers, folders, and services. Both shared objects and Active
Directory objects store access control permissions in security descriptors.
A security descriptor contains two access control lists (ACLs) used to assign and track security information for each object: the discretionary access control list (DACL) and
the system access control list (SACL).
Discretionary access control lists (DACLs). DACLs identify the users and groups that are assigned or denied access permissions on an object. If a DACL does not
explicitly identify a user, or any groups that a user is a member of, the user will be denied access to that object. By default, a DACL is controlled by the owner of an
object or the person who created the object, and it contains access control entries (ACEs) that determine user access to the object.
System access control lists (SACLs). SACLs identify the users and groups that you want to audit when they successfully access or fail to access an object. Auditing is
used to monitor events related to system or network security, to identify security breaches, and to determine the extent and location of any damage. By default, a
SACL is controlled by the owner of an object or the person who created the object. A SACL contains access control entries (ACEs) that determine whether to record
a successful or failed attempt by a user to access a object using a given permission, for example, Full Control and Read.
For more information about auditing, see Auditing settings on objects.
To view DACLs and SACLs on Active Directory objects using Active Directory Users and Computers, on the View menu, click Advanced Features to access the Security tab
for each object. For more information, see Assign, change, or remove permissions on Active Directory objects or attributes. You can also use the DSACLS support tool to
manage access control lists in Active Directory. For more information, see Active Directory support tools.
By default, DACLs and SACLs are associated with every Active Directory object, which reduces attacks to your network by malicious users or any accidental mistakes made
by domain users. However, if a malicious user obtains a user name and password of any account with administrative credentials to Active Directory, your forest will be
vulnerable to attack. For this reason, consider renaming or disabling the default administrator account and following the best practices as described in Active Directory
Best practices.
Object inheritance
By default, Active Directory objects inherit ACEs from the security descriptor located in their parent container object. Inheritance enables the access control information
defined at a container object in Active Directory to apply to the security descriptors of any subordinate objects, including other containers and their objects. This eliminates
the need to apply permissions each time a child object is created. If necessary, you can change the inherited permissions. However, as a best practice, avoid changing the
default permissions or inheritance settings on Active Directory objects. For more information, see Best practices for assigning permissions on Active Directory objects and
Changing inherited permissions.
User authentication
Active Directory also authenticates and authorizes users, groups, and computers to access objects on the network. The Local Security Authority (LSA) is the security
subsystem responsible for all interactive user authentication and authorization services on a local computer. The LSA is also used to process authentication requests made
through the Kerberos V5 protocol or NTLM protocol in Active Directory. For more information about Kerberos authentication, see Kerberos V5 authentication. For more
information about NTLM authentication, see NTLM authentication.
Once the identity of a user has been confirmed in Active Directory, the LSA on the authenticating domain controller generates a user access token and associates a security
ID (SID) with the user.
Access token. When a user is authenticated, LSA creates a security access token for that user. An access token contains the user's name, the groups to which that
user belongs, a SID for the user, and all of the SIDs for the groups to which the user belongs. If you add a user to a group after the user access token has been
issued, the user must log off and log on again before the access token will be updated.
Security ID (SID). Active Directory automatically assigns SIDs to security principal objects at the time they are created. Security principals are accounts in Active
Directory that can be assigned permissions such as computer, group, or user accounts. Once a SID is issued to the authenticated user, it is attached to the access
token of the user.
The information in the access token is used to determine a user's level of access to objects whenever the user attempts to access them. The SIDs in the access token are
compared with the list of SIDs that make up the DACL for the object to ensure that the user has sufficient permission to access the object. This is because the access
control process identifies user accounts by SID rather than by name.
Important
When a domain controller provides an access token to a user, the access token only contains information about membership in domain local groups if the domain
local groups are local to the domain controller's domain. For domain directory objects replicated in the global catalog, this fact requires certain security
considerations. For more information, see Global catalog replication.
For more information about authentication, see "Logon and Authentication" at the Microsoft Windows Resource Kits Web site.
For more information about access control and permissions, see Access control overview. For more information about authorization and access control, see "Authorization
and Access Control" at the Microsoft Windows Resource Kits Web site.
For information about additional security measures that can be implemented to protect Active Directory, see Securing Active Directory and Security information for Active
Directory.


Active Directory domain names are usually the full Domain Name System (DNS) name of the domain. However, for backward compatibility, each domain also has a preWindows 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
Server 2003 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 Server 2003 domain from computers running Windows 2000, Windows XP, or servers running Windows Server 2003. Users can also log on to computers
running Windows 2000, Windows XP, or servers running Windows Server 2003 using the user principal name (UPN) 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 UPN suffix. The
administrator enters the user logon name and selects the UPN 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 UPN based on IETF RFC 822, Standard for the Format of ARPA Internet Text Messages. The UPN is composed of the user logon
name and the UPN suffix joined by the @ sign.
Note
Do not add the @ sign to the user logon name or to the UPN suffix. Active Directory automatically adds it when it creates the UPN. A UPN that contains more than
one @ sign is invalid.
Important
Windows NT 4.0 and earlier domains allowed the use of a period (.) at the end of a user logon name as long as the user logon name did not consist solely of
period characters. Windows Server 2003 domains do not allow the use of a period or multiple periods at the end of a user logon name.
The second part of the UPN, the UPN suffix, identifies the domain in which the user account is located. This UPN 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 log on purposes. This alternative UPN suffix does not need to be a
valid DNS name.
In Active Directory, the default UPN suffix is the DNS name of the domain in which user account created. In most cases, this is the domain name registered as the enterprise
domain on the Internet. Using alternative domain names as the UPN 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 UPN 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 UPN 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 User and
computer accounts and Object names.
You can add or remove UPN suffixes using Active Directory Domains and Trusts. For more information, 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 (SPN). The administrator enters the computer name when creating the computer account. This
computer name is used as the Lightweight Directory Access Protocol (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 DNS name for a host is called a full computer name and is a DNS fully qualified domain name (FQDN). The full computer name is a concatenation of the computer
name (the first 15 bytes of the SAM account name of the computer account without the "$" character) and the primary DNS suffix (the DNS domain name of the domain in
which the computer account exists). It is listed on the Computer Name tab in System Properties in Control Panel.
By default, the primary DNS suffix portion of the FQDN for a computer must be the same as the name of the Active Directory domain where the computer is located. To
allow different primary DNS suffixes, a domain administrator may create a restricted list of allowed suffixes by creating the msDS-AllowedDNSSuffixes attribute in the
domain object container. This attribute is created and managed by the domain administrator using Active Directory Service Interfaces (ADSI) or the Lightweight Directory
Access Protocol (LDAP).
For more information, see Object names and User and computer accounts.
The service principal name (SPN) is a multivalue attribute. It is usually built from the DNS name of the host. The SPN 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 SPN of the service to which it is trying to connect. The SPN can be
modified by members of the Domain Admins group.


The Active Directory directory service uses a data store for all directory information. This data store is often 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 entire domain in which it is located. Changes made to the directory on one domain controller are replicated to other domain
controllers in the domain, domain tree, or forest. Active Directory uses four distinct directory partition types to store and copy different types of data. Directory partitions
contain domain, configuration, schema, and application data. This storage and replication design provides directory information to users and administrators throughout
the domain.
Directory data is stored in the Ntds.dit file on the domain controller. It is recommended that you store this file on an NTFS partition. For more information about the tool
used to manage the Active Directory database and log files, see Files in Ntdsutil. 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. For more information about replication, see Replication overview.
Directory data replicated between domain controllers includes the following:
Domain data
The domain data holds information about objects within a domain. This is 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. Domain controllers running Windows Server 2003 include 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 more information, see Schema.
Application data
Data stored in the application directory partition is intended to satisfy cases where information needs to be replicated but not necessarily on a global scale.
Application directory partitions are not part of the directory data store by default; they must be created, configured, and managed by the administrator.
For more information, see Application directory partitions.
Note
If a 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 The role of the global catalog.
Quotas and directory partitions

Quotas, a new feature with domain controllers running Windows Server 2003 , determine the number of objects that can be owned in a given directory partition by a
security principal. (The owner of an object is usually, but not always, the creator of the object.) Quotas can help prevent the denial of service that can occur if a security
principal accidentally, or intentionally, creates objects until the affected domain controller runs out of storage space.
Quotas are specified and administered for each directory partition separately. The schema partition, however, has no quotas. On a given directory partition, you can assign
quotas for any security principal, including users, inetOrgPersons, computers, and groups. Members of the Domain Admins and Enterprise Admins groups are exempt
from quotas. In some cases, a security principal might be covered by multiple quotas. For example, a user might be assigned an individual quota, and also belong to one
or more security groups that also have quotas assigned to them. In such cases, the effective quota is the maximum of the quotas assigned to the security principal.
If a security principal is not assigned a quota either directly or through a group membership, a default quota on the partition governs the security principal. If you do not
explicitly set the default quota on a given partition, the default quota of that partition is unlimited (ie, there is no limit).
Tombstone objects owned by a security principal are also counted as part of the quota consumption of that security principal. For each partition, you can specify a
tombstone quota factor to determine the percentage weight given to a tombstone object in quota accounting. For example, if the tombstone quota factor for a given
partition is set to 25 or 25%, then a tombstone object on the partition is counted as 0.25 or of a normal object. If a quota of 100 is specified for a user on this
partition, then the user could own a maximum of 100 normal objects, or a maximum 400 tombstone objects. The default tombstone quota factor for each partition is
initially set to 100 (or 100%), meaning that normal and tombstones objects are weighted equally.
The following example illustrates how quotas can be used. Consider the domain "sales.northwindtraders.com." Because this domain supports a lot of printing activity, the
domain contains several print servers that each support 1,000 or more print queues. Initially, the default quota of the sales.northwindtraders.com domain partition is set to
unlimited. To help control the number of objects created and owned, the administrator specifies a default quota of 500. Now, each user can own a maximum of 500
objects on the partition. Because print queues are directory objects that are created and owned by the respective print servers, the new default quota of 500 limits each
print server to 500 print queues. To remove this constraint, the administrator creates a group called "Print Servers" and adds the computer account of each print server to
the group. The administrator then specifies a quota of 2,000 for the Print Servers group. Now, each print server can support its original number of print queues, while the
default quota continues to prevent excess object creation by all other security principals.
Only domain controllers running Windows Server 2003 can enforce quotas. Quotas are enforced only on originating directory operations; quotas are not enforced on
replicated operations. In order for quotas to be fully effective for any given directory partition, all domain controllers that contain a writable copy of that partition must be
running Windows Server 2003 . Therefore, for quotas to be effective on a domain directory partition, all domain controllers in that domain must be running Windows
Server 2003 . For quotas to be effective on the configuration partition, all domain controllers in the forest must by running Windows Server 2003 .
For information about creating, modifying, and querying quotas, default quotas, and tombstone quota factors, see Dsadd, Dsmod, and Dsquery.


Active Directory clients must communicate with domain controllers when logging on 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. 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 Internet Engineering Task Force Web site.
Note
Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.

Updated: July 26, 2013

Active Directory user accounts and computer accounts represent a physical entity such as a computer or person. User accounts can also be used as dedicated service
accounts for some applications.
User accounts and computer accounts (as well as groups) are also referred to as security principals. Security principals are directory objects that are automatically
assigned security IDs (SIDs), which can be used to access domain resources. A user or computer account is used to:
Authenticate the identity of a user or computer.

A user account enables a user to log on to computers and domains with an identity that can be authenticated by the domain. For information about authentication,
see Access control in Active Directory. Each user who logs on to the network should have his or her own unique user account and password. To maximize security,
you should avoid multiple users sharing one account.
Authorize or deny access to domain resources.
Once the user has been authenticated, the user is authorized or denied access to domain resources based on the explicit permissions assigned to that user on the
resource. For more information, see Security information for Active Directory.
Administer other security principals.
Active Directory creates a foreign security principal object in the local domain to represent each security principal from a trusted external domain. For more
information about foreign security principals, see When to create an external trust.
Audit actions performed using the user or computer account.
Auditing can help you monitor account security. For more information about auditing, see Auditing overview.
User accounts
The Users container located in Active Directory Users and Computers displays the three built-in user accounts: Administrator, Guest, and HelpAssistant. These built-in user
accounts are created automatically when you create the domain.
Each built-in account has a different combination of rights and permissions. The Administrator account has the most extensive rights and permissions over the domain,
while the Guest account has limited rights and permissions. The table below describes each default user account on domain controllers running Windows Server 2003.
Default user
account
Administrator
account
Description
The Administrator account has full control of the domain and can assign user rights and access control permissions to domain users as necessary. This
account must be used only for tasks that require administrative credentials. It is recommended that you set up this account with a strong password. For
more information, see Strong passwords. For additional security considerations for accounts with administrative credentials, see Active Directory Best
practices.
The Administrator account is a default member of the Administrators, Domain Admins, Enterprise Admins, Group Policy Creator Owners, and Schema
Admins groups in Active Directory. The Administrator account can never be deleted or removed from the Administrators group, but it can be renamed
or disabled. Because the Administrator account is known to exist on many versions of Windows, renaming or disabling this account will make it more
difficult for malicious users to try and gain access to it. For more information about how to rename or disable a user account, see Rename a local user
account or Disable or enable a user account.
The Administrator account is the first account created when you set up a new domain using the Active Directory Installation Wizard.
Important When the Administrator account is disabled, it can still be used to gain access to a domain controller using Safe Mode.
Guest
account
The Guest account is used by people who do not have an actual account in the domain. A user whose account is disabled (but not deleted) can also use
the Guest account. The Guest account does not require a password.
You can set rights and permissions for the Guest account just like any user account. By default, the Guest account is a member of the built-in Guests
group and the Domain Guests global group, which allows a user to log on to a domain. The Guest account is disabled by default, and it is
recommended that it stay disabled.
HelpAssistant
account
(installed with
a Remote
Assistance
session)
The primary account used to establish a Remote Assistance session. This account is created automatically when you request a Remote Assistance
session and has limited access to the computer. The HelpAssistant account is managed by the Remote Desktop Help Session Manager service and will
be automatically deleted if no Remote Assistance requests are pending. For more information about Remote Assistance, see Administering Remote
Assistance.
Securing user accounts

If built-in account rights and permissions are not modified or disabled by a network administrator, they could be used by a malicious user (or service) to illegally log on to
a domain using the Administrator or Guest identity. A good security practice for protecting these accounts is to rename or disable them. Because it retains its security ID
(SID), a renamed user account retains all its other properties, such as its description, password, group memberships, user profile, account information, and any assigned
permissions and user rights.
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 a group 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.
You can help defend your domain from attackers by requiring strong passwords and implementing an account lockout policy. Strong passwords reduce the risk of
intelligent guessing and dictionary attacks on passwords. For more information, see Strong passwords and Password Best practices for passwords.
An account lockout policy decreases the possibility of an attacker compromising your domain through repeated logon attempts. This is because an account lockout policy
determines how many failed logon attempts a user account can have before it is disabled. For more information, see Apply or modify account lockout policy.
For more information about securing user accounts, see Securing Active Directory.
Account options
Each Active Directory user account has a number of account options that determine how someone logging on with that particular user account is authenticated on the
network. You can use the following options to configure password settings and security-specific information for user accounts:
Account option
Description
User must
change
password at next
logon
Forces a user to change their password the next time the user logs on to the network. Use this option when you want to ensure that the user will be
the only person to know their password.
User cannot
change
password
Prevents a user from changing their password. Use this option when you want to maintain control over a user account, such as for a guest or
temporary account.
Password never
expires
Prevents a user password from expiring. It is recommended that Service accounts should have this option enabled and should use strong
passwords. For more information about strong passwords, see Strong passwords.
Store passwords
using reversible
encryption
Allows a user to log on to a Windows network from Apple computers. If a user is not logging on from an Apple computer, this option should not
be used. For more information, see Store passwords using reversible encryption.
Account is
disabled
Prevents a user from logging on with the selected account. Many administrators use disabled accounts as templates for common user accounts. For
more information, see Disable or enable a user account.
Smart card is
required for
interactive logon
Requires that a user possess a smart card to log on to the network interactively. The user must also have a smart card reader attached to their
computer and a valid personal identification number (PIN) for the smart card. When this option is selected, the password for the user account is
automatically set to a random and complex value. For more information about smart cards, see Logging on to a computer with a smart card and
Authentication process.
Account is
trusted for
delegation
Allows a service running under this account to perform operations on behalf of other user accounts on the network. A service running under a user
account (otherwise known as a service account) that is trusted for delegation can impersonate a client to gain access to resources on the computer
where the service is running or on other computers. In a forest set to the Windows Server 2003 functional level, this setting is found on the
Delegation tab, and is only available for accounts that have been assigned service principal names (SPNs), as set using the setspn command from
the Windows Support Tools. This is a security-sensitive capability and should be cautiously assigned. For more information, see Allow a user to be
trusted for delegation and Delegating authentication.
This option is only available on domain controllers running Windows Server 2003 where the domain functionality is set to Windows 2000 mixed or
Windows 2000 native. On domain controllers running Windows Server 2003 where the domain functional level is set to Windows Server 2003, the
Delegation tab is used to configure delegation settings. The Delegation tab only appears for accounts which have an assigned SPN. For more
information about domain functionality, see Domain and forest functionality. For more information about configuring delegation in a Windows
Server 2003 domain, see Allow a user to be trusted for delegation.
Account is
sensitive and
cannot be
delegated
Allows control over a user account, such as for a guest or temporary account. This option can be used if this account cannot be assigned for
delegation by another account.
Use DES
encryption types
for this account
Provides support for 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 about DES
encryption, see Data encryption.
Do not require
Kerberos
preauthentication
Provides support for alternate implementations of the Kerberos protocol. Domain controllers running Windows 2000 or Windows Server 2003 can
use other mechanisms to synchronize time. Because preauthentication provides additional security, use caution when enabling this option. For more
information about Kerberos, see Kerberos V5 authentication.
InetOrgPerson accounts
Active Directory provides support for the InetOrgPerson object class and its associated attributes defined in RFC 2798. The InetOrgPerson object class is used in several
non-Microsoft LDAP and X.500 directory services to represent people within an organization.
Support for InetOrgPerson makes migrations from other LDAP directories to Active Directory more efficient. The InetOrgPerson object is derived from the user class and
can be used as a security principal just like the user class. For information about creating an inetOrgPerson user account, see Create a new user account.
When the domain functional level has been set to Windows Server 2003, you can set the userPassword attribute on InetOrgPerson and user objects as being the effective
password just like you can with the unicodePwd attribute.
Computer accounts
Every computer running Windows NT, Windows 2000, Windows XP, or a server running Windows Server 2003 that joins a domain has a computer account. Similar to user
accounts, computer accounts provide a means for authenticating and auditing computer access to the network and to domain resources. Each computer account must be
unique.
Note Computers running Windows 95 and Windows 98 do not have advanced security features and are not assigned computer accounts.
User and computer accounts can be added, disabled, reset, and deleted using Active Directory Users and Computers. A computer account can also be created when you
join a computer to a domain. For more information about user and computer accounts, see Active Directory naming and Object names.
When the domain functional level has been set to Windows Server 2003, a new lastLogonTimestamp attribute is used to track the last logon time of a user or computer
account. This attribute is replicated within the domain and can provide you with important information regarding the history of a user or computer.
Object names
Object names
Every object in Active Directory is an instance of a class defined in the 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 Schema.
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. Relative distinguished names must be unique in that users cannot have the same name within an organizational unit.
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 IDs (SIDs) and can be used to log on to the network and can be assigned 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
Computers running Windows Server 2003 and Windows 2000 can

use a user principal name (UPN) for a user account. Computers
running Windows NT 4.0 and earlier are limited to 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 (.) or spaces, or end in a period. Any
leading periods or spaces are cropped. Use of the @ symbol is not supported with
the logon format for Windows NT 4.0 and earlier, which is DomainName\UserName.
Windows 2000 logon names are unique to the domain and Windows Server 2003
logon names are unique within the forest.
Computer
account
NetBIOS = 15 characters, or 15 bytes depending upon the

character set; individual characters may require more than one
byte.
DNS = 63 characters or 63 bytes depending upon the character
set and 255 characters for a fully qualified domain name (FQDN)
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;

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, then it is possible to use computer names containing more than 15 characters. For more information, see
Active Directory naming.
From the information provided by the person who creates the security principal object, Active Directory generates a security ID (SID), 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 SID, 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 SID, 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 Active Directory naming and Add user principal name suffixes, and User and computer accounts.
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. You can then manage the configuration and use of accounts
and resources based on your organizational model. For more information about Group Policy settings, see Group Policy (pre-GPMC).
As shown in the figure, 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 have 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.


Computers that function as servers within a domain can have one of two roles: member server or domain controller. A server that is not in a domain is a stand-alone
server.
Member servers
A member server is a computer that:
Runs an operating system in the Windows 2000 Server family or the Windows Server 2003 family.
Belongs to a domain.
Is not a domain controller.
A member server does not process account logons, participate in Active Directory replication, or 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, and
remote access servers. For more information about server roles, see Server roles.
The following security-related features are common to all member servers:
Member servers adhere to Group Policy settings that are defined for the site, domain, or organizational unit.
Access control for resources that are available on a member server.
Member server users have assigned user rights.
Member servers contain a local security account database, the Security Accounts Manager (SAM).
Domain controllers
A domain controller is a computer that:
Uses Active Directory to store a read-write copy of the domain database, participate in multimaster replication, and authenticate users.
Domain controllers store directory data and manage communication between users and domains, including user logon processes, authentication, and directory searches.
Domain controllers synchronize directory data using multimaster replication, ensuring consistency of information over time. For more information about multimaster
replication, see Replication overview.
Active Directory supports multimaster replication of directory data between all domain controllers in a domain; however, multimaster replication is not appropriate for
some directory data replication. In this case, a domain controller, called the operations master, will process data. In an 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 Operations master roles.
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 install Active
Directory on a member server to make it a domain controller, or you can remove Active Directory from a domain controller to make it a member server. For more
information about domain controllers, see Domain controllers.
Note
You cannot install Active Directory on a computer running Windows Server 2003, Web Edition, but you can join the computer to an Active Directory domain as a
member server. For more information about Windows Server 2003, Web Edition, see Overview of Windows Server 2003, Web Edition.


With the Active Directory client, many of the Active Directory features available on Windows 2000 Professional or Windows XP Professional are available to computers
running Windows 95, Windows 98, and Windows NT 4.0.
Site awareness
You can log on to the domain controller that is closest to the client in the network. For more information, see Locating a domain controller.
Active Directory Service Interfaces (ADSI)
You can use scripting to Active Directory. ADSI also provides a common programming API to Active Directory programmers.
Distributed File System (DFS)
You can access DFS shared resources on servers running Windows 2000 and Windows Server 2003.
NTLM version 2 authentication
You can use the improved authentication features in NTLM version 2.
For more information about enabling NTML version 2, see article Q239869, "How to Enable NTLM 2 Authentication," in the Microsoft Knowledge Base.
Active Directory Windows Address Book (WAB) property pages
You can change properties, such as phone number and address, on user object pages.
Active Directory search capability
From the Start button, you can locate printers and people in a Windows 2000 Server or Windows Server 2003 domain.
For information about publishing printers in Active Directory, see article Q234619, "Publishing a Printer in Windows 2000 Active Directory," in the Microsoft
Knowledge Base.
Windows 2000 Professional and Windows XP Professional provide functionality that the Active Directory client on Windows 95, Windows 98, and Windows NT 4.0 does not,
including Kerberos V5 support; Group Policy or IntelliMirror support; and service principal name (SPN), or mutual authentication. You can take advantage of these
additional features by upgrading to Windows 2000 Professional or Windows XP Professional.
To install the Active Directory client, see the Active Directory client page at the Microsoft Web site.


Domain controllers
Renaming domain controllers
Connecting to domain controllers running Windows 2000
Domains
Renaming domains
Domain and forest functionality
Raising domain and forest functional levels
Application directory partitions
Application directory partitions and domain controller demotion
Managing application directory partitions
Operations master roles
Transferring operations master roles
Responding to operations master failures
Domain controllers
Domain controllers
When you create the first domain controller in your organization, you are also creating the first domain, the first forest, the first site, and installing Active Directory. Domain
controllers running Windows Server 2003 store directory data and manage user and domain interactions, including user logon processes, authentication, and directory
searches. Domain controllers are created by using the Active Directory Installation Wizard. For more information, see Using the Active Directory Installation Wizard.
Note
When using domain controllers in your organization, you will want to think about how many domain controllers youll need, the physical security of those domain
controllers, a plan for backing up the domain data, and upgrading domain controllers.
Determining the number of domain controllers you need

A small organization using a single local area network (LAN) might need only one domain with two domain controllers for high availability and fault tolerance. A larger
organization with many network locations will need one or more domain controllers in each site to provide high availability and fault tolerance.
If your network is divided into sites, it is often good practice to put at least one domain controller in each site to enhance network performance. When users log on to the
network, a domain controller must be contacted as part of the logon process. If clients must connect to a domain controller located in a different site, the logon process
can take a long time. For more information, see Replication between sites.
By creating a domain controller in each site, user logons are processed more efficiently within the site. For information about how to create additional domain controllers,
see Create an additional domain controller.
To optimize network traffic, you can also configure domain controllers to receive directory replication updates only during off-peak hours. For information about how to
schedule site replication, see Configure site link replication availability.
The best network performance is available when the domain controller at a site is also a global catalog. This way, the 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. For more information about the global catalog,
see The role of the global catalog. For more information about adding global catalogs to sites, see Global catalogs and sites.
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 Operations master roles.
Physical security
Physical access to a domain controller can provide a malicious user unauthorized access to encrypted passwords. For this reason, it is recommended that all domain
controllers in your organization be locked in a secured room with limited public access. You can use additional security measures such as Syskey for extra protection on
domain controllers. For more information about Syskey, see The system key utility.
Backing up domain controllers

You can back up domain directory partition data and data from other directory partitions by using Backup, which is included with the Windows Server 2003 family, from any
domain controller in a domain. By using the backup tool on a domain controller, you can:
Back up Active Directory while the domain controller is online.

Back up Active Directory using batch file commands.
Back up Active Directory to removable media, an available network drive, or a file.
Back up other system and data files.
When you use the backup tool on a domain controller it will automatically back up all of the system components and all of the distributed services upon which Active
Directory is dependent. This dependent data, which includes Active Directory, is known collectively as the System State data.
On a domain controller running Windows Server 2003, the System State data consists of the system startup files; the system registry; the class registration database of
COM+ (an extension to the Component Object Model); the SYSVOL directory; Certificate Services database (if installed); Domain Name System (if installed); Cluster service
(if installed); and Active Directory. It is recommended that you regularly back up System State data.
For general information about the System State, see System State data. For more information about how to back up the System State, see Back up System State data. For
more information about how to restore a System State backup, see Restore System State data.
You can install Active Directory on a server running Windows Server 2003 by using a restored backup taken from a domain controller running Windows Server 2003. For
more information, see Creating an additional domain controller.
Upgrading domain controllers

On domain controllers running Windows NT 4.0, you will first need to upgrade the primary domain controller (PDC) to successfully upgrade the domain. Once the PDC has
been upgraded, you can upgrade the backup domain controllers (BDCs). For more information, see Upgrading from a Windows NT domain.
If you currently have a Windows 2000 forest that does not have any domain controllers running Windows Server 2003, you will need to prepare the forest and the target
domain before you can upgrade domain controllers running Windows 2000. For more information, see Upgrading from a Windows 2000 domain.

Updated: April 23, 2013

The ability to rename domain controllers running Windows Server 2003 provides you with the flexibility to make changes in a Windows Server 2003 domain whenever the
need arises. Rename a domain controller to:
Restructure your network for organizational and business needs.

Make management and administrative control easier.
When you rename a domain controller, you must ensure that there will be no interruption in the ability of clients to locate or authenticate to the renamed domain
controller, except when the domain controller is restarted. The recommended practice for renaming a domain controller without interruption to clients is to use the
Netdom tool. To rename a domain controller using the Netdom tool, the domain functional level must be set to Windows Server 2003. For more information about
renaming a domain controller, see Rename a domain controller.
The System Properties dialog box can also be used to rename a domain controller, and it does not require the functional level to be raised to Windows Server 2003.
Using this dialog box may result in a service interruption to clients. For more information about functional levels, see Domain and forest functionality.
The new name of the domain controller is automatically updated to Domain Name System (DNS) and Active Directory. Once the new name propagates to DNS and Active
Directory, clients are then capable of locating and authenticating to the renamed domain controller. DNS and Active Directory replication latency may delay client ability to
locate or authenticate to the renamed domain controller. The length of time this takes depends on specifics of your network and the replication topology of your particular
organization.
During replication latency, clients may not be able to access the newly renamed domain controller. This might be acceptable for clients that try to locate and authenticate to
a particular domain controller since other domain controllers should be available to process the authentication request.
Note
The corresponding nTFRSMember or msDFSR-Member object is not renamed automatically, but the reference attributes are correctly set so SYSVOL replication is not
impacted. The only potential problem with not renaming these objects is that if another domain controller is created at a later date with the same NetBIOS name of the
old domain controller, then a conflict can occur as described in KB article 316826. After the rename is complete, you can optionally rename the nTFRSMember or
msDFSR-Member object as part of cleanup.


When you need to connect to a domain controller running Windows 2000 from a domain controller running Windows Server 2003, a number of Active Directory
administrative tools are available, such as Active Directory Domains and Trusts.
The following Windows Server 2003 Active Directory administrative tools will sign and encrypt all LDAP traffic by default:
Active Directory Users and Computers

Active Directory Sites and Services
Active Directory Domains and Trusts
Active Directory Schema
ADSI Edit
Dsrm.exe
Dsmove.exe
Dsadd.exe
Dsmod.exe
Dsget.exe
Dsquery.exe
Signing LDAP traffic guarantees that the packaged data comes from a known source and that it has not been tampered with. The Active Directory administrative tools in
Windows 2000 do not sign and encrypt all LDAP traffic by default. In order to maintain a secure network, it is strongly recommended that you upgrade all domain
controllers running Windows 2000 to Service Pack 3 or later.
You can use the corresponding Active Directory administrative tools in Windows 2000 to manage Windows 2000 domain controllers that do not have the Windows 2000
Server Service Pack 3 or later installed. However, traffic is not signed and encrypted by LDAP on domain controllers running Windows 2000.
Although it is not recommended, you can disable encrypted and signed LDAP traffic used with Active Directory administrative tools on a server running Windows
Server 2003 or on a computer running Windows XP Professional that has the Windows Server 2003 Administration Tools Pack installed. For more information, see Disable
signed or encrypted LDAP traffic.
Domains
Domains
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. Each domain in Active Directory is identified by a Domain Name System (DNS) domain name and requires one or more domain controllers. If your network
requires more than one domain, you can easily create multiple domains.
One or more domains that share a common schema and global catalog are referred to as a forest. The first domain in a forest is referred to as the forest root domain.
For more information about forests, see Creating a new forest. If multiple domains in the forest have contiguous DNS domain names, then the structure is referred to as a
domain tree. For more information, see Active Directory naming and Creating a new domain tree.
A single domain can span multiple physical locations or sites and can 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. For more information, see Sites overview.
A domain provides several benefits:
Organizing objects.
You do not need to create separate domains merely to reflect your company's organization of divisions and departments. Within a domain, you can use
organizational units for this purpose. Using organizational units helps you manage the accounts and resources in the domain. You can then assign Group Policy
settings and place users, groups, and computers into the organizational units. Using a single domain greatly simplifies administrative overhead. For more
information, see Organizational units.
Publishing resources and information about domain objects.
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. When using multiple domains, you can scale the Active Directory directory service to accommodate your administrative and
directory publishing requirements. For more information, Publishing resources.
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 (GPO) 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 GPOs, see Group Policy (pre-GPMC).
Delegating authority eliminates the need for a number of administrators with broad 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.
Security policies and settings (such as user rights and password policies) do not cross from one domain to another.
Each domain has its own security policies and trust relationships with other domains. However, the forest is the final security boundary. For more information, see
Creating a new forest.
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.
Creating a domain
You create a domain by creating the first domain controller for a domain. To do this, install Active Directory on a member server running Windows Server 2003 by using
the Active Directory Installation Wizard. The wizard uses the information that you provide to create the domain controller and create the domain within the existing domain
structure of your organization. Depending on the existing domain structure, the new domain could 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. For more information, see Creating a new forest, Creating a new domain tree, and Creating a new child domain.
A domain controller provides the Active Directory directory service to network users and computers, stores directory data, and manages user and domain interactions,
including user logon processes, authentication, and directory searches. Every domain must contain at least one domain controller. For more information, see Domain
controllers.
After you create the first domain controller for a domain, you can create additional domain controllers in an existing domain for fault tolerance and high availability of the
directory. For more information, see Creating an additional domain controller.
Planning for multiple domains

Some reasons to create more than one domain are:
Different password requirements between departments or divisions

Massive numbers of objects
Decentralized network administration
More control of replication
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.
Removing a domain
In order to remove a domain, you must first remove Active Directory from all of the domain controllers associated with that domain. Once Active Directory has been
removed from the last domain controller the domain will be removed from the forest and all of the information in that domain will be deleted. A domain can only be
removed from the forest if it has no child domains. If this is the last domain in the forest, removing this domain will also delete the forest.
For more information about how to remove a domain, see Remove a domain.
Caution
Removing a domain will result in the permanent loss of amy data contained in that domain. This includes all user, group, and computer accounts.
Before removing Active Directory from a domain controller, you should first remove any application directory partitions from that domain controller. For more information,
see Application directory partitions and Create or delete an application directory partition.
Trust relationships between domains

Trust relationships are automatically created between adjacent domains (parent and child domains) when a domain is created in Active Directory. In a forest, a trust
relationship is automatically created between the forest root domain and any tree root domains or child domains that are subordinate to the forest root domain. Because
these trust relationships are transitive, users and computers can be authenticated between any domains in the forest. For more information about trust relationships, see
Trust transitivity.
When upgrading a Windows NT domain to a Windows Server 2003 domain, the existing one-way trust relationship between that domain and any other domains remains
intact. This includes all trusts with other Windows NT domains. If you are creating a new Windows Server 2003 domain and want trust relationships with any Windows NT
domains, you must create external trusts with those domains. For more information about external trusts, see When to create an external trust.
Renaming domains
Renaming domains
The ability to rename a domain provides you with the flexibility to make important changes to your forest structure and namespace as the needs of your organization
change. Renaming domains can accommodate acquisitions, mergers, name changes, or reorganizations. Domain rename allows you to:
Change the Domain Name System (DNS) and NetBIOS names of any domain in the forest (including the forest root domain).
Restructure the position of any domain in the forest (except the forest root domain).
You can only rename domains in a forest where all of the domain controllers are running Windows Server 2003 and the forest functional level has been raised to Windows
Server 2003. For more information, see Domain and forest functionality.
Forest restructuring
Using domain rename, you can also restructure the hierarchy of domains in your forest so that a domain residing in one domain tree can be moved to another domain
tree. Restructuring a forest allows you to move a domain anywhere within the forest in which it resides (except the forest root domain). This includes the ability to move a
domain so that it becomes the root of its own domain tree.
You can use the domain rename utility (Rendom.exe) to rename or restructure a domain. A domain rename will affect every domain controller in your forest and is a
multistep process that requires a detailed understanding of the operation. For more information about this process and to download the Rendom.exe tool, see the
Windows Server 2003 Active Directory Domain Rename Tools page at the Microsoft Web site.


Domain and forest functionality, introduced in Windows Server 2003 Active Directory, provides a way to enable domain- or forest-wide Active Directory features within your
network environment. Different levels of domain functionality and forest functionality are available depending on your environment.
If all domain controllers in your domain or forest are running Windows Server 2003 and the functional level is set to Windows Server 2003, all domain- and forest-wide
features are available. When Windows NT 4.0 or Windows 2000 domain controllers are included in your domain or forest with domain controllers running Windows
Server 2003, Active Directory features are limited. For more information about how to enable domain- or forest-wide features, see Raising domain and forest functional
levels.
The concept of enabling additional functionality in Active Directory exists in Windows 2000 with mixed and native modes. Mixed-mode domains can contain
Windows NT 4.0 backup domain controllers and cannot use Universal security groups, group nesting, and security ID (SID) history capabilities. When the domain is set to
native mode, Universal security groups, group nesting, and SID history capabilities are available. Domain controllers running Windows 2000 Server are not aware of
domain and forest functionality.
Domain functionality
Domain functionality enables features that will affect the entire domain and that domain only. Four domain functional levels are available: Windows 2000 mixed (default),
Windows 2000 native, Windows Server 2003 interim, and Windows Server 2003. By default, domains operate at the Windows 2000 mixed functional level.
The following table lists the domain functional levels and their corresponding supported domain controllers.
Domain functional level
Domain controllers supported
Windows 2000 mixed (default)
Windows NT 4.0
Windows 2000
Windows Server 2003 family
Windows 2000 native
Windows 2000
Windows Server 2003 interim
Windows NT 4.0
Windows Server 2003
Once the domain functional level has been raised, domain controllers running earlier operating systems cannot be introduced into the domain. For example, if you raise
the domain functional level to Windows Server 2003, domain controllers running Windows 2000 Server cannot be added to that domain.
The following table describes the domain-wide features that are enabled for three of the domain functional levels. For information about the Windows Server 2003 interim
functional level, see Upgrading from a Windows NT domain.
Domain feature
Windows 2000 mixed
Windows 2000 native
Windows Server 2003
Domain controller rename tool

For more information, see Renaming domain controllers.
Disabled
Disabled
Enabled
Different location option for user and computer

accounts
For more information about how to redirect the default
location for user and computer accounts, see Redirect the
Users and Computers Containers.
Disabled
Disabled
Enabled
Update logon timestamp

For more information about the lastLogonTimestamp
attribute, see User and computer accounts.
Disabled
Disabled
Enabled
User password on InetOrgPerson object

For more information about InetOrgPerson objects, see
User and computer accounts.
Disabled
Disabled
Enabled
Universal Groups
For more information, see Group types and Group scope.
Enabled for distribution groups.

Disabled for security groups.
Enabled
Allows both security and
distribution groups.
Enabled
Group Nesting
For more information, see Nesting groups.

Disabled for security groups, except for
domain local security groups that can have
global groups as members.
Enabled
Allows full group nesting.
Enabled
Converting Groups
For more information, see Converting groups.
Disabled
No group conversions allowed.
Enabled
Allows conversion between
security groups and
Enabled
security groups and
SID history
Disabled
Enabled
Allows migration of
security principals from
one domain to another.
Enabled
Allows migration of
Forest functionality
Forest functionality enables features across all the domains within your forest. Three forest functional levels are available: Windows 2000 (default), Windows Server 2003
interim, and Windows Server 2003 . By default, forests operate at the Windows 2000 functional level. You can raise the forest functional level to Windows Server 2003 .
The following table lists the forest functional levels and their corresponding supported domain controllers:
Forest functional level
Windows 2000 (default)
Windows NT 4.0
Windows 2000
Windows NT 4.0
Windows Server 2003
Once the forest functional level has been raised, domain controllers running earlier operating systems cannot be introduced into the forest. For example, if you raise the
forest functional level to Windows Server 2003, domain controllers running Windows 2000 Server cannot be added to the forest.
If you are upgrading your first Windows NT 4.0 domain so that it becomes the first domain in a new Windows Server 2003 forest, you can set the domain functional level to
Windows Server 2003 interim. For more information, see Upgrading from a Windows NT domain.
The following table describes the forest-wide features that are enabled for the Windows 2000 and Windows Server 2003 forest functional levels.
Windows
Server 2003
Forest feature
Windows 2000
Global catalog replication improvements

For more information, see Global catalog replication.
Enabled if both replication partners are running Windows

Server 2003.
Otherwise, disabled.
Enabled
Defunct schema objects

For more information, see Deactivating a class or attribute.
Disabled
Enabled
Forest trusts
For more information, see Forest trusts.
Disabled
Enabled
Linked value replication

For more information, see How replication works.
Disabled
Enabled
Domain rename
For more information, see Renaming domains.
Disabled
Enabled
Improved Active Directory replication algorithms

For more information, see Replication overview.
Disabled
Enabled
Dynamic auxiliary classes.

For more information, see New features for Active Directory.
Disabled
Enabled
InetOrgPerson objectClass change

For more information about InetOrgPerson objects, see User and computer
accounts.
Disabled
Enabled


When Active Directory is installed on a server running Windows Server 2003, a set of basic Active Directory features is enabled by default. For more information about the
new default features, see New features for Active Directory.
In addition to the basic Active Directory features on individual domain controllers, there are new domain- and forest-wide Active Directory features available when all
domain controllers in a domain or forest are running Windows Server 2003.
To enable the new domain-wide features, all domain controllers in the domain must be running Windows Server 2003, and the domain functional level must be raised to
Windows Server 2003 . For information about raising the domain functional level, see Raise the domain functional level.
To enable new forest-wide features, all domain controllers in the forest must be running Windows Server 2003, and the forest functional level must be raised to Windows
Server 2003 . Before raising the forest functional level to Windows Server 2003 , verify that all domains in the forest are set to the domain functional level of Windows 2000
native or Windows Server 2003 . Note that domains that are set to the domain functional level of Windows 2000 native will automatically be raised to Windows Server 2003
at the same time the forest functional level is raised to Windows Server 2003 . For information about raising the forest functional level, see Raise the forest functional level.


An application directory partition is a directory partition that is replicated only to specific domain controllers. A domain controller that participates in the replication of a
particular application directory partition hosts a replica of that partition. Only domain controllers running Windows Server 2003 can host a replica of an application
directory partition.
Applications and services can use application directory partitions to store application-specific data. Application directory partitions can contain any type of object, except
security principals. TAPI is an example of a service that stores its application-specific data in an application directory partition.
Application directory partitions are usually created by the applications that will use them to store and replicate data. For testing and troubleshooting purposes, members
of the Enterprise Admins group can manually create or manage application directory partitions using the Ntdsutil command-line tool.
One of the benefits of an application directory partition is that, for redundancy, availability, or fault tolerance, the data in it can be replicated to different domain controllers
in a forest. The data can be replicated to a specific domain controller or any set of domain controllers anywhere in the forest. This differs from a domain directory partition
in which data is replicated to all domain controllers in that domain. Storing application data in an application directory partition instead of in a domain directory partition
may reduce replication traffic because the application data is only replicated to specific domain controllers. Some applications may use application directory partitions to
replicate data only to servers where the data will be locally useful.
Another benefit of application directory partitions is that applications or services that use Lightweight Directory Access Protocol (LDAP) can continue using it to access and
store their application data in Active Directory. For more information, see Managing application directory partitions.
Application directory partition naming

An application directory partition is part of the overall forest namespace just like a domain directory partition. It follows the same Domain Name System (DNS) and
distinguished names naming conventions as a domain directory partition. An application directory partition can appear anywhere in the forest namespace that a domain
directory partition can appear.
There are three possible application directory partition placements within your forest namespace:
A child of a domain directory partition.

A child of an application directory partition.
A new tree in the forest.
If you created an application directory partition called example1 as a child of the microsoft.com domain, the DNS name of the application directory partition would be
example1.microsoft.com. The distinguished name of the application directory partition would be dc=example1, dc=microsoft, dc=com.
If you then created an application directory partition called example2 as a child of example1.microsoft.com, the DNS name of the application directory partition would be
example2.example1.microsoft.com and the distinguished name would be dc=example2, dc=example1, dc=microsoft, dc=com.
If the domain microsoft.com was the root of the only domain tree in your forest, and you created an application directory partition with the DNS name of example1 and the
distinguished name of dc=example1, this application directory partition is not in the same tree as the microsoft.com domain. This application directory partition would be
the root of a new tree in the forest.
Domain directory partitions cannot be children of an application directory partition. For example, if you created an application directory partition with the DNS name of
example1.microsoft.com, you could not create a domain with the DNS name of domain.example1.microsoft.com.
Application directory partition replication

The Knowledge Consistency Checker (KCC) automatically generates and maintains the replication topology for all application directory partitions in the enterprise. When an
application directory partition has replicas in more than one site, those replicas follow the same intersite replication schedule as the domain directory partition.
Notes
Objects stored in an application directory partition are never replicated to the global catalog as read-only replicas. Any domain controller running Windows
Server 2003 can hold a replica, including global catalogs.
Additionally, if an application requests data through the global catalog port, that query will not return any objects from an application directory partition, even if the
computer hosting the application directory partition is also hosting the global catalog. This is done so that LDAP queries to different global catalogs will not return
inconsistent results because the application directory partition is replicated to only one of the global catalogs.
Security descriptor reference domain

Every container and object on the network has a set of access control information attached to it. Known as a security descriptor, this information controls the type of
access allowed by users, groups, and computers. If the object or container is not assigned a security descriptor by the application or service that created it, then it is
assigned the default security descriptor for that object class as defined in the schema. This default security descriptor is ambiguous in that it may assign members of the
Domain Admins group read permissions to the object, but it does not specify to what domain the domain administrators belong. When this object is created in a domain
naming partition, that domain naming partition is used to specify which Domain Admins group actually is assigned read permission. For example, if the object is created in
mydomain.microsoft.com then members of the mydomain Domain Admins group would be assigned read permission.
When an object is created in an application directory partition, the definition of the default security descriptor is difficult because an application directory partition can have
replicas on different domain controllers belonging to different domains. Because of this potential ambiguity, a default security descriptor reference domain is assigned
when the application directory partition is created.
The default security descriptor reference domain defines what domain name to use when an object in the application directory partition needs to define a domain value for
the default security descriptor. The default security descriptor reference domain is assigned at the time of creation.
If the application directory partition is a child of a domain directory partition, by default, the parent domain directory partition becomes the security descriptor reference
domain. If the application directory partition is a child object of another application directory partition, the security descriptor reference domain of the parent application
directory partition becomes the reference domain of the new, child, application directory partition. If the new application directory partition is created as the root of a new
tree, then the forest root domain is used as the default security descriptor reference domain.
You can manually specify a security reference domain using Ntdsutil. However, if you plan to change the default security descriptor reference domain of a particular
application directory partition, you should do so before creating the first instance of that partition. To do this, you must prepare the cross-reference object and change the
default security reference domain before completing the application directory partition creation process. For information about precreating the cross-reference object, see
Prepare a cross-reference object. For information about changing the default security reference domain, see Set an application directory partition reference domain.
Application directory partitions and domain controller

demotion

If a domain controller holds a replica of an application directory partition, then you must remove the domain controller from the replica set of the application directory
partition or delete the application directory partition before you can demote the domain controller.
If a domain controller holds the last replica of a particular application directory partition, then you must delete the application directory partition before you can demote
the domain controller.
The Active Directory Installation Wizard will not remove a replica or delete an application directory partition programmatically. You must decide when it is safe to delete the
last replica of a particular partition.
Before deleting the last replica of an application directory partition, identify the applications that use the application directory partition, determine if it is safe to delete the
last replica, identify the partition deletion tool provided by the application, and then remove the application directory partition by using the tool provided or by using the
Ntdsutil command-line tool.
Identify the applications that use the application directory partition

To determine what application directory partitions are hosted on a computer, refer to the list on the first page of the Active Directory Installation Wizard. If the list does not
provide enough information to identify the programs using a particular application directory partition, you may be able to identify them in one of the following ways:
Speak to a member of the Enterprise Admins group.

Consult the network change control records for your organization.
Use LDP or ADSI Edit to view the data contained in the partition. For more information about these tools, see the Active Directory Programmer's Guide at the
Microsoft Web site.
Determine if it is safe to delete the last replica

Removing the last replica of an application directory partition will result in the permanent loss of any data contained in the partition. If you have identified the applications
using the application directory partition, consult the documentation provided with those applications to determine if there is any reason to keep the data. If the applications
that use the application directory partition are out of service, it is probably safe to remove the partition.
If it is not safe to delete the last replica, or if you cannot determine whether or not it is safe, and you must demote the domain controller holding the last replica of a
particular application directory partition, follow these steps: Add a replica of the partition on another domain controller, force the replication of the contents of the
application directory partition to the domain controller holding the new replica, and then remove the replica of the partition on the domain controller to be demoted. For
more information, see Add or remove an application directory partition replica.
Identify the partition deletion tool provided by the application

Most applications that create application directory partitions provide a utility to remove the partitions. When possible, always delete an application directory partition using
the utility provided. For example, to delete a TAPI partition, use the Tapicfg.exe command-line tool. For more information about TAPI and removing TAPI application
directory partitions, see Telephony.
Remove the application directory partition using the tool provided or use Ntdsutil
Refer to the application's documentation for information about removing application directory partitions that were created and used by that application.
Caution
If possible, use the application's tool for managing its application directory partitions. The application may keep other data in addition to Active Directory managed
data for the application directory partitions. By using Ntdsutil, the two sets of data could cause a conflict.
If you cannot identify the application that created the application directory partition, or if your application does not provide a means to delete application directory
partitions that it created, you can use the Ntdsutil command-line tool. To do this, see Create or delete an application directory partition.
For information about demoting a domain controller, see Demote a domain controller. For general information about application directory partitions, see Application
directory partitions.


You can use the following tools to create, delete, or manage application directory partitions.
application-specific tools from the application vendor

Ntdsutil command-line tool
LDP
For information about creating and managing application directory partitions with ADSI, see Active Directory Service Interfaces (ADSI) at the Microsoft Web site. For
information about LDP, see Administration tools for the Active Directory schema.
For information about the Ntdsutil command-line tool, see Ntdsutil.
The following provides information about using Ntdsutil to create and manage application directory partitions.
Creating an application directory partition

When you create an application directory partition, you are creating the first instance of this partition. You can create an application directory partition by using the create
nc option in the domain management menu of Ntdsutil. When creating an application directory partition using LDP or ADSI, provide a description in the description
attribute of the domain DNS object that indicates the specific application that will use the partition. For example, if the application directory partition will be used to store
data for a Microsoft accounting program, the description could be Microsoft accounting application. Ntdsutil does not facilitate the creation of a description. For more
information, see Create or delete an application directory partition.
Deleting an application directory partition

When you delete an application directory partition, you are removing all replicas of that partition from your forest. You can delete an application directory partition by
using the delete nc command in the domain management menu of Ntdsutil. The deletion process will need to replicate to all domain controllers that contain a replica of
the application directory partition before the deletion process is complete. Any data that is contained in the application directory partition will be lost.
The Active Directory Promotion Wizard (Dcpromo) cannot demote a domain controller if that domain controller holds a copy of an application directory partition. For more
Adding and removing a replica of an application directory partition

An application directory partition replica is an instance of an partition on another domain controller. The information in the application directory partition is replicated
between the domain controllers. Application directory partition replicas are created for either redundancy or data access purposes. You can add a replica of an application
directory partition by using the add nc replica command in the domain management menu of Ntdsutil. You can remove an application directory partition replica by using
the delete nc replica command in the domain management menu of Ntdsutil. For more information, see Add or remove an application directory partition replica.
Setting application directory partition reference domain

The security descriptor reference domain defines a domain name for the default security descriptor for objects in the application directory partition. By default, the security
descriptor reference domain is the parent domain of the application directory partition. If the application directory partition is a child of another application directory
partition, the default security descriptor reference domain is the security descriptor reference domain of the parent application directory partition. If the application
directory partition has no parent, the forest root domain becomes the default security descriptor reference domain. You can use Ntdsutil to change the default security
descriptor reference domain. For more information, see Set an application directory partition reference domain.
Setting replication notification delays

Changes made to a particular directory partition on a particular domain controller are replicated to the other domain controllers that contain that directory partition. The
domain controller on which the change was made notifies its replication partners that it has a change. You can configure how long the domain controller will wait to send
the change notification to its first replication partner. You can also configure how long it waits to send the subsequent change notification to its remaining replication
partners. These delays can be set for any directory partition (including domain directory partitions) on a particular domain controller. For more information, see Set a
notification delay.
Displaying application directory partition information

Any domain controller that holds a replica of a particular directory partition (including application directory partitions) is said to be a member of the replica set for that
directory partition. You can use Ntdsutil to list the domain controllers that are members of a particular replica set for an application directory partition. An addition of a
domain controller to the replica set attribute on the cross-reference object does not create the replica, but it will display when the list nc replica command is used in
Ntdsutil. The creation of the instance must replicate before the creation of the replica is complete. For more information, see Display application directory partition
information.
Delegating the creation of application directory partitions

There are two things that happen when creating an application directory partition:
Creation of the cross-reference object.

Creation of the application directory partition root node.
Normally only members of the Enterprise Admins group can create an application directory partition. However, it is possible for a member of the Enterprise Admins group
to prepare a cross-reference object for the application directory partition and to delegate the rest of the process to someone with more limited permissions.
The cross-reference object for an application directory partition holds several valuable pieces of information, including the domain controllers that are to have a replica of
this partition and the security descriptor reference domain. The partition root node is the Active Directory object at the root of the partition
The Enterprise Admin can create the cross-reference object then delegate to a person or group with less permissions the right to create the application directory partition
root node. Both creation of the cross-reference object and the application directory partition root node can be accomplished using Ntdsutil.
After using Ntdsutil to create the cross-reference object, the enterprise administrator must modify the cross-reference object's access control list to allow the delegated
administrator to modify this cross-reference. This will allow the delegated administrator to create the application directory partition and modify the list of domain
controllers that holds replicas of this application directory partition. The delegated administrator must use the names of the application directory partition and the domain
controller name that were specified during the precreation process. For more information, see Prepare a cross-reference object.
For more information about application directory partitions, see Application directory partitions.

Updated: October 24, 2011
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008
R2

Active Directory supports multimaster replication of the directory data store between all domain controllers (DC) in the domain, so all domain controllers in a domain are
essentially peers. However, some changes are impractical to perform in using multimaster replication, so, for each of these types of changes, one domain controller, called
the operations master, accepts requests for such changes.
In every forest, there are at least five operations master roles that are assigned to one or more domain controllers. Forest-wide operations master roles must appear only
once in every forest. Domain-wide operations master roles must appear once in every domain in the forest.
Note
The operations master roles are sometimes called flexible single master operations (FSMO) roles.
Forest-wide operations master roles

Every 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. There can be only one schema master in the entire forest.

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.
Note
Any domain controller running Windows Server 2003 can hold the role of the domain naming master. A domain controller running Windows 2000 Server that holds
the role of domain naming master must also be enabled as a global catalog server.
Domain-wide operations master roles

Every domain in the forest must have the following roles:
Relative ID (RID) master

Primary domain controller (PDC) emulator master
Infrastructure master
These roles must be unique in each domain. This means that each domain in the forest can have only one RID master, PDC emulator master, and infrastructure master.
RID master
The RID master allocates sequences of relative IDs (RIDs) to each of the various domain controllers in its domain. At any time, there can be only one domain controller
acting as the RID 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 (SID). The SID consists of a domain SID, which is the
same for all SIDs created in the domain, and a RID, which is unique for each SID 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 RID master of the domain that currently
contains the object.
PDC emulator master

The PDC emulator master processes password changes from client computers and replicates these updates to all domain controllers throughout the domain. At any time,
there can be only one domain controller acting as the PDC emulator master in each domain in the forest.
The PDC emulator role is used in the following ways:
To provide consistent password experience for users across sites (can be turned off with AvoidPdcOnWan registry parameter) - The PDC emulator is used as a
reference DC to double-check incorrect passwords and it also receives new password changes. When the PDC is reachable, users can use a new password
immediately and consistently across the environment. For more information about AvoidPdcOnWan see, New Password Change and Conflict Resolution Functionality
in Windows (http://go.microsoft.com/fwlink/?LinkId=202451)
As a preferred point of administration for services (examples are Group Policy and Distributed File System, DFS) - For more information about DFS see, DFS
Management (http://go.microsoft.com/fwlink/?LinkId=202456). For more information about DCs and Group Policy see, Specifying a Domain Controller for Editing
Group Policy (http://go.microsoft.com/fwlink/?LinkId=202457).
As a point of contact for applications hard-coded to the PDC (often written for Windows NT 4.0 and older domains) - The legacy API often used for this is
NetGetDcName. It is strongly suggested to change applications to use the new API to locate DCs. DsGetDcName by default does not target the PDC, and has more
options that allows you to pick the type of DC needed to perform the operation. For more information about locating DCs from applications see, DSGetDcName
Function (http://go.microsoft.com/fwlink/?LinkId=202455).
As a default time server for all other DCs in the domain - The time server configuration of a PDC requires manual consideration and should be reviewed when you
change the owner of the PDC role.
The domain controller configured with the PDC emulator role supports two authentication protocols:
The Kerberos V5 protocol

The NTLM protocol
Note
For instructions on how to configure the PDC emulator to synchronize with an external time source, see Synchronize the Time Server for the Domain Controller with an
External Source (http://go.microsoft.com/fwlink/?LinkId=122513).
At any time, there can be only one domain controller acting as the infrastructure master in each domain. 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 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 it will never replicate any changes to the other domain controllers in the domain.
In the case where 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.
The infrastructure master is also responsible for updating the group-to-user references whenever the members of groups are renamed or changed. 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. This prevents the loss of group
memberships associated with a user account when the user account is renamed or moved. 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 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.


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 consoles in Microsoft Management Console (MMC).
Role
Console in MMC
Schema master
RID master
PDC emulator master
For general information about operations master roles, see Operations master roles.
Note
For procedures describing the transfer of operations master roles, see:
Transfer the schema master role

Transfer the domain naming master role
Transfer the RID master role
Transfer the PDC emulator role
Transfer the infrastructure master role

R2

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. Do not seize the operations master role if you can transfer it instead. For more information, see Transferring operations master
roles.
Note
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 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.
RID master failure

Temporary loss of the RID 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 IDs (RIDs).
If the RID 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 RID master is permanent.
Important
A domain controller whose RID master role has been seized must never be brought back online.
For procedures on how to seize the RID master role, see Seize the RID master role.
PDC emulator master failure

The severity of a PDC outage depends on your Service Level Agreement (SLA) and the actual behavior and configuration of the environment. For example, inconsistent
password change behavior may affect users beyond what your SLAs allow, or the lack of time synchronization may cause resource access failures.
Also, in smaller environments, it may happen that the PDC as the first server in the domain is the only DNS or Global Catalog Server, or is the only domain controller (DC)
with a valid SYSVOL in case other DCs did not successfully initiate or maintain SYSVOL replication. The PDC role holder may also be the target for regular file server access.
When this is done for folder redirection or logon script activities, it may also affect users when logging on and while they work.
Other than the conditions described above, there is no direct dependency of the domain members on the PDC role holder. However, you might be using applications that
are coded to contact the PDC only. You should try to avoid having this single point of failure.
Often, these applications were written for Windows NT 3.x and 4.0 deployments where the PDC was the only writable DC. However, since Active Directory, all DCs except
Read-Only DCs are writable. The DsGetDcName API allows you to pick the right type; similar options are available in AD API interfaces like ADSI (ADS_READONLY_SERVER)
or the .NET runtime.
The loss of the primary domain controller (PDC) emulator master may affect network users. Therefore, when the PDC emulator master is not available, you may need to
immediately seize the role.
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 Operations master roles.
Understanding groups
Groups
Group scope
Group types
Default groups
Nesting groups
Special identities
Where groups can be created
Groups
Groups
A group is a collection of user and computer accounts, contacts and other groups that can be managed as a single unit. Users and computers that belong to a particular
group are referred to as group members.
Using groups can simplify administration by assigning a common set of permissions and rights to many accounts at once, rather than assigning permissions and rights to
each account individually. For an overview of permissions and rights, see Access control overview.
Groups can be either directory-based or local to a particular computer. Groups in Active Directory are directory objects that reside within a domain and organizational unit
container objects. Active Directory provides a set of default groups upon installation, and also allows the option to create groups. For more information, see Default
groups.
Local groups, which exist on local computers and not in Active Directory, are discussed in Default local groups.
Groups in Active Directory allow you to:
Simplify administration by assigning permissions on a shared resource to a group, rather than to individual users. This assigns the same access on the resource to
all members of that group.
Delegate administration by assigning user rights once to a group through Group Policy, and then adding necessary members to the group that you want to have
the same rights as the group.
Create e-mail distribution lists. For more information, see Group types.
Groups are characterized by their scope and their type. The scope of a group determines the extent to which the group is applied within a domain or forest. For
information about group scope, see Group scope. The group type determines whether a group can be used to assign permissions from a shared resource (for security
groups) or if a group can be used for e-mail distribution lists only (for distribution groups). For information about security groups and distribution groups, see Group
types.
There are also groups for which you cannot modify or view the memberships. These groups are referred to as special identities and are used to represent different users
at different times, depending on the circumstances. For example, the Everyone group represents all current network users, including guests and users from other domains.
For more information, see Special identities.
Group scope
Updated: March 16, 2007
Group scope
Any group, whether it is a security group or a distribution group, is characterized by a scope that identifies the extent to which the group is applied in the domain tree or
forest. The boundary, or reach, of a group scope is also determined by the domain functional level setting of the domain in which it resides. There are three group scopes:
universal, global, and domain local.
The following table describes the differences between the scopes of each group.
Group
scope
Universal
Group can include as members
Accounts from any domain within the forest in

which this Universal Group resides
Group can be assigned permissions in
Any domain or forest
Group scope can be converted to
Domain local
Global (as long as no other
universal groups exist as
members)
Global groups from any domain within the

forest in which this Universal Group resides
Universal groups from any domain within the
Global
Accounts from the same domain as the parent

global group
Member permissions can be assigned in any domain
Universal (as long as it is not a

member of any other global groups)
Member permissions can be assigned only within the

same domain as the parent domain local group
Universal (as long as no other domain

local groups exist as members)
Global groups from the same domain as the

parent global group
Domain
local
Accounts from any domain

Global groups from any domain
Universal groups from any domain
Domain local groups but only from the same
domain as the parent domain local group
Note
The information in this table implies that the domain functional level is set to either Windows 2000 native or Windows Server 2003. When the domain functional level is
set to Windows 2000 mixed or Windows Server 2003 interim, security groups with universal scope cannot be created, although distribution groups with universal scope
are still permitted.
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. For example, to give five users access to a particular printer, you
can 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 must again 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 then 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 their own domain, you can change accounts in a group having global scope frequently without generating replication traffic to the global catalog. For
more information about groups and replication, see How replication works.
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 simplifies and rationalizes group management across domains. For example,
in a network with two domains, Europe and UnitedStates, if you have a group with global scope called GLAccounting in the UnitedStates domain, create a group called
GLAccounting in the Europe domain (unless the accounting function does not exist in the Europe domain).
It is strongly recommended that you use global groups or universal groups instead of domain local groups when you specify permissions on domain directory objects that
are replicated to the global catalog. For more information, see Global catalog replication.
Note
When the domain functional level is set to Windows 2000 mixed, members of global groups can include only accounts from the same domain.
When to use groups with universal scope

Use groups with universal scope to consolidate groups that span domains. To do this, add the accounts to groups with global scope, and then nest these groups within
groups that have universal scope. When you use this strategy, any membership changes in the groups that have global scope do not affect the groups with universal
scope.
For example, in a network with two domains, Europe and UnitedStates, and a group that has global scope called GLAccounting in each domain, create a group with
universal scope called UAccounting that has as its members the two GLAccounting groups, UnitedStates\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.
Do not change the membership of a group with universal scope frequently, because 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 universal groups and replication, see Global catalogs and sites.
Note
When the domain functional level is set to Windows 2000 mixed, you cannot create security groups with universal scope.
Changing group scope

When you create a new group, by default the new group is configured as a security group with global scope, regardless of the current domain functional level. Although
changing a group scope is not allowed in domains with a domain functional level of Windows 2000 mixed, the following conversions are allowed in domains with the
domain functional level of Windows 2000 native or Windows Server 2003:
Global to universal. This conversion is allowed only if the group that you want to change is not a member of another global scope group.
Domain local to universal. This conversion is allowed only if the group that you want to change does not have another domain local group as a member.
Universal to global. This conversion is allowed only if the group that you want to change does not have another universal group as a member.
Universal to domain local. There are no restrictions for this operation.
For more information, see Change group scope.
Groups on client computers 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, Windows XP Professional, Windows 2000 Server, and stand-alone servers running
Windows Server 2003 work the same way as in Windows NT 4.0:
Only local groups can be created locally on the computer.

A local group that is created on one of these computers can be assigned permissions only on that one computer.
For more information, see Default local groups.

Group types
Group types
Groups are used to collect user accounts, computer accounts, and other group accounts into manageable units. Working with groups instead of with individual users helps
simplify network maintenance and administration.
There are two types of groups in Active Directory: distribution groups and security groups. You can use distribution groups to create e-mail distribution lists and security
groups to assign permissions to shared resources.
Distributions groups
Distribution groups can be used only with e-mail applications (such as Exchange) to send e-mail to collections of users. Distribution groups are not security-enabled, which
means that they cannot be listed in discretionary access control lists (DACLs). If you need a group for controlling access to shared resources, create a security group.
Security groups
Used with care, security groups provide an efficient way to assign access to resources on your network. Using security groups, you can:
Assign user rights to security groups in Active Directory

User rights are assigned to security groups to determine what members of that group can do within the scope of a domain (or forest). User rights are automatically
assigned to some security groups at the time Active Directory is installed to help administrators define a person's administrative role in the domain. For example, a
user who is added to the Backup Operators group in Active Directory has the ability to backup and restore files and directories located on each domain controller in
the domain.
This is possible because by default, the user rights Back up files and directories and Restore files and directories are automatically assigned to the Backup
Operators group. Therefore, members of this group inherit the user rights assigned to that group. For more information about user rights, see User rights. For
more information about the user rights assigned to security groups, see Default groups.
You can assign user rights to security groups, using Group Policy, to help delegate specific tasks. You should always use discretion when assigning delegated tasks
because an untrained user assigned too many rights on a security group can potentially cause significant harm to your network. For more information, see
Delegating administration. For more information about assigning user rights to groups, see Assign user rights to a group in Active Directory.
Assign permissions to security groups on resources
Permissions should not be confused with user rights. Permissions are assigned to the security group on the shared resource. Permissions determine who can access
the resource and the level of access, such as Full Control. Some permissions set on domain objects are automatically assigned to allow various levels of access to
default security groups such as the Account Operators group or the Domain Admins group. For more information about permissions, see Access control in Active
Directory.
Security groups are listed in DACLs that define permissions on resources and objects. 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 assigned to that group in Active Directory and the permissions defined for
that group at the resource.
Like distribution groups, 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.
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 functional level is set to Windows 2000 native
or higher. No groups can be converted while the domain functional level is set to Windows 2000 mixed.
For specific procedural information, see Convert a group to another group type. For information about domain functionality, see Domain and forest functionality.
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.
Default groups
Default groups
Default groups, such as the Domain Admins group, are security groups that are created automatically when you create an Active Directory domain. You can use these
predefined groups to help control access to shared resources and delegate specific domain-wide administrative roles. For information about default groups stored on
local computers, see Default local groups.
Many default groups are automatically assigned a set of user rights that authorize members of the group to perform specific actions in a domain, such as logging on to a
local system or backing up files and folders. For example, a member of the Backup Operators group has the right to perform backup operations for all domain controllers
in the domain.
When you add a user to a group, the user receives all the user rights assigned to the group and all the permissions assigned to the group on any shared resources. For
more information about user rights and permissions, see Group types.
You can manage groups by using the Active Directory Users and Computers snap-in in Microsoft Management Console (MMC). Default groups are located in the Builtin
container and the Users container.
The Builtin container default groups contain groups that are defined with domain local scope. You can move groups in and out of this container, but you cannot move the
default groups in this container to another location or to another domain.
The Users container default groups contain groups that are defined with global scope and groups that are defined with domain local scope. You can add the groups in
this container to other groups and you can move the default groups in this container to other organizational units (OUs) or containers, but you cannot move the group to
another domain.
As a security best practice, it is recommended that members of default groups with broad administrative access use the Run as command to perform administrative tasks.
For more information, see Using Run as. For information about security best practices, see Active Directory Best practices. For information about additional security
measures that can be used to protect Active Directory, see Securing Active Directory.
Note
To learn what group you need to be a member of to perform a particular procedure, many procedural topics under How To in Help and Support Center provide a
note that identifies this information.
Groups in the Builtin container

The following table provides descriptions of the default groups located in the Builtin container and lists the assigned user rights for each group. For complete descriptions
of the user rights listed in the table, see User Rights Assignment. For information about editing these rights, see Edit security settings on a Group Policy object.
Group
Description
Default user rights
Account
Operators
Members of this group can create, modify, and delete accounts for
users, groups, and computers located in the Users or Computers
containers and organizational units in the domain, except the Domain
Controllers organizational unit. Members of this group do not have
permission to modify the Administrators or the Domain Admins groups,
nor do they have permission to modify the accounts for members of
those groups. Members of this group can log on locally to domain
controllers in the domain and shut them down. Because this group has
significant power in the domain, add users with caution.
Allow log on locally; Shut down the system.
Administrators
Members of this group have full control of all domain controllers in the
domain. By default, the Domain Admins and Enterprise Admins groups
are members of the Administrators group. The Administrator account is
also a default member. Because this group has full control in the
domain, add users with caution.
Access this computer from the network; Adjust memory quotas for a
process; Back up files and directories; Bypass traverse checking; Change the
system time; Create a pagefile; Debug programs; Enable computer and
user accounts to be trusted for delegation; Force a shutdown from a
remote system; Increase scheduling priority; Load and unload device
drivers; Allow log on locally; Manage auditing and security log; Modify
firmware environment values; Profile single process; Profile system
performance; Remove computer from docking station; Restore files and
directories; Shut down the system; Take ownership of files or other objects.
Backup
Operators
Members of this group can back up and restore all files on domain
controllers in the domain, regardless of their own individual
permissions on those files. Backup Operators can also log on to
domain controllers and shut them down. This group has no default
members. Because this group has significant power on domain
controllers, add users with caution.
Back up files and directories; Allow log on locally; Restore files and
directories; Shut down the system.
Guests
By default, the Domain Guests group is a member of this group. The

Guest account (which is disabled by default) is also a default member
of this group.
No default user rights.
Incoming
Members of this group can create one-way, incoming forest trusts to
Forest Trust
Builders (only
appears in the
forest root
domain)
the forest root domain. For example, members of this group residing in
Forest A can create a one-way, incoming forest trust from Forest B. This
one-way, incoming forest trust allows users in Forest A to access
resources located in Forest B. Members of this group are granted the
permission Create Inbound Forest Trust on the forest root domain. This
group has no default members. For more information about creating
forest trusts, see Create a forest trust.
Network
Configuration
Operators
Members of this group can make changes to TCP/IP settings and renew
and release TCP/IP addresses on domain controllers in the domain.
This group has no default members.
Performance
Monitor Users
Members of this group can monitor performance counters on domain

controllers in the domain, locally and from remote clients without being
a member of the Administrators or Performance Log Users groups.
Performance
Log Users
Members of this group can manage performance counters, logs and

alerts on domain controllers in the domain, locally and from remote
clients without being a member of the Administrators group.
PreWindows 2000
Compatible
Access
Members of this group have read access on all users and groups in the
domain. This group is provided for backward compatibility for
computers running Windows NT 4.0 and earlier. By default, the special
identity Everyone is a member of this group. For more information
about special identities, see Special identities. Add users to this group
only if they are running Windows NT 4.0 or earlier.
Access this computer from the network; Bypass traverse checking.
Print
Operators
Members of this group can manage, create, share, and delete printers
connected to domain controllers in the domain. They can also manage
Active Directory printer objects in the domain. Members of this group
can log on locally to domain controllers in the domain and shut them
down. This group has no default members. Because members of this
group can load and unload device drivers on all domain controllers in
the domain, add users with caution.
Remote
Desktop Users
Members of this group can remotely log on to domain controllers in

the domain. This group has no default members.
Replicator
This group supports directory replication functions and is used by the

File Replication service on domain controllers in the domain. This group
has no default members. Do not add users to this group.
Server
Operators
On domain controllers, members of this group can log on interactively,

create and delete shared resources, start and stop some services, back
up and restore files, format the hard disk, and shut down the computer.
This group has no default members. Because this group has significant
power on domain controllers, add users with caution.
Back up files and directories; Change the system time; Force shutdown from
a remote system; Allow log on locally; Restore files and directories; Shut
down the system.
Users
Members of this group can perform most common tasks, such as

running applications, using local and network printers, and locking the
server. By default, the Domain Users group, Authenticated Users, and
Interactive are members of this group. Therefore, any user account
created in the domain becomes a member of this group.
Groups in the Users container

The following table provides a description of the default groups located in the Users container and lists the assigned user rights for each group. For complete descriptions
Group
Description
Default user rights
Cert Publishers
Members of this group are permitted to publish

certificates for users and computers. This group has no
default members.
DnsAdmins
(installed with
DNS)
Members of this group have administrative access to the

DNS Server service. This group has no default members.
DnsUpdateProxy
(installed with
DNS)
Members of this group are DNS clients that can perform

dynamic updates on behalf of other clients, such as DHCP
servers. This group has no default members.
Domain Admins
Members of this group have full control of the domain. By

default, this group is a member of the Administrators
group on all domain controllers, all domain workstations,
and all domain member servers at the time they are
joined to the domain. By default, the Administrator
account is a member of this group. Because the group
Access this computer from the network; Adjust memory quotas for a process; Back up
files and directories; Bypass traverse checking; Change the system time; Create a
pagefile; Debug programs; Enable computer and user accounts to be trusted for
delegation; Force a shutdown from a remote system; Increase scheduling priority; Load
and unload device drivers; Allow log on locally; Manage auditing and security log;
Modify firmware environment values; Profile single process; Profile system
has full control in the domain, add users with caution.
performance; Remove computer from docking station; Restore files and directories;
Shut down the system; Take ownership of files or other objects.
Domain
Computers
This group contains all workstations and servers joined to

the domain. By default, any computer account created
becomes a member of this group automatically.
Domain
Controllers
This group contains all domain controllers in the domain.
Domain Guests
This group contains all domain guests.
Domain Users
This group contains all domain users. By default, any user

account created in the domain becomes a member of this
group automatically. This group can be used to represent
all users in the domain. For example, if you want all
domain users to have access to a printer, you can assign
permissions for the printer to this group (or add the
Domain Users group to a local group, on the print server,
that has permissions for the printer).
Enterprise
Admins (only
appears in the
forest root
domain)
Members of this group have full control of all domains in

the forest. By default, this group is a member of the
Administrators group on all domain controllers in the
forest. By default, the Administrator account is a member
of this group. Because this group has full control of the
forest, add users with caution.
delegation; Force shutdown from a remote system; Increase scheduling priority; Load
Group Policy
Creator Owners
Members of this group can modify Group Policy in the

domain. By default, the Administrator account is a
member of this group. Because this group has significant
power in the domain, add users with caution.
IIS_WPG
(installed with
IIS)
The IIS_WPG group is the Internet Information Services

(IIS) 6.0 worker process group. Within the functioning of
IIS 6.0 are worker processes that serve specific
namespaces. For example, www.microsoft.com is a
namespace served by one worker process, which can run
under an identity added to the IIS_WPG group, such as
MicrosoftAccount. This group has no default members.
RAS and IAS

Servers
Servers in this group are permitted access to the remote

access properties of users.
Schema Admins
(only appears in
the forest root
domain)
Members of this group can modify the Active Directory

schema. By default, the Administrator account is a
power in the forest, add users with caution.
See Also
Concepts
Using Run as
Create a shortcut using the runas command
Why you should not run your computer as an administrator
Other Resources
Run a program with administrative credentials
Nesting groups
Nesting groups
Using nesting, you can add a group as a member of another group. You nest groups to consolidate member accounts and reduce replication traffic.
Nesting options depend on whether the domain functionality of your Windows Server 2003 domain is set to Windows 2000 native or Windows 2000 mixed.
By default, when you nest a group within another group, user rights are inherited. For example, if you make Group_1 a member of Group_2, users in Group_1 have the
same permissions as the users in Group_2.
Groups in domains set to the Windows 2000 native functional level or distribution groups in domains set to the Windows 2000 mixed functional level can have the following
members:
Groups with universal scope can have the following members: accounts, computer accounts, other groups with universal scope, and groups with global scope from
any domain.
Groups with global scope can have the following members: accounts from the same domain and other groups with global scope from the same domain.
Groups with domain local scope can have the following members: accounts, groups with universal scope, and groups with global scope, all from any domain. This
group can also have as members other groups with domain local scope from within the same domain.
Security groups in domains set to the Windows 2000 mixed functional level 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 domains with the domain functional level set to Windows 2000 mixed because universal scope is supported only
in domains where the domain functional level is set to Windows 2000 native or Windows Server 2003.
Note
You cannot add the default groups that are located in the Builtin container as members to other groups. However, you can add other groups as members to the default
groups that are located in the Builtin container.
For more information about domain functionality, see Domain and forest functionality.
Special identities
Special identities
In addition to the groups in the Users and Builtin containers, servers running Windows Server 2003 include several special identities. For convenience, these identities are
generally referred to as groups. These special groups do not have specific memberships that can be modified, but they can represent different users at different times,
depending on the circumstances. The special groups are:
Anonymous Logon
Represents users and services that access a computer and its resources through the network without using an account name, password, or domain name. On
computers running Windows NT and earlier, the Anonymous Logon group is a default member of the Everyone group. On computers running a member of the
Windows Server 2003 family, the Anonymous Logon group is not a member of the Everyone group by default.
Everyone
Represents all current network users, including guests and users from other domains. Whenever a user logs on to the network, the user is 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, the user is 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, the user is automatically added to
the Interactive group.
Although the special identities can be assigned rights and permissions to resources, the memberships cannot be modified or viewed. 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.
For general information about groups, see Groups.


In Active Directory, groups are created in domains. You use Active Directory Users and Computers to create groups. With the necessary permissions, groups can be
created in the root domain of the forest, in 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 the domain functional level is set to Windows 2000 native or higher, the 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.
For information about the tools used to move groups between domains, see Using the Windows Deployment and Resource Kits.
Understanding trusts
Trusts
Trust types
Trust direction
Trust transitivity
When to create an external trust
When to create a shortcut trust
When to create a realm trust
When to create a forest trust
Forest trusts
Accessing resources across domains
Accessing resources across forests
Routing name suffixes across forests
Trusts
Trusts
A trust is a relationship established between domains that enables users in one domain to be authenticated by a domain controller in the other domain. Trust relationships
in Windows NT are different than in Windows 2000 and Windows Server 2003 operating systems.
Trusts in Windows NT
In Windows NT 4.0 and earlier, trusts are limited to two domains and the trust relationship is one-way and nontransitive. In the following figure, the nontransitive, one-way
trust is shown by the straight arrow pointing to the trusted domain.
Trusts in Windows Server 2003 and Windows 2000 Server operating systems
All trusts in a Windows 2000 and Windows Server 2003 forest are transitive, two-way trusts. Therefore, both domains in a trust relationship are trusted. As shown in the
following figure, this means that if Domain A trusts Domain B and Domain B trusts Domain C, then users from Domain C can access resources in Domain A (when assigned
the proper permissions). Only members of the Domain Admins group can manage trust relationships.
Trust protocols
A domain controller running Windows Server 2003 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, Windows XP Professional, or Windows Server 2003. 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 account domain to verify the account credentials.
Trusted domain objects

Trusted domain objects (TDOs) are objects that represent each trust relationship within a particular domain. Each time a trust is established a unique TDO is created and
stored (in the System container) in its domain. Attributes such as a trust transitivity, type, and the reciprocal domain names are represented in a TDO.
Forest trust TDOs store additional attributes to identify all of the trusted namespaces from its partner forest. These attributes include domain tree names, user principal
name (UPN) suffixes, service principal name (SPN) suffixes, and security ID (SID) namespaces.
For more information about domain trusts, see "Domain Trust" at the Microsoft Windows Resource Kits Web site. For more information about trust relationships, see
"Designing an Authorization Strategy" at the Microsoft Windows Resource Kits Web site.
Trust types
Trust types
Communication between domains occurs through trusts. Trusts are authentication pipelines that must be present in order for users in one domain to access resources in
another domain. Two default trusts are created when using the Active Directory Installation Wizard. There are four other types of trusts that can be created using the New
Trust Wizard or the Netdom command-line tool.
Default trusts
By default, two-way, transitive trusts are automatically created when a new domain is added to a domain tree or forest root domain using the Active Directory Installation
Wizard. The two default trust types are defined in the following table.
Trust
type
Transitivity
Direction
Description
Parent
and
child
Transitive
Two-way
By default, when a new child domain is added to an existing domain tree, a new parent and child trust is established. Authentication
requests made from subordinate domains flow upward through their parent to the trusting domain. For information about creating
a new child domain, see Create a new child domain.
Treeroot
Transitive
Two-way
By default, when a new domain tree is created in an existing forest, a new tree-root trust is established. For information about
creating a new domain tree, see Create a new domain tree.
Other trusts
Four other types of trusts can be created using the New Trust Wizard or the Netdom command-line tool: external, realm, forest, and shortcut trusts. These trusts are
defined in the following table.
Trust
type
Transitivity
Direction
Description
External
Nontransitive
One-way
or twoway
Use external trusts to provide access to resources located on a Windows NT 4.0 domain or a domain located in a separate
forest that is not joined by a forest trust. For more information, see When to create an external trust.
Realm
Transitive or
nontransitive
One-way
or twoway
Use realm trusts to form a trust relationship between a non-Windows Kerberos realm and a Windows Server 2003 domain. For
more information, see When to create a realm trust.
Forest
Transitive
One-way
or twoway
Use forest trusts to share resources between forests. If a forest trust is a two-way trust, authentication requests made in either
forest can reach the other forest. For more information, see When to create a forest trust.
Shortcut
Transitive
One-way
or twoway
Use shortcut trusts to improve user logon times between two domains within a Windows Server 2003 forest. This is useful when
two domains are separated by two domain trees. For more information, see When to create a shortcut trust.
When creating external, shortcut, realm, or forest trusts, you have the option to create each side of the trust separately or both sides of a trust simultaneously.
If you choose to create each side of the trust separately, then you will need to run the New Trust Wizard twice--once for each domain. When creating trusts using the
method, you will need to supply the same trust password for each domain. As a security best practice, all trust passwords should be strong passwords. For more
information, see Strong passwords.
If you choose to create both sides of the trust simultaneously, you will need to run the New Trust Wizard once. When you choose this option, a strong trust password is
automatically generated for you.
You will need the appropriate administrative credentials for each domain between which you will be creating a trust.
Netdom.exe can also be used to create trusts. For more information about Netdom, see Active Directory support tools.
For more information about trusts, see Trust transitivity and Trust direction.
Trust direction
Trust direction
The trust type and its assigned direction will impact the trust path used for authentication. A trust path is a series of trust relationships that authentication requests must
follow between domains. Before a user can access a resource in another domain, the security system on domain controllers running Windows Server 2003 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 security system computes the trust path between a domain controller in the trusting domain and a domain controller in the trusted domain. In the
following figure, trust paths are indicated by arrows showing the direction of the trust (this is a one-way trust):
All domain trust relationships have only two domains in the relationship: the trusting domain and the trusted domain.
One-way trust
A one-way trust is a unidirectional authentication path created between two domains. This means that in a one-way trust between Domain A and Domain B, users in
Domain A (trusted domain) can access resources in Domain B (trusting domain). However, users in Domain B cannot access resources in Domain A. Some one-way trusts
can be a nontransitive trust or a transitive trust depending on the type of trust being created. For more information about trust types, see Trust types.
Two-way trust
All domain trusts in a Windows Server 2003 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, both domains that are involved in a trust relationship trust each other. This means that
authentication requests can be passed between the two domains in both directions. Some two-way relationships can be nontransitive or transitive depending on the type
of trust being created. For more information, see Trust types.
A Windows Server 2003 domain can establish a one-way or two-way trust with:
Windows Server 2003 domains in the same forest

Windows Server 2003 domains in a different forest
Windows NT 4.0 domains
Kerberos V5 realms
For more information Kerberos V5, see Kerberos V5 authentication.

Trust transitivity
Trust transitivity
Transitivity determines whether a trust can be extended outside of the two domains with which it was formed. A transitive trust can be used to extend trust relationships
with other domains and a nontransitive trust can be used to deny trust relationships with other domains.
Transitive trusts
Each time you create a new domain in a forest, a two-way, transitive trust relationship is automatically created between the new domain and its parent domain. If child
domains are added to the new domain, the trust path flows upward through the domain hierarchy extending the initial trust path created between the new domain and its
parent domain.
Transitive trust relationships flow upward through a domain tree as it is formed, creating transitive trusts between all domains in the domain tree.
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, accounts with the proper permissions can access resources in any domain in the forest. For more information, see Authentication protocols overview.
The diagram displays that all domains in the Domain A tree and all domains in the Domain 1 tree have transitive trust relationships by default. As a result, users in the
Domain A tree can access resources in domains in the Domain 1 tree and users in the Domain 1 tree can access resources in the Domain A tree, when the proper
permissions are assigned at the resource.
In addition to the default transitive trusts established in a Windows Server 2003 forest, using the New Trust Wizard, you can manually create the following transitive trusts.
Shortcut trust. A transitive trust between a domain in the same domain tree or forest used to shorten the trust path in a large and complex domain tree or forest.
Forest trust. A transitive trust between a forest root domain and a second forest root domain.
Realm trust. A transitive trust between an Active Directory domain and an Kerberos V5 realm. For more information about Kerberos V5 realms, see Kerberos V5
authentication.
For more information about trust types, see Trust types.
Nontransitive trust
A nontransitive trust is restricted by the two domains in the trust relationship and does not flow to any other domains in the forest. A nontransitive trust can be a two-way
trust or a one-way trust.
Nontransitive trusts are one-way by default, although you can also create a two-way relationship by creating two one-way trusts. In summary, nontransitive domain trusts
are the only form of trust relationship possible between:
A Windows Server 2003 domain and a Windows NT domain

A Windows Server 2003 domain in one forest and a domain in another forest (when not joined by a forest trust)
Using the New Trust Wizard, you manually create the following nontransitive trusts:
External trust. A nontransitive trust created between a Windows Server 2003 domain and a Windows NT domain or a Windows 2000 domain or Windows
Server 2003 domain in another forest.
When you upgrade a Windows NT domain to a Windows Server 2003 domain, all existing Windows NT trusts are preserved intact. All trust relationships between
Windows Server 2003 domains and Windows NT domains are nontransitive.
Realm trust. A nontransitive trust between an Active Directory domain and an Kerberos V5 realm. For more information about Kerberos V5 realms, see Kerberos
V5 authentication.



You can create an external trust to form a one-way or two-way, nontransitive trust with domains outside of your forest. External trusts are sometimes necessary when users
need access to resources located in a Windows NT 4.0 domain or in a domain located within a separate forest that is not joined by a forest trust, as shown in the figure.
When a trust is established between a domain in a particular forest and a domain outside of that forest, security principals from the external domain can access 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.
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 To view advanced features.
In domains with the functional level set to Windows 2000 mixed, it is recommended that you delete external trusts from a domain controller running Windows Server 2003.
External trusts to Windows NT 4.0 or 3.51 domains can be deleted by authorized administrators on the domain controllers running Windows NT 4.0 or 3.51. However, only
the trusted side of the relationship can be deleted on the domain controllers running Windows NT 4.0 or 3.51. The trusting side of the relationship (created in the
Windows Server 2003 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 domain controller running Windows Server 2003 in the trusting domain. If an external trust is inadvertently
deleted from a domain controller running Windows NT 4.0 or 3.51, you will need to recreate the trust from any domain controller running Windows Server 2003 in the
trusting domain.
For more information about how to create an external trust, see Create an external trust.
Securing external trusts

To improve the security of Active Directory forests, domain controllers running Windows Server 2003 and Windows 2000 Service Pack 4 (or higher) enable security identifier
(SID) filter quarantining on all new outgoing external trusts by default.
By applying SID filter quarantining to outgoing external trusts, you prevent malicious users who have domain administrator level access in the trusted domain from
granting, to themselves or other user accounts in their domain, elevated user rights to the trusting domain.
When a malicious user can grant unauthorized user rights to another user it is known as an elevation of privilege attack. For more information about SID filtering and how
to further mitigate an elevation of privilege attack, see MS02-001: Forged SID could result in elevated privileges in Windows 2000 (http://go.microsoft.com/fwlink/?
LinkId=102075).
How SID filter quarantining works

When security principals are created in a domain, the domain SID is included in the security principal's SID to identify the domain in which it was created. The domain SID is
an important characteristic of a security principal because the Windows security subsystem uses it to verify the security principal's authenticity.
In a similar fashion, outgoing external trusts created from the trusting domain use SID filter quarantining to verify that incoming authentication requests made from security
principals in the trusted domain contain SIDs of security principals from the trusted domain only. This is done by comparing the SIDs of the incoming security principal to
the domain SID of the trusted domain. If any of the security principal SIDs include a domain SID other than the one from the trusted domain, the trust removes the
offending SID.
SID filtering ensures that any misuse of the SID history attribute on security principals (including inetOrgPerson) in the trusted forest cannot pose a threat to the integrity of
the trusting forest.
The SID history attribute can be useful to domain administrators when they migrate user and group accounts from one domain to another. Domain administrators can add
SIDs from an old user or group account to the SID history attribute of the new, migrated account. By doing this, domain administrators give the new account the same level
of access to resources as the old account.
If domain administrators could not use the SID history attribute in this way, they would have to track down and reapply permissions for the new account on each network
resource that the old account had access to.
Understanding the threat

If not for SID filtering on outgoing external trusts, a malicious user with administrative credentials residing in the trusted domain could sniff network authentication requests
from the trusting domain to obtain the SID information of a user who has full access to resources in the trusting domain, such as a domain administrator.
After obtaining the domain administrators SID from the trusting domain, a malicious user with administrative credentials can add that SID to a user account's SID history
attribute in the trusted domain and attempt to gain full access to the trusting domain and the resources within that domain. In this scenario, a malicious user who has
domain administrator credentials in the trusted domain is a threat to the entire trusting forest.
SID filtering neutralizes the threat of malicious users in the trusted domain from using the SID history attribute to gain elevated privileges.
Impact of SID filter quarantining

SID filter quarantining on external trusts can affect your existing Active Directory infrastructure in the following two areas:
SID history data that contains SIDs from any domain other than the trusted domain will be removed from authentication requests made from the trusted domain.
This will result in access being denied to resources that have the user's old SID.
Universal group access control strategy between forests will require changes.
When SID filter quarantining is enabled, users who use SID history data for authorization to resources in the trusting domain no longer have access to those resources.
If you typically assign universal groups from a trusted forest to access control lists (ACLs) on shared resources in the trusting domain, SID filter quarantining will have a
major impact on your access control strategy.
Because universal groups must adhere to the same SID filter quarantining guidelines as other security principal objects (that is, the universal group object SID must also
contain the domain SID), you should verify that any universal groups that are assigned to shared resources in the trusting domain were created in the trusted domain.
If the universal group in the trusted forest was not created in the trusted domain, even though it may contain users from the trusted domain as members, authentication
requests made from members of that universal group will be filtered and discarded.
Therefore, before assigning access to resources in the trusting domain for users in the trusted domain, you should confirm that the universal group containing the trusted
domain users was created in the trusted domain.
Disabling SID Filter quarantining

Although it is not recommended, you can disable SID filter quarantining for an external trust by using the Netdom.exe tool. You should consider disabling SID filter
quarantining only in the following situations:
You have the same level of trust for all administrators who have physical access to domain controllers in the trusted domain as the administrators in the trusting
domain.
You have a strict requirement to assign universal groups to resources in the trusting domain that were not created in the trusted domain.
Users have been migrated to the trusted domain with their SID histories preserved, and you want to grant them access to resources in the trusting domain based on
the SID history attribute.
Only domain administrators can disable SID filtering. To disable SID filter quarantining for the trusting domain, type the following syntax at a command-prompt:
Netdom trust TrustingDomainName /domain: TrustedDomainName /quarantine:No /userD:domainadministratorAcct/passwordD:domainadminpwd
To enable SID filter quarantining, set the /quarantine: command-line option to Yes. For more information about Netdom.exe, see Active Directory support tools.
You can enable or disable SID filter quarantining only from the trusting side of the trust. If the trust is a two-way trust, you can also disable SID filter quarantining in the
trusted domain by using the domain administrator's credentials for the trusted domain and reversing the TrustingDomainName and TrustedDomainName values in the
command-line syntax.
Notes
To further secure your forest, you should consider enabling SID filter quarantining on all existing external trusts that were created by domain controllers running
Windows 2000 Service Pack 3 (or earlier). You can do this by using Netdom.exe to enable SID filtering on existing external trusts, or by recreating these external
trusts from a domain controller running Windows Server 2003 or Windows 2000 Service Pack 4 (or later).
You cannot turn off the default behavior that enables SID filter quarantining for newly created external trusts.
External trusts created from domain controllers running Windows 2000 Service Pack 3 (or earlier) do not enforce SID filter quarantining by default.
Domain controllers running Windows NT Server 4.0 do not take part in the trust creation process when existing domain controllers in the same domain are running
Windows 2000 or Windows Server 2003.
You can enable or disable SID filter quarantining only for trusts that extend beyond forest boundaries such as external and forest trusts. For more information about
SID filtering and forest trusts, see Forest trusts.
Allowing SID history to traverse forest trusts

If you are migrating users from one domain to another in different forests, you may want to allow the migrated users to access resources in their original forest by using
their migrated (SID history) credentials. The default SID filtering that is applied to forest trusts prevents user-resource-access requests from traversing the trusts with the
credentials of the original domain. If you want to make it possible for users to use the credentials that were migrated from their original domain, you can allow SID history
to traverse forest trusts by using the netdom command.
Only domain administrators or enterprise administrators can modify SID filtering settings. To allow SID history credentials to traverse a trust relationship between two
forests, type a command using the following syntax at a command prompt, and then press ENTER:
Netdom trust TrustingDomainName /domain: TrustedDomainName /enablesidhistory:Yes /usero:domainadministratorAcct/passwordo:domainadminpwd
To re-enable the default SID filtering setting across forest trusts, set the /enablesidhistory: command-line option to No. For more information about Netdom, see
Domain and Forest Trust Tools and Settings.
Note
The same security considerations for removing SID filter quarantining from external trusts apply to allowing SID history to traverse forest trusts.


Shortcut trusts are one-way or two-way, transitive trusts that can be used when administrators need to optimize the authentication process. Authentication requests must
first travel a trust path between domain trees, and in a complex forest this can take time, which can be reduced with shortcut trusts. A trust path is the series of domain
trust relationships that must be traversed in order to pass authentication requests between any two domains. For more information about trust paths, see Trust direction.
Shortcut trusts are necessary when many users in a domain regularly log on to other domains in a forest. For example, using the following figure as an example, you could
form a shortcut trust between domain B and domain D or domain A and domain 1 and so on.
Shortcut trusts effectively shorten the path traveled for authentication's made between domains located in two separate trees.
For more information about how to create a shortcut trust, see Create a shortcut trust.
Using one-way trusts

A one-way, shortcut trust established between two domains located in separate domain trees can reduce the time needed to fulfill authentication requests, but in only one
direction. For example, when a one-way, shortcut trust is established between domain A and domain B, authentication requests made in domain A to domain B can utilize
the new one-way trust path. However, authentication requests made in domain B to domain A will still need to travel the longer trust path.
Using two-way trusts

A two-way, shortcut trust established between two domains located in separate domain trees will reduce the time needed to fulfill authentication requests originating in
either domain. For example, when a two-way trust is established between domain A and domain B, authentication requests made from either domain to the other can
utilize the new, two-way trust path.


A realm trust can be established between any non-Windows Kerberos V5 realm and a Windows Server 2003 domain. This trust relationship allows cross-platform
interoperability with security services based on other Kerberos V5 versions such as UNIX and MIT implementations. Realm trusts can switch from nontransitive to transitive
and back. Realm trusts can also be either one-way or two-way.
For more information about how to create a realm trust, see Create a realm trust.


A forest trust can only be created between a forest root domain in one Windows Server 2003 forest and a forest root domain in another Windows Server 2003 forest.
Creating a forest trust between two Windows Server 2003 forests provides a one-way or two-way, transitive trust relationship between every domain residing within each
forest. Forest trusts are useful for Application Service Providers, companies undergoing mergers or acquisitions, collaborative business extranets, and companies seeking a
solution for administrative autonomy.
For more information about creating forest trusts, see Checklist: Creating a forest trust.
Note
You should not enable SID filter quarantining on forest trusts, that is, by using the netdom command with the /quarantine:yes option. However, if you have migrated
users from one Windows Server 2003 forest to another and the migrated users need access to resources in the former domain, you can relax the default SID filtering
that is applied to a forest trust by using the netdom command with the /enablesidhistory:yes option. Using that command on a forest trust reduces the level of SID
filtering on the forest trust. So, ensure that you trust the administrators of the trusted domain, as well as their security practices.
Using one-way forest trusts

A one-way, forest trust between two forests allows members of the trusted forest to utilize resources located in the trusting forest. However, the trust operates in only one
direction. For example, when a one-way, forest trust is created between forest A (the trusted forest) and forest B (the trusting forest), members of forest A can access
resources located in forest B, but members of forest B cannot access resources located in forest A using the same trust.
Using two-way forest trusts

A two-way, forest trust between two forests allows members from either forest to utilize resources located in the other forest; domains in each respective forest trust
domains in the other forest implicitly. For example, when a two-way, forest trust is established between forest A and forest B, members of forest A can access resources
located in forest B, and members of forest B can access resources in forest A, using the same trust.
Forest trusts
Forest trusts
In a Windows Server 2003 forest, you can link two disjoined Windows Server 2003 forests together to form a one-way or two-way, transitive trust relationships. A two-way,
forest trust is used to form a transitive trust relationship between every domain in both forests.
Forest trusts can provide the following benefits:
Simplified management of resources across two Windows Server 2003 forests by reducing the number of external trusts necessary to share resources.
Complete two-way trust relationships with every domain in each forest.
Use of user principal name (UPN) authentication across two forests.
Use of both the Kerberos V5 and NTLM authentication protocols to improve the trustworthiness of authorization data transferred between forests.
Flexibility of administration. Administrative tasks can be unique to each forest.
Forest trusts can only be created between two forests and cannot be implicitly extended to a third forest. This means that if a forest trust is created between forest 1 and
forest 2, and a forest trust is also created between forest 2 and forest 3, forest 1 will not have an implicit trust with forest 3. For more information about the requirements
needed for a forest trust, see When to create a forest trust.
Notes
In a Windows 2000 forest, if users in one forest need to access resources in another forest, an administrator can create an external trust relationship between the
two domains. External trusts can be one-way or two-way and are nontransitive, and therefore, limit the ability for trust paths to extend to other domains. For more
information about external trusts, see Trust types.
All trusts in Windows Server 2003 Active Directory use security identifier (SID) filtering to some degree. External trusts are quarantined by default, which prevents any
domain SIDs other than those of the quarantined trusted domain from traversing the trust relationship. SID filtering is used to prevent attacks from malicious users
who might try to grant elevated user rights to another user account. SID filtering on forest trusts does not prevent migrations to domains within the same forest
from using SID history and will not affect your universal group access control strategy. For more information about SID filtering, see When to create an external
trust.
Managing a multiple forest environment

Forest trusts help you to manage a segmented Active Directory infrastructure within your organization by providing support for accessing resources and other objects
across multiple forests. For more information about accessing resources across multiple forests, see Accessing resources across forests.
Because each forest is administered separately, adding additional forests to your organization increases your organization's management needs. For more information,
see Creating a new forest.
Reasons to create multiple forests in your organization include:
To secure data within each forest. Sensitive data can be protected so that only users within that forest can access it.
To isolate directory replication within each forest. Schema changes, configuration changes, and the addition of new domains to a forest only have forest-wide
impact within that forest, not on a trusting forest.
Delegating forest-wide administrative control

Active Directory data that is stored in the schema and configuration containers is replicated to every domain controller in the forest. Since changes to the schema and
configuration containers will affect all domains in the forest, administrative control for forest-wide changes should be entrusted to highly trained or experienced
administrators. All domain data contained in the forest root domain should also be regarded as highly sensitive data.
The following groups provide forest-wide administrative control in each forest:
Enterprise Admins
Domain Admins (in the forest root domain)
Schema Admins
Since membership in any of these groups can affect forest-wide behavior, add users with caution. As a security best practice, avoid adding users from another forest to
any of these forest-wide administrative groups. For more information about these groups, see Default groups.
Synchronizing data across forests

You can synchronize global address lists (GALs) and objects across forests using Microsoft Metadirectory Services (MMS) or another supported synchronization tool.
Common data types that need synchronization across forests include:
GALs (Exchange)
Public folders
Directory objects
Synchronizing this data across forests will help end users view address lists and other data the same way as they do when viewing this information within their own forest.
For more information about MMS, see Microsoft Metadirectory Services.


Since two or more Active Directory domains within the same forest are implicitly connected by two-way, transitive trusts, authentication requests made from one domain to
another are successfully routed in order to provide a seamless coexistence of resources across domains. Users can only gain access to resources in other domains after
first being authenticated in their own domain.
Domain controllers running Windows 2000 or Windows Server 2003 authenticate users and applications using one of two authentication protocols: Kerberos V5 or NTLM.
For more information about Kerberos authentication, see Kerberos V5 authentication. For more information about NTLM authentication, see NTLM authentication. For
more information about the Active Directory authentication process, see Access control in Active Directory.
Once authenticated, the user can attempt to gain access to resources from any domain in the forest using the Active Directory authorization process. For more information
about the Active Directory authorization process, see Security information for Active Directory.
To access a shared resource in another domain using Kerberos, a user's workstation first requests a ticket from a domain controller in its account domain to the server
(hosting the resource) in the trusting domain. This ticket is then issued by an intermediary trusted by the workstation and the server. The workstation presents this trusted
ticket to the server in the trusting domain for authentication.
The following figure and corresponding steps provide a detailed description of the Kerberos authentication process that is used when a computer running Windows 2000
Professional, Windows 2000 Server, Windows XP Professional, or a member of the Windows Server 2003 family attempts to access resources from a server located in
another domain.
1. User1 logs on to Workstation1 using credentials from the child1.microsoft.com domain. As part of this process, the authenticating domain controller issues User1 a
ticket-granting ticket (TGT). This ticket is required to be authenticated to resources. The user then attempts to access a shared resource (\\fileserver1\share) on a file
server located in the child2 domain.
2. Workstation1 contacts the Key Distribution Center (KDC) on a domain controller in its domain (ChildDC1) and requests a service ticket for the FileServer1 service
principal name (SPN).
3. ChildDC1 does not find the SPN in its domain database and queries the global catalog to see if any domains in the forest contain this SPN. The global catalog sends
the requested information back to ChildDC1.
4. ChildDC1 sends the referral to Workstation1.
5. Workstation1 contacts a domain controller in ForestRootDC1 (its parent domain) for a referral to a domain controller (ChildDC2) in the Child2 domain.
ForestRootDC1 sends the referral to Workstation 1.
6. Workstation1 contacts the KDC on ChildDC2 and negotiates the ticket for the user to gain access to FileServer1.
7. Now that Workstation1 has a service ticket, it sends the service ticket to FileServer1, which reads the user's security credentials and constructs an access token
accordingly.
Each domain has its own set of security policies that do not cross from one domain to another. For more information, see Domains.
Planning your access control strategy for multiple domains

It is recommended that you carefully plan the most efficient access control strategy for your organization's resource needs. Your design and implementation of security
groups throughout each domain in a single forest will be an important factor to consider during your planning. For information about planning an access control strategy
for multiple forests, see Accessing resources across forests.
It is important to understand the following security group concepts before you begin the planning process:
Security groups. User rights can be applied to groups in Active Directory while permissions can be assigned to security groups on member servers hosting a
resource. For more information, see Group types.

Group nesting. The ability to nest security groups is dependent on group scopes and domain functionality. For more information, see Nesting groups.
Group scope. Group scope helps determine the domain-wide and forest-wide access boundaries of security groups. For more information, see Group scope.
Domain functionality. The domain functional level of the trusting and trusted domains can affect group functionality such as group nesting. For more information,
see Domain and forest functionality.
Once you have gained a thorough understanding of security group concepts, determine the resource needs of each department and geographical division to assist you
with the planning effort.
Best practices for controlling access to shared resources across domains

By carefully using domain local, global, and universal groups, administrators can more effectively control access to resources located in other domains. Consider the
following best practices:
Organize domain users based on administrative needs, such as their locations or departments, and then create a global group, and add the appropriate user
accounts as members.
For example, add all employee user accounts in the Sales department to the Sales Department global group, and add all employee user accounts in the Accounting
Department to the Accounting Department global group.
Create a domain local group, and add all global groups from the other domains that need the same access to a resource in your domain.
For example, employees in the Sales Department and Accounting Department global groups located in DomainA use similar print resources located in DomainB. To
make future administration changes more flexible, create a domain local group called Print Resources in DomainB, and add as members both the Sales Department
and Accounting Department global groups in DomainA.
Assign the required permissions on the shared resource to the domain local group.
For example, assign permissions to the Print Resources domain local group located in DomainB so that its members, including the Sales Department and Accounting
Department groups from DomainA, can access the printer located in DomainB.
Selective authentication between domains in an external trust

Using Active Directory Domains and Trusts, you can determine the scope of authentication between two domains that are joined by an external trust. You can set selective
authentication differently for outgoing and incoming external trusts. With selective trusts, administrators can make flexible access control decisions between external
domains. For more information about how to set selective authentication, see Select the scope of authentication for users.
If you use domain-wide authentication on the incoming external trust, users in the second domain would have the same level of access to resources in the local domain as
users who belong to the local domain. For example, if DomainA has an incoming external trust from DomainB and domain-wide authentication is used, any user from
DomainB would be able to access any resource in DomainA (assuming that they have the required permissions).
If you set selective authentication on an incoming external trust, you need to manually assign permissions on each resource to which you want users in the second domain
to have access. To do this, set a control access right Allowed to authenticate on an object for that particular user or group from the external domain.
When a user authenticates across a trust with the Selective authentication option enabled, an Other Organizationsecurity ID (SID) is added to the user's authorization data.
The presence of this SID prompts a check on the resource domain to ensure that the user is allowed to authenticate to the particular service. Once the user is
authenticated, if the Other Organization SID is not already present, then the server adds the This Organization SID. Only one of these special SIDs can be present in an
authenticated user's context. For more detailed information about how selective authentication works, see Security Considerations for Trusts.
Administrators in each domain can add objects from one domain to access control lists (ACLs) on shared resources in the other domain. You can use the ACL editor to add
or remove objects residing in one domain to ACLs on resources in the other domain. For more information about how to set permissions on resources, see Set
permissions on a shared resource.
For information about setting authentication restrictions for multiple forests, see Accessing resources across forests.

Updated: February 21, 2006

When two Windows Server 2003 forests are connected by a forest trust, authentication requests made using the Kerberos V5 or NTLM protocols can be routed between
forests to provide access to resources in both forests. For more information about routing authentication requests across forests, see Routing name suffixes across
forests.
Before authentication protocols can follow the forest trust path, the service principal name (SPN) of the resource computer must be resolved to a location in the other
forest. An SPN can be one of the following:
Domain Name System (DNS) name of a host

DNS name of a domain
Distinguished name of a service connection point object
When a workstation in one forest attempts to access data on the resource computer in another forest, Kerberos contacts the domain controller for a service ticket to the
SPN of the resource computer. Once the domain controller queries the global catalog and identifies that the SPN is not in the same forest as the domain controller, the
domain controller sends a referral for its parent domain back to the workstation. At that point, the workstation queries the parent domain for the service ticket and follows
the referral chain until it gets to the domain where the resource is located.
The following figure and corresponding steps provide a detailed description of the Kerberos authentication process that is used when computers running Windows 2000
Professional, Windows XP Professional, Windows 2000 Server, or a member of the Windows Server 2003 family attempt to access resources from a computer located in
another forest.
1. User1 logs on to Workstation1 using credentials from the child.microsoft.com domain. The user then attempts to access a shared resource on FileServer1 located in
the msn.com forest.
2. Workstation1 contacts the Key Distribution Center (KDC) on a domain controller in its domain (ChildDC1) and requests a service ticket for the FileServer1 SPN.
3. ChildDC1 does not find the SPN in its domain database and queries the global catalog to see if any domains in the microsoft.com forest contain this SPN. Since a
global catalog is limited to its own forest, the SPN is not found. The global catalog then checks its database for information about any forest trusts that are
established with its forest, and, if found, it compares the name suffixes listed in the forest trust trusted domain object (TDO) to the suffix of the target SPN to find a
match. Once a match is found, the global catalog provides a routing hint back to ChildDC1.
4. ChildDC1 sends a referral for its parent domain back to Workstation1.
5. Workstation1 contacts a domain controller in ForestRootDC1 (its parent domain) for a referral to a domain controller (ForestRootDC2) in the forest root domain of
the msn.com forest.
6. Workstation1 contacts ForestRootDC2 in the msn.com forest for a service ticket to the requested service.
7. ForestRootDC2 contacts its global catalog to find the SPN, and the global catalog finds a match for the SPN and sends it back to ForestRootDC2.
8. ForestRootDC2 then sends the referral to child.msn.com back to Workstation1.
9. Workstation1 contacts the KDC on ChildDC2 and negotiates the ticket for User1 to gain access to FileServer1.
10. Now that workstation1 has a service ticket, it sends the server service ticket to FileServer1, which reads User1's security credentials and constructs an access token
accordingly.
When a forest trust is first established, each forest collects all of the trusted namespaces in its partner forest and stores the information in a TDO. Trusted namespaces
include domain tree names, user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security ID (SID) namespaces used in the other forest. TDO
objects are replicated to the global catalog. For more information about TDOs, see Trusts.
Routing hints
Routing hints are only used when all traditional authentication channels (local domain controller and then global catalog) have failed to produce a location of a SPN.
Routing hints help direct authentication requests toward the destination forest.
When an SPN cannot be located in the domain from where the network logon request originated or from the global catalog database, the global catalog checks the forest
trust TDO for trusted name suffixes located in the other forest that might match the suffix in the SPN. If a match is found, the forest root domain returns a routing hint back
to the original source computer so that it can continue the SPN location process in the other forest.
Notes
Routing hints can only reference trusted name suffixes that are listed in the TDO for its forest trust. They do not verify the name suffix before sending the hint back
to the original source computer.
Accessing NetBIOS names and Kerberos delegation across forest trusts is not supported. NTLM is fully supported and cannot be disabled.
Planning your access control strategy for multiple forests

groups throughout each forest will be an important factor to consider during your planning. For information about planning an access control strategy for multiple
domains, see Accessing resources across domains.
Group nesting. The ability to nest security groups is dependent on groups scopes and domain functionality. For more information, see Nesting groups.
Best practices for using security groups across forests

By carefully using domain local, global, and universal groups, administrators can more effectively control access to resources located in other forests. Consider the
To represent the sets of users who need access to the same types of resources, create role-based global groups in every domain and forest that contains these
users. For example, users in the Sales Department in ForestA require access to an order-entry application that is a resource in ForestB. Account Department users in
ForestA require access to the same application, but these users are in a different domain. In ForestA, create the global group SalesOrder and add users in the Sales
Department to the group. Create the global group AccountsOrder and add users in the Accounting Department to that group.
To group the users from one forest who require similar access to the same resources in a different forest, create universal groups that correspond to the global
group roles. For example, in ForestA, create a universal group called SalesAccountsOrders and add the global groups SalesOrder and AccountsOrder to the group.
Note
Universal groups are not available as security groups in Windows 2000 Server mixed-mode domains or in Windows Server 2003 domains that have a domain
functional level of Windows 2000 mixed. They are available as distribution groups.
To assign permissions to resources that are to be accessed by users from a different forest, create resource-based domain local groups in every domain and use
these groups to assign permissions on the resources in that domain. For example, in ForestB, create a domain local group called OrderEntryApp. Add this group to
the access control list (ACL) that allows access to the order entry application, and assign appropriate permissions.
To implement access to a resource across a forest, add universal groups from trusted forests to the domain local groups in the trusting forests. For example, add
the SalesAccountsOrders universal group from ForestA to the OrderEntryApp domain local group in ForestB.
When a new user account needs access to a resource in a different forest, add the account to the respective global group in the domain of the user. When a new resource
needs to be shared across forests, add the appropriate domain local group to the ACL for that resource. In this way, access is enabled across forests for resources on the
basis of group membership.
For more information, see Set permissions on a shared resource.
Selective authentication between forests

Using Active Directory Domains and Trusts, you can determine the scope of authentication between two forests that are joined by a forest trust. You can set selective
authentication differently for outgoing and incoming forest trusts. With selective trusts, administrators can make flexible forest-wide access control decisions. For more
information about how to set selective authentication, see Select the scope of authentication for users.
If you use forest-wide authentication on an incoming forest trust, users from the outside forest have the same level of access to resources in the local forest as users who
belong to the local forest. For example, if ForestA has an incoming forest trust from ForestB and forest-wide authentication is used, users from ForestB would be able to
access any resource in ForestA (assuming they have the required permissions).
If you decide to set selective authentication on an incoming forest trust, you need to manually assign permissions on each computer in the domain as well as the resources
to which you want users in the second forest to have access. To do this, set a control access right Allowed to authenticate on the computer object that hosts the resource in
Active Directory Users and Computers in the second forest. Then, allow user or group access to the particular resources you want to share.
When a user authenticates across a trust with the Selective authentication option enabled, an Other Organization security ID (SID) is added to the user's authorization
data. The presence of this SID prompts a check on the resource domain to ensure that the user is allowed to authenticate to the particular service. Once the user is
authenticated, then the server to which he authenticates adds the This Organization SID if the Other Organization SID is not already present. Only one of these special SIDs
can be present in an authenticated user's context. For more detailed information about how selective authentication works, see Security Considerations for Trusts.
Administrators in each forest can add objects from one forest to access control lists (ACLs) on shared resources in the other forest. You can use the ACL editor to add or
remove objects residing in one forest to ACLs on resources in another forest. For more information about how to set permissions on resources, see Set permissions on a
shared resource.
For information about setting authentication restrictions for external domains, see Accessing resources across domains.


Name suffix routing is a mechanism used to manage how authentication requests are routed across Windows Server 2003 forests that are joined together by forest trusts.
To simplify administration of authentication requests, when a forest trust is initially created, all unique name suffixes are routed by default. A unique name suffix is a name
suffix within a forest, such as a user principal name (UPN) suffix, service principal name (SPN) suffix, or DNS forest or domain tree name, that is not subordinate to any
other name suffix. For example, the DNS forest name microsoft.com is a unique name suffix within the microsoft.com forest.
Forests can contain multiple unique name suffixes, and all children of unique name suffixes are routed implicitly. In Active Directory Domains and Trusts, name suffixes
appear with an asterisk (*) at the beginning because of this. For example, if your forest uses *.microsoft.com as a unique name suffix, then authentication requests for all
children of microsoft.com (*.child.microsoft.com) will be routed because the child domains are part of the microsoft.com name suffix.
If a forest trust exists between two forests, then name suffixes that do not exist in one forest can be used to route authentication requests to a second forest. When a new
child name suffix (*.child.widgets.com) is added to a unique name suffix (*.widgets.com), the child name suffix will inherit the routing configuration of the unique name suffix
to which it belongs. Any new unique name suffixes that are created after a forest trust has been established will be visible in the forest trust Properties dialog box after you
verify the trust. However, routing for those new unique name suffixes will be disabled by default. For more information about how to verify a trust, see Verify a trust.
When a duplicate name suffix is detected, the routing for the newest name suffix will be disabled by default. For more information about how to route name suffixes, see
Enable or disable an existing name suffix from routing. Administrators can use the forest trust Properties dialog box to manually prevent authentication requests for
specific name suffixes from being routed to a forest.
Notes
Do not add the @ sign to the UPN suffix or a user name. When authentication requests are routed to a trusted forest, all characters before the first @ symbol are
interpreted as the user name and everything after the first @ symbol as the UPN suffix.
The Local Security Authority (LSA) will block routing to any UPN suffix that is not a valid DNS name. For example, adding an @ symbol to a UPN suffix will cause it to
automatically be disabled.
Collision detection
When two Windows Server 2003 forests are linked by a forest trust, there is a possibility that unique name suffixes existing in one forest might collide with unique name
suffixes located in the second forest. Collision detection guarantees that each name suffix will only be routed to a single forest.
Active Directory Domains and Trusts will detect a name suffix conflict when:
The same Domain Name System (DNS) name is already in use.

The same NetBIOS name is already in use.
A domain security ID (SID) conflicts with another name suffix SID.
When a name suffix in a forest conflicts with a new forest trust partner or when a name suffix in an existing forest trust conflicts with a new forest trust partner, the name
will be disabled in the new trust. For example, a conflict will occur if one forest is named widgets.com and the second forest is named sales.widgets.com. Despite the name
suffix conflict, routing will still work for any other unique name suffixes in the second forest.
For another example, assume that the msn.com forest needs to establish a two-way, forest trust with the widgets.com forest. Both msn.com and widgets.com have identical
UPN suffixes of microsoft.com. During the creation of the two-way, forest trust, the New Trust Wizard will detect and display the conflict between the two UPN name
suffixes and then create the forest trust.
If Active Directory Domains and Trusts detects a name suffix conflict with a trust partner domain, access to that domain from outside the forest may be denied. However,
access to the conflicted domain from within its forest will function normally.
For example, if the domain widgets.com exists in both the msn.com and microsoft.com forests, users within the msn.com forest will be able to access resources in
widgets.com domain that resides in the msn.com forest. However, users in the msn.com forest will be denied access to resources in the widgets.com domain located in the
microsoft.com forest.
Conflicts will be listed in Active Directory Domains and Trusts, in the forest trust Properties dialog box, on the Name Suffix Routing tab. If a name suffix conflict is
detected during the creation of the forest trust, then the New Trust Wizard will prompt you to save a log file of the conflicts. You can also save a log file after a trust has
been created. For more information about how to save this log file, see Change the routing status of a name suffix.
If a NetBIOS or domain SID conflict exists, Active Directory Domains and Trusts identifies the name suffixes routing status as enabled or disabled with exceptions, as
appropriate. The details about where the conflict exists are listed in the log file.
You can also use the Netdom command-line tool to list all routed names and to enable and disable routing for NetBIOS names and SIDs. For example, a forest named
microsoft.com has a forest trust with widgets.com and you also need to add a forest trust to msn.com. Both widgets.com and msn.com have child domains with the
NetBIOS name of SALES (and DNS names of USsales.widgets.com and sales.msn.com).
After you create the new trust to msn.com, routing to the SALES domain name in msn.com will be disabled. If you need to use the name SALES to route to the msn.com
forest but don't need to use it to the widgets.com forest, you can use Netdom to disable SALES in widgets.com, and then enable it in msn.com.
For information about Netdom, see Active Directory support tools.

Understanding sites and replication

Sites overview
Replication overview
How replication works
Replication within a site
Replication between sites
When to establish a single or separate sites
Bandwidth
Managing replication
Sites overview
Sites overview
Sites in Active Directory represent the physical structure, or topology, of your network. Active Directory uses topology information, stored as site and site link objects in
the directory, to build the most efficient replication topology. You use Active Directory Sites and Services to define sites and site links. A site is a set of well-connected
subnets. Sites differ from domains; sites represent the physical structure of your network, while domains represent the logical structure of your organization.
Using sites
Sites help facilitate several activities within Active Directory, including:
Replication. Active Directory balances the need for up-to-date directory information with the need for bandwidth optimization by replicating information within a
site more frequently than between sites. You can also configure the relative cost of connectivity between sites to further optimize replication. For more information,
see Replication between sites and Managing replication.
Authentication. Site information helps make authentication faster and more efficient. When a client logs on to a domain, it first searches its local site for a domain
controller to authenticate against. By establishing multiple sites, you can ensure that clients authenticate against domain controllers nearest to them, reducing
authentication latency and keeping traffic off WAN connections.
Active Directory-enabled services. Active Directory-enabled services can leverage site and subnet information to enable clients to locate the nearest server
providers more easily. For information about services, see Services.
Defining sites using subnets

In Active Directory, a site is a set of computers well-connected by a high-speed network, such as a local area network (LAN). All computers within the same site typically
reside in the same building, or on the same campus network. A single site consists of one or more Internet Protocol (IP) subnets. Subnets are subdivisions of an IP network,
with each subnet possessing its own unique network address. A subnet address groups neighboring computers in much the same way that postal codes group
neighboring postal addresses. The following figure shows several clients within a subnet that defines an Active Directory site.
Sites and subnets are represented in Active Directory by site and subnet objects, which you create through Active Directory Sites and Services. Each site object is associated
with one or more subnet objects.
For information about creating sites, see Create a site.
For information about creating subnets, see Create a subnet.
For information about subnets, see "Introduction to TCP/IP" at the Microsoft Windows Resource Kits Web site.
Assigning computers to sites

Computers are assigned to sites based on their Internet Protocol (IP) address and subnet mask. Site assignment is handled differently for clients and member servers than
for domain controllers. For a client, site assignment is dynamically determined by its IP address and subnet mask during logon. For a domain controller, site membership is
determined by the location of its associated server object in Active Directory. For more information, see "Active Directory Replication" at the Microsoft Windows Resource
Kits Web site.
For information about associating subnets with sites, see Associate a subnet with a site.
For information about establishing single or multiple sites, see When to establish a single or separate sites.
Understanding sites and domains

In Active Directory, sites map the physical structure of your network, while domains map the logical or administrative structure of your organization. This separation of
physical and logical structure provides the following benefits:
You can design and maintain the logical and physical structures of your network independently.
You do not have to base domain namespaces on your physical network.
You can deploy domain controllers for multiple domains within the same site. You can also deploy domain controllers for the same domain in multiple sites.
For more information about domains, see Domains.

Except for very small networks, directory data must reside in more than one place on the network to be equally useful to all users. Through replication, the
Active Directory directory service maintains replicas of directory data on multiple domain controllers, ensuring directory availability and performance for all users. Active
Directory uses a multimaster replication model, allowing you to make directory changes at any domain controller, not just at a designated primary domain controller.
Active Directory relies on the concept of sites to help keep replication efficient, and on the Knowledge Consistency Checker (KCC) to automatically determine the best
replication topology for the network.
Organizing data for replication

Data is stored on each domain controller in the directory store, which is divided logically into specific directory partitions. Each partition stores a different type of directory
data, either domain data, forest schema data, forest configuration data, or application data. All domain controllers within a forest hold a replica of the schema and
configuration partitions for that forest, and all domain controllers within a particular domain hold a replica of the domain partition for their domain. Application directory
partitions hold directory data specific to a particular application and can be stored by domain controllers belonging to different domains. Changes to each directory
partition are replicated to all other domain controllers that hold a copy of that partition. For more information, see Directory data store.
Replication also ensures the availability of the global catalog throughout the entire forest. The global catalog is a searchable directory store containing data about every
object in all domains. The global catalog is stored by domain controllers for which the global catalog has been enabled. For more information, see Global catalog
replication.
Improving replication efficiency with sites

To help make replication more efficient, Active Directory relies on sites. Sites, defined as groups of well-connected computers, determine how directory data is replicated.
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 replicated updates first. The domain controllers in other sites also receive the changes, but less frequently, reducing network
bandwidth consumption. For more information, see How replication works and Sites overview.
Determining the replication topology

The Knowledge Consistency Checker (KCC), a process running on each domain controller, automatically identifies the most efficient replication topology for your network,
based on information you provide about your network in Active Directory Sites and Services. The KCC regularly recalculate the replication topology to adjust for any
network changes that have occurred. The KCC of one domain controller within each site (the intersite topology generator) determines the intersite replication topology. For
more information about the KCC, see Active Directory Replication Technologies.
Replication enhancements in the Windows Server 2003 family

The Microsoft Windows Server 2003 family includes enhancements to make replication both more efficient, as well as more scalable across a larger number of domains
and sites. These include refinements in memory usage, enhancements to the Windows 2000 spanning tree algorithm, a completely new spanning tree algorithm for
Windows Server 2003 forests, and a new load balancing tool.
In a forest set to the Windows 2000 functional level, the replication enhancements provide gains in replication efficiency and scalability, even when sites and domains
contain domain controllers running Windows 2000. If a site contains at least one domain controller running Windows Server 2003, then a domain controller running
Windows Server 2003 assumes the intersite topology generator role for the site, allowing the enhancements to take effect.
In a forest set to the Windows Server 2003 functional level, the new Windows Server 2003 spanning tree algorithm goes into effect for larger gains in both efficiency and
scalability. For example, using the original spanning tree algorithm from Windows 2000, one domain can contain up to 300 sites. With the new Windows Server 2003
algorithm, one domain can contain up to at least 3,000 sites. In the new algorithm, the intersite topology generator in each site uses a randomized selection process to
determine the bridgehead servers for the site. This selection process more evenly distributes the bridgehead replication workload among domain controllers in a site,
resulting in much better efficiency (particularly in hub sites with a number of domain controllers). By default, the randomized selection process takes place only when new
connection objects are added to the site. However, a new tool, called adlb.exe, can be run to rebalance the load each time changes occur in the topology or in the number
of domain controllers in the site. In addition, adlb can stagger schedules so that the outbound replication load for each server is spread out evenly across time. For more
information about adlb and to download the tool, see the "Windows Server 2003 Active Directory Branch Office Planning and Deployment Guide."


To keep directory data on all domain controllers consistent and up to date, Active Directory replicates directory changes on a regular basis. Replication occurs over
standard network protocols, uses change tracking information to prevent unnecessary replication, and uses linked value replication to improve efficiency.
Transferring replication data

Active Directory uses remote procedure call (RPC) over Internet Protocol (IP) to transfer replication data between domain controllers. RPC over IP is used for both intersite
and intrasite replication. To keep data secure while in transit, RPC over IP replication uses both authentication (using the Kerberos V5 authentication protocol) and data
encryption.
When a direct or reliable IP connection is not available, replication between sites can be configured to use the Simple Mail Transfer Protocol (SMTP). However, SMTP
replication functionality is limited, and requires an enterprise certification authority (CA). SMTP can only be used to replicate the configuration, schema and application
directory partitions, and does not support the replication of domain directory partitions. For more information, see "Active Directory Replication" at the Microsoft Windows
Resource Kits Web site.
Preventing unnecessary replication

Once a domain controller has processed a directory change from another domain controller successfully, it should not try to replicate those changes back to the domain
controller that sent the change. In addition, a domain controller should avoid sending updates to another domain controller if the target domain controller has already
received that same update from a different replication partner. To prevent such unnecessary replication, Active Directory uses change tracking information stored in the
directory. For information about change tracking, see "Active Directory Replication" at the Microsoft Windows Resource Kits Web site.
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 in the same
domain before replication of either change occurs. In such a case, both changes are replicated as new changes, creating a conflict. To resolve this conflict, domain
controllers that receive these conflicting changes examine the attribute data contained within the changes, each of which holds a version and a timestamp. Domain
controllers will accept the change with the higher version and discard the other change. If the versions are identical, domain controllers will accept the change with the
more recent timestamp.
Improving replication efficiency

Introduced in the Windows Server 2003 family, linked value replication allows individual values of a multivalued attribute to be replicated separately. In Windows 2000, when
a change was made to a member of a group (one example of a multivalued attribute with linked values) the entire group had to be replicated. With linked value replication,
only the group member that has changed is replicated, and not the entire group. To enable linked value replication, you must raise the forest functional level to Windows
Server 2003 . For more information about forest functional levels, see Domain and forest functionality. For more information about multivalued attributes, see Schema.
For more information about how replication works, see "Active Directory Replication" at the Microsoft Windows Resource Kits Web site.


Active Directory handles replication within a site, or intrasite replication, differently than replication between sites because bandwidth within a site is more readily available.
The Active Directory Knowledge Consistency Checker (KCC) builds the intrasite replication topology using a bidirectional ring design. Intrasite replication is optimized for
speed, and directory updates within a site occur automatically on the basis of change notification. Unlike replication data travelling between sites, directory updates
replicated within a site are not compressed.
For information about intersite replication, see Replication between sites and How replication works.
Building the intrasite replication topology

The Knowledge Consistency Checker (KCC) on each domain controller automatically builds the most efficient replication topology for intrasite replication, using a
bidirectional ring design. This bidirectional ring topology attempts to create at least two connections to each domain controller (for fault tolerance) and no more than
three hops between any two domain controllers (to reduce replication latency). To prevent connections of more than three hops, the topology can include shortcut
connections across the ring. The KCC updates the replication topology regularly.
Note
The KCC actually creates a separate replication topology for each directory partition (schema, configuration, domain, application). Within a single site, these
topologies are usually identical for all partitions hosted by the same set of the domain controllers.
Determining when intrasite replication occurs

Directory updates made within a site are likely to have the most direct impact on local clients, so intrasite replication is optimized for speed. Replication within a site occurs
automatically on the basis of change notification. Intrasite replication begins when you make a directory update on a domain controller. By default, the source domain
controller waits 15 seconds and then sends an update notification to its closest replication partner. If the source domain controller has more than one replication partner,
subsequent notifications go out by default at 3 second intervals to each partner. After receiving notification of a change, a partner domain controller sends a directory
update request to the source domain controller. The source domain controller responds to the request with a replication operation. The 3 second notification interval
prevents the source domain controller from being overwhelmed with simultaneous update requests from its replication partners.
For some directory updates in a site, the 15 second waiting time does not apply and replication occurs immediately. Known as urgent replication, this immediate replication
applies to critical directory updates, including the assigning of account lockouts and changes in the account lockout policy, the domain password policy, or the password
on a domain controller account.
For more information about intrasite replication, see "Active Directory Replication" at the Microsoft Windows Resource Kits Web site.


Active Directory handles replication between sites, or intersite replication, differently than replication within sites because bandwidth between sites is usually limited. The
Active Directory Knowledge Consistency Checker (KCC) builds the intersite replication topology using a least-cost spanning tree design. Intersite replication is optimized for
bandwidth efficiency, and directory updates between sites occur automatically based on a configurable schedule. Directory updates replicated between sites are
compressed to preserve bandwidth.
For information about intrasite replication, see Replication within a site.
For information about site design, see "Designing the Site Topology" at the Microsoft Windows Resource Kits Web site.
Building the intersite replication topology

Active Directory automatically builds the most efficient intersite replication topology using information you provide (through Active Directory Sites and Services) about your
site connections. The directory stores this information as site link objects. One domain controller per site, called the intersite topology generator, is assigned to build the
topology. A least-cost spanning tree algorithm is used to eliminate redundant replication paths between sites. The intersite replication topology is updated regularly to
respond to any changes that occur in the network. You can control intersite replication through the information you provide when you create your site links. For more
information, see Managing replication.
Determining when intersite replication occurs

Active Directory preserves bandwidth between sites by minimizing the frequency of replication and by allowing you to schedule the availability of site links for replication.
By default, intersite replication across each site link occurs every 180 minutes (3 hours). You can adjust this frequency to match your specific needs. Be aware that increasing
this frequency increases the amount of bandwidth used by replication. In addition, you can schedule the availability of site links for use by replication. By default, a site link
is available to carry replication traffic 24 hours a day, 7 days a week. You can limit this schedule to specific days of the week and times of day. You can, for example,
schedule intersite replication so that it only occurs after normal business hours. For more information, see Configure site link replication frequency and Configure site link
replication availability.
Notes
With certain restrictions, you can use the Simple Mail Transfer Protocol (SMTP) for replicating to sites that do not have a direct or reliable Internet Protocol (IP)
connection. For more information, see "Active Directory Replication" at the Microsoft Windows Resource Kits Web site.
Intersite replication through a firewall or virtual private network requires some special considerations. For more information, see Active Directory at the Microsoft
Web site.


You can optimize the replication efficiency and reduce the administrative overhead of your network by establishing sites appropriately. The most effective number of sites
depends on the physical design of your network. When you first create a new forest, a single, default Active Directory site (called Default-Site-First-Name) is created that
represents your entire network. A forest or domain consisting of a single site can be very efficient for a single location network connected completely by high-speed
bandwidth. If your forest or domain contains multiple geographic locations that communicate over low-speed wide area network (WAN) connections, establishing multiple
sites gives you more detailed control of replication behavior, reduces authentication latency, and reduces network traffic on the WAN.
For information about sites, see Sites overview.
For information about designing a site topology, see "Designing the Site Topology" at the Microsoft Windows Resource Kits Web site.
Why bandwidth is important

Within a site, bandwidth affects how efficiently replication can work. The frequency with which intrasite replication occurs requires high-speed bandwidth to function most
effectively. So before you a create new site, you should make sure that high-speed bandwidth connects all computers within the site candidate. Any area where domain
controllers are connected by 10 megabits per second (Mbps) or more of bandwidth is a good site candidate.
When to establish a single site

If you have a single LAN consisting of a single subnet, or if your network contains multiple subnets connected by a high-speed backbone, establishing a single site
replication topology can provide the following benefits:
Simplified replication management

Prompt directory updates between all domain controllers
A single site topology allows all replication on your network to occur as intrasite replication, which requires no manual replication configuration. A single site design also
allows all domain controllers to remain very current with respect to directory changes, because directory updates are replicated almost immediately. For more information,
see Replication within a site. For information about creating sites, see Create a site.
When to establish multiple sites

When your network consists of multiple geographic locations connected by a WAN, establishing separate sites for each location provides the following benefits:
Efficient use of WAN bandwidth for replication

Detailed control of replication behavior
Reduction in authentication latency
Physically separate network locations typically communicate over WAN connections, which are most often characterized by low-speed bandwidth. By creating a separate
site for each physical location on your network, you ensure that domain controllers communicating over WAN connections use intersite replication, which is specifically
designed for efficiency on low bandwidth connections. For more information, see Replication between sites.
With multiple sites, you have more detailed control of replication behavior through several configurable intersite replication settings. These settings include the relative cost
of different replication paths, the domain controllers associated with each site, the subnets associated with each site, the frequency of directory update transfers, and the
availability of connections for use by replication. For more information, see Managing replication.
A network client logging on to a domain must contact a domain controller as part of the authentication process, first looking within its own site. If the site includes two or
more physically separate network locations, the client may authenticate against a domain controller across a WAN connection. Authentication across a WAN introduces a
delay in the authentication process. By placing physically separate network locations into separate Active Directory sites, you can ensure that clients first attempt to
authenticate against a domain controller in their own site.
Bandwidth
Bandwidth
Bandwidth is the most important practical consideration affecting intrasite 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:
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.
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 about how bandwidth may affect the way you configure sites, see Replication between sites.
Active Directory relies on site configuration information to manage and optimize the process of replication. Active Directory provides automatic configuration of these
settings in some cases. In addition, you can configure site-related information for your network using Active Directory Sites and Services. Configurable information includes
settings for site links, site link bridges, and bridgehead servers.
Configuring site links

You can use site link settings to control replication between sites. Configurable settings include the relative cost of each site link, the frequency of replication on each site
link, and the schedule availability of each site link for replication. For information about site links, see Replication between sites.
Site link cost

The cost of a site link determines the relative preference of the Active Directory Knowledge Consistency Checker (KCC) for using a site link in the replication topology. The
higher the cost of the site link, the lower will be the KCC's preference for using the site link. For example, if you have two site links, site link A and site link B, and you set the
cost of site link A to 150 and the cost of site link B to 200, the KCC will prefer to use site link A in the replication topology. By default, the cost of a newly created site link is
100. For information about setting site link cost, see Configure site link cost. For information about the KCC, see Replication overview.
Replication frequency
The replication frequency of a site link determines how often replication occurs over that site link. By default, the replication frequency for a site link is 180 minutes, meaning
that replication occurs over that site link every 180 minutes, or three hours. Using Active Directory Sites and Services, you can set the replication frequency from 15 minutes
to 10,080 minutes (one week). A site link must be available for any replication to occur. If a site link is not available when the number of minutes between replication
updates has passed, no replication will occur. For more information, see Configure site link replication frequency.
Site link availability

The availability schedule for a site link determines during which hours or days of the week a site link can be used for replication. By default, a site link is always available for
replication, 24 hours a day and 7 days a week. You can change this schedule, for example, to exclude business hours during which your network is busy handling other
types of traffic. Or, you can exclude particular days on which you do not want replication to occur. Scheduling information is ignored by site links that use the Simple Mail
Transfer Protocol (SMTP) for replication. For more information, see Configure site link replication availability.
Configuring site link bridges

By default, all site links are bridged, or transitive. This allows any two sites that are not connected by an explicit site link to communicate directly, through a chain of
intermediary site links and sites. One advantage to bridging all site links is that your network is easier to maintain because you do not need to create a site link to describe
every possible path between pairs of sites.
Generally, you can leave automatic site link bridging enabled. However, you might want to disable automatic site link bridging and create site link bridges manually just for
specific site links, in the following cases:
Your network is not fully routed (not every domain controller can directly communicate with every other domain controller).
You have a network routing or security policy in place that prevents every domain controller from being able to directly communicate with every other domain
controller.
Your Active Directory design includes a large number of sites. For more information, see the Active Directory Branch Office Planning Guide at the Microsoft Web site.
For more information about site link bridges and their affects on replication, see "Active Directory Replication" at the Microsoft Windows Resource Kits Web site.
For information about disabling automatic site link bridging, see Enable or disable site link bridges.
For information about creating a site link bridge manually, see Create a site link bridge.
Configuring preferred bridgehead servers

When the KCC constructs the intersite replication topology, it automatically assigns one or more bridgehead servers for each site to ensure that directory changes only
need to be replicated across a site link one time. It is recommended that you allow the KCC to make the bridgehead server assignments. You can make the bridgehead
server assignments manually through Active Directory Sites and Services. However, doing so can potentially disrupt replication if one of your manually assigned
bridgehead servers becomes unavailable. For more information, see "Active Directory Replication" at the Microsoft Windows Resource Kits Web site.
For information about manually configuring a bridgehead server, see Designate a preferred bridgehead server.

Understanding the global catalog

The role of the global catalog

Global catalog replication
Customizing the global catalog
Global catalogs and sites


A global catalog is a domain controller that stores a copy of all Active Directory objects in a forest. The global catalog stores a full copy of all objects in the directory for
its host domain and a partial copy of all objects for all other domains in the forest, as shown in the following figure.
The partial copies of all domain objects included in the global catalog are those most commonly used in user search operations. These attributes are marked for inclusion
in the global catalog as part of their schema definition. Storing the most commonly searched upon attributes of all domain objects in the global catalog provides users
with efficient searches without affecting network performance with unnecessary referrals to domain controllers.
You can manually add or remove other object attributes to the global catalog by using the Active Directory Schema snap-in. For more information, see Customizing the
global catalog.
A global catalog is created automatically on the initial domain controller in the forest. You can add global catalog functionality to other domain controllers or change the
default location of the global catalog to another domain controller. For more information, see Enable or disable a global catalog.
A global catalog performs the following directory roles:
Finds objects
A global catalog enables user searches for directory information throughout all domains in a forest, regardless of where the data is stored. Searches within a forest
are performed with maximum speed and minimum network traffic.
When you search for people or printers from the Start menu or choose the Entire Directory option within a query, you are searching a global catalog. Once you
enter your search request, it is routed to the default global catalog port 3268 and sent to a global catalog for resolution. For more information, see Finding
directory information and "Finding information in Active Directory" at the Microsoft Windows Resource Kits Web site.
Supplies user principal name authentication
A global catalog resolves user principal names UPNs when the authenticating domain controller does not have knowledge of the account. For example, if a users
account is located in example1.microsoft.com and the user decides to log on with a user principal name of user1@example1.microsoft.com from a computer
located in example2.microsoft.com, the domain controller in example2.microsoft.com will be unable to find the users account, and will then contact a global catalog
to complete the logon process. For more information, see Active Directory naming.
Supplies universal group membership information in a multiple domain environment
Unlike global group memberships, which are stored in each domain, universal group memberships are only stored in a global catalog. For example, when a user
who belongs to a universal group logs on to a domain that is set to the Windows 2000 native domain functional level or higher, the global catalog provides
universal group membership information for the users account at the time the user logs on to the domain.
If a global catalog is not available when a user logs on to a domain set to the functional level of Windows 2000 native or higher, the computer will use cached
credentials to log on the user if the user has logged on to the domain previously. If the user has not logged on to the domain previously, the user can only log on
to the local computer. However, if a user logs on as the Administrator in the domain (Builtin Administrator account), the user can always log on to the domain, even
when a global catalog is not available.
For more information about universal groups, see Group scope. For more information about universal groups and replication, see Global catalog replication and
Global catalogs and sites.
Note
When there is only one domain in a forest, it is not necessary for users to obtain universal group memberships from a global catalog when logging on. This
is because Active Directory can detect that there are no other domains in the forest and will prevent a query to the global catalog for this information.
Validates object references within a forest
A global catalog is used by domain controllers to validate references to objects of other domains in the forest. When a domain controller holds a directory object
with an attribute containing a reference to an object in another domain, this reference is validated using a global catalog.


Replication of the global catalog ensures that users throughout the forest have fast access to information about every object in the forest. The default attributes that make
up the global catalog provide a baseline of the most commonly searched attributes. These attributes are replicated to the global catalog as part of normal Active Directory
replication.
The replication topology for the global catalog is generated automatically by the Knowledge Consistency Checker (KCC). However, the global catalog is replicated only to
other domain controllers that have been designated as global catalogs. Global catalog replication is affected both by the attributes marked for inclusion in the global
catalog, and by universal group memberships.
Adding attributes
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 the Active Directory Schema snap-in, you can specify additional attributes to be kept in the global catalog.
In Windows 2000 forests, extending the partial attribute set causes a full synchronization of all object attributes stored in the global catalog (for all domains in the forest).
In a large, multi-domain forest, this synchronization can cause significant network traffic. Between domain controllers enabled as global catalogs that are running Windows
Server 2003, only the newly added attribute is replicated. For more information about adding attributes to the global catalog, see Customizing the global catalog.
Preventing unpredictable access to global catalog data

Special security consideration should be given when specifying permissions on domain data that is also replicated to the global catalog. When a user connects to a global
catalog, an impersonation token is created for the user, which is used in subsequent access control decisions on the global catalog. The user's universal, global and
domain local group memberships are represented in this token. However, only domain local groups from the domain that the domain controller hosting the global catalog
(to which the user has connected) belongs to and of which the user is a member show up in the user's token. Domain local groups in the user's domain (and in other
domains) of which the user is a member do not show up in the access token.
A global catalog stores a replicated, read-only copy of all objects in the forest and a partial set of each object's attributes, including the security descriptor for each object.
The security descriptor contains a discretionary access control list (DACL), which specifies permissions on the object. When a user connects to a global catalog and tries to
access an object, an access check is performed based on the user's token and the object's DACL. Any permissions specified in the object's DACL for domain local groups
that are not from the domain that the domain controller hosting the global catalog (to which the user has connected) belongs to, will be ineffective because only domain
local groups from the global catalog's domain of which the user is a member are represented in the user's access token. As a result, a user may be denied access when
access should have been granted, or allowed access when access should have been denied.
As a best practice, you should avoid using domain local groups when assigning permissions on Active Directory objects, or be aware of the implications if you do use
them. To prevent unauthorized access to global catalog data, use global groups or universal groups instead. For information about global and universal groups, see
Group scope.
How universal groups affect global catalog replication

Groups with universal scope, and their members, are listed exclusively in the global catalog. Groups with 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 the replication traffic associated with keeping 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.
When you first create a universal group, you do so from any domain that is set to the domain functional level of Windows 2000 or higher. The universal group resides in
the domain directory partition in which it was created and is also replicated to the global catalog. Updates to the group membership are thereafter replicated to both the
domain and the global catalog.
For more information about domain functional levels, see Domain and forest functionality.


There may be instances where you will need to customize the global catalog to include additional attributes. However, you will want to carefully consider your options as
changes to attributes can impact network traffic. By default, the global catalog contains an objects most common attributes for every object in the entire forest, which
applications and users can query. For example, you can find a user by first name, last name, e-mail address, or other common properties of a user account.
To add additional searchable attributes to the global catalog, administrators can use the Active Directory Schema snap-in. For more information about adding additional
attributes to the global catalog, see Add an attribute to the global catalog.
When determining whether or not to add an attribute to the global catalog, consider only adding additional attributes that are frequently queried and referenced by users
or applications across the enterprise. Also consider how frequently an attribute gets updated during replication. Attributes that are stored in the global catalog are
replicated to every global catalog in the forest. The smaller the attribute, the lower the impact of that replication. If the attribute is large, but very seldom changes, it will
have a smaller replication impact than a small attribute that changes often.
For more information about attribute definitions, see the Active Directory Programmer's Guide at the Microsoft Web site.
Important
It is strongly recommended that you use global groups or universal groups instead of domain local groups when specifying permissions on domain directory
partition objects replicated to the global catalog. For more information, see Global catalog replication.
Notes
In Windows 2000, 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 Windows 2000 forest, this synchronization can cause significant network traffic. Between domain controllers enabled as global catalogs that are
running Windows Server 2003, only the newly added attribute is replicated.
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.


To optimize network performance in a multiple site environment, consider adding global catalogs for select sites. In a single site environment, a single global catalog is
usually sufficient to cover common Active Directory queries. The following table will help you determine whether your multiple site environment will benefit using additional
global catalogs.
Use a global catalog when
Advantage
Disadvantage
A commonly used application in the site utilizes port 3268 to resolve global catalog queries.
Performance
improvement
Additional
network traffic
due to
replication
A slow or unreliable WAN connection is used to connect to other sites. Use the same failure and load distribution rules that you used
for individual domain controllers to determine whether additional global catalog servers are necessary in each site.
Fault
tolerance
Additional
network traffic
due to
replication
Users in the site belong to a Windows 2000 domain running in native mode. In this case, all users must obtain universal group
membership information from a global catalog server. If a global catalog is not located within the same site all logon requests must
be routed over your WAN connection to a global catalog located in another site.
If a domain controller running Windows Server 2003 in the site has universal group membership caching enabled, then all users will
obtain a current cached listing of their universal group memberships.
Fast user
logons
Additional
network traffic
due to
replication
Note
Network traffic related to global catalog queries generally use more network resources than normal directory replication traffic.
Universal group membership caching

Due to available network bandwidth and server hardware limitations, it may not be practical to have a global catalog in smaller branch office locations. For these sites, you
can deploy domain controllers running Windows Server 2003, which can store universal group membership information locally.
Information is stored locally once this option is enabled and a user attempts to log on for the first time. The domain controller obtains the universal group membership for
that user from a global catalog. Once the universal group membership information is obtained, it is cached on the domain controller for that site indefinitely and is
periodically refreshed. The next time that user attempts to log on, the authenticating domain controller running Windows Server 2003 will obtain the universal group
membership information from its local cache without the need to contact a global catalog.
By default, the universal group membership information contained in the cache of each domain controller will be refreshed every 8 hours. To refresh the cache, domain
controllers running Windows Server 2003 will send a universal group membership confirmation request to a designated global catalog. Up to 500 universal group
memberships can be updated at once. Universal group membership caching can be enabled using Active Directory Sites and Services. Universal group membership
caching is site specific and requires that all domain controllers running Windows Server 2003 be located in that site to participate. For more information about how to
enable this option, see Cache universal group memberships.
The following list summarizes potential benefits for caching universal group memberships in branch office locations:
Faster logon times since authenticating domain controllers no longer need to access a global catalog to obtain universal group membership information.
No need to upgrade hardware of existing domain controllers to handle the extra system requirements necessary for hosting a global catalog.
Minimized network bandwidth usage since a domain controller will not have to handle replication for all of the objects located in the forest.
Note
You might want to continue using a global catalog in branch office locations if an application in a site is sending global catalog queries to port 3268. Universal
group membership caching does not intercept calls made to port 3268.


DNS integration
Group Policy integration
DNS integration
DNS integration
Active Directory is integrated with DNS in the following ways:
Active Directory and Domain Name System (DNS) have the same hierarchical structure.
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. For more information, see Namespace planning for DNS.
DNS zones can be stored in Active Directory.
If you are using the Windows Server 2003 DNS Server 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.
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 about how Active Directory clients rely on DNS, see Locating a domain controller.
Note
You can use Dcdiag.exe and Netdiag.exe to troubleshoot client computers that cannot locate a domain controller. These tools can help determine both server and
client DNS misconfigurations. For more information, see article Q265706, "DCDiag/NetDiag Facilitate Join and DC Creation" in the Microsoft Knowledge Base. For a
brief description of support tools, see Active Directory support tools.
While Active Directory is integrated with DNS and shares the same namespace structure, it is important to distinguish 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
domain controllers using the Lightweight Directory Access Protocol (LDAP). In order to locate a domain controller, an Active Directory client queries DNS. Active
Directory requires DNS to function.
For a checklist on deploying DNS for Active Directory, see Checklist: Deploying DNS for Active Directory.
For information about configuring DNS servers for Active Directory, see Configure a DNS server for use with Active Directory.


Group Policy can be used to define default settings that will be automatically applied to user and computer accounts in Active Directory. Policy settings can be used to
manage desktop appearance, assign scripts, redirect folders from local computers to network locations, determine security options and control what software can be
installed on particular computers and what software is available to particular groups of users.
Here are a few examples of how Group Policy settings can be used in Active Directory:
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.
Logon, logoff, startup, and shutdown scripts can be assigned based on the locations of the computer and user accounts in Active Directory.
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.
Policy settings are stored in Group Policy objects. 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 and how to create a Group Policy object, see Group Policy (pre-GPMC).
You can use security groups 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 security groups, see Group types. For general information about Group Policy, see Group Policy overview.
Understanding schema
Schema
Schema classes and attributes
Schema object names
Deactivating a class or attribute
Extending the schema
Schema
Schema
The Active Directory schema contains the definitions for all objects in the directory. Every new directory object you create is validated against the appropriate object
definition in the schema before being written to the directory. The schema is made up of object classes and attributes. The base (or default) schema contains a rich set of
object classes and attributes to meet the needs of most organizations, and is modeled after the International Standards Organization (ISO) X.500 standard for directory
services. Because it is extensible, you can modify and add classes and attributes to the base schema. However, you should carefully consider each change you make,
because extending the schema affects the entire network. For more information, see Extending the schema.
How directory objects are defined

In the schema, an object class represents a category of directory objects, such as users, printers, or application programs, that share a set of common characteristics. The
definition for each object class contains a list of the schema attributes that can be used to describe instances of the class. For example, the User class has attributes such
as givenName, surname, and streetAddress. When you create a new user in the directory the user becomes an instance of the User class, and the information you enter
about the user becomes instances of the attributes. For more information, see Schema classes and attributes.
How the schema is stored

Each forest can contain only one schema, which is stored in the schema directory partition. The schema directory partition, along with the configuration directory partition,
is replicated to all domain controllers in a forest. However, a single domain controller, the schema master, controls the structure and content of the schema. For more
information about the schema master, see Operations master roles.
Schema cache
To improve performance on schema operations (such as new object validation), each domain controller holds a copy of the schema in memory (in addition to the copy it
holds on disk). This cached version is automatically updated (after a small time interval) each time you update the schema. Or, you can reload the updated schema to cache
manually for immediate effect. For more information, see Reload the schema.
Securing the schema

Like every object in Active Directory, schema objects are protected from unauthorized use by access control lists (ACLs). By default, only members of the Schema Admins
group have write access to the schema. So, to extend the schema you must be a member of the Schema Admins group. The only default member of the Schema Admins
group is the administrator account in the root domain of the forest. You should restrict membership in the Schema Admins group because extending the schema
improperly can have serious consequences to your network. For more information, see Access control in Active Directory and Default groups.
For more information about the schema, see "Active Directory Schema" at the Microsoft Windows Resource Kits Web site and at the Microsoft MSDN Web site.


Every directory object you create is an instance of an object class contained in the schema. Each object class contains a list of associated attributes that determine the
information the object can contain. Classes and attributes are defined independently, so that a single attribute can be associated with multiple classes. All schema classes
and attributes are defined by the classSchema and attributeSchema objects, respectively.
Classes
ClassSchema objects are used to define classes in the schema. A classSchema object provides the template for building directory objects of that class. Examples of
classSchema include User and Server. A classSchema object contains, among other things, the following information:
Class type (structural, abstract, or auxiliary)

Common name and Lightweight Directory Access Protocol (LDAP) display name
Lists of the "must contain" and "may contain" attributes for instances of the object
Relative distinguished name attribute
A list of possible parent classes
Class types
Three different types of classes exist in the schema:
Class type
Purpose
Structural
Used to instantiate objects (users, servers and so on) in the directory.
Abstract
Provides templates for deriving structural classes
Auxiliary
Contains predefined lists of attributes that can be included in structural and abstract classes.
Note
With the Windows Server 2003 family, the inetOrgPerson class is now a part of base schema. This class can be used as a security principal in the same manner as
the user class.
Attributes
AttributeSchema objects are used to define attributes in the schema. An attributeSchema object determines the allowable contents and syntax for instances of that attribute
in the directory. Examples of attributeSchema include User-Principal-Name and Telex-Number. An attributeSchema object contains, among other things, the following
information:
Common name and LDAP display name

Syntax rules
Data constraints (single versus multivalued, minimum, and maximum values)
Whether and how the attribute is indexed
Single and multivalued attributes

Attributes can be single-valued or multivalued. An instance of a single-valued attribute can can only contain a single value. An instance of a multivalued attribute can contain
multiple values of uniform syntax. A multivalued attribute stores no information about ordering of the attributes it contains. Each value of a multivalue attribute must be
unique.
Indexed attributes
Both multivalued and single valued attributes can be indexed to help improve the performance of queries on that attribute. (Indexing does not apply to classes.) Attributes
are marked for indexing based on their schema definition. Indexing an attribute also allows users to use wildcards (*) as prefixes and suffixes when specifying a search
string. 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. Indexing
attributes, particularly multivalued attributes, can negatively affect replication and object creation time, as well as directory database size. So, it is recommended that you
only index commonly used attributes. For more information, see Index an attribute in Active Directory.
For more information about the schema, see "Active Directory Schema" at the Microsoft Windows Resource Kits Web site and the Microsoft MSDN Web site.
Schema object names

Schema object names

When extending the schema, you need to know how to reference schema objects. Both class and attribute schema objects can be referenced in several ways:
Lightweight Directory Access Protocol (LDAP) display name

common name
object identifier
LDAP display name

The Active Directory Schema snap-in and other administrative tools display the LDAP display name of objects. Programmers and system administrators use LDAP display
names to reference objects programmatically. The LDAP display name typically consists of two or more words combined. When the name consists of multiple words,
subsequent words in the name are identified using capitalization. Example LDAP display names are mailAddress and machinePasswordChangeInterval. The LDAP display
name is guaranteed to be unique for each object.
Common name
The common name is a more readable version of the LDAP display name. The common names of the two attributes used in the previous example are SMTP-Mail-Address
and Machine-Password-Change-Interval. Common names are guaranteed to be unique within a container.
Object identifier
An object identifier (also known as OID) is issued by an issuing authority such as the International Organization for Standardization (ISO) or 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 must be unique. For more
information about ISO, see the International Organization for Standardization Web site.
When extending your schema, you can register new object identifiers through Microsoft. For more information, see the Microsoft Web site.
Schema object naming rules

To help standardize schema naming conventions, Microsoft strongly suggests that schema extensions adhere to naming rules for both the LDAP Display Name and the
Common Name. To qualify as "Certified for Windows," an application that extends the schema must adhere to these naming rules. For more information, see the Active
Directory chapter of the certification program documentation at the Microsoft Web site. See also the Active Directory Programmer's Guide at the Microsoft Web site.
Message queuing aliases

A message queuing alias is an object in Active Directory that can be used to reference queues which might not be listed in Active Directory. For example, a queuing alias
can be used to reference a private queue within the context of a distribution list. You can create a queuing alias by using Active Directory Users and Computers. Using
queuing aliases provides the following benefits:
When a queuing alias object is deleted, the alias is automatically removed from all distribution lists that reference the alias.
A queue referenced by a queuing alias can be changed without changing the alias.
Queuing aliases can be used to reference a queue not listed in the directory service, including private queues or queues from another organization.
Queuing aliases can be used to send http messages by referencing the destination queue using a direct format name.
A queuing alias object has a single attribute, a format name that references a queue. Queuing aliases can contain public, private, and direct format names. The format
name for the queue cannot exceed 255 characters. For more information, see Using Message Queuing.
Note


Domain controllers running Windows Server 2003 do not permit the deletion of classes or attributes, but they can be deactivated if they are no longer needed or if there
was an error in the original definition. A deactivated class or attribute is considered defunct. A defunct class or attribute is unavailable for use; however, it is easily
reactivated.
If your forest has been raised to the Windows Server 2003 functional level, you can reuse the object identifier (governsId and attributeId values), the ldapDisplayName, and
the schemaIdGUID that were associated with the defunct class or attribute. This allows you to change the object identifier associated with a particular class or attribute. The
only exception to this is that an attribute used as a rdnAttId of a class continues to own its attributeId, ldapDisplayName, and schemaIdGuid values even after being
deactivated (for example, those values cannot be reused).
If your forest has been raised to the Windows Server 2003 functional level, you can deactivate a class or attribute and then redefine it. For example, the Unicode String
syntax of an attribute called SalesManager could be changed to Distinguished Name. Since Active Directory does not permit you to change the syntax of an attribute after
it has been defined in the schema, you can deactivate the SalesManager attribute and create a new SalesManager attribute that reuses the same object identifier and LDAP
display name as the old attribute, but with the desired attribute syntax. You must rename the deactivated attribute before it can be redefined.
For more information about forest functionality, see Domain and forest functionality.
Notes
Classes and attributes added to the base schema can be deactivated without raising the forest functional level. However, they can be redefined only in forests raised
to the Windows Server 2003 functional level or higher.
Default schema attributes or classes in the base schema cannot be deactivated if bit 4 of the systemFlags attribute is set to 1. Only attributes or classes where bit 4
of the systemFlags attribute is equal to zero can be deactivated.
Object identifiers must be unique. Mistyping a number when entering an object identifier can cause a conflict between the invalid object identifier and a legitimate object
identifier that is registered by an application. When installing an application that adds an attribute or class, the application may need to use the mistyped object identifier
for one of its legitimate schema extensions. You can correct object identifier conflicts in forests that are set to the Windows Server 2003 functional level. To correct the
conflict, deactivate the attribute or class with the incorrect object identifier. The application installation program will then be able to create the new attribute or class using
the correct object identifier.
Before deactivating a class, consider the following:
You can deactivate a class only if that class is not specified as a subClassOf, auxiliaryClass, systemAuxiliaryClass, possSuperiors, or systemPossSuperiors of any
existing active class.
You cannot use a defunct class in definitions of new classes, and you cannot add it to existing class definitions.
You cannot create objects that are instances of the defunct class or modify existing instances of the class. However, the instances of the defunct class become
available again for modification when the defunct class is reactivated.
Before deactivating an attribute, consider the following:
You can deactivate an attribute only if the attribute is not specified as a systemMustContain, mustContain, systemMayContain, mayContain, or rdnAttId of any existing
active class.
You cannot use a defunct attribute in definitions of new classes, and you cannot add it to existing class definitions.
You cannot read, modify, or delete instances of the defunct attribute present in existing objects. However, the instances of the defunct attribute become available
when the defunct attribute is reactivated.
To purge the directory of instances of an attribute you must delete the instances before deactivating the attribute.
Classes and attributes can be deactivated programmatically (recommended) or by using the Active Directory Schema snap-in. To deactivate a class or attribute using the
Active Directory Schema snap-in, 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.
Reactivating a class
A defunct class can be reactivated. However, a defunct class cannot be reactivated unless the attributes referenced in its mustContain, systemMustContain, mayContain, and
systemMayContain properties are active and the classes referenced in its subClassOf, auxiliaryClass, systemAuxiliaryClass, possSuperiors, and systemPossibleSuperiors
properties are also active.
Further, a defunct class cannot be reactivated if the values of the following attributes collide with an already active attribute or class: ldapDisplayName, attributeId,
governsId, or schemaIdGuid.
To reactive a defunct class, see Reactivate a class or attribute.
Reactivating an attribute
An defunct attribute can be reactivated. However, a defunct attribute cannot be reactivated if the values of the following attributes collide with an already active attribute or
class: ldapDisplayName, attributeId, governsId, schemaIdGuid, or mapiId.
To reactive a defunct attribute, see Reactivate a class or attribute.



When the set of classes and attributes in the base Active Directory schema do not meet your needs, you can extend the schema by modifying or adding classes and
attributes. You should only extend the schema when absolutely necessary. The easiest way to extend the schema is through the Schema Microsoft Management Console
(MMC) snap-in. You should always develop and test your schema extensions in a test lab before moving them to your production network.
Before extending the schema

Before extending the schema, review these key points:
Check the base schema first
Verify that no existing class or attribute in the base schema meets your application or data needs. For the complete set of classes and
attributes in the base schema, see the Microsoft Web site.
Review schema
documentation
For detailed information about extending the schema, see the Active Directory Programmer's Guide at the Microsoft Web site and
"Active Directory Schema" at the Microsoft Windows Resource Kits Web site.
Schema modifications are

global
When you extend the schema, the changes apply to every domain controller in the entire forest.
Schema classes related to

the system cannot be
modified
You cannot modify default system classes (those classes required for Windows to run) within the schema. However, directory-enabled
applications that modify the schema may add new classes that you can modify.
Schema extensions are not

reversible
Attributes or classes cannot be removed after creation. At best, they can be modified or deactivated. For more information, see
Deactivating a class or attribute.
Obtain valid object

identifiers
Every class and attribute in the schema must have a unique and valid object identifier (also known as OID). Do not create arbitrary object
identifiers or recycle old object identifiers. For information about obtaining valid object identifiers, see Schema object names.
Document your changes
If you do decide to extend the schema, be sure to document your changes.
How to extend the schema

You can modify the schema through graphical user interface (GUI) tools, command-line tools, and through scripting. The easiest way to modify the schema is by using the
Active Directory Schema snap-in in Microsoft Management Console (MMC), which is a GUI tool for schema management. For information about installing the Active
Directory Schema snap-in, see Install the Active Directory Schema snap-in. Modifying the schema through scripting requires programming knowledge and familiarity with
the Active Directory Service Interfaces (ADSI). For more information, see the Active Directory Programmer's Guide and Extending the Schema at the Microsoft MSDN Web
site.
For more information about schema administration tools, see Administration tools for the Active Directory schema.
For more information about extending the schema, see Modify an existing schema class or attribute definition and Add a new schema class or attribute definition. For
information about deactivation and reactivation, see Deactivating a class or attribute, Deactivate a class or attribute and Reactivate a class or attribute.
Using a test forest

A very simple way to avoid damaging or costly schema mistakes in your production forest is to first test your schema extensions on a test forest. By using a test
environment, you can identify any potential problems in your plan before they affect your users and your production environment.
After making schema changes in a test forest, you can reinstall the default schema by demoting each domain controller in the test forest to which the schema changes have
replicated. Then, use the Active Directory Installation Wizard to reinstall Active Directory on the servers. This procedure is practical only in a test environment.
Active Directory Concepts

Concepts
This section provides general background information about Active Directory:
Active Directory Overview

Deploying Active Directory
Administering Active Directory
Active Directory Resources
Active Directory Overview

Active Directory overview

A directory is a hierarchical structure that stores information about objects on the network. A directory service, such as Active Directory Domain Services (AD DS), provides
the methods for storing directory data and making this data available to network users and administrators. For example, AD DS 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.
Introduction to Active Directory

New features for Active Directory
Security information for Active Directory


Active Directory can be installed on servers running Microsoft Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows
Server 2003, Datacenter Edition. Active Directory stores information about objects on the network and makes this information easy for administrators and users to find and
use. Active Directory uses a structured data store as the basis for a logical, hierarchical organization of directory information.
This data store, also known as the directory, contains information about Active Directory objects. These objects typically include shared resources such as servers, volumes,
printers, and the network user and computer accounts. For more information about the Active Directory data store, see Directory data store.
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. For more information about Active Directory security, see Security overview.
Active Directory also includes:
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 Schema.
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 The role of the 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 overview.
Support for Active Directory client software, which makes many features on Microsoft Windows 2000 Professional or Windows XP Professional available to
computers running Windows 95, Windows 98, and Windows NT Server 4.0. To client computers not running Active Directory client software, the directory will
appear like a Windows NT directory. For more information about client software, see Active Directory clients.
Note
You cannot install Active Directory on a server running Windows Server 2003, Web Edition, but you can join the server to an Active Directory domain as a member
server. For more information about Windows Server 2003, Web Edition, see Overview of Windows Server 2003, Web Edition.
New features for Active Directory

New Active Directory features in Windows Server 2003 with Service Pack 1 (SP1)
The following list summarizes the Active Directory features that are new since the original release of Windows Server 2003.
Directory service backup reminders. A new event message, event ID 2089, provides the backup status of each directory partition that a domain controller stores,
including application directory partitions and Active Directory Application Mode (ADAM) partitions. If halfway through the tombstone lifetime a partition has not
been backed up, this event is logged in the Directory Service event log and continues daily until the partition is backed up.
Added replication security and fewer replication errors. Replication metadata for domain controllers from which Active Directory has been removed is no longer
retained by default, although a waiting period can be configured. This change improves replication security and eliminates replication error messages that are
caused by failed attempts to replicate with decommissioned domain controllers. For more information about preserving replication metadata, see How the
Active Directory Replication Model Works.
Install from Media improvement for installing DNS servers. Install from Media improvements make it easier to create a new domain controller that is a Domain
Name System (DNS) server by providing a new option to include application directory partitions in the backup media that is used to install the new domain
controller. This option eliminates the requirement for replication of the DomainDNSZones and ForestDNSZones application directory partitions before the DNS
server is operational.
Enhancements for replication and DNS testing. The Dcdiag.exe command-line tool, which is available in Windows Support Tools, provides new reporting on the
overall health of replication with respect to Active Directory security. This test provides a summary of results, along with detailed information for each domain
controller that is tested and a diagnosis of any security errors. Dcdiag.exe also has new DNS tests for connectivity, service availability, forwarders and root hints,
delegation, dynamic update, locator record registrations, external name resolution, and enterprise infrastructure. These tests can be performed on one domain
controller or on all domain controllers in a forest. For more information about using Dcdiag.exe, see Windows Support Tools Help.
Support for running domain controllers in virtual machines. On a single physical server that is running Windows Server 2003 and Microsoft Virtual Server 2005,
you can install multiple Windows Server 2003 or Windows 2000 Server domain controllers in separate virtual machines. This platform is well suited for test
environments. By using virtual machines, you can effectively host multiple domains, multiple domain controllers for the same domain, or even multiple forests on one
physical server that is running a single operating system. Windows Server 2003 SP1 also provides protection against directory corruption that can result from
improper backup and restore of domain controller images. For more information about running domain controllers in virtual machines, see Running Domain
Controllers in Virtual Server 2005.
Operations master health and status reporting. If an operation that requires a domain controller that holds an operations master role (also known as flexible
single-master operations (FSMO)) cannot be performed, events are now logged in the Directory Service event log. Events identify role holders that do not exist, exist
but are not available, or are available but have not replicated recently with the contacting domain controller. For more information about operations masters, see
How Operations Masters Work.
Extended storage of deleted objects. The default period that a copy of a deleted object is retained in Active Directory, called the tombstone lifetime, is extended
from 60 days to 180 days. Longer tombstone lifetime decreases the chance that a deleted object remains in the local directory of a disconnected domain controller
beyond the time when the object is permanently deleted from online domain controllers. The tombstone lifetime is not changed automatically when you upgrade to
Windows Server 2003 with SP1, but you can change the tombstone lifetime manually after the upgrade. New forests that are installed with Windows Server 2003 with
SP1 have a default tombstone lifetime of 180 days. For more information about tombstone lifetime, see How the Data Store Works.
Improved domain controller name resolution. In response to DNS name resolution failures that may be encountered during location of replication partners and
global catalog servers, domain controllers running Windows Server 2003 with SP1 request other variations of the server name that might be registered, which
results in fewer failures due to DNS delays and misconfiguration. For more information about DNS name resolution, see How DNS Support for Active Directory
Works.
Improved server metadata removal. The Ntdsutil.exe command-line tool for managing the Active Directory database has new functionality that makes it easier to
remove domain controller metadata. Preliminary steps, such as connecting to a server, domain, and site, are no longer required. You simply specify the server to
remove. You can also specify the server on which to perform the deletion. Metadata removal is now more comprehensive: in addition to Active Directory replication
metadata, the tool now removes File replication service (FRS) metadata and operations master metadata. If an operations master role is assigned to the server that
is being removed, the tool attempts to transfer the role to an appropriate domain controller. For more information, see Delete extinct server metadata.
Improved security to protect confidential attributes. To prevent Read access to confidential attributes, such as a Social Security number, while allowing Read
access to other object attributes, you can designate specific attributes as confidential by setting a search flag on the respective attributeSchema object. By default,
only domain administrators have Read access to confidential attributes, but this access can be delegated. For more information about access to attributes, see How
Security Descriptors and Access Control Lists Work.
Retention of SID history on tombstones. The sIDHistory attribute has been added to the set of attributes that are retained on an object tombstone when the
object is deleted. If a tombstoned object is reactivated (undeleted), the sIDHistory attribute is now restored with the object. For more information about
tombstones, see How the Data Store Works.
Adprep.exe improvements for Windows 2000 Server upgrades. The Adprep tool has been improved to reduce the impact of FRS synchronization that results
from updating SYSVOL files during upgrade. Adprep is used to upgrade the Windows 2000 Server schema to the Windows Server 2003 schema and to update
some forest- and domain-specific configuration, including SYSVOL, that is required for a Windows Server 2003 domain controller to be operational. The tool now
allows performing SYSVOL operations in a separate step when the domain is prepared for upgrade. A new switch, /gpprep, has been added to accommodate the
SYSVOL updates, which can be performed at a convenient time following the upgrade. The adprep /domainprep command, which formerly performed both
directory and SYSVOL updates, now updates only the directory. Adprep also now detects third-party schema extensions that block an upgrade, identifies the
blocking extensions, and recommends fixes. Microsoft Exchange schema objects are also detected so that the Exchange schema can be prepared appropriately to
accommodate inetOrgPerson naming. For more information about Adprep.exe, see Adprep.
Improved authoritative restore. The authoritative restore option in Ntdsutil now locates backlinks for all objects that are authoritatively restored, including links
that were created before implementation of the Windows Server 2003 or Windows Server 2003 interim forest functional level, in which linked-value replication (LVR)
functionality was introduced. For example, suppose that a user object is restored and the user belongs to group G1, which was created before the forest functional
level was raised, and the user also belongs to group G2, which was created after the forest functional level was raised. During authoritative restore of the user
object, the member attribute of G2 is updated, but not the member attribute of G1. Ntdsutil now creates a text file that identifies the authoritatively restored objects
and uses this file to create an LDAP Data Interchange Format (LDIF) file that can be used to restore all backlinks for pre-LVR groups in this domain. In the example,
when this LDIF file is run after authoritative restore, the restored user is added to group G1. A new option in authoritative restore also allows you to generate an
LDIF file that you can use to restore links in other domains in which a restored object has backlinks.
New Active Directory features in Windows Server 2003

With the new Active Directory features available in Microsoft Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows
Server 2003, Datacenter Edition, more efficient administration of Active Directory is available to you.
The following list summarizes the Active Directory features that are available by default on any domain controller running Windows Server 2003.
Multiple selection of user objects. Modify common attributes of multiple user objects at one time.
Drag-and-drop functionality. Move Active Directory objects from container to container by dragging one or more objects to a desired location in the domain
hierarchy. You can also add objects to group membership lists by dragging one or more objects (including other group objects) to the target group.
Efficient search capabilities. Search functionality is object-oriented and provides an efficient search that minimizes network traffic associated with browsing objects.
For more information, see Finding directory information.
Saved queries. Save commonly used search parameters for reuse in Active Directory Users and Computers. For more information, see Using saved queries.
Active Directory command-line tools. Run new directory service commands for administration scenarios. For more information, see Managing Active Directory
from the command line.
InetOrgPerson class. The inetOrgPerson class has been added to the base schema as a security principal and can be used in the same manner as the user class.
The userPassword attribute can also be used to set the account password. For more information, see User and computer accounts.
Application directory partitions. Configure the replication scope for application-specific data among domain controllers. For example, you can control the
replication scope of Domain Name System (DNS) zone data stored in Active Directory so that only specific domain controllers in the forest participate in DNS zone
replication. For more information, see Application directory partitions.
Ability to add additional domain controllers using backup media. Reduce the time it takes to add an additional domain controller in an existing domain by using
backup media. For more information, see Using the Active Directory Installation Wizard.
Universal group membership caching. Prevent the need to locate a global catalog across a wide area network (WAN) when logging on by storing universal group
membership information on an authenticating domain controller. For more information, see Global catalogs and sites.
Secure LDAP traffic. Active Directory administrative tools sign and encrypt all Lightweight Directory Access Protocol (LDAP) traffic by default. Signing LDAP traffic
guarantees that the packaged data comes from a known source and that it has not been tampered with. For more information, see Connecting to domain
controllers running Windows 2000.
Active Directory quotas. Quotas can be specified in Active Directory to control the number of objects a user, group, or computer can own in a given directory
partition. Domain Administrators and Enterprise Administrators are exempt from quotas.
New domain- and forest-wide Active Directory features

New domain- or forest-wide Active Directory features can be enabled only when all domain controllers in a domain or forest are running Windows Server 2003 and the
domain functionality or forest functionality has been set to Windows Server 2003. For more information about domain and forest functionality settings, see Domain and
forest functionality.
The following list summarizes the domain- and forest-wide Active Directory features that can be enabled when either a domain or forest functional level has been raised to
Windows Server 2003.
Domain controller rename tool. Rename domain controllers without first demoting them. For more information, see Renaming domain controllers.
Domain rename. Rename any Windows Server 2003 domain. You can change the NetBIOS name or DNS name of any child, parent, tree, or forest root domain. For
more information, see Renaming domains.
Different location option for user and computer accounts. You can now redirect the default location for user accounts and computer accounts that are created
by the following application programming interfaces (APIs): NetUserAdd, NetGroupAdd, and NetJoinDomain. You can redirect the location of the accounts from the
Users and Computers containers to organizational units (OUs) where Group Policy settings can be applied. For more information, see Redirect the Users and
Computers Containers.
Forest trusts. Create a forest trust to extend two-way transitivity beyond the scope of a single forest to a second forest. For more information, see Forest trusts.
Forest restructuring. Move existing domains to other locations in the domain hierarchy. For more information, see Renaming domains.
Defunct schema objects. Deactivate unnecessary classes or attributes from the schema. For more information, see Deactivating a class or attribute.
Dynamic auxiliary classes. Provides support for dynamically linking auxiliary classes to individual objects, and not just to entire classes of objects. In addition,
auxiliary classes that have been attached to an object instance can subsequently be removed from the instance.
Global catalog replication improvements. Preserves the synchronization state of the global catalog when an administrative action results in an extension of the
partial attribute set. This minimizes the replication traffic as a result of a partial attribute set extension by only transmitting attributes that were added. For more
information, see Global catalog replication.
Replication enhancements. Linked-value replication allows individual group members to be replicated across the network instead of treating the entire group
membership as a single unit of replication. For more information about linked-value replication, see How replication works. In addition, new spanning tree
algorithms make replication more efficient, as well as more scalable across a larger number of domains and sites in both Windows 2000 and Windows Server 2003
forests. For more information, see Replication overview.
User access control to resources between domains or forests. Block users in a domain or forest from accessing resources in another domain or forest, and then
allow selective access by setting the Allow to authenticate access control entry (ACE) on a local resource for the user or group object. For more information, see
Accessing resources across domains or Accessing resources across forests.


Active Directory provides a secure directory environment for your organization using built-in logon authentication and user authorization, which are core features of the
Local Security Authority (LSA). Logon authentication and user authorization are available by default and provide immediate protection for network access and network
resources.
For information about additional security tools and features that you can use to further secure Active Directory, see Securing Active Directory and Active Directory Best
practices.
Protecting access to the network

Active Directory requires confirmation of the identity of a user before allowing access to the network, a process known as authentication. Users only need to provide a
single sign-on to the domain (or to trusted domains) to gain access to the network. Once Active Directory confirms the identity of the user, the LSA on the authenticating
domain controller generates an access token that determines what level of access that user has on network resources. For more information about the authentication
process, see Access control in Active Directory and Certificates and Authentication.
Active Directory supports a number of secure Internet-standard protocols and authentication mechanisms used to prove identity upon logon, including Kerberos V5, X.509
v3 certificates, smart cards, public key infrastructure (PKI) and Lightweight Directory Access Protocol (LDAP) using Secure Sockets Layer (SSL).
Authentication between domains occurs through trusts. A trust is a relationship established between two or more domains to allow users in one domain to be
authenticated by a domain controller in another domain.
Trust relationships can be transitive or nontransitive but must always be present in order for users in one domain to access shared resources in another domain. For more
information, see Trusts.
In addition to securing network access through authentication, Active Directory helps to protect shared resources by facilitating user authorization. Once a user logon has
been authenticated by Active Directory, the user rights assigned to the user through security groups and the permissions assigned on the shared resource will determine if
the user will be authorized to access that resource. This authorization process protects shared resources from unauthorized access and permits access to only authorized
users or groups.
For more information about user rights and security groups, see Group types. For more information about the user rights assigned to default groups, see Default groups.
For more information about authorization, see "Designing an Authorization Strategy" at the Microsoft Windows Resource Kits Web site.
For more information about authentication, see "Logon and Authentication" at the Microsoft Windows Resource Kits Web site. For more information about authorization
and access control, see "Authorization and Access Control" at the Microsoft Windows Resource Kits Web site.


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.

Object names


Active Directory provides a secure directory environment for your organization using built-in logon authentication and user authorization. To further secure Active Directory
once it has been deployed, consider the following precautions and recommendations.
For general security information about Active Directory, see Security information for Active Directory.
For more information about authentication, see "Logon and Authentication" at the Microsoft Windows Resource Kits Web Site. For more information about authorization,
see "Authorization and Access Control" at the Microsoft Windows Resource Kits Web Site.
Important
Physical access to a domain controller can provide a malicious user unauthorized access to encrypted passwords. Therefore, it is recommended that all domain
controllers be locked in a secured room with limited public access. In addition, you should limit membership in the Enterprise Admins, Domain Admins, Account
Operators, Server Operators, Print Operators, and Backup Operators groups to trusted personnel in your organization. For more information about domain
controllers and groups, see Domain controllers and Default groups.
To
Use
Manage the security relationship between two forests and simplify security administration and
authentication across forests.
Forest trusts
See Forest trusts.
Force domain users to use strong passwords.
Group Policy
See Strong passwords.
Enable audit policy. Auditing event logs can notify you of actions that could pose a security
risk.
Group Policy
See Auditing Policy.
Assign user rights to new security groups so you can specifically define a user's administrative
role in the domain.
Group Policy
See Group types.
Enforce account lockouts on user accounts and decrease the possibility of an attacker
compromising your domain through repeated logon attempts.
Group Policy
See User and computer accounts.
Enforce password history on user accounts and decrease the possibility of an attacker
compromising your domain.
Group Policy
See Enforce password history.
Enforce minimum and maximum password ages on user accounts and decrease the possibility
of an attacker compromising your domain.
Group Policy
See Minimum password age, Maximum password age.
Verify and authenticate the validity of each user through the use of public key cryptography.
Public key infrastructure

See Deploying a Public Key Infrastructure.
Promote a secure operating environment by running your computer without administrative

credentials except when required.
Run as
See Using Run as.
Restrict user, group, and computer access to shared resources and filter Group Policy settings.
Security groups
See Group types.
Prevent attacks from malicious users who might try to grant elevated user rights to another
user account.
SID filtering
See "Using Security Identifier (SID) Filtering to Prevent Elevation of
Privilege Attacks" at the Microsoft Web Site.
Provide tamper-resistant user authentication and e-mail security.
Smart cards
See Smart cards overview.
Use strong encryption techniques to secure account password information on local computers,
member servers, or domain controllers.
Syskey
See The system key utility.


Administrators can use access control to manage user access to shared resources for security purposes. In Active Directory, access control is administered at the object
level by setting different levels of access, or permissions, to objects, such as Full Control, Write, Read, or No Access. Access control in Active Directory defines how different
users can use Active Directory objects. By default, permissions on objects in Active Directory are set to the most secure setting.
The elements that define access control permissions on Active Directory objects include security descriptors, object inheritance, and user authentication.
Security descriptors
Access control permissions are assigned to shared objects and Active Directory objects to control how different users can use each object. A shared object, or shared
resource, is an object that is intended to be used over a network by one or more users and includes files, printers, folders, and services. Both shared objects and Active
Directory objects store access control permissions in security descriptors.
A security descriptor contains two access control lists (ACLs) used to assign and track security information for each object: the discretionary access control list (DACL) and
the system access control list (SACL).
Discretionary access control lists (DACLs). DACLs identify the users and groups that are assigned or denied access permissions on an object. If a DACL does not
explicitly identify a user, or any groups that a user is a member of, the user will be denied access to that object. By default, a DACL is controlled by the owner of an
object or the person who created the object, and it contains access control entries (ACEs) that determine user access to the object.
System access control lists (SACLs). SACLs identify the users and groups that you want to audit when they successfully access or fail to access an object. Auditing is
used to monitor events related to system or network security, to identify security breaches, and to determine the extent and location of any damage. By default, a
SACL is controlled by the owner of an object or the person who created the object. A SACL contains access control entries (ACEs) that determine whether to record
a successful or failed attempt by a user to access a object using a given permission, for example, Full Control and Read.
For more information about auditing, see Auditing settings on objects.
To view DACLs and SACLs on Active Directory objects using Active Directory Users and Computers, on the View menu, click Advanced Features to access the Security tab
for each object. For more information, see Assign, change, or remove permissions on Active Directory objects or attributes. You can also use the DSACLS support tool to
manage access control lists in Active Directory. For more information, see Active Directory support tools.
By default, DACLs and SACLs are associated with every Active Directory object, which reduces attacks to your network by malicious users or any accidental mistakes made
by domain users. However, if a malicious user obtains a user name and password of any account with administrative credentials to Active Directory, your forest will be
vulnerable to attack. For this reason, consider renaming or disabling the default administrator account and following the best practices as described in Active Directory
Best practices.
Object inheritance
By default, Active Directory objects inherit ACEs from the security descriptor located in their parent container object. Inheritance enables the access control information
defined at a container object in Active Directory to apply to the security descriptors of any subordinate objects, including other containers and their objects. This eliminates
the need to apply permissions each time a child object is created. If necessary, you can change the inherited permissions. However, as a best practice, avoid changing the
default permissions or inheritance settings on Active Directory objects. For more information, see Best practices for assigning permissions on Active Directory objects and
Changing inherited permissions.
User authentication
Active Directory also authenticates and authorizes users, groups, and computers to access objects on the network. The Local Security Authority (LSA) is the security
subsystem responsible for all interactive user authentication and authorization services on a local computer. The LSA is also used to process authentication requests made
through the Kerberos V5 protocol or NTLM protocol in Active Directory. For more information about Kerberos authentication, see Kerberos V5 authentication. For more
information about NTLM authentication, see NTLM authentication.
Once the identity of a user has been confirmed in Active Directory, the LSA on the authenticating domain controller generates a user access token and associates a security
ID (SID) with the user.
Access token. When a user is authenticated, LSA creates a security access token for that user. An access token contains the user's name, the groups to which that
user belongs, a SID for the user, and all of the SIDs for the groups to which the user belongs. If you add a user to a group after the user access token has been
issued, the user must log off and log on again before the access token will be updated.
Security ID (SID). Active Directory automatically assigns SIDs to security principal objects at the time they are created. Security principals are accounts in Active
Directory that can be assigned permissions such as computer, group, or user accounts. Once a SID is issued to the authenticated user, it is attached to the access
token of the user.
The information in the access token is used to determine a user's level of access to objects whenever the user attempts to access them. The SIDs in the access token are
compared with the list of SIDs that make up the DACL for the object to ensure that the user has sufficient permission to access the object. This is because the access
control process identifies user accounts by SID rather than by name.
Important
When a domain controller provides an access token to a user, the access token only contains information about membership in domain local groups if the domain
local groups are local to the domain controller's domain. For domain directory objects replicated in the global catalog, this fact requires certain security
considerations. For more information, see Global catalog replication.
For more information about authentication, see "Logon and Authentication" at the Microsoft Windows Resource Kits Web site.
For more information about access control and permissions, see Access control overview. For more information about authorization and access control, see "Authorization
and Access Control" at the Microsoft Windows Resource Kits Web site.
For information about additional security measures that can be implemented to protect Active Directory, see Securing Active Directory and Security information for Active
Directory.


Active Directory domain names are usually the full Domain Name System (DNS) name of the domain. However, for backward compatibility, each domain also has a preWindows 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
Server 2003 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 Server 2003 domain from computers running Windows 2000, Windows XP, or servers running Windows Server 2003. Users can also log on to computers
running Windows 2000, Windows XP, or servers running Windows Server 2003 using the user principal name (UPN) 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 UPN suffix. The
administrator enters the user logon name and selects the UPN 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 UPN based on IETF RFC 822, Standard for the Format of ARPA Internet Text Messages. The UPN is composed of the user logon
name and the UPN suffix joined by the @ sign.
Note
Do not add the @ sign to the user logon name or to the UPN suffix. Active Directory automatically adds it when it creates the UPN. A UPN that contains more than
one @ sign is invalid.
Important
Windows NT 4.0 and earlier domains allowed the use of a period (.) at the end of a user logon name as long as the user logon name did not consist solely of
period characters. Windows Server 2003 domains do not allow the use of a period or multiple periods at the end of a user logon name.
The second part of the UPN, the UPN suffix, identifies the domain in which the user account is located. This UPN 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 log on purposes. This alternative UPN suffix does not need to be a
valid DNS name.
In Active Directory, the default UPN suffix is the DNS name of the domain in which user account created. In most cases, this is the domain name registered as the enterprise
domain on the Internet. Using alternative domain names as the UPN 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 UPN 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 UPN 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 User and
computer accounts and Object names.
You can add or remove UPN suffixes using Active Directory Domains and Trusts. For more information, 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 (SPN). The administrator enters the computer name when creating the computer account. This
computer name is used as the Lightweight Directory Access Protocol (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 DNS name for a host is called a full computer name and is a DNS fully qualified domain name (FQDN). The full computer name is a concatenation of the computer
name (the first 15 bytes of the SAM account name of the computer account without the "$" character) and the primary DNS suffix (the DNS domain name of the domain in
which the computer account exists). It is listed on the Computer Name tab in System Properties in Control Panel.
By default, the primary DNS suffix portion of the FQDN for a computer must be the same as the name of the Active Directory domain where the computer is located. To
allow different primary DNS suffixes, a domain administrator may create a restricted list of allowed suffixes by creating the msDS-AllowedDNSSuffixes attribute in the
domain object container. This attribute is created and managed by the domain administrator using Active Directory Service Interfaces (ADSI) or the Lightweight Directory
Access Protocol (LDAP).
For more information, see Object names and User and computer accounts.
The service principal name (SPN) is a multivalue attribute. It is usually built from the DNS name of the host. The SPN 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 SPN of the service to which it is trying to connect. The SPN can be
modified by members of the Domain Admins group.


The Active Directory directory service uses a data store for all directory information. This data store is often 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 entire domain in which it is located. Changes made to the directory on one domain controller are replicated to other domain
controllers in the domain, domain tree, or forest. Active Directory uses four distinct directory partition types to store and copy different types of data. Directory partitions
contain domain, configuration, schema, and application data. This storage and replication design provides directory information to users and administrators throughout
the domain.
Directory data is stored in the Ntds.dit file on the domain controller. It is recommended that you store this file on an NTFS partition. For more information about the tool
used to manage the Active Directory database and log files, see Files in Ntdsutil. 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. For more information about replication, see Replication overview.
Directory data replicated between domain controllers includes the following:
Domain data
The domain data holds information about objects within a domain. This is 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. Domain controllers running Windows Server 2003 include 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 more information, see Schema.
Application data
Data stored in the application directory partition is intended to satisfy cases where information needs to be replicated but not necessarily on a global scale.
Application directory partitions are not part of the directory data store by default; they must be created, configured, and managed by the administrator.
For more information, see Application directory partitions.
Note
If a 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 The role of the global catalog.
Quotas and directory partitions

Quotas, a new feature with domain controllers running Windows Server 2003 , determine the number of objects that can be owned in a given directory partition by a
security principal. (The owner of an object is usually, but not always, the creator of the object.) Quotas can help prevent the denial of service that can occur if a security
principal accidentally, or intentionally, creates objects until the affected domain controller runs out of storage space.
Quotas are specified and administered for each directory partition separately. The schema partition, however, has no quotas. On a given directory partition, you can assign
quotas for any security principal, including users, inetOrgPersons, computers, and groups. Members of the Domain Admins and Enterprise Admins groups are exempt
from quotas. In some cases, a security principal might be covered by multiple quotas. For example, a user might be assigned an individual quota, and also belong to one
or more security groups that also have quotas assigned to them. In such cases, the effective quota is the maximum of the quotas assigned to the security principal.
If a security principal is not assigned a quota either directly or through a group membership, a default quota on the partition governs the security principal. If you do not
explicitly set the default quota on a given partition, the default quota of that partition is unlimited (ie, there is no limit).
Tombstone objects owned by a security principal are also counted as part of the quota consumption of that security principal. For each partition, you can specify a
tombstone quota factor to determine the percentage weight given to a tombstone object in quota accounting. For example, if the tombstone quota factor for a given
partition is set to 25 or 25%, then a tombstone object on the partition is counted as 0.25 or of a normal object. If a quota of 100 is specified for a user on this
partition, then the user could own a maximum of 100 normal objects, or a maximum 400 tombstone objects. The default tombstone quota factor for each partition is
initially set to 100 (or 100%), meaning that normal and tombstones objects are weighted equally.
The following example illustrates how quotas can be used. Consider the domain "sales.northwindtraders.com." Because this domain supports a lot of printing activity, the
domain contains several print servers that each support 1,000 or more print queues. Initially, the default quota of the sales.northwindtraders.com domain partition is set to
unlimited. To help control the number of objects created and owned, the administrator specifies a default quota of 500. Now, each user can own a maximum of 500
objects on the partition. Because print queues are directory objects that are created and owned by the respective print servers, the new default quota of 500 limits each
print server to 500 print queues. To remove this constraint, the administrator creates a group called "Print Servers" and adds the computer account of each print server to
the group. The administrator then specifies a quota of 2,000 for the Print Servers group. Now, each print server can support its original number of print queues, while the
default quota continues to prevent excess object creation by all other security principals.
Only domain controllers running Windows Server 2003 can enforce quotas. Quotas are enforced only on originating directory operations; quotas are not enforced on
replicated operations. In order for quotas to be fully effective for any given directory partition, all domain controllers that contain a writable copy of that partition must be
running Windows Server 2003 . Therefore, for quotas to be effective on a domain directory partition, all domain controllers in that domain must be running Windows
Server 2003 . For quotas to be effective on the configuration partition, all domain controllers in the forest must by running Windows Server 2003 .
For information about creating, modifying, and querying quotas, default quotas, and tombstone quota factors, see Dsadd, Dsmod, and Dsquery.


Active Directory clients must communicate with domain controllers when logging on 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. 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 Internet Engineering Task Force Web site.
Note

Updated: July 26, 2013

Active Directory user accounts and computer accounts represent a physical entity such as a computer or person. User accounts can also be used as dedicated service
accounts for some applications.
User accounts and computer accounts (as well as groups) are also referred to as security principals. Security principals are directory objects that are automatically
assigned security IDs (SIDs), which can be used to access domain resources. A user or computer account is used to:
Authenticate the identity of a user or computer.

A user account enables a user to log on to computers and domains with an identity that can be authenticated by the domain. For information about authentication,
see Access control in Active Directory. Each user who logs on to the network should have his or her own unique user account and password. To maximize security,
you should avoid multiple users sharing one account.
Authorize or deny access to domain resources.
Once the user has been authenticated, the user is authorized or denied access to domain resources based on the explicit permissions assigned to that user on the
resource. For more information, see Security information for Active Directory.
Administer other security principals.
Active Directory creates a foreign security principal object in the local domain to represent each security principal from a trusted external domain. For more
information about foreign security principals, see When to create an external trust.
Audit actions performed using the user or computer account.
Auditing can help you monitor account security. For more information about auditing, see Auditing overview.
User accounts
The Users container located in Active Directory Users and Computers displays the three built-in user accounts: Administrator, Guest, and HelpAssistant. These built-in user
accounts are created automatically when you create the domain.
Each built-in account has a different combination of rights and permissions. The Administrator account has the most extensive rights and permissions over the domain,
while the Guest account has limited rights and permissions. The table below describes each default user account on domain controllers running Windows Server 2003.
Default user
account
Administrator
account
Description
The Administrator account has full control of the domain and can assign user rights and access control permissions to domain users as necessary. This
account must be used only for tasks that require administrative credentials. It is recommended that you set up this account with a strong password. For
more information, see Strong passwords. For additional security considerations for accounts with administrative credentials, see Active Directory Best
practices.
The Administrator account is a default member of the Administrators, Domain Admins, Enterprise Admins, Group Policy Creator Owners, and Schema
Admins groups in Active Directory. The Administrator account can never be deleted or removed from the Administrators group, but it can be renamed
or disabled. Because the Administrator account is known to exist on many versions of Windows, renaming or disabling this account will make it more
difficult for malicious users to try and gain access to it. For more information about how to rename or disable a user account, see Rename a local user
account or Disable or enable a user account.
The Administrator account is the first account created when you set up a new domain using the Active Directory Installation Wizard.
Important When the Administrator account is disabled, it can still be used to gain access to a domain controller using Safe Mode.
Guest
account
The Guest account is used by people who do not have an actual account in the domain. A user whose account is disabled (but not deleted) can also use
the Guest account. The Guest account does not require a password.
You can set rights and permissions for the Guest account just like any user account. By default, the Guest account is a member of the built-in Guests
group and the Domain Guests global group, which allows a user to log on to a domain. The Guest account is disabled by default, and it is
recommended that it stay disabled.
HelpAssistant
account
(installed with
a Remote
Assistance
session)
The primary account used to establish a Remote Assistance session. This account is created automatically when you request a Remote Assistance
session and has limited access to the computer. The HelpAssistant account is managed by the Remote Desktop Help Session Manager service and will
be automatically deleted if no Remote Assistance requests are pending. For more information about Remote Assistance, see Administering Remote
Assistance.
Securing user accounts

If built-in account rights and permissions are not modified or disabled by a network administrator, they could be used by a malicious user (or service) to illegally log on to
a domain using the Administrator or Guest identity. A good security practice for protecting these accounts is to rename or disable them. Because it retains its security ID
(SID), a renamed user account retains all its other properties, such as its description, password, group memberships, user profile, account information, and any assigned
permissions and user rights.
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 a group 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.
You can help defend your domain from attackers by requiring strong passwords and implementing an account lockout policy. Strong passwords reduce the risk of
intelligent guessing and dictionary attacks on passwords. For more information, see Strong passwords and Password Best practices for passwords.
An account lockout policy decreases the possibility of an attacker compromising your domain through repeated logon attempts. This is because an account lockout policy
determines how many failed logon attempts a user account can have before it is disabled. For more information, see Apply or modify account lockout policy.
For more information about securing user accounts, see Securing Active Directory.
Account options
Each Active Directory user account has a number of account options that determine how someone logging on with that particular user account is authenticated on the
network. You can use the following options to configure password settings and security-specific information for user accounts:
Account option
Description
User must
change
password at next
logon
Forces a user to change their password the next time the user logs on to the network. Use this option when you want to ensure that the user will be
the only person to know their password.
User cannot
change
password
Prevents a user from changing their password. Use this option when you want to maintain control over a user account, such as for a guest or
temporary account.
Password never
expires
Prevents a user password from expiring. It is recommended that Service accounts should have this option enabled and should use strong
passwords. For more information about strong passwords, see Strong passwords.
Store passwords
using reversible
encryption
Allows a user to log on to a Windows network from Apple computers. If a user is not logging on from an Apple computer, this option should not
be used. For more information, see Store passwords using reversible encryption.
Account is
disabled
Prevents a user from logging on with the selected account. Many administrators use disabled accounts as templates for common user accounts. For
more information, see Disable or enable a user account.
Smart card is
required for
interactive logon
Requires that a user possess a smart card to log on to the network interactively. The user must also have a smart card reader attached to their
computer and a valid personal identification number (PIN) for the smart card. When this option is selected, the password for the user account is
automatically set to a random and complex value. For more information about smart cards, see Logging on to a computer with a smart card and
Authentication process.
Account is
trusted for
delegation
Allows a service running under this account to perform operations on behalf of other user accounts on the network. A service running under a user
account (otherwise known as a service account) that is trusted for delegation can impersonate a client to gain access to resources on the computer
where the service is running or on other computers. In a forest set to the Windows Server 2003 functional level, this setting is found on the
Delegation tab, and is only available for accounts that have been assigned service principal names (SPNs), as set using the setspn command from
the Windows Support Tools. This is a security-sensitive capability and should be cautiously assigned. For more information, see Allow a user to be
trusted for delegation and Delegating authentication.
This option is only available on domain controllers running Windows Server 2003 where the domain functionality is set to Windows 2000 mixed or
Windows 2000 native. On domain controllers running Windows Server 2003 where the domain functional level is set to Windows Server 2003, the
Delegation tab is used to configure delegation settings. The Delegation tab only appears for accounts which have an assigned SPN. For more
information about domain functionality, see Domain and forest functionality. For more information about configuring delegation in a Windows
Server 2003 domain, see Allow a user to be trusted for delegation.
Account is
sensitive and
cannot be
delegated
Allows control over a user account, such as for a guest or temporary account. This option can be used if this account cannot be assigned for
delegation by another account.
Use DES
encryption types
for this account
Provides support for 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 about DES
encryption, see Data encryption.
Do not require
Kerberos
preauthentication
Provides support for alternate implementations of the Kerberos protocol. Domain controllers running Windows 2000 or Windows Server 2003 can
use other mechanisms to synchronize time. Because preauthentication provides additional security, use caution when enabling this option. For more
information about Kerberos, see Kerberos V5 authentication.
InetOrgPerson accounts
Active Directory provides support for the InetOrgPerson object class and its associated attributes defined in RFC 2798. The InetOrgPerson object class is used in several
non-Microsoft LDAP and X.500 directory services to represent people within an organization.
Support for InetOrgPerson makes migrations from other LDAP directories to Active Directory more efficient. The InetOrgPerson object is derived from the user class and
can be used as a security principal just like the user class. For information about creating an inetOrgPerson user account, see Create a new user account.
When the domain functional level has been set to Windows Server 2003, you can set the userPassword attribute on InetOrgPerson and user objects as being the effective
password just like you can with the unicodePwd attribute.
Computer accounts
Every computer running Windows NT, Windows 2000, Windows XP, or a server running Windows Server 2003 that joins a domain has a computer account. Similar to user
accounts, computer accounts provide a means for authenticating and auditing computer access to the network and to domain resources. Each computer account must be
unique.
Note Computers running Windows 95 and Windows 98 do not have advanced security features and are not assigned computer accounts.
User and computer accounts can be added, disabled, reset, and deleted using Active Directory Users and Computers. A computer account can also be created when you
join a computer to a domain. For more information about user and computer accounts, see Active Directory naming and Object names.
When the domain functional level has been set to Windows Server 2003, a new lastLogonTimestamp attribute is used to track the last logon time of a user or computer
account. This attribute is replicated within the domain and can provide you with important information regarding the history of a user or computer.
Object names
Object names
Every object in Active Directory is an instance of a class defined in the 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 Schema.
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. Relative distinguished names must be unique in that users cannot have the same name within an organizational unit.
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 IDs (SIDs) and can be used to log on to the network and can be assigned 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
Computers running Windows Server 2003 and Windows 2000 can

use a user principal name (UPN) for a user account. Computers
running Windows NT 4.0 and earlier are limited to 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 (.) or spaces, or end in a period. Any
leading periods or spaces are cropped. Use of the @ symbol is not supported with
the logon format for Windows NT 4.0 and earlier, which is DomainName\UserName.
Windows 2000 logon names are unique to the domain and Windows Server 2003
logon names are unique within the forest.
Computer
account
NetBIOS = 15 characters, or 15 bytes depending upon the

character set; individual characters may require more than one
byte.
DNS = 63 characters or 63 bytes depending upon the character
set and 255 characters for a fully qualified domain name (FQDN)
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;

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, then it is possible to use computer names containing more than 15 characters. For more information, see
Active Directory naming.
From the information provided by the person who creates the security principal object, Active Directory generates a security ID (SID), 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 SID, 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 SID, 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 Active Directory naming and Add user principal name suffixes, and User and computer accounts.
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. You can then manage the configuration and use of accounts
and resources based on your organizational model. For more information about Group Policy settings, see Group Policy (pre-GPMC).
As shown in the figure, 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 have 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.


Computers that function as servers within a domain can have one of two roles: member server or domain controller. A server that is not in a domain is a stand-alone
server.
Member servers
A member server is a computer that:
Belongs to a domain.
Is not a domain controller.
A member server does not process account logons, participate in Active Directory replication, or 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, and
remote access servers. For more information about server roles, see Server roles.
The following security-related features are common to all member servers:
Member servers adhere to Group Policy settings that are defined for the site, domain, or organizational unit.
Access control for resources that are available on a member server.
Member server users have assigned user rights.
Member servers contain a local security account database, the Security Accounts Manager (SAM).
Domain controllers
A domain controller is a computer that:
Uses Active Directory to store a read-write copy of the domain database, participate in multimaster replication, and authenticate users.
Domain controllers store directory data and manage communication between users and domains, including user logon processes, authentication, and directory searches.
Domain controllers synchronize directory data using multimaster replication, ensuring consistency of information over time. For more information about multimaster
replication, see Replication overview.
Active Directory supports multimaster replication of directory data between all domain controllers in a domain; however, multimaster replication is not appropriate for
some directory data replication. In this case, a domain controller, called the operations master, will process data. In an 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 Operations master roles.
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 install Active
Directory on a member server to make it a domain controller, or you can remove Active Directory from a domain controller to make it a member server. For more
information about domain controllers, see Domain controllers.
Note


With the Active Directory client, many of the Active Directory features available on Windows 2000 Professional or Windows XP Professional are available to computers
running Windows 95, Windows 98, and Windows NT 4.0.
Site awareness
You can log on to the domain controller that is closest to the client in the network. For more information, see Locating a domain controller.
You can use scripting to Active Directory. ADSI also provides a common programming API to Active Directory programmers.
Distributed File System (DFS)
You can access DFS shared resources on servers running Windows 2000 and Windows Server 2003.
NTLM version 2 authentication
You can use the improved authentication features in NTLM version 2.
For more information about enabling NTML version 2, see article Q239869, "How to Enable NTLM 2 Authentication," in the Microsoft Knowledge Base.
Active Directory Windows Address Book (WAB) property pages
You can change properties, such as phone number and address, on user object pages.
Active Directory search capability
From the Start button, you can locate printers and people in a Windows 2000 Server or Windows Server 2003 domain.
For information about publishing printers in Active Directory, see article Q234619, "Publishing a Printer in Windows 2000 Active Directory," in the Microsoft
Knowledge Base.
Windows 2000 Professional and Windows XP Professional provide functionality that the Active Directory client on Windows 95, Windows 98, and Windows NT 4.0 does not,
including Kerberos V5 support; Group Policy or IntelliMirror support; and service principal name (SPN), or mutual authentication. You can take advantage of these
additional features by upgrading to Windows 2000 Professional or Windows XP Professional.
To install the Active Directory client, see the Active Directory client page at the Microsoft Web site.


Domain controllers
Domains
Renaming domains
Domain controllers
Domain controllers
When you create the first domain controller in your organization, you are also creating the first domain, the first forest, the first site, and installing Active Directory. Domain
controllers running Windows Server 2003 store directory data and manage user and domain interactions, including user logon processes, authentication, and directory
searches. Domain controllers are created by using the Active Directory Installation Wizard. For more information, see Using the Active Directory Installation Wizard.
Note
When using domain controllers in your organization, you will want to think about how many domain controllers youll need, the physical security of those domain
controllers, a plan for backing up the domain data, and upgrading domain controllers.
Determining the number of domain controllers you need

A small organization using a single local area network (LAN) might need only one domain with two domain controllers for high availability and fault tolerance. A larger
organization with many network locations will need one or more domain controllers in each site to provide high availability and fault tolerance.
If your network is divided into sites, it is often good practice to put at least one domain controller in each site to enhance network performance. When users log on to the
network, a domain controller must be contacted as part of the logon process. If clients must connect to a domain controller located in a different site, the logon process
can take a long time. For more information, see Replication between sites.
By creating a domain controller in each site, user logons are processed more efficiently within the site. For information about how to create additional domain controllers,
see Create an additional domain controller.
To optimize network traffic, you can also configure domain controllers to receive directory replication updates only during off-peak hours. For information about how to
schedule site replication, see Configure site link replication availability.
The best network performance is available when the domain controller at a site is also a global catalog. This way, the 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. For more information about the global catalog,
see The role of the global catalog. For more information about adding global catalogs to sites, see Global catalogs and sites.
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 Operations master roles.
Physical security
Physical access to a domain controller can provide a malicious user unauthorized access to encrypted passwords. For this reason, it is recommended that all domain
controllers in your organization be locked in a secured room with limited public access. You can use additional security measures such as Syskey for extra protection on
domain controllers. For more information about Syskey, see The system key utility.
Backing up domain controllers

You can back up domain directory partition data and data from other directory partitions by using Backup, which is included with the Windows Server 2003 family, from any
domain controller in a domain. By using the backup tool on a domain controller, you can:
Back up Active Directory while the domain controller is online.

Back up Active Directory using batch file commands.
Back up Active Directory to removable media, an available network drive, or a file.
Back up other system and data files.
When you use the backup tool on a domain controller it will automatically back up all of the system components and all of the distributed services upon which Active
Directory is dependent. This dependent data, which includes Active Directory, is known collectively as the System State data.
On a domain controller running Windows Server 2003, the System State data consists of the system startup files; the system registry; the class registration database of
COM+ (an extension to the Component Object Model); the SYSVOL directory; Certificate Services database (if installed); Domain Name System (if installed); Cluster service
(if installed); and Active Directory. It is recommended that you regularly back up System State data.
For general information about the System State, see System State data. For more information about how to back up the System State, see Back up System State data. For
more information about how to restore a System State backup, see Restore System State data.
You can install Active Directory on a server running Windows Server 2003 by using a restored backup taken from a domain controller running Windows Server 2003. For
more information, see Creating an additional domain controller.
Upgrading domain controllers

On domain controllers running Windows NT 4.0, you will first need to upgrade the primary domain controller (PDC) to successfully upgrade the domain. Once the PDC has
been upgraded, you can upgrade the backup domain controllers (BDCs). For more information, see Upgrading from a Windows NT domain.
If you currently have a Windows 2000 forest that does not have any domain controllers running Windows Server 2003, you will need to prepare the forest and the target
domain before you can upgrade domain controllers running Windows 2000. For more information, see Upgrading from a Windows 2000 domain.


The ability to rename domain controllers running Windows Server 2003 provides you with the flexibility to make changes in a Windows Server 2003 domain whenever the
need arises. Rename a domain controller to:
Restructure your network for organizational and business needs.

Make management and administrative control easier.
When you rename a domain controller, you must ensure that there will be no interruption in the ability of clients to locate or authenticate to the renamed domain
controller, except when the domain controller is restarted. The recommended practice for renaming a domain controller without interruption to clients is to use the
Netdom tool. To rename a domain controller using the Netdom tool, the domain functional level must be set to Windows Server 2003. For more information about
renaming a domain controller, see Rename a domain controller.
The System Properties dialog box can also be used to rename a domain controller, and it does not require the functional level to be raised to Windows Server 2003.
Using this dialog box may result in a service interruption to clients. For more information about functional levels, see Domain and forest functionality.
The new name of the domain controller is automatically updated to Domain Name System (DNS) and Active Directory. Once the new name propagates to DNS and Active
Directory, clients are then capable of locating and authenticating to the renamed domain controller. DNS and Active Directory replication latency may delay client ability to
locate or authenticate to the renamed domain controller. The length of time this takes depends on specifics of your network and the replication topology of your particular
organization.
During replication latency, clients may not be able to access the newly renamed domain controller. This might be acceptable for clients that try to locate and authenticate to
a particular domain controller since other domain controllers should be available to process the authentication request.
Note
The corresponding nTFRSMember or msDFSR-Member object is not renamed automatically, but the reference attributes are correctly set so SYSVOL replication is not
impacted. The only potential problem with not renaming these objects is that if another domain controller is created at a later date with the same NetBIOS name of the
old domain controller, then a conflict can occur as described in KB article 316826. After the rename is complete, you can optionally rename the nTFRSMember or
msDFSR-Member object as part of cleanup.


When you need to connect to a domain controller running Windows 2000 from a domain controller running Windows Server 2003, a number of Active Directory
administrative tools are available, such as Active Directory Domains and Trusts.
The following Windows Server 2003 Active Directory administrative tools will sign and encrypt all LDAP traffic by default:

ADSI Edit
Dsrm.exe
Dsmove.exe
Dsadd.exe
Dsmod.exe
Dsget.exe
Dsquery.exe
Signing LDAP traffic guarantees that the packaged data comes from a known source and that it has not been tampered with. The Active Directory administrative tools in
Windows 2000 do not sign and encrypt all LDAP traffic by default. In order to maintain a secure network, it is strongly recommended that you upgrade all domain
controllers running Windows 2000 to Service Pack 3 or later.
You can use the corresponding Active Directory administrative tools in Windows 2000 to manage Windows 2000 domain controllers that do not have the Windows 2000
Server Service Pack 3 or later installed. However, traffic is not signed and encrypted by LDAP on domain controllers running Windows 2000.
Although it is not recommended, you can disable encrypted and signed LDAP traffic used with Active Directory administrative tools on a server running Windows
Server 2003 or on a computer running Windows XP Professional that has the Windows Server 2003 Administration Tools Pack installed. For more information, see Disable
signed or encrypted LDAP traffic.
Domains
Domains
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. Each domain in Active Directory is identified by a Domain Name System (DNS) domain name and requires one or more domain controllers. If your network
requires more than one domain, you can easily create multiple domains.
One or more domains that share a common schema and global catalog are referred to as a forest. The first domain in a forest is referred to as the forest root domain.
For more information about forests, see Creating a new forest. If multiple domains in the forest have contiguous DNS domain names, then the structure is referred to as a
domain tree. For more information, see Active Directory naming and Creating a new domain tree.
A single domain can span multiple physical locations or sites and can 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. For more information, see Sites overview.
A domain provides several benefits:
Organizing objects.
You do not need to create separate domains merely to reflect your company's organization of divisions and departments. Within a domain, you can use
organizational units for this purpose. Using organizational units helps you manage the accounts and resources in the domain. You can then assign Group Policy
settings and place users, groups, and computers into the organizational units. Using a single domain greatly simplifies administrative overhead. For more
information, see Organizational units.
Publishing resources and information about domain objects.
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. When using multiple domains, you can scale the Active Directory directory service to accommodate your administrative and
directory publishing requirements. For more information, Publishing resources.
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 (GPO) 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 GPOs, see Group Policy (pre-GPMC).
Delegating authority eliminates the need for a number of administrators with broad 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.
Security policies and settings (such as user rights and password policies) do not cross from one domain to another.
Each domain has its own security policies and trust relationships with other domains. However, the forest is the final security boundary. For more information, see
Creating a new forest.
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.
Creating a domain
You create a domain by creating the first domain controller for a domain. To do this, install Active Directory on a member server running Windows Server 2003 by using
the Active Directory Installation Wizard. The wizard uses the information that you provide to create the domain controller and create the domain within the existing domain
structure of your organization. Depending on the existing domain structure, the new domain could 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. For more information, see Creating a new forest, Creating a new domain tree, and Creating a new child domain.
A domain controller provides the Active Directory directory service to network users and computers, stores directory data, and manages user and domain interactions,
including user logon processes, authentication, and directory searches. Every domain must contain at least one domain controller. For more information, see Domain
controllers.
After you create the first domain controller for a domain, you can create additional domain controllers in an existing domain for fault tolerance and high availability of the
directory. For more information, see Creating an additional domain controller.
Planning for multiple domains

Some reasons to create more than one domain are:
Different password requirements between departments or divisions

Massive numbers of objects
Decentralized network administration
More control of replication
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.
Removing a domain
In order to remove a domain, you must first remove Active Directory from all of the domain controllers associated with that domain. Once Active Directory has been
removed from the last domain controller the domain will be removed from the forest and all of the information in that domain will be deleted. A domain can only be
removed from the forest if it has no child domains. If this is the last domain in the forest, removing this domain will also delete the forest.
For more information about how to remove a domain, see Remove a domain.
Caution
Removing a domain will result in the permanent loss of amy data contained in that domain. This includes all user, group, and computer accounts.
Before removing Active Directory from a domain controller, you should first remove any application directory partitions from that domain controller. For more information,
see Application directory partitions and Create or delete an application directory partition.
Trust relationships between domains

Trust relationships are automatically created between adjacent domains (parent and child domains) when a domain is created in Active Directory. In a forest, a trust
relationship is automatically created between the forest root domain and any tree root domains or child domains that are subordinate to the forest root domain. Because
these trust relationships are transitive, users and computers can be authenticated between any domains in the forest. For more information about trust relationships, see
Trust transitivity.
When upgrading a Windows NT domain to a Windows Server 2003 domain, the existing one-way trust relationship between that domain and any other domains remains
intact. This includes all trusts with other Windows NT domains. If you are creating a new Windows Server 2003 domain and want trust relationships with any Windows NT
domains, you must create external trusts with those domains. For more information about external trusts, see When to create an external trust.
Renaming domains
Renaming domains
The ability to rename a domain provides you with the flexibility to make important changes to your forest structure and namespace as the needs of your organization
change. Renaming domains can accommodate acquisitions, mergers, name changes, or reorganizations. Domain rename allows you to:
Change the Domain Name System (DNS) and NetBIOS names of any domain in the forest (including the forest root domain).
Restructure the position of any domain in the forest (except the forest root domain).
You can only rename domains in a forest where all of the domain controllers are running Windows Server 2003 and the forest functional level has been raised to Windows
Server 2003. For more information, see Domain and forest functionality.
Forest restructuring
Using domain rename, you can also restructure the hierarchy of domains in your forest so that a domain residing in one domain tree can be moved to another domain
tree. Restructuring a forest allows you to move a domain anywhere within the forest in which it resides (except the forest root domain). This includes the ability to move a
domain so that it becomes the root of its own domain tree.
You can use the domain rename utility (Rendom.exe) to rename or restructure a domain. A domain rename will affect every domain controller in your forest and is a
multistep process that requires a detailed understanding of the operation. For more information about this process and to download the Rendom.exe tool, see the
Windows Server 2003 Active Directory Domain Rename Tools page at the Microsoft Web site.


Domain and forest functionality, introduced in Windows Server 2003 Active Directory, provides a way to enable domain- or forest-wide Active Directory features within your
network environment. Different levels of domain functionality and forest functionality are available depending on your environment.
If all domain controllers in your domain or forest are running Windows Server 2003 and the functional level is set to Windows Server 2003, all domain- and forest-wide
features are available. When Windows NT 4.0 or Windows 2000 domain controllers are included in your domain or forest with domain controllers running Windows
Server 2003, Active Directory features are limited. For more information about how to enable domain- or forest-wide features, see Raising domain and forest functional
levels.
The concept of enabling additional functionality in Active Directory exists in Windows 2000 with mixed and native modes. Mixed-mode domains can contain
Windows NT 4.0 backup domain controllers and cannot use Universal security groups, group nesting, and security ID (SID) history capabilities. When the domain is set to
native mode, Universal security groups, group nesting, and SID history capabilities are available. Domain controllers running Windows 2000 Server are not aware of
domain and forest functionality.
Domain functionality
Domain functionality enables features that will affect the entire domain and that domain only. Four domain functional levels are available: Windows 2000 mixed (default),
Windows 2000 native, Windows Server 2003 interim, and Windows Server 2003. By default, domains operate at the Windows 2000 mixed functional level.
The following table lists the domain functional levels and their corresponding supported domain controllers.
Domain functional level
Windows 2000 mixed (default)
Windows NT 4.0
Windows 2000
Windows 2000 native
Windows 2000
Windows NT 4.0
Windows Server 2003
Once the domain functional level has been raised, domain controllers running earlier operating systems cannot be introduced into the domain. For example, if you raise
the domain functional level to Windows Server 2003, domain controllers running Windows 2000 Server cannot be added to that domain.
The following table describes the domain-wide features that are enabled for three of the domain functional levels. For information about the Windows Server 2003 interim
functional level, see Upgrading from a Windows NT domain.
Domain feature
Windows 2000 mixed
Windows 2000 native
Windows Server 2003
Domain controller rename tool

For more information, see Renaming domain controllers.
Disabled
Disabled
Enabled
Different location option for user and computer

accounts
For more information about how to redirect the default
location for user and computer accounts, see Redirect the
Users and Computers Containers.
Disabled
Disabled
Enabled
Update logon timestamp

For more information about the lastLogonTimestamp
attribute, see User and computer accounts.
Disabled
Disabled
Enabled
User password on InetOrgPerson object

For more information about InetOrgPerson objects, see
User and computer accounts.
Disabled
Disabled
Enabled
Universal Groups
For more information, see Group types and Group scope.

Disabled for security groups.
Enabled
Enabled
Group Nesting
For more information, see Nesting groups.

Disabled for security groups, except for
domain local security groups that can have
global groups as members.
Enabled
Enabled
Converting Groups
For more information, see Converting groups.
Disabled
No group conversions allowed.
Enabled
security groups and
Enabled
security groups and
SID history
Disabled
Enabled
Allows migration of
Enabled
Allows migration of
Forest functionality
Forest functionality enables features across all the domains within your forest. Three forest functional levels are available: Windows 2000 (default), Windows Server 2003
interim, and Windows Server 2003 . By default, forests operate at the Windows 2000 functional level. You can raise the forest functional level to Windows Server 2003 .
The following table lists the forest functional levels and their corresponding supported domain controllers:
Forest functional level
Windows 2000 (default)
Windows NT 4.0
Windows 2000
Windows NT 4.0
Windows Server 2003
Once the forest functional level has been raised, domain controllers running earlier operating systems cannot be introduced into the forest. For example, if you raise the
forest functional level to Windows Server 2003, domain controllers running Windows 2000 Server cannot be added to the forest.
If you are upgrading your first Windows NT 4.0 domain so that it becomes the first domain in a new Windows Server 2003 forest, you can set the domain functional level to
Windows Server 2003 interim. For more information, see Upgrading from a Windows NT domain.
The following table describes the forest-wide features that are enabled for the Windows 2000 and Windows Server 2003 forest functional levels.
Windows
Server 2003
Forest feature
Windows 2000
Global catalog replication improvements

For more information, see Global catalog replication.
Enabled if both replication partners are running Windows

Server 2003.
Otherwise, disabled.
Enabled
Defunct schema objects

For more information, see Deactivating a class or attribute.
Disabled
Enabled
Forest trusts
For more information, see Forest trusts.
Disabled
Enabled
Linked value replication

For more information, see How replication works.
Disabled
Enabled
Domain rename
For more information, see Renaming domains.
Disabled
Enabled
Improved Active Directory replication algorithms

For more information, see Replication overview.
Disabled
Enabled
Dynamic auxiliary classes.

Disabled
Enabled
InetOrgPerson objectClass change

For more information about InetOrgPerson objects, see User and computer
accounts.
Disabled
Enabled


When Active Directory is installed on a server running Windows Server 2003, a set of basic Active Directory features is enabled by default. For more information about the
new default features, see New features for Active Directory.
In addition to the basic Active Directory features on individual domain controllers, there are new domain- and forest-wide Active Directory features available when all
domain controllers in a domain or forest are running Windows Server 2003.
To enable the new domain-wide features, all domain controllers in the domain must be running Windows Server 2003, and the domain functional level must be raised to
Windows Server 2003 . For information about raising the domain functional level, see Raise the domain functional level.
To enable new forest-wide features, all domain controllers in the forest must be running Windows Server 2003, and the forest functional level must be raised to Windows
Server 2003 . Before raising the forest functional level to Windows Server 2003 , verify that all domains in the forest are set to the domain functional level of Windows 2000
native or Windows Server 2003 . Note that domains that are set to the domain functional level of Windows 2000 native will automatically be raised to Windows Server 2003
at the same time the forest functional level is raised to Windows Server 2003 . For information about raising the forest functional level, see Raise the forest functional level.


An application directory partition is a directory partition that is replicated only to specific domain controllers. A domain controller that participates in the replication of a
particular application directory partition hosts a replica of that partition. Only domain controllers running Windows Server 2003 can host a replica of an application
directory partition.
Applications and services can use application directory partitions to store application-specific data. Application directory partitions can contain any type of object, except
security principals. TAPI is an example of a service that stores its application-specific data in an application directory partition.
Application directory partitions are usually created by the applications that will use them to store and replicate data. For testing and troubleshooting purposes, members
of the Enterprise Admins group can manually create or manage application directory partitions using the Ntdsutil command-line tool.
One of the benefits of an application directory partition is that, for redundancy, availability, or fault tolerance, the data in it can be replicated to different domain controllers
in a forest. The data can be replicated to a specific domain controller or any set of domain controllers anywhere in the forest. This differs from a domain directory partition
in which data is replicated to all domain controllers in that domain. Storing application data in an application directory partition instead of in a domain directory partition
may reduce replication traffic because the application data is only replicated to specific domain controllers. Some applications may use application directory partitions to
replicate data only to servers where the data will be locally useful.
Another benefit of application directory partitions is that applications or services that use Lightweight Directory Access Protocol (LDAP) can continue using it to access and
store their application data in Active Directory. For more information, see Managing application directory partitions.
Application directory partition naming

An application directory partition is part of the overall forest namespace just like a domain directory partition. It follows the same Domain Name System (DNS) and
distinguished names naming conventions as a domain directory partition. An application directory partition can appear anywhere in the forest namespace that a domain
directory partition can appear.
There are three possible application directory partition placements within your forest namespace:
A child of a domain directory partition.

A child of an application directory partition.
A new tree in the forest.
If you created an application directory partition called example1 as a child of the microsoft.com domain, the DNS name of the application directory partition would be
example1.microsoft.com. The distinguished name of the application directory partition would be dc=example1, dc=microsoft, dc=com.
If you then created an application directory partition called example2 as a child of example1.microsoft.com, the DNS name of the application directory partition would be
example2.example1.microsoft.com and the distinguished name would be dc=example2, dc=example1, dc=microsoft, dc=com.
If the domain microsoft.com was the root of the only domain tree in your forest, and you created an application directory partition with the DNS name of example1 and the
distinguished name of dc=example1, this application directory partition is not in the same tree as the microsoft.com domain. This application directory partition would be
the root of a new tree in the forest.
Domain directory partitions cannot be children of an application directory partition. For example, if you created an application directory partition with the DNS name of
example1.microsoft.com, you could not create a domain with the DNS name of domain.example1.microsoft.com.
Application directory partition replication

The Knowledge Consistency Checker (KCC) automatically generates and maintains the replication topology for all application directory partitions in the enterprise. When an
application directory partition has replicas in more than one site, those replicas follow the same intersite replication schedule as the domain directory partition.
Notes
Objects stored in an application directory partition are never replicated to the global catalog as read-only replicas. Any domain controller running Windows
Server 2003 can hold a replica, including global catalogs.
Additionally, if an application requests data through the global catalog port, that query will not return any objects from an application directory partition, even if the
computer hosting the application directory partition is also hosting the global catalog. This is done so that LDAP queries to different global catalogs will not return
inconsistent results because the application directory partition is replicated to only one of the global catalogs.
Security descriptor reference domain

Every container and object on the network has a set of access control information attached to it. Known as a security descriptor, this information controls the type of
access allowed by users, groups, and computers. If the object or container is not assigned a security descriptor by the application or service that created it, then it is
assigned the default security descriptor for that object class as defined in the schema. This default security descriptor is ambiguous in that it may assign members of the
Domain Admins group read permissions to the object, but it does not specify to what domain the domain administrators belong. When this object is created in a domain
naming partition, that domain naming partition is used to specify which Domain Admins group actually is assigned read permission. For example, if the object is created in
mydomain.microsoft.com then members of the mydomain Domain Admins group would be assigned read permission.
When an object is created in an application directory partition, the definition of the default security descriptor is difficult because an application directory partition can have
replicas on different domain controllers belonging to different domains. Because of this potential ambiguity, a default security descriptor reference domain is assigned
when the application directory partition is created.
The default security descriptor reference domain defines what domain name to use when an object in the application directory partition needs to define a domain value for
the default security descriptor. The default security descriptor reference domain is assigned at the time of creation.
If the application directory partition is a child of a domain directory partition, by default, the parent domain directory partition becomes the security descriptor reference
domain. If the application directory partition is a child object of another application directory partition, the security descriptor reference domain of the parent application
directory partition becomes the reference domain of the new, child, application directory partition. If the new application directory partition is created as the root of a new
tree, then the forest root domain is used as the default security descriptor reference domain.
You can manually specify a security reference domain using Ntdsutil. However, if you plan to change the default security descriptor reference domain of a particular
application directory partition, you should do so before creating the first instance of that partition. To do this, you must prepare the cross-reference object and change the
default security reference domain before completing the application directory partition creation process. For information about precreating the cross-reference object, see
Prepare a cross-reference object. For information about changing the default security reference domain, see Set an application directory partition reference domain.
Application directory partitions and domain controller

demotion

If a domain controller holds a replica of an application directory partition, then you must remove the domain controller from the replica set of the application directory
partition or delete the application directory partition before you can demote the domain controller.
If a domain controller holds the last replica of a particular application directory partition, then you must delete the application directory partition before you can demote
the domain controller.
The Active Directory Installation Wizard will not remove a replica or delete an application directory partition programmatically. You must decide when it is safe to delete the
last replica of a particular partition.
Before deleting the last replica of an application directory partition, identify the applications that use the application directory partition, determine if it is safe to delete the
last replica, identify the partition deletion tool provided by the application, and then remove the application directory partition by using the tool provided or by using the
Ntdsutil command-line tool.
Identify the applications that use the application directory partition

To determine what application directory partitions are hosted on a computer, refer to the list on the first page of the Active Directory Installation Wizard. If the list does not
provide enough information to identify the programs using a particular application directory partition, you may be able to identify them in one of the following ways:
Speak to a member of the Enterprise Admins group.

Consult the network change control records for your organization.
Use LDP or ADSI Edit to view the data contained in the partition. For more information about these tools, see the Active Directory Programmer's Guide at the
Microsoft Web site.
Determine if it is safe to delete the last replica

Removing the last replica of an application directory partition will result in the permanent loss of any data contained in the partition. If you have identified the applications
using the application directory partition, consult the documentation provided with those applications to determine if there is any reason to keep the data. If the applications
that use the application directory partition are out of service, it is probably safe to remove the partition.
If it is not safe to delete the last replica, or if you cannot determine whether or not it is safe, and you must demote the domain controller holding the last replica of a
particular application directory partition, follow these steps: Add a replica of the partition on another domain controller, force the replication of the contents of the
application directory partition to the domain controller holding the new replica, and then remove the replica of the partition on the domain controller to be demoted. For
more information, see Add or remove an application directory partition replica.
Identify the partition deletion tool provided by the application

Most applications that create application directory partitions provide a utility to remove the partitions. When possible, always delete an application directory partition using
the utility provided. For example, to delete a TAPI partition, use the Tapicfg.exe command-line tool. For more information about TAPI and removing TAPI application
directory partitions, see Telephony.
Remove the application directory partition using the tool provided or use Ntdsutil
Refer to the application's documentation for information about removing application directory partitions that were created and used by that application.
Caution
If possible, use the application's tool for managing its application directory partitions. The application may keep other data in addition to Active Directory managed
data for the application directory partitions. By using Ntdsutil, the two sets of data could cause a conflict.
If you cannot identify the application that created the application directory partition, or if your application does not provide a means to delete application directory
partitions that it created, you can use the Ntdsutil command-line tool. To do this, see Create or delete an application directory partition.
For information about demoting a domain controller, see Demote a domain controller. For general information about application directory partitions, see Application
directory partitions.


You can use the following tools to create, delete, or manage application directory partitions.
application-specific tools from the application vendor

Ntdsutil command-line tool
LDP
For information about creating and managing application directory partitions with ADSI, see Active Directory Service Interfaces (ADSI) at the Microsoft Web site. For
information about LDP, see Administration tools for the Active Directory schema.
For information about the Ntdsutil command-line tool, see Ntdsutil.
The following provides information about using Ntdsutil to create and manage application directory partitions.
Creating an application directory partition

When you create an application directory partition, you are creating the first instance of this partition. You can create an application directory partition by using the create
nc option in the domain management menu of Ntdsutil. When creating an application directory partition using LDP or ADSI, provide a description in the description
attribute of the domain DNS object that indicates the specific application that will use the partition. For example, if the application directory partition will be used to store
data for a Microsoft accounting program, the description could be Microsoft accounting application. Ntdsutil does not facilitate the creation of a description. For more
Deleting an application directory partition

When you delete an application directory partition, you are removing all replicas of that partition from your forest. You can delete an application directory partition by
using the delete nc command in the domain management menu of Ntdsutil. The deletion process will need to replicate to all domain controllers that contain a replica of
the application directory partition before the deletion process is complete. Any data that is contained in the application directory partition will be lost.
The Active Directory Promotion Wizard (Dcpromo) cannot demote a domain controller if that domain controller holds a copy of an application directory partition. For more
Adding and removing a replica of an application directory partition

An application directory partition replica is an instance of an partition on another domain controller. The information in the application directory partition is replicated
between the domain controllers. Application directory partition replicas are created for either redundancy or data access purposes. You can add a replica of an application
directory partition by using the add nc replica command in the domain management menu of Ntdsutil. You can remove an application directory partition replica by using
the delete nc replica command in the domain management menu of Ntdsutil. For more information, see Add or remove an application directory partition replica.
Setting application directory partition reference domain

The security descriptor reference domain defines a domain name for the default security descriptor for objects in the application directory partition. By default, the security
descriptor reference domain is the parent domain of the application directory partition. If the application directory partition is a child of another application directory
partition, the default security descriptor reference domain is the security descriptor reference domain of the parent application directory partition. If the application
directory partition has no parent, the forest root domain becomes the default security descriptor reference domain. You can use Ntdsutil to change the default security
descriptor reference domain. For more information, see Set an application directory partition reference domain.
Setting replication notification delays

Changes made to a particular directory partition on a particular domain controller are replicated to the other domain controllers that contain that directory partition. The
domain controller on which the change was made notifies its replication partners that it has a change. You can configure how long the domain controller will wait to send
the change notification to its first replication partner. You can also configure how long it waits to send the subsequent change notification to its remaining replication
partners. These delays can be set for any directory partition (including domain directory partitions) on a particular domain controller. For more information, see Set a
notification delay.
Displaying application directory partition information

Any domain controller that holds a replica of a particular directory partition (including application directory partitions) is said to be a member of the replica set for that
directory partition. You can use Ntdsutil to list the domain controllers that are members of a particular replica set for an application directory partition. An addition of a
domain controller to the replica set attribute on the cross-reference object does not create the replica, but it will display when the list nc replica command is used in
Ntdsutil. The creation of the instance must replicate before the creation of the replica is complete. For more information, see Display application directory partition
information.
Delegating the creation of application directory partitions

There are two things that happen when creating an application directory partition:
Creation of the cross-reference object.

Creation of the application directory partition root node.
Normally only members of the Enterprise Admins group can create an application directory partition. However, it is possible for a member of the Enterprise Admins group
to prepare a cross-reference object for the application directory partition and to delegate the rest of the process to someone with more limited permissions.
The cross-reference object for an application directory partition holds several valuable pieces of information, including the domain controllers that are to have a replica of
this partition and the security descriptor reference domain. The partition root node is the Active Directory object at the root of the partition
The Enterprise Admin can create the cross-reference object then delegate to a person or group with less permissions the right to create the application directory partition
root node. Both creation of the cross-reference object and the application directory partition root node can be accomplished using Ntdsutil.
After using Ntdsutil to create the cross-reference object, the enterprise administrator must modify the cross-reference object's access control list to allow the delegated
administrator to modify this cross-reference. This will allow the delegated administrator to create the application directory partition and modify the list of domain
controllers that holds replicas of this application directory partition. The delegated administrator must use the names of the application directory partition and the domain
controller name that were specified during the precreation process. For more information, see Prepare a cross-reference object.
For more information about application directory partitions, see Application directory partitions.

Updated: October 24, 2011
R2

Active Directory supports multimaster replication of the directory data store between all domain controllers (DC) in the domain, so all domain controllers in a domain are
essentially peers. However, some changes are impractical to perform in using multimaster replication, so, for each of these types of changes, one domain controller, called
the operations master, accepts requests for such changes.
In every forest, there are at least five operations master roles that are assigned to one or more domain controllers. Forest-wide operations master roles must appear only
once in every forest. Domain-wide operations master roles must appear once in every domain in the forest.
Note
Forest-wide operations master roles

Every forest must have the following roles:
Schema 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. There can be only one schema master in the entire forest.

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.
Note
Any domain controller running Windows Server 2003 can hold the role of the domain naming master. A domain controller running Windows 2000 Server that holds
the role of domain naming master must also be enabled as a global catalog server.
Domain-wide operations master roles

Every domain in the forest must have the following roles:
Relative ID (RID) master

Primary domain controller (PDC) emulator master
These roles must be unique in each domain. This means that each domain in the forest can have only one RID master, PDC emulator master, and infrastructure master.
RID master
The RID master allocates sequences of relative IDs (RIDs) to each of the various domain controllers in its domain. At any time, there can be only one domain controller
acting as the RID 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 (SID). The SID consists of a domain SID, which is the
same for all SIDs created in the domain, and a RID, which is unique for each SID 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 RID master of the domain that currently
contains the object.
PDC emulator master

The PDC emulator master processes password changes from client computers and replicates these updates to all domain controllers throughout the domain. At any time,
there can be only one domain controller acting as the PDC emulator master in each domain in the forest.
The PDC emulator role is used in the following ways:
To provide consistent password experience for users across sites (can be turned off with AvoidPdcOnWan registry parameter) - The PDC emulator is used as a
reference DC to double-check incorrect passwords and it also receives new password changes. When the PDC is reachable, users can use a new password
immediately and consistently across the environment. For more information about AvoidPdcOnWan see, New Password Change and Conflict Resolution Functionality
in Windows (http://go.microsoft.com/fwlink/?LinkId=202451)
As a preferred point of administration for services (examples are Group Policy and Distributed File System, DFS) - For more information about DFS see, DFS
Management (http://go.microsoft.com/fwlink/?LinkId=202456). For more information about DCs and Group Policy see, Specifying a Domain Controller for Editing
Group Policy (http://go.microsoft.com/fwlink/?LinkId=202457).
As a point of contact for applications hard-coded to the PDC (often written for Windows NT 4.0 and older domains) - The legacy API often used for this is
NetGetDcName. It is strongly suggested to change applications to use the new API to locate DCs. DsGetDcName by default does not target the PDC, and has more
options that allows you to pick the type of DC needed to perform the operation. For more information about locating DCs from applications see, DSGetDcName
Function (http://go.microsoft.com/fwlink/?LinkId=202455).
As a default time server for all other DCs in the domain - The time server configuration of a PDC requires manual consideration and should be reviewed when you
change the owner of the PDC role.
The domain controller configured with the PDC emulator role supports two authentication protocols:
The Kerberos V5 protocol

The NTLM protocol
Note
For instructions on how to configure the PDC emulator to synchronize with an external time source, see Synchronize the Time Server for the Domain Controller with an
External Source (http://go.microsoft.com/fwlink/?LinkId=122513).
At any time, there can be only one domain controller acting as the infrastructure master in each domain. 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 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 it will never replicate any changes to the other domain controllers in the domain.
In the case where 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.
The infrastructure master is also responsible for updating the group-to-user references whenever the members of groups are renamed or changed. 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. This prevents the loss of group
memberships associated with a user account when the user account is renamed or moved. 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 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.


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 consoles in Microsoft Management Console (MMC).
Role
Console in MMC
Schema master
RID master
PDC emulator master
For general information about operations master roles, see Operations master roles.
Note
For procedures describing the transfer of operations master roles, see:
Transfer the schema master role

Transfer the domain naming master role
Transfer the RID master role
Transfer the PDC emulator role
Transfer the infrastructure master role

R2

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. Do not seize the operations master role if you can transfer it instead. For more information, see Transferring operations master
roles.
Note
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 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.
RID master failure

Temporary loss of the RID 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 IDs (RIDs).
If the RID 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 RID master is permanent.
Important
A domain controller whose RID master role has been seized must never be brought back online.
For procedures on how to seize the RID master role, see Seize the RID master role.
PDC emulator master failure

The severity of a PDC outage depends on your Service Level Agreement (SLA) and the actual behavior and configuration of the environment. For example, inconsistent
password change behavior may affect users beyond what your SLAs allow, or the lack of time synchronization may cause resource access failures.
Also, in smaller environments, it may happen that the PDC as the first server in the domain is the only DNS or Global Catalog Server, or is the only domain controller (DC)
with a valid SYSVOL in case other DCs did not successfully initiate or maintain SYSVOL replication. The PDC role holder may also be the target for regular file server access.
When this is done for folder redirection or logon script activities, it may also affect users when logging on and while they work.
Other than the conditions described above, there is no direct dependency of the domain members on the PDC role holder. However, you might be using applications that
are coded to contact the PDC only. You should try to avoid having this single point of failure.
Often, these applications were written for Windows NT 3.x and 4.0 deployments where the PDC was the only writable DC. However, since Active Directory, all DCs except
Read-Only DCs are writable. The DsGetDcName API allows you to pick the right type; similar options are available in AD API interfaces like ADSI (ADS_READONLY_SERVER)
or the .NET runtime.
The loss of the primary domain controller (PDC) emulator master may affect network users. Therefore, when the PDC emulator master is not available, you may need to
immediately seize the role.
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 Operations master roles.
Understanding groups
Groups
Group scope
Group types
Default groups
Nesting groups
Special identities
Groups
Groups
A group is a collection of user and computer accounts, contacts and other groups that can be managed as a single unit. Users and computers that belong to a particular
group are referred to as group members.
Using groups can simplify administration by assigning a common set of permissions and rights to many accounts at once, rather than assigning permissions and rights to
each account individually. For an overview of permissions and rights, see Access control overview.
Groups can be either directory-based or local to a particular computer. Groups in Active Directory are directory objects that reside within a domain and organizational unit
container objects. Active Directory provides a set of default groups upon installation, and also allows the option to create groups. For more information, see Default
groups.
Local groups, which exist on local computers and not in Active Directory, are discussed in Default local groups.
Groups in Active Directory allow you to:
Simplify administration by assigning permissions on a shared resource to a group, rather than to individual users. This assigns the same access on the resource to
all members of that group.
Delegate administration by assigning user rights once to a group through Group Policy, and then adding necessary members to the group that you want to have
the same rights as the group.
Create e-mail distribution lists. For more information, see Group types.
Groups are characterized by their scope and their type. The scope of a group determines the extent to which the group is applied within a domain or forest. For
information about group scope, see Group scope. The group type determines whether a group can be used to assign permissions from a shared resource (for security
groups) or if a group can be used for e-mail distribution lists only (for distribution groups). For information about security groups and distribution groups, see Group
types.
There are also groups for which you cannot modify or view the memberships. These groups are referred to as special identities and are used to represent different users
at different times, depending on the circumstances. For example, the Everyone group represents all current network users, including guests and users from other domains.
For more information, see Special identities.
Group scope
Updated: March 16, 2007
Group scope
Any group, whether it is a security group or a distribution group, is characterized by a scope that identifies the extent to which the group is applied in the domain tree or
forest. The boundary, or reach, of a group scope is also determined by the domain functional level setting of the domain in which it resides. There are three group scopes:
universal, global, and domain local.
The following table describes the differences between the scopes of each group.
Group
scope
Universal
Group can include as members
Accounts from any domain within the forest in

which this Universal Group resides
Group can be assigned permissions in
Any domain or forest
Group scope can be converted to
Domain local
Global (as long as no other
universal groups exist as
members)
Global groups from any domain within the

Universal groups from any domain within the
Global
Accounts from the same domain as the parent

global group
Member permissions can be assigned in any domain
Universal (as long as it is not a

member of any other global groups)
Member permissions can be assigned only within the

same domain as the parent domain local group
Universal (as long as no other domain

local groups exist as members)
Global groups from the same domain as the

parent global group
Domain
local
Accounts from any domain

Global groups from any domain
Universal groups from any domain
Domain local groups but only from the same
domain as the parent domain local group
Note
The information in this table implies that the domain functional level is set to either Windows 2000 native or Windows Server 2003. When the domain functional level is
set to Windows 2000 mixed or Windows Server 2003 interim, security groups with universal scope cannot be created, although distribution groups with universal scope
are still permitted.
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. For example, to give five users access to a particular printer, you
can 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 must again 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 then 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 their own domain, you can change accounts in a group having global scope frequently without generating replication traffic to the global catalog. For
more information about groups and replication, see How replication works.
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 simplifies and rationalizes group management across domains. For example,
in a network with two domains, Europe and UnitedStates, if you have a group with global scope called GLAccounting in the UnitedStates domain, create a group called
GLAccounting in the Europe domain (unless the accounting function does not exist in the Europe domain).
It is strongly recommended that you use global groups or universal groups instead of domain local groups when you specify permissions on domain directory objects that
are replicated to the global catalog. For more information, see Global catalog replication.
Note
When the domain functional level is set to Windows 2000 mixed, members of global groups can include only accounts from the same domain.
When to use groups with universal scope

Use groups with universal scope to consolidate groups that span domains. To do this, add the accounts to groups with global scope, and then nest these groups within
groups that have universal scope. When you use this strategy, any membership changes in the groups that have global scope do not affect the groups with universal
scope.
For example, in a network with two domains, Europe and UnitedStates, and a group that has global scope called GLAccounting in each domain, create a group with
universal scope called UAccounting that has as its members the two GLAccounting groups, UnitedStates\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.
Do not change the membership of a group with universal scope frequently, because 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 universal groups and replication, see Global catalogs and sites.
Note
When the domain functional level is set to Windows 2000 mixed, you cannot create security groups with universal scope.
Changing group scope

When you create a new group, by default the new group is configured as a security group with global scope, regardless of the current domain functional level. Although
changing a group scope is not allowed in domains with a domain functional level of Windows 2000 mixed, the following conversions are allowed in domains with the
domain functional level of Windows 2000 native or Windows Server 2003:
Global to universal. This conversion is allowed only if the group that you want to change is not a member of another global scope group.
Domain local to universal. This conversion is allowed only if the group that you want to change does not have another domain local group as a member.
Universal to global. This conversion is allowed only if the group that you want to change does not have another universal group as a member.
Universal to domain local. There are no restrictions for this operation.
For more information, see Change group scope.
Groups on client computers 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, Windows XP Professional, Windows 2000 Server, and stand-alone servers running
Windows Server 2003 work the same way as in Windows NT 4.0:
Only local groups can be created locally on the computer.

A local group that is created on one of these computers can be assigned permissions only on that one computer.
For more information, see Default local groups.

Group types
Group types
Groups are used to collect user accounts, computer accounts, and other group accounts into manageable units. Working with groups instead of with individual users helps
simplify network maintenance and administration.
There are two types of groups in Active Directory: distribution groups and security groups. You can use distribution groups to create e-mail distribution lists and security
groups to assign permissions to shared resources.
Distributions groups
Distribution groups can be used only with e-mail applications (such as Exchange) to send e-mail to collections of users. Distribution groups are not security-enabled, which
means that they cannot be listed in discretionary access control lists (DACLs). If you need a group for controlling access to shared resources, create a security group.
Security groups
Used with care, security groups provide an efficient way to assign access to resources on your network. Using security groups, you can:
Assign user rights to security groups in Active Directory

User rights are assigned to security groups to determine what members of that group can do within the scope of a domain (or forest). User rights are automatically
assigned to some security groups at the time Active Directory is installed to help administrators define a person's administrative role in the domain. For example, a
user who is added to the Backup Operators group in Active Directory has the ability to backup and restore files and directories located on each domain controller in
the domain.
This is possible because by default, the user rights Back up files and directories and Restore files and directories are automatically assigned to the Backup
Operators group. Therefore, members of this group inherit the user rights assigned to that group. For more information about user rights, see User rights. For
more information about the user rights assigned to security groups, see Default groups.
You can assign user rights to security groups, using Group Policy, to help delegate specific tasks. You should always use discretion when assigning delegated tasks
because an untrained user assigned too many rights on a security group can potentially cause significant harm to your network. For more information, see
Delegating administration. For more information about assigning user rights to groups, see Assign user rights to a group in Active Directory.
Assign permissions to security groups on resources
Permissions should not be confused with user rights. Permissions are assigned to the security group on the shared resource. Permissions determine who can access
the resource and the level of access, such as Full Control. Some permissions set on domain objects are automatically assigned to allow various levels of access to
default security groups such as the Account Operators group or the Domain Admins group. For more information about permissions, see Access control in Active
Directory.
Security groups are listed in DACLs that define permissions on resources and objects. 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 assigned to that group in Active Directory and the permissions defined for
that group at the resource.
Like distribution groups, 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.
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 functional level is set to Windows 2000 native
or higher. No groups can be converted while the domain functional level is set to Windows 2000 mixed.
For specific procedural information, see Convert a group to another group type. For information about domain functionality, see Domain and forest functionality.
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.
Default groups
Default groups
Default groups, such as the Domain Admins group, are security groups that are created automatically when you create an Active Directory domain. You can use these
predefined groups to help control access to shared resources and delegate specific domain-wide administrative roles. For information about default groups stored on
local computers, see Default local groups.
Many default groups are automatically assigned a set of user rights that authorize members of the group to perform specific actions in a domain, such as logging on to a
local system or backing up files and folders. For example, a member of the Backup Operators group has the right to perform backup operations for all domain controllers
in the domain.
When you add a user to a group, the user receives all the user rights assigned to the group and all the permissions assigned to the group on any shared resources. For
more information about user rights and permissions, see Group types.
You can manage groups by using the Active Directory Users and Computers snap-in in Microsoft Management Console (MMC). Default groups are located in the Builtin
container and the Users container.
The Builtin container default groups contain groups that are defined with domain local scope. You can move groups in and out of this container, but you cannot move the
default groups in this container to another location or to another domain.
The Users container default groups contain groups that are defined with global scope and groups that are defined with domain local scope. You can add the groups in
this container to other groups and you can move the default groups in this container to other organizational units (OUs) or containers, but you cannot move the group to
another domain.
As a security best practice, it is recommended that members of default groups with broad administrative access use the Run as command to perform administrative tasks.
For more information, see Using Run as. For information about security best practices, see Active Directory Best practices. For information about additional security
measures that can be used to protect Active Directory, see Securing Active Directory.
Note
To learn what group you need to be a member of to perform a particular procedure, many procedural topics under How To in Help and Support Center provide a
note that identifies this information.
Groups in the Builtin container

The following table provides descriptions of the default groups located in the Builtin container and lists the assigned user rights for each group. For complete descriptions
Group
Description
Default user rights
Account
Operators
Members of this group can create, modify, and delete accounts for
users, groups, and computers located in the Users or Computers
containers and organizational units in the domain, except the Domain
Controllers organizational unit. Members of this group do not have
permission to modify the Administrators or the Domain Admins groups,
nor do they have permission to modify the accounts for members of
those groups. Members of this group can log on locally to domain
controllers in the domain and shut them down. Because this group has
significant power in the domain, add users with caution.
Administrators
Members of this group have full control of all domain controllers in the
domain. By default, the Domain Admins and Enterprise Admins groups
are members of the Administrators group. The Administrator account is
also a default member. Because this group has full control in the
domain, add users with caution.
Access this computer from the network; Adjust memory quotas for a
process; Back up files and directories; Bypass traverse checking; Change the
system time; Create a pagefile; Debug programs; Enable computer and
user accounts to be trusted for delegation; Force a shutdown from a
remote system; Increase scheduling priority; Load and unload device
drivers; Allow log on locally; Manage auditing and security log; Modify
firmware environment values; Profile single process; Profile system
performance; Remove computer from docking station; Restore files and
directories; Shut down the system; Take ownership of files or other objects.
Backup
Operators
Members of this group can back up and restore all files on domain
controllers in the domain, regardless of their own individual
permissions on those files. Backup Operators can also log on to
domain controllers and shut them down. This group has no default
members. Because this group has significant power on domain
controllers, add users with caution.
Back up files and directories; Allow log on locally; Restore files and
directories; Shut down the system.
Guests
By default, the Domain Guests group is a member of this group. The

Guest account (which is disabled by default) is also a default member
of this group.
Incoming
Members of this group can create one-way, incoming forest trusts to
Forest Trust
Builders (only
appears in the
forest root
domain)
the forest root domain. For example, members of this group residing in
Forest A can create a one-way, incoming forest trust from Forest B. This
one-way, incoming forest trust allows users in Forest A to access
resources located in Forest B. Members of this group are granted the
permission Create Inbound Forest Trust on the forest root domain. This
group has no default members. For more information about creating
forest trusts, see Create a forest trust.
Network
Configuration
Operators
Members of this group can make changes to TCP/IP settings and renew
and release TCP/IP addresses on domain controllers in the domain.
This group has no default members.
Performance
Monitor Users
Members of this group can monitor performance counters on domain

controllers in the domain, locally and from remote clients without being
a member of the Administrators or Performance Log Users groups.
Performance
Log Users
Members of this group can manage performance counters, logs and

alerts on domain controllers in the domain, locally and from remote
clients without being a member of the Administrators group.
PreWindows 2000
Compatible
Access
Members of this group have read access on all users and groups in the
domain. This group is provided for backward compatibility for
computers running Windows NT 4.0 and earlier. By default, the special
identity Everyone is a member of this group. For more information
about special identities, see Special identities. Add users to this group
only if they are running Windows NT 4.0 or earlier.
Access this computer from the network; Bypass traverse checking.
Print
Operators
Members of this group can manage, create, share, and delete printers
connected to domain controllers in the domain. They can also manage
Active Directory printer objects in the domain. Members of this group
can log on locally to domain controllers in the domain and shut them
down. This group has no default members. Because members of this
group can load and unload device drivers on all domain controllers in
the domain, add users with caution.
Remote
Desktop Users
Members of this group can remotely log on to domain controllers in

the domain. This group has no default members.
Replicator
This group supports directory replication functions and is used by the

File Replication service on domain controllers in the domain. This group
has no default members. Do not add users to this group.
Server
Operators
On domain controllers, members of this group can log on interactively,

create and delete shared resources, start and stop some services, back
up and restore files, format the hard disk, and shut down the computer.
This group has no default members. Because this group has significant
power on domain controllers, add users with caution.
Back up files and directories; Change the system time; Force shutdown from
a remote system; Allow log on locally; Restore files and directories; Shut
down the system.
Users
Members of this group can perform most common tasks, such as

running applications, using local and network printers, and locking the
server. By default, the Domain Users group, Authenticated Users, and
Interactive are members of this group. Therefore, any user account
created in the domain becomes a member of this group.
Groups in the Users container

The following table provides a description of the default groups located in the Users container and lists the assigned user rights for each group. For complete descriptions
Group
Description
Default user rights
Cert Publishers
Members of this group are permitted to publish

certificates for users and computers. This group has no
default members.
DnsAdmins
(installed with
DNS)
Members of this group have administrative access to the

DNS Server service. This group has no default members.
DnsUpdateProxy
(installed with
DNS)
Members of this group are DNS clients that can perform

dynamic updates on behalf of other clients, such as DHCP
servers. This group has no default members.
Domain Admins
Members of this group have full control of the domain. By

default, this group is a member of the Administrators
group on all domain controllers, all domain workstations,
and all domain member servers at the time they are
joined to the domain. By default, the Administrator
account is a member of this group. Because the group
delegation; Force a shutdown from a remote system; Increase scheduling priority; Load
has full control in the domain, add users with caution.
Domain
Computers
This group contains all workstations and servers joined to

the domain. By default, any computer account created
becomes a member of this group automatically.
Domain
Controllers
This group contains all domain controllers in the domain.
Domain Guests
This group contains all domain guests.
Domain Users
This group contains all domain users. By default, any user

account created in the domain becomes a member of this
group automatically. This group can be used to represent
all users in the domain. For example, if you want all
domain users to have access to a printer, you can assign
permissions for the printer to this group (or add the
Domain Users group to a local group, on the print server,
that has permissions for the printer).
Enterprise
Admins (only
appears in the
forest root
domain)
Members of this group have full control of all domains in

the forest. By default, this group is a member of the
Administrators group on all domain controllers in the
forest. By default, the Administrator account is a member
of this group. Because this group has full control of the
forest, add users with caution.
delegation; Force shutdown from a remote system; Increase scheduling priority; Load
Group Policy
Creator Owners
Members of this group can modify Group Policy in the

domain. By default, the Administrator account is a
power in the domain, add users with caution.
IIS_WPG
(installed with
IIS)
The IIS_WPG group is the Internet Information Services

(IIS) 6.0 worker process group. Within the functioning of
IIS 6.0 are worker processes that serve specific
namespaces. For example, www.microsoft.com is a
namespace served by one worker process, which can run
under an identity added to the IIS_WPG group, such as
MicrosoftAccount. This group has no default members.
RAS and IAS

Servers
Servers in this group are permitted access to the remote

access properties of users.
Schema Admins
(only appears in
the forest root
domain)
Members of this group can modify the Active Directory

schema. By default, the Administrator account is a
power in the forest, add users with caution.
See Also
Concepts
Using Run as
Create a shortcut using the runas command
Why you should not run your computer as an administrator
Other Resources
Run a program with administrative credentials
Nesting groups
Nesting groups
Using nesting, you can add a group as a member of another group. You nest groups to consolidate member accounts and reduce replication traffic.
Nesting options depend on whether the domain functionality of your Windows Server 2003 domain is set to Windows 2000 native or Windows 2000 mixed.
By default, when you nest a group within another group, user rights are inherited. For example, if you make Group_1 a member of Group_2, users in Group_1 have the
same permissions as the users in Group_2.
Groups in domains set to the Windows 2000 native functional level or distribution groups in domains set to the Windows 2000 mixed functional level can have the following
members:
Groups with universal scope can have the following members: accounts, computer accounts, other groups with universal scope, and groups with global scope from
any domain.
Groups with global scope can have the following members: accounts from the same domain and other groups with global scope from the same domain.
Groups with domain local scope can have the following members: accounts, groups with universal scope, and groups with global scope, all from any domain. This
group can also have as members other groups with domain local scope from within the same domain.
Security groups in domains set to the Windows 2000 mixed functional level 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 domains with the domain functional level set to Windows 2000 mixed because universal scope is supported only
in domains where the domain functional level is set to Windows 2000 native or Windows Server 2003.
Note
You cannot add the default groups that are located in the Builtin container as members to other groups. However, you can add other groups as members to the default
groups that are located in the Builtin container.
For more information about domain functionality, see Domain and forest functionality.
Special identities
Special identities
In addition to the groups in the Users and Builtin containers, servers running Windows Server 2003 include several special identities. For convenience, these identities are
generally referred to as groups. These special groups do not have specific memberships that can be modified, but they can represent different users at different times,
depending on the circumstances. The special groups are:
Anonymous Logon
Represents users and services that access a computer and its resources through the network without using an account name, password, or domain name. On
computers running Windows NT and earlier, the Anonymous Logon group is a default member of the Everyone group. On computers running a member of the
Windows Server 2003 family, the Anonymous Logon group is not a member of the Everyone group by default.
Everyone
Represents all current network users, including guests and users from other domains. Whenever a user logs on to the network, the user is 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, the user is 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, the user is automatically added to
the Interactive group.
Although the special identities can be assigned rights and permissions to resources, the memberships cannot be modified or viewed. 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.
For general information about groups, see Groups.


In Active Directory, groups are created in domains. You use Active Directory Users and Computers to create groups. With the necessary permissions, groups can be
created in the root domain of the forest, in 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 the domain functional level is set to Windows 2000 native or higher, the 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.
For information about the tools used to move groups between domains, see Using the Windows Deployment and Resource Kits.
Understanding trusts
Trusts
Trust types
Trust direction
Trust transitivity
Forest trusts
Trusts
Trusts
A trust is a relationship established between domains that enables users in one domain to be authenticated by a domain controller in the other domain. Trust relationships
in Windows NT are different than in Windows 2000 and Windows Server 2003 operating systems.
Trusts in Windows NT
In Windows NT 4.0 and earlier, trusts are limited to two domains and the trust relationship is one-way and nontransitive. In the following figure, the nontransitive, one-way
trust is shown by the straight arrow pointing to the trusted domain.
Trusts in Windows Server 2003 and Windows 2000 Server operating systems
All trusts in a Windows 2000 and Windows Server 2003 forest are transitive, two-way trusts. Therefore, both domains in a trust relationship are trusted. As shown in the
following figure, this means that if Domain A trusts Domain B and Domain B trusts Domain C, then users from Domain C can access resources in Domain A (when assigned
the proper permissions). Only members of the Domain Admins group can manage trust relationships.
Trust protocols
A domain controller running Windows Server 2003 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, Windows XP Professional, or Windows Server 2003. 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 account domain to verify the account credentials.
Trusted domain objects

Trusted domain objects (TDOs) are objects that represent each trust relationship within a particular domain. Each time a trust is established a unique TDO is created and
stored (in the System container) in its domain. Attributes such as a trust transitivity, type, and the reciprocal domain names are represented in a TDO.
Forest trust TDOs store additional attributes to identify all of the trusted namespaces from its partner forest. These attributes include domain tree names, user principal
name (UPN) suffixes, service principal name (SPN) suffixes, and security ID (SID) namespaces.
For more information about domain trusts, see "Domain Trust" at the Microsoft Windows Resource Kits Web site. For more information about trust relationships, see
"Designing an Authorization Strategy" at the Microsoft Windows Resource Kits Web site.
Trust types
Trust types
Communication between domains occurs through trusts. Trusts are authentication pipelines that must be present in order for users in one domain to access resources in
another domain. Two default trusts are created when using the Active Directory Installation Wizard. There are four other types of trusts that can be created using the New
Trust Wizard or the Netdom command-line tool.
Default trusts
By default, two-way, transitive trusts are automatically created when a new domain is added to a domain tree or forest root domain using the Active Directory Installation
Wizard. The two default trust types are defined in the following table.
Trust
type
Transitivity
Direction
Description
Parent
and
child
Transitive
Two-way
By default, when a new child domain is added to an existing domain tree, a new parent and child trust is established. Authentication
requests made from subordinate domains flow upward through their parent to the trusting domain. For information about creating
a new child domain, see Create a new child domain.
Treeroot
Transitive
Two-way
By default, when a new domain tree is created in an existing forest, a new tree-root trust is established. For information about
creating a new domain tree, see Create a new domain tree.
Other trusts
Four other types of trusts can be created using the New Trust Wizard or the Netdom command-line tool: external, realm, forest, and shortcut trusts. These trusts are
defined in the following table.
Trust
type
Transitivity
Direction
Description
External
Nontransitive
One-way
or twoway
Use external trusts to provide access to resources located on a Windows NT 4.0 domain or a domain located in a separate
forest that is not joined by a forest trust. For more information, see When to create an external trust.
Realm
Transitive or
nontransitive
One-way
or twoway
Use realm trusts to form a trust relationship between a non-Windows Kerberos realm and a Windows Server 2003 domain. For
more information, see When to create a realm trust.
Forest
Transitive
One-way
or twoway
Use forest trusts to share resources between forests. If a forest trust is a two-way trust, authentication requests made in either
forest can reach the other forest. For more information, see When to create a forest trust.
Shortcut
Transitive
One-way
or twoway
Use shortcut trusts to improve user logon times between two domains within a Windows Server 2003 forest. This is useful when
two domains are separated by two domain trees. For more information, see When to create a shortcut trust.
When creating external, shortcut, realm, or forest trusts, you have the option to create each side of the trust separately or both sides of a trust simultaneously.
If you choose to create each side of the trust separately, then you will need to run the New Trust Wizard twice--once for each domain. When creating trusts using the
method, you will need to supply the same trust password for each domain. As a security best practice, all trust passwords should be strong passwords. For more
information, see Strong passwords.
If you choose to create both sides of the trust simultaneously, you will need to run the New Trust Wizard once. When you choose this option, a strong trust password is
automatically generated for you.
You will need the appropriate administrative credentials for each domain between which you will be creating a trust.
Netdom.exe can also be used to create trusts. For more information about Netdom, see Active Directory support tools.
For more information about trusts, see Trust transitivity and Trust direction.
Trust direction
Trust direction
The trust type and its assigned direction will impact the trust path used for authentication. A trust path is a series of trust relationships that authentication requests must
follow between domains. Before a user can access a resource in another domain, the security system on domain controllers running Windows Server 2003 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 security system computes the trust path between a domain controller in the trusting domain and a domain controller in the trusted domain. In the
following figure, trust paths are indicated by arrows showing the direction of the trust (this is a one-way trust):
All domain trust relationships have only two domains in the relationship: the trusting domain and the trusted domain.
One-way trust
A one-way trust is a unidirectional authentication path created between two domains. This means that in a one-way trust between Domain A and Domain B, users in
Domain A (trusted domain) can access resources in Domain B (trusting domain). However, users in Domain B cannot access resources in Domain A. Some one-way trusts
can be a nontransitive trust or a transitive trust depending on the type of trust being created. For more information about trust types, see Trust types.
Two-way trust
All domain trusts in a Windows Server 2003 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, both domains that are involved in a trust relationship trust each other. This means that
authentication requests can be passed between the two domains in both directions. Some two-way relationships can be nontransitive or transitive depending on the type
of trust being created. For more information, see Trust types.
A Windows Server 2003 domain can establish a one-way or two-way trust with:
Windows Server 2003 domains in the same forest

Windows Server 2003 domains in a different forest
Windows NT 4.0 domains
Kerberos V5 realms
For more information Kerberos V5, see Kerberos V5 authentication.

Trust transitivity
Trust transitivity
Transitivity determines whether a trust can be extended outside of the two domains with which it was formed. A transitive trust can be used to extend trust relationships
with other domains and a nontransitive trust can be used to deny trust relationships with other domains.
Transitive trusts
Each time you create a new domain in a forest, a two-way, transitive trust relationship is automatically created between the new domain and its parent domain. If child
domains are added to the new domain, the trust path flows upward through the domain hierarchy extending the initial trust path created between the new domain and its
parent domain.
Transitive trust relationships flow upward through a domain tree as it is formed, creating transitive trusts between all domains in the domain tree.
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, accounts with the proper permissions can access resources in any domain in the forest. For more information, see Authentication protocols overview.
The diagram displays that all domains in the Domain A tree and all domains in the Domain 1 tree have transitive trust relationships by default. As a result, users in the
Domain A tree can access resources in domains in the Domain 1 tree and users in the Domain 1 tree can access resources in the Domain A tree, when the proper
permissions are assigned at the resource.
In addition to the default transitive trusts established in a Windows Server 2003 forest, using the New Trust Wizard, you can manually create the following transitive trusts.
Shortcut trust. A transitive trust between a domain in the same domain tree or forest used to shorten the trust path in a large and complex domain tree or forest.
Forest trust. A transitive trust between a forest root domain and a second forest root domain.
Realm trust. A transitive trust between an Active Directory domain and an Kerberos V5 realm. For more information about Kerberos V5 realms, see Kerberos V5
authentication.
Nontransitive trust
A nontransitive trust is restricted by the two domains in the trust relationship and does not flow to any other domains in the forest. A nontransitive trust can be a two-way
trust or a one-way trust.
Nontransitive trusts are one-way by default, although you can also create a two-way relationship by creating two one-way trusts. In summary, nontransitive domain trusts
are the only form of trust relationship possible between:
A Windows Server 2003 domain and a Windows NT domain

A Windows Server 2003 domain in one forest and a domain in another forest (when not joined by a forest trust)
Using the New Trust Wizard, you manually create the following nontransitive trusts:
External trust. A nontransitive trust created between a Windows Server 2003 domain and a Windows NT domain or a Windows 2000 domain or Windows
Server 2003 domain in another forest.
When you upgrade a Windows NT domain to a Windows Server 2003 domain, all existing Windows NT trusts are preserved intact. All trust relationships between
Windows Server 2003 domains and Windows NT domains are nontransitive.
Realm trust. A nontransitive trust between an Active Directory domain and an Kerberos V5 realm. For more information about Kerberos V5 realms, see Kerberos
V5 authentication.



You can create an external trust to form a one-way or two-way, nontransitive trust with domains outside of your forest. External trusts are sometimes necessary when users
need access to resources located in a Windows NT 4.0 domain or in a domain located within a separate forest that is not joined by a forest trust, as shown in the figure.
When a trust is established between a domain in a particular forest and a domain outside of that forest, security principals from the external domain can access 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.
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 To view advanced features.
In domains with the functional level set to Windows 2000 mixed, it is recommended that you delete external trusts from a domain controller running Windows Server 2003.
External trusts to Windows NT 4.0 or 3.51 domains can be deleted by authorized administrators on the domain controllers running Windows NT 4.0 or 3.51. However, only
the trusted side of the relationship can be deleted on the domain controllers running Windows NT 4.0 or 3.51. The trusting side of the relationship (created in the
Windows Server 2003 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 domain controller running Windows Server 2003 in the trusting domain. If an external trust is inadvertently
deleted from a domain controller running Windows NT 4.0 or 3.51, you will need to recreate the trust from any domain controller running Windows Server 2003 in the
trusting domain.
For more information about how to create an external trust, see Create an external trust.
Securing external trusts

To improve the security of Active Directory forests, domain controllers running Windows Server 2003 and Windows 2000 Service Pack 4 (or higher) enable security identifier
(SID) filter quarantining on all new outgoing external trusts by default.
By applying SID filter quarantining to outgoing external trusts, you prevent malicious users who have domain administrator level access in the trusted domain from
granting, to themselves or other user accounts in their domain, elevated user rights to the trusting domain.
When a malicious user can grant unauthorized user rights to another user it is known as an elevation of privilege attack. For more information about SID filtering and how
to further mitigate an elevation of privilege attack, see MS02-001: Forged SID could result in elevated privileges in Windows 2000 (http://go.microsoft.com/fwlink/?
LinkId=102075).
How SID filter quarantining works

When security principals are created in a domain, the domain SID is included in the security principal's SID to identify the domain in which it was created. The domain SID is
an important characteristic of a security principal because the Windows security subsystem uses it to verify the security principal's authenticity.
In a similar fashion, outgoing external trusts created from the trusting domain use SID filter quarantining to verify that incoming authentication requests made from security
principals in the trusted domain contain SIDs of security principals from the trusted domain only. This is done by comparing the SIDs of the incoming security principal to
the domain SID of the trusted domain. If any of the security principal SIDs include a domain SID other than the one from the trusted domain, the trust removes the
offending SID.
SID filtering ensures that any misuse of the SID history attribute on security principals (including inetOrgPerson) in the trusted forest cannot pose a threat to the integrity of
the trusting forest.
The SID history attribute can be useful to domain administrators when they migrate user and group accounts from one domain to another. Domain administrators can add
SIDs from an old user or group account to the SID history attribute of the new, migrated account. By doing this, domain administrators give the new account the same level
of access to resources as the old account.
If domain administrators could not use the SID history attribute in this way, they would have to track down and reapply permissions for the new account on each network
resource that the old account had access to.
Understanding the threat

If not for SID filtering on outgoing external trusts, a malicious user with administrative credentials residing in the trusted domain could sniff network authentication requests
from the trusting domain to obtain the SID information of a user who has full access to resources in the trusting domain, such as a domain administrator.
After obtaining the domain administrators SID from the trusting domain, a malicious user with administrative credentials can add that SID to a user account's SID history
attribute in the trusted domain and attempt to gain full access to the trusting domain and the resources within that domain. In this scenario, a malicious user who has
domain administrator credentials in the trusted domain is a threat to the entire trusting forest.
SID filtering neutralizes the threat of malicious users in the trusted domain from using the SID history attribute to gain elevated privileges.
Impact of SID filter quarantining

SID filter quarantining on external trusts can affect your existing Active Directory infrastructure in the following two areas:
SID history data that contains SIDs from any domain other than the trusted domain will be removed from authentication requests made from the trusted domain.
This will result in access being denied to resources that have the user's old SID.
Universal group access control strategy between forests will require changes.
When SID filter quarantining is enabled, users who use SID history data for authorization to resources in the trusting domain no longer have access to those resources.
If you typically assign universal groups from a trusted forest to access control lists (ACLs) on shared resources in the trusting domain, SID filter quarantining will have a
major impact on your access control strategy.
Because universal groups must adhere to the same SID filter quarantining guidelines as other security principal objects (that is, the universal group object SID must also
contain the domain SID), you should verify that any universal groups that are assigned to shared resources in the trusting domain were created in the trusted domain.
If the universal group in the trusted forest was not created in the trusted domain, even though it may contain users from the trusted domain as members, authentication
requests made from members of that universal group will be filtered and discarded.
Therefore, before assigning access to resources in the trusting domain for users in the trusted domain, you should confirm that the universal group containing the trusted
domain users was created in the trusted domain.
Disabling SID Filter quarantining

Although it is not recommended, you can disable SID filter quarantining for an external trust by using the Netdom.exe tool. You should consider disabling SID filter
quarantining only in the following situations:
You have the same level of trust for all administrators who have physical access to domain controllers in the trusted domain as the administrators in the trusting
domain.
You have a strict requirement to assign universal groups to resources in the trusting domain that were not created in the trusted domain.
Users have been migrated to the trusted domain with their SID histories preserved, and you want to grant them access to resources in the trusting domain based on
the SID history attribute.
Only domain administrators can disable SID filtering. To disable SID filter quarantining for the trusting domain, type the following syntax at a command-prompt:
Netdom trust TrustingDomainName /domain: TrustedDomainName /quarantine:No /userD:domainadministratorAcct/passwordD:domainadminpwd
To enable SID filter quarantining, set the /quarantine: command-line option to Yes. For more information about Netdom.exe, see Active Directory support tools.
You can enable or disable SID filter quarantining only from the trusting side of the trust. If the trust is a two-way trust, you can also disable SID filter quarantining in the
trusted domain by using the domain administrator's credentials for the trusted domain and reversing the TrustingDomainName and TrustedDomainName values in the
command-line syntax.
Notes
To further secure your forest, you should consider enabling SID filter quarantining on all existing external trusts that were created by domain controllers running
Windows 2000 Service Pack 3 (or earlier). You can do this by using Netdom.exe to enable SID filtering on existing external trusts, or by recreating these external
trusts from a domain controller running Windows Server 2003 or Windows 2000 Service Pack 4 (or later).
You cannot turn off the default behavior that enables SID filter quarantining for newly created external trusts.
External trusts created from domain controllers running Windows 2000 Service Pack 3 (or earlier) do not enforce SID filter quarantining by default.
Domain controllers running Windows NT Server 4.0 do not take part in the trust creation process when existing domain controllers in the same domain are running
Windows 2000 or Windows Server 2003.
You can enable or disable SID filter quarantining only for trusts that extend beyond forest boundaries such as external and forest trusts. For more information about
SID filtering and forest trusts, see Forest trusts.
Allowing SID history to traverse forest trusts

If you are migrating users from one domain to another in different forests, you may want to allow the migrated users to access resources in their original forest by using
their migrated (SID history) credentials. The default SID filtering that is applied to forest trusts prevents user-resource-access requests from traversing the trusts with the
credentials of the original domain. If you want to make it possible for users to use the credentials that were migrated from their original domain, you can allow SID history
to traverse forest trusts by using the netdom command.
Only domain administrators or enterprise administrators can modify SID filtering settings. To allow SID history credentials to traverse a trust relationship between two
forests, type a command using the following syntax at a command prompt, and then press ENTER:
Netdom trust TrustingDomainName /domain: TrustedDomainName /enablesidhistory:Yes /usero:domainadministratorAcct/passwordo:domainadminpwd
To re-enable the default SID filtering setting across forest trusts, set the /enablesidhistory: command-line option to No. For more information about Netdom, see
Domain and Forest Trust Tools and Settings.
Note
The same security considerations for removing SID filter quarantining from external trusts apply to allowing SID history to traverse forest trusts.


Shortcut trusts are one-way or two-way, transitive trusts that can be used when administrators need to optimize the authentication process. Authentication requests must
first travel a trust path between domain trees, and in a complex forest this can take time, which can be reduced with shortcut trusts. A trust path is the series of domain
trust relationships that must be traversed in order to pass authentication requests between any two domains. For more information about trust paths, see Trust direction.
Shortcut trusts are necessary when many users in a domain regularly log on to other domains in a forest. For example, using the following figure as an example, you could
form a shortcut trust between domain B and domain D or domain A and domain 1 and so on.
Shortcut trusts effectively shorten the path traveled for authentication's made between domains located in two separate trees.
For more information about how to create a shortcut trust, see Create a shortcut trust.
Using one-way trusts

A one-way, shortcut trust established between two domains located in separate domain trees can reduce the time needed to fulfill authentication requests, but in only one
direction. For example, when a one-way, shortcut trust is established between domain A and domain B, authentication requests made in domain A to domain B can utilize
the new one-way trust path. However, authentication requests made in domain B to domain A will still need to travel the longer trust path.
Using two-way trusts

A two-way, shortcut trust established between two domains located in separate domain trees will reduce the time needed to fulfill authentication requests originating in
either domain. For example, when a two-way trust is established between domain A and domain B, authentication requests made from either domain to the other can
utilize the new, two-way trust path.


A realm trust can be established between any non-Windows Kerberos V5 realm and a Windows Server 2003 domain. This trust relationship allows cross-platform
interoperability with security services based on other Kerberos V5 versions such as UNIX and MIT implementations. Realm trusts can switch from nontransitive to transitive
and back. Realm trusts can also be either one-way or two-way.
For more information about how to create a realm trust, see Create a realm trust.


A forest trust can only be created between a forest root domain in one Windows Server 2003 forest and a forest root domain in another Windows Server 2003 forest.
Creating a forest trust between two Windows Server 2003 forests provides a one-way or two-way, transitive trust relationship between every domain residing within each
forest. Forest trusts are useful for Application Service Providers, companies undergoing mergers or acquisitions, collaborative business extranets, and companies seeking a
solution for administrative autonomy.
For more information about creating forest trusts, see Checklist: Creating a forest trust.
Note
You should not enable SID filter quarantining on forest trusts, that is, by using the netdom command with the /quarantine:yes option. However, if you have migrated
users from one Windows Server 2003 forest to another and the migrated users need access to resources in the former domain, you can relax the default SID filtering
that is applied to a forest trust by using the netdom command with the /enablesidhistory:yes option. Using that command on a forest trust reduces the level of SID
filtering on the forest trust. So, ensure that you trust the administrators of the trusted domain, as well as their security practices.
Using one-way forest trusts

A one-way, forest trust between two forests allows members of the trusted forest to utilize resources located in the trusting forest. However, the trust operates in only one
direction. For example, when a one-way, forest trust is created between forest A (the trusted forest) and forest B (the trusting forest), members of forest A can access
resources located in forest B, but members of forest B cannot access resources located in forest A using the same trust.
Using two-way forest trusts

A two-way, forest trust between two forests allows members from either forest to utilize resources located in the other forest; domains in each respective forest trust
domains in the other forest implicitly. For example, when a two-way, forest trust is established between forest A and forest B, members of forest A can access resources
located in forest B, and members of forest B can access resources in forest A, using the same trust.
Forest trusts
Forest trusts
In a Windows Server 2003 forest, you can link two disjoined Windows Server 2003 forests together to form a one-way or two-way, transitive trust relationships. A two-way,
forest trust is used to form a transitive trust relationship between every domain in both forests.
Forest trusts can provide the following benefits:
Simplified management of resources across two Windows Server 2003 forests by reducing the number of external trusts necessary to share resources.
Complete two-way trust relationships with every domain in each forest.
Use of user principal name (UPN) authentication across two forests.
Use of both the Kerberos V5 and NTLM authentication protocols to improve the trustworthiness of authorization data transferred between forests.
Flexibility of administration. Administrative tasks can be unique to each forest.
Forest trusts can only be created between two forests and cannot be implicitly extended to a third forest. This means that if a forest trust is created between forest 1 and
forest 2, and a forest trust is also created between forest 2 and forest 3, forest 1 will not have an implicit trust with forest 3. For more information about the requirements
needed for a forest trust, see When to create a forest trust.
Notes
In a Windows 2000 forest, if users in one forest need to access resources in another forest, an administrator can create an external trust relationship between the
two domains. External trusts can be one-way or two-way and are nontransitive, and therefore, limit the ability for trust paths to extend to other domains. For more
information about external trusts, see Trust types.
All trusts in Windows Server 2003 Active Directory use security identifier (SID) filtering to some degree. External trusts are quarantined by default, which prevents any
domain SIDs other than those of the quarantined trusted domain from traversing the trust relationship. SID filtering is used to prevent attacks from malicious users
who might try to grant elevated user rights to another user account. SID filtering on forest trusts does not prevent migrations to domains within the same forest
from using SID history and will not affect your universal group access control strategy. For more information about SID filtering, see When to create an external
trust.
Managing a multiple forest environment

Forest trusts help you to manage a segmented Active Directory infrastructure within your organization by providing support for accessing resources and other objects
across multiple forests. For more information about accessing resources across multiple forests, see Accessing resources across forests.
Because each forest is administered separately, adding additional forests to your organization increases your organization's management needs. For more information,
see Creating a new forest.
Reasons to create multiple forests in your organization include:
To secure data within each forest. Sensitive data can be protected so that only users within that forest can access it.
To isolate directory replication within each forest. Schema changes, configuration changes, and the addition of new domains to a forest only have forest-wide
impact within that forest, not on a trusting forest.
Delegating forest-wide administrative control

Active Directory data that is stored in the schema and configuration containers is replicated to every domain controller in the forest. Since changes to the schema and
configuration containers will affect all domains in the forest, administrative control for forest-wide changes should be entrusted to highly trained or experienced
administrators. All domain data contained in the forest root domain should also be regarded as highly sensitive data.
The following groups provide forest-wide administrative control in each forest:
Enterprise Admins
Domain Admins (in the forest root domain)
Schema Admins
Since membership in any of these groups can affect forest-wide behavior, add users with caution. As a security best practice, avoid adding users from another forest to
any of these forest-wide administrative groups. For more information about these groups, see Default groups.
Synchronizing data across forests

You can synchronize global address lists (GALs) and objects across forests using Microsoft Metadirectory Services (MMS) or another supported synchronization tool.
Common data types that need synchronization across forests include:
GALs (Exchange)
Public folders
Directory objects
Synchronizing this data across forests will help end users view address lists and other data the same way as they do when viewing this information within their own forest.
For more information about MMS, see Microsoft Metadirectory Services.


Since two or more Active Directory domains within the same forest are implicitly connected by two-way, transitive trusts, authentication requests made from one domain to
another are successfully routed in order to provide a seamless coexistence of resources across domains. Users can only gain access to resources in other domains after
first being authenticated in their own domain.
Domain controllers running Windows 2000 or Windows Server 2003 authenticate users and applications using one of two authentication protocols: Kerberos V5 or NTLM.
For more information about Kerberos authentication, see Kerberos V5 authentication. For more information about NTLM authentication, see NTLM authentication. For
more information about the Active Directory authentication process, see Access control in Active Directory.
Once authenticated, the user can attempt to gain access to resources from any domain in the forest using the Active Directory authorization process. For more information
about the Active Directory authorization process, see Security information for Active Directory.
To access a shared resource in another domain using Kerberos, a user's workstation first requests a ticket from a domain controller in its account domain to the server
(hosting the resource) in the trusting domain. This ticket is then issued by an intermediary trusted by the workstation and the server. The workstation presents this trusted
ticket to the server in the trusting domain for authentication.
The following figure and corresponding steps provide a detailed description of the Kerberos authentication process that is used when a computer running Windows 2000
Professional, Windows 2000 Server, Windows XP Professional, or a member of the Windows Server 2003 family attempts to access resources from a server located in
another domain.
1. User1 logs on to Workstation1 using credentials from the child1.microsoft.com domain. As part of this process, the authenticating domain controller issues User1 a
ticket-granting ticket (TGT). This ticket is required to be authenticated to resources. The user then attempts to access a shared resource (\\fileserver1\share) on a file
server located in the child2 domain.
2. Workstation1 contacts the Key Distribution Center (KDC) on a domain controller in its domain (ChildDC1) and requests a service ticket for the FileServer1 service
principal name (SPN).
3. ChildDC1 does not find the SPN in its domain database and queries the global catalog to see if any domains in the forest contain this SPN. The global catalog sends
the requested information back to ChildDC1.
4. ChildDC1 sends the referral to Workstation1.
5. Workstation1 contacts a domain controller in ForestRootDC1 (its parent domain) for a referral to a domain controller (ChildDC2) in the Child2 domain.
ForestRootDC1 sends the referral to Workstation 1.
6. Workstation1 contacts the KDC on ChildDC2 and negotiates the ticket for the user to gain access to FileServer1.
7. Now that Workstation1 has a service ticket, it sends the service ticket to FileServer1, which reads the user's security credentials and constructs an access token
accordingly.
Each domain has its own set of security policies that do not cross from one domain to another. For more information, see Domains.
Planning your access control strategy for multiple domains

groups throughout each domain in a single forest will be an important factor to consider during your planning. For information about planning an access control strategy
for multiple forests, see Accessing resources across forests.

Group nesting. The ability to nest security groups is dependent on group scopes and domain functionality. For more information, see Nesting groups.
Best practices for controlling access to shared resources across domains

By carefully using domain local, global, and universal groups, administrators can more effectively control access to resources located in other domains. Consider the
Organize domain users based on administrative needs, such as their locations or departments, and then create a global group, and add the appropriate user
accounts as members.
For example, add all employee user accounts in the Sales department to the Sales Department global group, and add all employee user accounts in the Accounting
Department to the Accounting Department global group.
Create a domain local group, and add all global groups from the other domains that need the same access to a resource in your domain.
For example, employees in the Sales Department and Accounting Department global groups located in DomainA use similar print resources located in DomainB. To
make future administration changes more flexible, create a domain local group called Print Resources in DomainB, and add as members both the Sales Department
and Accounting Department global groups in DomainA.
Assign the required permissions on the shared resource to the domain local group.
For example, assign permissions to the Print Resources domain local group located in DomainB so that its members, including the Sales Department and Accounting
Department groups from DomainA, can access the printer located in DomainB.
Selective authentication between domains in an external trust

Using Active Directory Domains and Trusts, you can determine the scope of authentication between two domains that are joined by an external trust. You can set selective
authentication differently for outgoing and incoming external trusts. With selective trusts, administrators can make flexible access control decisions between external
domains. For more information about how to set selective authentication, see Select the scope of authentication for users.
If you use domain-wide authentication on the incoming external trust, users in the second domain would have the same level of access to resources in the local domain as
users who belong to the local domain. For example, if DomainA has an incoming external trust from DomainB and domain-wide authentication is used, any user from
DomainB would be able to access any resource in DomainA (assuming that they have the required permissions).
If you set selective authentication on an incoming external trust, you need to manually assign permissions on each resource to which you want users in the second domain
to have access. To do this, set a control access right Allowed to authenticate on an object for that particular user or group from the external domain.
When a user authenticates across a trust with the Selective authentication option enabled, an Other Organizationsecurity ID (SID) is added to the user's authorization data.
The presence of this SID prompts a check on the resource domain to ensure that the user is allowed to authenticate to the particular service. Once the user is
authenticated, if the Other Organization SID is not already present, then the server adds the This Organization SID. Only one of these special SIDs can be present in an
authenticated user's context. For more detailed information about how selective authentication works, see Security Considerations for Trusts.
Administrators in each domain can add objects from one domain to access control lists (ACLs) on shared resources in the other domain. You can use the ACL editor to add
or remove objects residing in one domain to ACLs on resources in the other domain. For more information about how to set permissions on resources, see Set
permissions on a shared resource.
For information about setting authentication restrictions for multiple forests, see Accessing resources across forests.

Updated: February 21, 2006

When two Windows Server 2003 forests are connected by a forest trust, authentication requests made using the Kerberos V5 or NTLM protocols can be routed between
forests to provide access to resources in both forests. For more information about routing authentication requests across forests, see Routing name suffixes across
forests.
Before authentication protocols can follow the forest trust path, the service principal name (SPN) of the resource computer must be resolved to a location in the other
forest. An SPN can be one of the following:
Domain Name System (DNS) name of a host

DNS name of a domain
Distinguished name of a service connection point object
When a workstation in one forest attempts to access data on the resource computer in another forest, Kerberos contacts the domain controller for a service ticket to the
SPN of the resource computer. Once the domain controller queries the global catalog and identifies that the SPN is not in the same forest as the domain controller, the
domain controller sends a referral for its parent domain back to the workstation. At that point, the workstation queries the parent domain for the service ticket and follows
the referral chain until it gets to the domain where the resource is located.
The following figure and corresponding steps provide a detailed description of the Kerberos authentication process that is used when computers running Windows 2000
Professional, Windows XP Professional, Windows 2000 Server, or a member of the Windows Server 2003 family attempt to access resources from a computer located in
another forest.
1. User1 logs on to Workstation1 using credentials from the child.microsoft.com domain. The user then attempts to access a shared resource on FileServer1 located in
the msn.com forest.
2. Workstation1 contacts the Key Distribution Center (KDC) on a domain controller in its domain (ChildDC1) and requests a service ticket for the FileServer1 SPN.
3. ChildDC1 does not find the SPN in its domain database and queries the global catalog to see if any domains in the microsoft.com forest contain this SPN. Since a
global catalog is limited to its own forest, the SPN is not found. The global catalog then checks its database for information about any forest trusts that are
established with its forest, and, if found, it compares the name suffixes listed in the forest trust trusted domain object (TDO) to the suffix of the target SPN to find a
match. Once a match is found, the global catalog provides a routing hint back to ChildDC1.
4. ChildDC1 sends a referral for its parent domain back to Workstation1.
5. Workstation1 contacts a domain controller in ForestRootDC1 (its parent domain) for a referral to a domain controller (ForestRootDC2) in the forest root domain of
the msn.com forest.
6. Workstation1 contacts ForestRootDC2 in the msn.com forest for a service ticket to the requested service.
7. ForestRootDC2 contacts its global catalog to find the SPN, and the global catalog finds a match for the SPN and sends it back to ForestRootDC2.
8. ForestRootDC2 then sends the referral to child.msn.com back to Workstation1.
9. Workstation1 contacts the KDC on ChildDC2 and negotiates the ticket for User1 to gain access to FileServer1.
10. Now that workstation1 has a service ticket, it sends the server service ticket to FileServer1, which reads User1's security credentials and constructs an access token
accordingly.
When a forest trust is first established, each forest collects all of the trusted namespaces in its partner forest and stores the information in a TDO. Trusted namespaces
include domain tree names, user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security ID (SID) namespaces used in the other forest. TDO
objects are replicated to the global catalog. For more information about TDOs, see Trusts.
Routing hints
Routing hints are only used when all traditional authentication channels (local domain controller and then global catalog) have failed to produce a location of a SPN.
Routing hints help direct authentication requests toward the destination forest.
When an SPN cannot be located in the domain from where the network logon request originated or from the global catalog database, the global catalog checks the forest
trust TDO for trusted name suffixes located in the other forest that might match the suffix in the SPN. If a match is found, the forest root domain returns a routing hint back
to the original source computer so that it can continue the SPN location process in the other forest.
Notes
Routing hints can only reference trusted name suffixes that are listed in the TDO for its forest trust. They do not verify the name suffix before sending the hint back
to the original source computer.
Accessing NetBIOS names and Kerberos delegation across forest trusts is not supported. NTLM is fully supported and cannot be disabled.
Planning your access control strategy for multiple forests

groups throughout each forest will be an important factor to consider during your planning. For information about planning an access control strategy for multiple
domains, see Accessing resources across domains.
Group nesting. The ability to nest security groups is dependent on groups scopes and domain functionality. For more information, see Nesting groups.
Best practices for using security groups across forests

By carefully using domain local, global, and universal groups, administrators can more effectively control access to resources located in other forests. Consider the
To represent the sets of users who need access to the same types of resources, create role-based global groups in every domain and forest that contains these
users. For example, users in the Sales Department in ForestA require access to an order-entry application that is a resource in ForestB. Account Department users in
ForestA require access to the same application, but these users are in a different domain. In ForestA, create the global group SalesOrder and add users in the Sales
Department to the group. Create the global group AccountsOrder and add users in the Accounting Department to that group.
To group the users from one forest who require similar access to the same resources in a different forest, create universal groups that correspond to the global
group roles. For example, in ForestA, create a universal group called SalesAccountsOrders and add the global groups SalesOrder and AccountsOrder to the group.
Note
Universal groups are not available as security groups in Windows 2000 Server mixed-mode domains or in Windows Server 2003 domains that have a domain
functional level of Windows 2000 mixed. They are available as distribution groups.
To assign permissions to resources that are to be accessed by users from a different forest, create resource-based domain local groups in every domain and use
these groups to assign permissions on the resources in that domain. For example, in ForestB, create a domain local group called OrderEntryApp. Add this group to
the access control list (ACL) that allows access to the order entry application, and assign appropriate permissions.
To implement access to a resource across a forest, add universal groups from trusted forests to the domain local groups in the trusting forests. For example, add
the SalesAccountsOrders universal group from ForestA to the OrderEntryApp domain local group in ForestB.
When a new user account needs access to a resource in a different forest, add the account to the respective global group in the domain of the user. When a new resource
needs to be shared across forests, add the appropriate domain local group to the ACL for that resource. In this way, access is enabled across forests for resources on the
basis of group membership.
For more information, see Set permissions on a shared resource.
Selective authentication between forests

Using Active Directory Domains and Trusts, you can determine the scope of authentication between two forests that are joined by a forest trust. You can set selective
authentication differently for outgoing and incoming forest trusts. With selective trusts, administrators can make flexible forest-wide access control decisions. For more
information about how to set selective authentication, see Select the scope of authentication for users.
If you use forest-wide authentication on an incoming forest trust, users from the outside forest have the same level of access to resources in the local forest as users who
belong to the local forest. For example, if ForestA has an incoming forest trust from ForestB and forest-wide authentication is used, users from ForestB would be able to
access any resource in ForestA (assuming they have the required permissions).
If you decide to set selective authentication on an incoming forest trust, you need to manually assign permissions on each computer in the domain as well as the resources
to which you want users in the second forest to have access. To do this, set a control access right Allowed to authenticate on the computer object that hosts the resource in
Active Directory Users and Computers in the second forest. Then, allow user or group access to the particular resources you want to share.
When a user authenticates across a trust with the Selective authentication option enabled, an Other Organization security ID (SID) is added to the user's authorization
data. The presence of this SID prompts a check on the resource domain to ensure that the user is allowed to authenticate to the particular service. Once the user is
authenticated, then the server to which he authenticates adds the This Organization SID if the Other Organization SID is not already present. Only one of these special SIDs
can be present in an authenticated user's context. For more detailed information about how selective authentication works, see Security Considerations for Trusts.
Administrators in each forest can add objects from one forest to access control lists (ACLs) on shared resources in the other forest. You can use the ACL editor to add or
remove objects residing in one forest to ACLs on resources in another forest. For more information about how to set permissions on resources, see Set permissions on a
shared resource.
For information about setting authentication restrictions for external domains, see Accessing resources across domains.


Name suffix routing is a mechanism used to manage how authentication requests are routed across Windows Server 2003 forests that are joined together by forest trusts.
To simplify administration of authentication requests, when a forest trust is initially created, all unique name suffixes are routed by default. A unique name suffix is a name
suffix within a forest, such as a user principal name (UPN) suffix, service principal name (SPN) suffix, or DNS forest or domain tree name, that is not subordinate to any
other name suffix. For example, the DNS forest name microsoft.com is a unique name suffix within the microsoft.com forest.
Forests can contain multiple unique name suffixes, and all children of unique name suffixes are routed implicitly. In Active Directory Domains and Trusts, name suffixes
appear with an asterisk (*) at the beginning because of this. For example, if your forest uses *.microsoft.com as a unique name suffix, then authentication requests for all
children of microsoft.com (*.child.microsoft.com) will be routed because the child domains are part of the microsoft.com name suffix.
If a forest trust exists between two forests, then name suffixes that do not exist in one forest can be used to route authentication requests to a second forest. When a new
child name suffix (*.child.widgets.com) is added to a unique name suffix (*.widgets.com), the child name suffix will inherit the routing configuration of the unique name suffix
to which it belongs. Any new unique name suffixes that are created after a forest trust has been established will be visible in the forest trust Properties dialog box after you
verify the trust. However, routing for those new unique name suffixes will be disabled by default. For more information about how to verify a trust, see Verify a trust.
When a duplicate name suffix is detected, the routing for the newest name suffix will be disabled by default. For more information about how to route name suffixes, see
Enable or disable an existing name suffix from routing. Administrators can use the forest trust Properties dialog box to manually prevent authentication requests for
specific name suffixes from being routed to a forest.
Notes
Do not add the @ sign to the UPN suffix or a user name. When authentication requests are routed to a trusted forest, all characters before the first @ symbol are
interpreted as the user name and everything after the first @ symbol as the UPN suffix.
The Local Security Authority (LSA) will block routing to any UPN suffix that is not a valid DNS name. For example, adding an @ symbol to a UPN suffix will cause it to
automatically be disabled.
Collision detection
When two Windows Server 2003 forests are linked by a forest trust, there is a possibility that unique name suffixes existing in one forest might collide with unique name
suffixes located in the second forest. Collision detection guarantees that each name suffix will only be routed to a single forest.
Active Directory Domains and Trusts will detect a name suffix conflict when:
The same Domain Name System (DNS) name is already in use.

The same NetBIOS name is already in use.
A domain security ID (SID) conflicts with another name suffix SID.
When a name suffix in a forest conflicts with a new forest trust partner or when a name suffix in an existing forest trust conflicts with a new forest trust partner, the name
will be disabled in the new trust. For example, a conflict will occur if one forest is named widgets.com and the second forest is named sales.widgets.com. Despite the name
suffix conflict, routing will still work for any other unique name suffixes in the second forest.
For another example, assume that the msn.com forest needs to establish a two-way, forest trust with the widgets.com forest. Both msn.com and widgets.com have identical
UPN suffixes of microsoft.com. During the creation of the two-way, forest trust, the New Trust Wizard will detect and display the conflict between the two UPN name
suffixes and then create the forest trust.
If Active Directory Domains and Trusts detects a name suffix conflict with a trust partner domain, access to that domain from outside the forest may be denied. However,
access to the conflicted domain from within its forest will function normally.
For example, if the domain widgets.com exists in both the msn.com and microsoft.com forests, users within the msn.com forest will be able to access resources in
widgets.com domain that resides in the msn.com forest. However, users in the msn.com forest will be denied access to resources in the widgets.com domain located in the
microsoft.com forest.
Conflicts will be listed in Active Directory Domains and Trusts, in the forest trust Properties dialog box, on the Name Suffix Routing tab. If a name suffix conflict is
detected during the creation of the forest trust, then the New Trust Wizard will prompt you to save a log file of the conflicts. You can also save a log file after a trust has
been created. For more information about how to save this log file, see Change the routing status of a name suffix.
If a NetBIOS or domain SID conflict exists, Active Directory Domains and Trusts identifies the name suffixes routing status as enabled or disabled with exceptions, as
appropriate. The details about where the conflict exists are listed in the log file.
You can also use the Netdom command-line tool to list all routed names and to enable and disable routing for NetBIOS names and SIDs. For example, a forest named
microsoft.com has a forest trust with widgets.com and you also need to add a forest trust to msn.com. Both widgets.com and msn.com have child domains with the
NetBIOS name of SALES (and DNS names of USsales.widgets.com and sales.msn.com).
After you create the new trust to msn.com, routing to the SALES domain name in msn.com will be disabled. If you need to use the name SALES to route to the msn.com
forest but don't need to use it to the widgets.com forest, you can use Netdom to disable SALES in widgets.com, and then enable it in msn.com.
For information about Netdom, see Active Directory support tools.

Understanding sites and replication

Sites overview
Bandwidth
Sites overview
Sites overview
Sites in Active Directory represent the physical structure, or topology, of your network. Active Directory uses topology information, stored as site and site link objects in
the directory, to build the most efficient replication topology. You use Active Directory Sites and Services to define sites and site links. A site is a set of well-connected
subnets. Sites differ from domains; sites represent the physical structure of your network, while domains represent the logical structure of your organization.
Using sites
Sites help facilitate several activities within Active Directory, including:
Replication. Active Directory balances the need for up-to-date directory information with the need for bandwidth optimization by replicating information within a
site more frequently than between sites. You can also configure the relative cost of connectivity between sites to further optimize replication. For more information,
see Replication between sites and Managing replication.
Authentication. Site information helps make authentication faster and more efficient. When a client logs on to a domain, it first searches its local site for a domain
controller to authenticate against. By establishing multiple sites, you can ensure that clients authenticate against domain controllers nearest to them, reducing
authentication latency and keeping traffic off WAN connections.
Active Directory-enabled services. Active Directory-enabled services can leverage site and subnet information to enable clients to locate the nearest server
providers more easily. For information about services, see Services.
Defining sites using subnets

In Active Directory, a site is a set of computers well-connected by a high-speed network, such as a local area network (LAN). All computers within the same site typically
reside in the same building, or on the same campus network. A single site consists of one or more Internet Protocol (IP) subnets. Subnets are subdivisions of an IP network,
with each subnet possessing its own unique network address. A subnet address groups neighboring computers in much the same way that postal codes group
neighboring postal addresses. The following figure shows several clients within a subnet that defines an Active Directory site.
Sites and subnets are represented in Active Directory by site and subnet objects, which you create through Active Directory Sites and Services. Each site object is associated
with one or more subnet objects.
For information about creating sites, see Create a site.
For information about creating subnets, see Create a subnet.
For information about subnets, see "Introduction to TCP/IP" at the Microsoft Windows Resource Kits Web site.
Assigning computers to sites

Computers are assigned to sites based on their Internet Protocol (IP) address and subnet mask. Site assignment is handled differently for clients and member servers than
for domain controllers. For a client, site assignment is dynamically determined by its IP address and subnet mask during logon. For a domain controller, site membership is
determined by the location of its associated server object in Active Directory. For more information, see "Active Directory Replication" at the Microsoft Windows Resource
Kits Web site.
For information about associating subnets with sites, see Associate a subnet with a site.
For information about establishing single or multiple sites, see When to establish a single or separate sites.
Understanding sites and domains

In Active Directory, sites map the physical structure of your network, while domains map the logical or administrative structure of your organization. This separation of
physical and logical structure provides the following benefits:
You can design and maintain the logical and physical structures of your network independently.
You do not have to base domain namespaces on your physical network.
You can deploy domain controllers for multiple domains within the same site. You can also deploy domain controllers for the same domain in multiple sites.
For more information about domains, see Domains.

Except for very small networks, directory data must reside in more than one place on the network to be equally useful to all users. Through replication, the
Active Directory directory service maintains replicas of directory data on multiple domain controllers, ensuring directory availability and performance for all users. Active
Directory uses a multimaster replication model, allowing you to make directory changes at any domain controller, not just at a designated primary domain controller.
Active Directory relies on the concept of sites to help keep replication efficient, and on the Knowledge Consistency Checker (KCC) to automatically determine the best
replication topology for the network.
Organizing data for replication

Data is stored on each domain controller in the directory store, which is divided logically into specific directory partitions. Each partition stores a different type of directory
data, either domain data, forest schema data, forest configuration data, or application data. All domain controllers within a forest hold a replica of the schema and
configuration partitions for that forest, and all domain controllers within a particular domain hold a replica of the domain partition for their domain. Application directory
partitions hold directory data specific to a particular application and can be stored by domain controllers belonging to different domains. Changes to each directory
partition are replicated to all other domain controllers that hold a copy of that partition. For more information, see Directory data store.
Replication also ensures the availability of the global catalog throughout the entire forest. The global catalog is a searchable directory store containing data about every
object in all domains. The global catalog is stored by domain controllers for which the global catalog has been enabled. For more information, see Global catalog
replication.
Improving replication efficiency with sites

To help make replication more efficient, Active Directory relies on sites. Sites, defined as groups of well-connected computers, determine how directory data is replicated.
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 replicated updates first. The domain controllers in other sites also receive the changes, but less frequently, reducing network
bandwidth consumption. For more information, see How replication works and Sites overview.
Determining the replication topology

The Knowledge Consistency Checker (KCC), a process running on each domain controller, automatically identifies the most efficient replication topology for your network,
based on information you provide about your network in Active Directory Sites and Services. The KCC regularly recalculate the replication topology to adjust for any
network changes that have occurred. The KCC of one domain controller within each site (the intersite topology generator) determines the intersite replication topology. For
more information about the KCC, see Active Directory Replication Technologies.
Replication enhancements in the Windows Server 2003 family

The Microsoft Windows Server 2003 family includes enhancements to make replication both more efficient, as well as more scalable across a larger number of domains
and sites. These include refinements in memory usage, enhancements to the Windows 2000 spanning tree algorithm, a completely new spanning tree algorithm for
Windows Server 2003 forests, and a new load balancing tool.
In a forest set to the Windows 2000 functional level, the replication enhancements provide gains in replication efficiency and scalability, even when sites and domains
contain domain controllers running Windows 2000. If a site contains at least one domain controller running Windows Server 2003, then a domain controller running
Windows Server 2003 assumes the intersite topology generator role for the site, allowing the enhancements to take effect.
In a forest set to the Windows Server 2003 functional level, the new Windows Server 2003 spanning tree algorithm goes into effect for larger gains in both efficiency and
scalability. For example, using the original spanning tree algorithm from Windows 2000, one domain can contain up to 300 sites. With the new Windows Server 2003
algorithm, one domain can contain up to at least 3,000 sites. In the new algorithm, the intersite topology generator in each site uses a randomized selection process to
determine the bridgehead servers for the site. This selection process more evenly distributes the bridgehead replication workload among domain controllers in a site,
resulting in much better efficiency (particularly in hub sites with a number of domain controllers). By default, the randomized selection process takes place only when new
connection objects are added to the site. However, a new tool, called adlb.exe, can be run to rebalance the load each time changes occur in the topology or in the number
of domain controllers in the site. In addition, adlb can stagger schedules so that the outbound replication load for each server is spread out evenly across time. For more
information about adlb and to download the tool, see the "Windows Server 2003 Active Directory Branch Office Planning and Deployment Guide."


To keep directory data on all domain controllers consistent and up to date, Active Directory replicates directory changes on a regular basis. Replication occurs over
standard network protocols, uses change tracking information to prevent unnecessary replication, and uses linked value replication to improve efficiency.
Transferring replication data

Active Directory uses remote procedure call (RPC) over Internet Protocol (IP) to transfer replication data between domain controllers. RPC over IP is used for both intersite
and intrasite replication. To keep data secure while in transit, RPC over IP replication uses both authentication (using the Kerberos V5 authentication protocol) and data
encryption.
When a direct or reliable IP connection is not available, replication between sites can be configured to use the Simple Mail Transfer Protocol (SMTP). However, SMTP
replication functionality is limited, and requires an enterprise certification authority (CA). SMTP can only be used to replicate the configuration, schema and application
directory partitions, and does not support the replication of domain directory partitions. For more information, see "Active Directory Replication" at the Microsoft Windows
Resource Kits Web site.
Preventing unnecessary replication

Once a domain controller has processed a directory change from another domain controller successfully, it should not try to replicate those changes back to the domain
controller that sent the change. In addition, a domain controller should avoid sending updates to another domain controller if the target domain controller has already
received that same update from a different replication partner. To prevent such unnecessary replication, Active Directory uses change tracking information stored in the
directory. For information about change tracking, see "Active Directory Replication" at the Microsoft Windows Resource Kits Web site.
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 in the same
domain before replication of either change occurs. In such a case, both changes are replicated as new changes, creating a conflict. To resolve this conflict, domain
controllers that receive these conflicting changes examine the attribute data contained within the changes, each of which holds a version and a timestamp. Domain
controllers will accept the change with the higher version and discard the other change. If the versions are identical, domain controllers will accept the change with the
more recent timestamp.
Improving replication efficiency

Introduced in the Windows Server 2003 family, linked value replication allows individual values of a multivalued attribute to be replicated separately. In Windows 2000, when
a change was made to a member of a group (one example of a multivalued attribute with linked values) the entire group had to be replicated. With linked value replication,
only the group member that has changed is replicated, and not the entire group. To enable linked value replication, you must raise the forest functional level to Windows
Server 2003 . For more information about forest functional levels, see Domain and forest functionality. For more information about multivalued attributes, see Schema.
For more information about how replication works, see "Active Directory Replication" at the Microsoft Windows Resource Kits Web site.


Active Directory handles replication within a site, or intrasite replication, differently than replication between sites because bandwidth within a site is more readily available.
The Active Directory Knowledge Consistency Checker (KCC) builds the intrasite replication topology using a bidirectional ring design. Intrasite replication is optimized for
speed, and directory updates within a site occur automatically on the basis of change notification. Unlike replication data travelling between sites, directory updates
replicated within a site are not compressed.
For information about intersite replication, see Replication between sites and How replication works.
Building the intrasite replication topology

The Knowledge Consistency Checker (KCC) on each domain controller automatically builds the most efficient replication topology for intrasite replication, using a
bidirectional ring design. This bidirectional ring topology attempts to create at least two connections to each domain controller (for fault tolerance) and no more than
three hops between any two domain controllers (to reduce replication latency). To prevent connections of more than three hops, the topology can include shortcut
connections across the ring. The KCC updates the replication topology regularly.
Note
The KCC actually creates a separate replication topology for each directory partition (schema, configuration, domain, application). Within a single site, these
topologies are usually identical for all partitions hosted by the same set of the domain controllers.
Determining when intrasite replication occurs

Directory updates made within a site are likely to have the most direct impact on local clients, so intrasite replication is optimized for speed. Replication within a site occurs
automatically on the basis of change notification. Intrasite replication begins when you make a directory update on a domain controller. By default, the source domain
controller waits 15 seconds and then sends an update notification to its closest replication partner. If the source domain controller has more than one replication partner,
subsequent notifications go out by default at 3 second intervals to each partner. After receiving notification of a change, a partner domain controller sends a directory
update request to the source domain controller. The source domain controller responds to the request with a replication operation. The 3 second notification interval
prevents the source domain controller from being overwhelmed with simultaneous update requests from its replication partners.
For some directory updates in a site, the 15 second waiting time does not apply and replication occurs immediately. Known as urgent replication, this immediate replication
applies to critical directory updates, including the assigning of account lockouts and changes in the account lockout policy, the domain password policy, or the password
on a domain controller account.
For more information about intrasite replication, see "Active Directory Replication" at the Microsoft Windows Resource Kits Web site.


Active Directory handles replication between sites, or intersite replication, differently than replication within sites because bandwidth between sites is usually limited. The
Active Directory Knowledge Consistency Checker (KCC) builds the intersite replication topology using a least-cost spanning tree design. Intersite replication is optimized for
bandwidth efficiency, and directory updates between sites occur automatically based on a configurable schedule. Directory updates replicated between sites are
compressed to preserve bandwidth.
For information about intrasite replication, see Replication within a site.
For information about site design, see "Designing the Site Topology" at the Microsoft Windows Resource Kits Web site.
Building the intersite replication topology

Active Directory automatically builds the most efficient intersite replication topology using information you provide (through Active Directory Sites and Services) about your
site connections. The directory stores this information as site link objects. One domain controller per site, called the intersite topology generator, is assigned to build the
topology. A least-cost spanning tree algorithm is used to eliminate redundant replication paths between sites. The intersite replication topology is updated regularly to
respond to any changes that occur in the network. You can control intersite replication through the information you provide when you create your site links. For more
information, see Managing replication.
Determining when intersite replication occurs

Active Directory preserves bandwidth between sites by minimizing the frequency of replication and by allowing you to schedule the availability of site links for replication.
By default, intersite replication across each site link occurs every 180 minutes (3 hours). You can adjust this frequency to match your specific needs. Be aware that increasing
this frequency increases the amount of bandwidth used by replication. In addition, you can schedule the availability of site links for use by replication. By default, a site link
is available to carry replication traffic 24 hours a day, 7 days a week. You can limit this schedule to specific days of the week and times of day. You can, for example,
schedule intersite replication so that it only occurs after normal business hours. For more information, see Configure site link replication frequency and Configure site link
replication availability.
Notes
With certain restrictions, you can use the Simple Mail Transfer Protocol (SMTP) for replicating to sites that do not have a direct or reliable Internet Protocol (IP)
connection. For more information, see "Active Directory Replication" at the Microsoft Windows Resource Kits Web site.
Intersite replication through a firewall or virtual private network requires some special considerations. For more information, see Active Directory at the Microsoft
Web site.


You can optimize the replication efficiency and reduce the administrative overhead of your network by establishing sites appropriately. The most effective number of sites
depends on the physical design of your network. When you first create a new forest, a single, default Active Directory site (called Default-Site-First-Name) is created that
represents your entire network. A forest or domain consisting of a single site can be very efficient for a single location network connected completely by high-speed
bandwidth. If your forest or domain contains multiple geographic locations that communicate over low-speed wide area network (WAN) connections, establishing multiple
sites gives you more detailed control of replication behavior, reduces authentication latency, and reduces network traffic on the WAN.
For information about sites, see Sites overview.
For information about designing a site topology, see "Designing the Site Topology" at the Microsoft Windows Resource Kits Web site.
Why bandwidth is important

Within a site, bandwidth affects how efficiently replication can work. The frequency with which intrasite replication occurs requires high-speed bandwidth to function most
effectively. So before you a create new site, you should make sure that high-speed bandwidth connects all computers within the site candidate. Any area where domain
controllers are connected by 10 megabits per second (Mbps) or more of bandwidth is a good site candidate.
When to establish a single site

If you have a single LAN consisting of a single subnet, or if your network contains multiple subnets connected by a high-speed backbone, establishing a single site
replication topology can provide the following benefits:
Simplified replication management

Prompt directory updates between all domain controllers
A single site topology allows all replication on your network to occur as intrasite replication, which requires no manual replication configuration. A single site design also
allows all domain controllers to remain very current with respect to directory changes, because directory updates are replicated almost immediately. For more information,
see Replication within a site. For information about creating sites, see Create a site.
When to establish multiple sites

When your network consists of multiple geographic locations connected by a WAN, establishing separate sites for each location provides the following benefits:
Efficient use of WAN bandwidth for replication

Detailed control of replication behavior
Reduction in authentication latency
Physically separate network locations typically communicate over WAN connections, which are most often characterized by low-speed bandwidth. By creating a separate
site for each physical location on your network, you ensure that domain controllers communicating over WAN connections use intersite replication, which is specifically
designed for efficiency on low bandwidth connections. For more information, see Replication between sites.
With multiple sites, you have more detailed control of replication behavior through several configurable intersite replication settings. These settings include the relative cost
of different replication paths, the domain controllers associated with each site, the subnets associated with each site, the frequency of directory update transfers, and the
availability of connections for use by replication. For more information, see Managing replication.
A network client logging on to a domain must contact a domain controller as part of the authentication process, first looking within its own site. If the site includes two or
more physically separate network locations, the client may authenticate against a domain controller across a WAN connection. Authentication across a WAN introduces a
delay in the authentication process. By placing physically separate network locations into separate Active Directory sites, you can ensure that clients first attempt to
authenticate against a domain controller in their own site.
Bandwidth
Bandwidth
Bandwidth is the most important practical consideration affecting intrasite 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:
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.
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 about how bandwidth may affect the way you configure sites, see Replication between sites.
Active Directory relies on site configuration information to manage and optimize the process of replication. Active Directory provides automatic configuration of these
settings in some cases. In addition, you can configure site-related information for your network using Active Directory Sites and Services. Configurable information includes
settings for site links, site link bridges, and bridgehead servers.
Configuring site links

You can use site link settings to control replication between sites. Configurable settings include the relative cost of each site link, the frequency of replication on each site
link, and the schedule availability of each site link for replication. For information about site links, see Replication between sites.
Site link cost

The cost of a site link determines the relative preference of the Active Directory Knowledge Consistency Checker (KCC) for using a site link in the replication topology. The
higher the cost of the site link, the lower will be the KCC's preference for using the site link. For example, if you have two site links, site link A and site link B, and you set the
cost of site link A to 150 and the cost of site link B to 200, the KCC will prefer to use site link A in the replication topology. By default, the cost of a newly created site link is
100. For information about setting site link cost, see Configure site link cost. For information about the KCC, see Replication overview.
Replication frequency
The replication frequency of a site link determines how often replication occurs over that site link. By default, the replication frequency for a site link is 180 minutes, meaning
that replication occurs over that site link every 180 minutes, or three hours. Using Active Directory Sites and Services, you can set the replication frequency from 15 minutes
to 10,080 minutes (one week). A site link must be available for any replication to occur. If a site link is not available when the number of minutes between replication
updates has passed, no replication will occur. For more information, see Configure site link replication frequency.
Site link availability

The availability schedule for a site link determines during which hours or days of the week a site link can be used for replication. By default, a site link is always available for
replication, 24 hours a day and 7 days a week. You can change this schedule, for example, to exclude business hours during which your network is busy handling other
types of traffic. Or, you can exclude particular days on which you do not want replication to occur. Scheduling information is ignored by site links that use the Simple Mail
Transfer Protocol (SMTP) for replication. For more information, see Configure site link replication availability.
Configuring site link bridges

By default, all site links are bridged, or transitive. This allows any two sites that are not connected by an explicit site link to communicate directly, through a chain of
intermediary site links and sites. One advantage to bridging all site links is that your network is easier to maintain because you do not need to create a site link to describe
every possible path between pairs of sites.
Generally, you can leave automatic site link bridging enabled. However, you might want to disable automatic site link bridging and create site link bridges manually just for
specific site links, in the following cases:
Your network is not fully routed (not every domain controller can directly communicate with every other domain controller).
You have a network routing or security policy in place that prevents every domain controller from being able to directly communicate with every other domain
controller.
Your Active Directory design includes a large number of sites. For more information, see the Active Directory Branch Office Planning Guide at the Microsoft Web site.
For more information about site link bridges and their affects on replication, see "Active Directory Replication" at the Microsoft Windows Resource Kits Web site.
For information about disabling automatic site link bridging, see Enable or disable site link bridges.
For information about creating a site link bridge manually, see Create a site link bridge.
Configuring preferred bridgehead servers

When the KCC constructs the intersite replication topology, it automatically assigns one or more bridgehead servers for each site to ensure that directory changes only
need to be replicated across a site link one time. It is recommended that you allow the KCC to make the bridgehead server assignments. You can make the bridgehead
server assignments manually through Active Directory Sites and Services. However, doing so can potentially disrupt replication if one of your manually assigned
bridgehead servers becomes unavailable. For more information, see "Active Directory Replication" at the Microsoft Windows Resource Kits Web site.
For information about manually configuring a bridgehead server, see Designate a preferred bridgehead server.

Understanding the global catalog




A global catalog is a domain controller that stores a copy of all Active Directory objects in a forest. The global catalog stores a full copy of all objects in the directory for
its host domain and a partial copy of all objects for all other domains in the forest, as shown in the following figure.
The partial copies of all domain objects included in the global catalog are those most commonly used in user search operations. These attributes are marked for inclusion
in the global catalog as part of their schema definition. Storing the most commonly searched upon attributes of all domain objects in the global catalog provides users
with efficient searches without affecting network performance with unnecessary referrals to domain controllers.
You can manually add or remove other object attributes to the global catalog by using the Active Directory Schema snap-in. For more information, see Customizing the
global catalog.
A global catalog is created automatically on the initial domain controller in the forest. You can add global catalog functionality to other domain controllers or change the
default location of the global catalog to another domain controller. For more information, see Enable or disable a global catalog.
A global catalog performs the following directory roles:
Finds objects
A global catalog enables user searches for directory information throughout all domains in a forest, regardless of where the data is stored. Searches within a forest
are performed with maximum speed and minimum network traffic.
When you search for people or printers from the Start menu or choose the Entire Directory option within a query, you are searching a global catalog. Once you
enter your search request, it is routed to the default global catalog port 3268 and sent to a global catalog for resolution. For more information, see Finding
directory information and "Finding information in Active Directory" at the Microsoft Windows Resource Kits Web site.
Supplies user principal name authentication
A global catalog resolves user principal names UPNs when the authenticating domain controller does not have knowledge of the account. For example, if a users
account is located in example1.microsoft.com and the user decides to log on with a user principal name of user1@example1.microsoft.com from a computer
located in example2.microsoft.com, the domain controller in example2.microsoft.com will be unable to find the users account, and will then contact a global catalog
to complete the logon process. For more information, see Active Directory naming.
Supplies universal group membership information in a multiple domain environment
Unlike global group memberships, which are stored in each domain, universal group memberships are only stored in a global catalog. For example, when a user
who belongs to a universal group logs on to a domain that is set to the Windows 2000 native domain functional level or higher, the global catalog provides
universal group membership information for the users account at the time the user logs on to the domain.
If a global catalog is not available when a user logs on to a domain set to the functional level of Windows 2000 native or higher, the computer will use cached
credentials to log on the user if the user has logged on to the domain previously. If the user has not logged on to the domain previously, the user can only log on
to the local computer. However, if a user logs on as the Administrator in the domain (Builtin Administrator account), the user can always log on to the domain, even
when a global catalog is not available.
For more information about universal groups, see Group scope. For more information about universal groups and replication, see Global catalog replication and
Global catalogs and sites.
Note
When there is only one domain in a forest, it is not necessary for users to obtain universal group memberships from a global catalog when logging on. This
is because Active Directory can detect that there are no other domains in the forest and will prevent a query to the global catalog for this information.
Validates object references within a forest
A global catalog is used by domain controllers to validate references to objects of other domains in the forest. When a domain controller holds a directory object
with an attribute containing a reference to an object in another domain, this reference is validated using a global catalog.


Replication of the global catalog ensures that users throughout the forest have fast access to information about every object in the forest. The default attributes that make
up the global catalog provide a baseline of the most commonly searched attributes. These attributes are replicated to the global catalog as part of normal Active Directory
replication.
The replication topology for the global catalog is generated automatically by the Knowledge Consistency Checker (KCC). However, the global catalog is replicated only to
other domain controllers that have been designated as global catalogs. Global catalog replication is affected both by the attributes marked for inclusion in the global
catalog, and by universal group memberships.
Adding attributes
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 the Active Directory Schema snap-in, you can specify additional attributes to be kept in the global catalog.
In Windows 2000 forests, extending the partial attribute set causes a full synchronization of all object attributes stored in the global catalog (for all domains in the forest).
In a large, multi-domain forest, this synchronization can cause significant network traffic. Between domain controllers enabled as global catalogs that are running Windows
Server 2003, only the newly added attribute is replicated. For more information about adding attributes to the global catalog, see Customizing the global catalog.
Preventing unpredictable access to global catalog data

Special security consideration should be given when specifying permissions on domain data that is also replicated to the global catalog. When a user connects to a global
catalog, an impersonation token is created for the user, which is used in subsequent access control decisions on the global catalog. The user's universal, global and
domain local group memberships are represented in this token. However, only domain local groups from the domain that the domain controller hosting the global catalog
(to which the user has connected) belongs to and of which the user is a member show up in the user's token. Domain local groups in the user's domain (and in other
domains) of which the user is a member do not show up in the access token.
A global catalog stores a replicated, read-only copy of all objects in the forest and a partial set of each object's attributes, including the security descriptor for each object.
The security descriptor contains a discretionary access control list (DACL), which specifies permissions on the object. When a user connects to a global catalog and tries to
access an object, an access check is performed based on the user's token and the object's DACL. Any permissions specified in the object's DACL for domain local groups
that are not from the domain that the domain controller hosting the global catalog (to which the user has connected) belongs to, will be ineffective because only domain
local groups from the global catalog's domain of which the user is a member are represented in the user's access token. As a result, a user may be denied access when
access should have been granted, or allowed access when access should have been denied.
As a best practice, you should avoid using domain local groups when assigning permissions on Active Directory objects, or be aware of the implications if you do use
them. To prevent unauthorized access to global catalog data, use global groups or universal groups instead. For information about global and universal groups, see
Group scope.
How universal groups affect global catalog replication

Groups with universal scope, and their members, are listed exclusively in the global catalog. Groups with 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 the replication traffic associated with keeping 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.
When you first create a universal group, you do so from any domain that is set to the domain functional level of Windows 2000 or higher. The universal group resides in
the domain directory partition in which it was created and is also replicated to the global catalog. Updates to the group membership are thereafter replicated to both the
domain and the global catalog.
For more information about domain functional levels, see Domain and forest functionality.


There may be instances where you will need to customize the global catalog to include additional attributes. However, you will want to carefully consider your options as
changes to attributes can impact network traffic. By default, the global catalog contains an objects most common attributes for every object in the entire forest, which
applications and users can query. For example, you can find a user by first name, last name, e-mail address, or other common properties of a user account.
To add additional searchable attributes to the global catalog, administrators can use the Active Directory Schema snap-in. For more information about adding additional
attributes to the global catalog, see Add an attribute to the global catalog.
When determining whether or not to add an attribute to the global catalog, consider only adding additional attributes that are frequently queried and referenced by users
or applications across the enterprise. Also consider how frequently an attribute gets updated during replication. Attributes that are stored in the global catalog are
replicated to every global catalog in the forest. The smaller the attribute, the lower the impact of that replication. If the attribute is large, but very seldom changes, it will
have a smaller replication impact than a small attribute that changes often.
For more information about attribute definitions, see the Active Directory Programmer's Guide at the Microsoft Web site.
Important
It is strongly recommended that you use global groups or universal groups instead of domain local groups when specifying permissions on domain directory
partition objects replicated to the global catalog. For more information, see Global catalog replication.
Notes
In Windows 2000, 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 Windows 2000 forest, this synchronization can cause significant network traffic. Between domain controllers enabled as global catalogs that are
running Windows Server 2003, only the newly added attribute is replicated.
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.


To optimize network performance in a multiple site environment, consider adding global catalogs for select sites. In a single site environment, a single global catalog is
usually sufficient to cover common Active Directory queries. The following table will help you determine whether your multiple site environment will benefit using additional
global catalogs.
Use a global catalog when
Advantage
Disadvantage
A commonly used application in the site utilizes port 3268 to resolve global catalog queries.
Performance
improvement
Additional
network traffic
due to
replication
A slow or unreliable WAN connection is used to connect to other sites. Use the same failure and load distribution rules that you used
for individual domain controllers to determine whether additional global catalog servers are necessary in each site.
Fault
tolerance
Additional
network traffic
due to
replication
Users in the site belong to a Windows 2000 domain running in native mode. In this case, all users must obtain universal group
membership information from a global catalog server. If a global catalog is not located within the same site all logon requests must
be routed over your WAN connection to a global catalog located in another site.
If a domain controller running Windows Server 2003 in the site has universal group membership caching enabled, then all users will
obtain a current cached listing of their universal group memberships.
Fast user
logons
Additional
network traffic
due to
replication
Note
Network traffic related to global catalog queries generally use more network resources than normal directory replication traffic.
Universal group membership caching

Due to available network bandwidth and server hardware limitations, it may not be practical to have a global catalog in smaller branch office locations. For these sites, you
can deploy domain controllers running Windows Server 2003, which can store universal group membership information locally.
Information is stored locally once this option is enabled and a user attempts to log on for the first time. The domain controller obtains the universal group membership for
that user from a global catalog. Once the universal group membership information is obtained, it is cached on the domain controller for that site indefinitely and is
periodically refreshed. The next time that user attempts to log on, the authenticating domain controller running Windows Server 2003 will obtain the universal group
membership information from its local cache without the need to contact a global catalog.
By default, the universal group membership information contained in the cache of each domain controller will be refreshed every 8 hours. To refresh the cache, domain
controllers running Windows Server 2003 will send a universal group membership confirmation request to a designated global catalog. Up to 500 universal group
memberships can be updated at once. Universal group membership caching can be enabled using Active Directory Sites and Services. Universal group membership
caching is site specific and requires that all domain controllers running Windows Server 2003 be located in that site to participate. For more information about how to
enable this option, see Cache universal group memberships.
The following list summarizes potential benefits for caching universal group memberships in branch office locations:
Faster logon times since authenticating domain controllers no longer need to access a global catalog to obtain universal group membership information.
No need to upgrade hardware of existing domain controllers to handle the extra system requirements necessary for hosting a global catalog.
Minimized network bandwidth usage since a domain controller will not have to handle replication for all of the objects located in the forest.
Note
You might want to continue using a global catalog in branch office locations if an application in a site is sending global catalog queries to port 3268. Universal
group membership caching does not intercept calls made to port 3268.


DNS integration
DNS integration
DNS integration
Active Directory is integrated with DNS in the following ways:
Active Directory and Domain Name System (DNS) have the same hierarchical structure.
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. For more information, see Namespace planning for DNS.
DNS zones can be stored in Active Directory.
If you are using the Windows Server 2003 DNS Server 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.
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 about how Active Directory clients rely on DNS, see Locating a domain controller.
Note
You can use Dcdiag.exe and Netdiag.exe to troubleshoot client computers that cannot locate a domain controller. These tools can help determine both server and
client DNS misconfigurations. For more information, see article Q265706, "DCDiag/NetDiag Facilitate Join and DC Creation" in the Microsoft Knowledge Base. For a
brief description of support tools, see Active Directory support tools.
While Active Directory is integrated with DNS and shares the same namespace structure, it is important to distinguish 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
domain controllers using the Lightweight Directory Access Protocol (LDAP). In order to locate a domain controller, an Active Directory client queries DNS. Active
Directory requires DNS to function.
For a checklist on deploying DNS for Active Directory, see Checklist: Deploying DNS for Active Directory.
For information about configuring DNS servers for Active Directory, see Configure a DNS server for use with Active Directory.


Group Policy can be used to define default settings that will be automatically applied to user and computer accounts in Active Directory. Policy settings can be used to
manage desktop appearance, assign scripts, redirect folders from local computers to network locations, determine security options and control what software can be
installed on particular computers and what software is available to particular groups of users.
Here are a few examples of how Group Policy settings can be used in Active Directory:
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.
Logon, logoff, startup, and shutdown scripts can be assigned based on the locations of the computer and user accounts in Active Directory.
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.
Policy settings are stored in Group Policy objects. 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 and how to create a Group Policy object, see Group Policy (pre-GPMC).
You can use security groups 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 security groups, see Group types. For general information about Group Policy, see Group Policy overview.
Understanding schema
Schema
Schema object names
Schema
Schema
The Active Directory schema contains the definitions for all objects in the directory. Every new directory object you create is validated against the appropriate object
definition in the schema before being written to the directory. The schema is made up of object classes and attributes. The base (or default) schema contains a rich set of
object classes and attributes to meet the needs of most organizations, and is modeled after the International Standards Organization (ISO) X.500 standard for directory
services. Because it is extensible, you can modify and add classes and attributes to the base schema. However, you should carefully consider each change you make,
because extending the schema affects the entire network. For more information, see Extending the schema.
How directory objects are defined

In the schema, an object class represents a category of directory objects, such as users, printers, or application programs, that share a set of common characteristics. The
definition for each object class contains a list of the schema attributes that can be used to describe instances of the class. For example, the User class has attributes such
as givenName, surname, and streetAddress. When you create a new user in the directory the user becomes an instance of the User class, and the information you enter
about the user becomes instances of the attributes. For more information, see Schema classes and attributes.
How the schema is stored

Each forest can contain only one schema, which is stored in the schema directory partition. The schema directory partition, along with the configuration directory partition,
is replicated to all domain controllers in a forest. However, a single domain controller, the schema master, controls the structure and content of the schema. For more
information about the schema master, see Operations master roles.
Schema cache
To improve performance on schema operations (such as new object validation), each domain controller holds a copy of the schema in memory (in addition to the copy it
holds on disk). This cached version is automatically updated (after a small time interval) each time you update the schema. Or, you can reload the updated schema to cache
manually for immediate effect. For more information, see Reload the schema.
Securing the schema

Like every object in Active Directory, schema objects are protected from unauthorized use by access control lists (ACLs). By default, only members of the Schema Admins
group have write access to the schema. So, to extend the schema you must be a member of the Schema Admins group. The only default member of the Schema Admins
group is the administrator account in the root domain of the forest. You should restrict membership in the Schema Admins group because extending the schema
improperly can have serious consequences to your network. For more information, see Access control in Active Directory and Default groups.
For more information about the schema, see "Active Directory Schema" at the Microsoft Windows Resource Kits Web site and at the Microsoft MSDN Web site.


Every directory object you create is an instance of an object class contained in the schema. Each object class contains a list of associated attributes that determine the
information the object can contain. Classes and attributes are defined independently, so that a single attribute can be associated with multiple classes. All schema classes
and attributes are defined by the classSchema and attributeSchema objects, respectively.
Classes
ClassSchema objects are used to define classes in the schema. A classSchema object provides the template for building directory objects of that class. Examples of
classSchema include User and Server. A classSchema object contains, among other things, the following information:
Class type (structural, abstract, or auxiliary)

Common name and Lightweight Directory Access Protocol (LDAP) display name
Lists of the "must contain" and "may contain" attributes for instances of the object
Relative distinguished name attribute
A list of possible parent classes
Class types
Three different types of classes exist in the schema:
Class type
Purpose
Structural
Used to instantiate objects (users, servers and so on) in the directory.
Abstract
Provides templates for deriving structural classes
Auxiliary
Contains predefined lists of attributes that can be included in structural and abstract classes.
Note
With the Windows Server 2003 family, the inetOrgPerson class is now a part of base schema. This class can be used as a security principal in the same manner as
the user class.
Attributes
AttributeSchema objects are used to define attributes in the schema. An attributeSchema object determines the allowable contents and syntax for instances of that attribute
in the directory. Examples of attributeSchema include User-Principal-Name and Telex-Number. An attributeSchema object contains, among other things, the following
information:
Common name and LDAP display name

Syntax rules
Data constraints (single versus multivalued, minimum, and maximum values)
Whether and how the attribute is indexed
Single and multivalued attributes

Attributes can be single-valued or multivalued. An instance of a single-valued attribute can can only contain a single value. An instance of a multivalued attribute can contain
multiple values of uniform syntax. A multivalued attribute stores no information about ordering of the attributes it contains. Each value of a multivalue attribute must be
unique.
Indexed attributes
Both multivalued and single valued attributes can be indexed to help improve the performance of queries on that attribute. (Indexing does not apply to classes.) Attributes
are marked for indexing based on their schema definition. Indexing an attribute also allows users to use wildcards (*) as prefixes and suffixes when specifying a search
string. 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. Indexing
attributes, particularly multivalued attributes, can negatively affect replication and object creation time, as well as directory database size. So, it is recommended that you
only index commonly used attributes. For more information, see Index an attribute in Active Directory.
For more information about the schema, see "Active Directory Schema" at the Microsoft Windows Resource Kits Web site and the Microsoft MSDN Web site.
Schema object names

Schema object names

When extending the schema, you need to know how to reference schema objects. Both class and attribute schema objects can be referenced in several ways:
Lightweight Directory Access Protocol (LDAP) display name

common name
object identifier
LDAP display name

The Active Directory Schema snap-in and other administrative tools display the LDAP display name of objects. Programmers and system administrators use LDAP display
names to reference objects programmatically. The LDAP display name typically consists of two or more words combined. When the name consists of multiple words,
subsequent words in the name are identified using capitalization. Example LDAP display names are mailAddress and machinePasswordChangeInterval. The LDAP display
name is guaranteed to be unique for each object.
Common name
The common name is a more readable version of the LDAP display name. The common names of the two attributes used in the previous example are SMTP-Mail-Address
and Machine-Password-Change-Interval. Common names are guaranteed to be unique within a container.
Object identifier
An object identifier (also known as OID) is issued by an issuing authority such as the International Organization for Standardization (ISO) or 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 must be unique. For more
information about ISO, see the International Organization for Standardization Web site.
When extending your schema, you can register new object identifiers through Microsoft. For more information, see the Microsoft Web site.
Schema object naming rules

To help standardize schema naming conventions, Microsoft strongly suggests that schema extensions adhere to naming rules for both the LDAP Display Name and the
Common Name. To qualify as "Certified for Windows," an application that extends the schema must adhere to these naming rules. For more information, see the Active
Directory chapter of the certification program documentation at the Microsoft Web site. See also the Active Directory Programmer's Guide at the Microsoft Web site.
Message queuing aliases

A message queuing alias is an object in Active Directory that can be used to reference queues which might not be listed in Active Directory. For example, a queuing alias
can be used to reference a private queue within the context of a distribution list. You can create a queuing alias by using Active Directory Users and Computers. Using
queuing aliases provides the following benefits:
When a queuing alias object is deleted, the alias is automatically removed from all distribution lists that reference the alias.
A queue referenced by a queuing alias can be changed without changing the alias.
Queuing aliases can be used to reference a queue not listed in the directory service, including private queues or queues from another organization.
Queuing aliases can be used to send http messages by referencing the destination queue using a direct format name.
A queuing alias object has a single attribute, a format name that references a queue. Queuing aliases can contain public, private, and direct format names. The format
name for the queue cannot exceed 255 characters. For more information, see Using Message Queuing.
Note


Domain controllers running Windows Server 2003 do not permit the deletion of classes or attributes, but they can be deactivated if they are no longer needed or if there
was an error in the original definition. A deactivated class or attribute is considered defunct. A defunct class or attribute is unavailable for use; however, it is easily
reactivated.
If your forest has been raised to the Windows Server 2003 functional level, you can reuse the object identifier (governsId and attributeId values), the ldapDisplayName, and
the schemaIdGUID that were associated with the defunct class or attribute. This allows you to change the object identifier associated with a particular class or attribute. The
only exception to this is that an attribute used as a rdnAttId of a class continues to own its attributeId, ldapDisplayName, and schemaIdGuid values even after being
deactivated (for example, those values cannot be reused).
If your forest has been raised to the Windows Server 2003 functional level, you can deactivate a class or attribute and then redefine it. For example, the Unicode String
syntax of an attribute called SalesManager could be changed to Distinguished Name. Since Active Directory does not permit you to change the syntax of an attribute after
it has been defined in the schema, you can deactivate the SalesManager attribute and create a new SalesManager attribute that reuses the same object identifier and LDAP
display name as the old attribute, but with the desired attribute syntax. You must rename the deactivated attribute before it can be redefined.
For more information about forest functionality, see Domain and forest functionality.
Notes
Classes and attributes added to the base schema can be deactivated without raising the forest functional level. However, they can be redefined only in forests raised
to the Windows Server 2003 functional level or higher.
Default schema attributes or classes in the base schema cannot be deactivated if bit 4 of the systemFlags attribute is set to 1. Only attributes or classes where bit 4
of the systemFlags attribute is equal to zero can be deactivated.
Object identifiers must be unique. Mistyping a number when entering an object identifier can cause a conflict between the invalid object identifier and a legitimate object
identifier that is registered by an application. When installing an application that adds an attribute or class, the application may need to use the mistyped object identifier
for one of its legitimate schema extensions. You can correct object identifier conflicts in forests that are set to the Windows Server 2003 functional level. To correct the
conflict, deactivate the attribute or class with the incorrect object identifier. The application installation program will then be able to create the new attribute or class using
the correct object identifier.
Before deactivating a class, consider the following:
You can deactivate a class only if that class is not specified as a subClassOf, auxiliaryClass, systemAuxiliaryClass, possSuperiors, or systemPossSuperiors of any
existing active class.
You cannot use a defunct class in definitions of new classes, and you cannot add it to existing class definitions.
You cannot create objects that are instances of the defunct class or modify existing instances of the class. However, the instances of the defunct class become
available again for modification when the defunct class is reactivated.
Before deactivating an attribute, consider the following:
You can deactivate an attribute only if the attribute is not specified as a systemMustContain, mustContain, systemMayContain, mayContain, or rdnAttId of any existing
active class.
You cannot use a defunct attribute in definitions of new classes, and you cannot add it to existing class definitions.
You cannot read, modify, or delete instances of the defunct attribute present in existing objects. However, the instances of the defunct attribute become available
when the defunct attribute is reactivated.
To purge the directory of instances of an attribute you must delete the instances before deactivating the attribute.
Classes and attributes can be deactivated programmatically (recommended) or by using the Active Directory Schema snap-in. To deactivate a class or attribute using the
Active Directory Schema snap-in, 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.
Reactivating a class
A defunct class can be reactivated. However, a defunct class cannot be reactivated unless the attributes referenced in its mustContain, systemMustContain, mayContain, and
systemMayContain properties are active and the classes referenced in its subClassOf, auxiliaryClass, systemAuxiliaryClass, possSuperiors, and systemPossibleSuperiors
properties are also active.
Further, a defunct class cannot be reactivated if the values of the following attributes collide with an already active attribute or class: ldapDisplayName, attributeId,
governsId, or schemaIdGuid.
To reactive a defunct class, see Reactivate a class or attribute.
Reactivating an attribute
An defunct attribute can be reactivated. However, a defunct attribute cannot be reactivated if the values of the following attributes collide with an already active attribute or
class: ldapDisplayName, attributeId, governsId, schemaIdGuid, or mapiId.
To reactive a defunct attribute, see Reactivate a class or attribute.



When the set of classes and attributes in the base Active Directory schema do not meet your needs, you can extend the schema by modifying or adding classes and
attributes. You should only extend the schema when absolutely necessary. The easiest way to extend the schema is through the Schema Microsoft Management Console
(MMC) snap-in. You should always develop and test your schema extensions in a test lab before moving them to your production network.
Before extending the schema

Before extending the schema, review these key points:
Check the base schema first
Verify that no existing class or attribute in the base schema meets your application or data needs. For the complete set of classes and
attributes in the base schema, see the Microsoft Web site.
Review schema
documentation
For detailed information about extending the schema, see the Active Directory Programmer's Guide at the Microsoft Web site and
"Active Directory Schema" at the Microsoft Windows Resource Kits Web site.
Schema modifications are

global
When you extend the schema, the changes apply to every domain controller in the entire forest.
Schema classes related to

the system cannot be
modified
You cannot modify default system classes (those classes required for Windows to run) within the schema. However, directory-enabled
applications that modify the schema may add new classes that you can modify.
Schema extensions are not

reversible
Attributes or classes cannot be removed after creation. At best, they can be modified or deactivated. For more information, see
Deactivating a class or attribute.
Obtain valid object

identifiers
Every class and attribute in the schema must have a unique and valid object identifier (also known as OID). Do not create arbitrary object
identifiers or recycle old object identifiers. For information about obtaining valid object identifiers, see Schema object names.
Document your changes
If you do decide to extend the schema, be sure to document your changes.
How to extend the schema

You can modify the schema through graphical user interface (GUI) tools, command-line tools, and through scripting. The easiest way to modify the schema is by using the
Active Directory Schema snap-in in Microsoft Management Console (MMC), which is a GUI tool for schema management. For information about installing the Active
Directory Schema snap-in, see Install the Active Directory Schema snap-in. Modifying the schema through scripting requires programming knowledge and familiarity with
the Active Directory Service Interfaces (ADSI). For more information, see the Active Directory Programmer's Guide and Extending the Schema at the Microsoft MSDN Web
site.
For more information about schema administration tools, see Administration tools for the Active Directory schema.
For more information about extending the schema, see Modify an existing schema class or attribute definition and Add a new schema class or attribute definition. For
information about deactivation and reactivation, see Deactivating a class or attribute, Deactivate a class or attribute and Reactivate a class or attribute.
Using a test forest

A very simple way to avoid damaging or costly schema mistakes in your production forest is to first test your schema extensions on a test forest. By using a test
environment, you can identify any potential problems in your plan before they affect your users and your production environment.
After making schema changes in a test forest, you can reinstall the default schema by demoting each domain controller in the test forest to which the schema changes have
replicated. Then, use the Active Directory Installation Wizard to reinstall Active Directory on the servers. This procedure is practical only in a test environment.


Deployment resources
Using the Active Directory Installation Wizard
Creating an additional domain controller
Creating a new domain tree
Creating a new child domain
Creating a new forest
Upgrading from Windows NT or Windows 2000
To deploy domain controllers running Windows Server 2003, it is recommended that you use the Microsoft Windows Server 2003 Deployment Kit, which is available online at
the Microsoft Windows Resource Kits Web site.
The online deployment kit includes case studies and the necessary information for deploying Windows Server 2003 Active Directory in networks that have domain
controllers running Windows NT 4.0 or Windows 2000. For complete information, see "Upgrading Windows NT 4.0 Domains to Windows Server 2003" at the Microsoft
Windows Resource Kits Web site.
If your network includes branch offices, see "Designing the Site Topology" at the Microsoft Windows Resource Kits Web site. This online guide helps plan Active Directory
deployment when there are branch office sites connected with slow network links.
For information about monitoring Active Directory, see "Monitoring Active Directory" at the Microsoft Windows Resource Kits Web site.


The Active Directory Installation Wizard installs and configures domain controllers, which provide network users and computers access to the Active Directory directory
service. You can install Active Directory on any member server (except those with restrictive license agreements) using the Active Directory Installation Wizard. Using the
wizard, you will define one of the following roles for the new domain controller:
New forest (also a new domain)

For a checklist about creating a new forest, see Checklist: Creating a new forest.
New child domain
For a checklist about creating a child domain, see Checklist: Creating a new child domain.
New domain tree in an existing forest
For a checklist about creating a new domain tree, see Checklist: Creating a new domain tree.
An additional domain controller in an existing domain.
For a checklist about creating an additional domain controller, see Checklist: Creating an additional domain controller in an existing domain.
Before using the Active Directory Installation Wizard, consider DNS configuration and support for existing applications.
DNS configuration
By default, the Active Directory Installation Wizard attempts to locate an authoritative DNS server for the new domain from its list of configured DNS servers that will accept
a dynamic update of a service (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, then the Active Directory Installation Wizard will take the following steps 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.
For example, if the domain that you chose for your first domain in the forest is example.microsoft.com, then a zone rooted at the DNS domain name of
example.microsoft.com is added and configured to use the DNS Server service on the new domain controller.
2. A text file containing the appropriate DNS resource records for the domain controller is created.
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 Net Logon service and supports Active Directory on servers running non-Windows Server 2003 DNS.
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
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.
If no DNS servers are available on the network, you can choose the option to automatically install and configure a local DNS server when you install Active Directory using
the Active Directory Installation Wizard. The DNS server will be installed on the server on which you are running the wizard, and the server's preferred DNS server setting
will be configured to use the new local DNS server.
Before running the Active Directory Installation Wizard, ensure that the authoritative DNS zone allows dynamic updates and that the DNS server hosting the zone supports
the DNS SRV resource record. For more information, see Checklist: Verifying DNS before installing Active Directory.
For more information, see Configure a DNS server for use with Active Directory. For general information about DNS integration with Active Directory, see DNS integration.
Support for existing applications

On servers running Windows NT 4.0 and earlier, read access for user and group information is assigned to anonymous users so that existing applications and some nonMicrosoft applications function correctly.
On servers running Windows 2000 and Windows Server 2003, members of the Anonymous Logon group have read access to this information only when the group is
added to the Pre-Windows 2000 Compatible Access group.
Using the Active Directory Installation Wizard, you can choose if you want the Anonymous Logon group and the Everyone security groups to be added to the PreWindows 2000 Compatible Access group by selecting the Permissions compatible with pre-Windows 2000 Server operating systems option. To prevent members of
the Anonymous Logon group from gaining read access to user and group information, choose the Permissions compatible only with Windows Server 2003 operating
systems option.
When upgrading a domain controller from Windows 2000 to a Windows Server 2003 operating system, if the Everyone security group is already a member of the preWindows 2000 Compatible Access security group (indicating backward compatibility settings), the Anonymous Logon security group will be added as a member of the preWindows 2000 Compatible Access security group during the upgrade.
You can manually switch between the backward compatible and high-security settings on Active Directory objects by adding the Anonymous Logon security group to the
pre-Windows 2000 Compatible Access security group using Active Directory Users and Computers. For more information about adding members to a group, see Add a
member to a group. For more information about default groups, see Default groups and Special identities.
Note
If you select the Permissions compatible only with Windows Server 2003 operating systems check box when installing Active Directory and find that your
applications are not functioning correctly, try resolving the problem by manually adding the special group Everyone to the Pre-Windows 2000 Compatible Access
security group, and then restarting the domain controllers in the domain. Once you have upgraded to applications compatible with the Windows Server 2003 family,
you should return to the more secure Windows Server 2003 operating system configuration by removing the Everyone group from the Pre-Windows 2000
Compatible Access security group and restarting the domain controllers in the affected domain.
Creating an additional domain controller

Creating additional domain controllers

If you already have one domain controller in a domain, you can add additional domain controllers to the domain to improve the availability and reliability of network
services. Adding additional domain controllers can help provide fault tolerance, balance the load of existing domain controllers, and provide additional infrastructure
support to sites.
More than one domain controller in a domain makes it possible for the domain to continue to function if a domain controller fails or must be disconnected. Multiple
domain controllers can also improve performance by making it easier for clients to connect to a domain controller when logging on to the network. You can add additional
domain controllers over the network or from backup media.
Before adding domain controllers you should thoroughly understand Active Directory and the requirements necessary to set up additional domain controllers in an existing
domain. For more information, see Checklist: Creating an additional domain controller in an existing domain and Create an additional domain controller.
Using backup media to create additional domain controllers

With Windows 2000, the only way you can create an additional domain controller in an existing domain is by replicating the entire directory database to the new domain
controller. With low network bandwidth or a large directory database, this replication can take hours or days to complete. With servers running Windows Server 2003, you
can create an additional domain controller using a restored backup taken from a domain controller running Windows Server 2003. This backup can be stored on any
backup media (tape, CD, or DVD) or a shared resource.
Using restored backup files to create an additional domain controller will greatly reduce the network bandwidth used when installing Active Directory over a shared
resource; however, network connectivity is still necessary so that all new objects and recent changes to existing objects are replicated to the new domain controller.
It is recommended that you use the most recent backup available. Older backups require more network bandwidth for replication. The backup used cannot be older than
the tombstone lifetime of the domain, which is set to a default value of 60 days (180 days in a forest that is created on a server running Windows Server 2003 with Service
Pack 1 [SP1]).
If a domain controller that was backed up contained an application directory partition, it will not be restored on the new domain controller. To manually create an
application directory partition on a new domain controller, see Create or delete an application directory partition.
When adding an additional domain controller using backup media, a System State backup taken only from a domain controllers running Windows Server 2003 can be used
once it has been restored. For more information about how to restore a System State backup, see Restore System State data.
For general information about restoring backups, see Authoritative, primary, and normal restores.


Create a new domain tree only when you need to create a domain whose DNS namespace is not related to the other domains in the forest. This means that the name of
the tree root domain (and all of its children) does not have to contain the full name of the parent domain. A forest can contain one or more domain trees. For information
about how to create a new domain tree, see Create a new domain tree.
Before you create a new domain tree, consider whether another forest is necessary. Multiple forests provide isolation of the schema and configuration directory partitions,
separate security boundaries, administrative autonomy, and the flexibility to use an independent namespace design for each forest. Adding an additional forest does,
however, increase the complexity and cost of implementing and maintaining your deployment. Therefore, the decision to create a new forest should not be made lightly.
Create a forest where you have a specific deployment requirement. For example, create a forest when you need a separate security boundary or if you need to isolate
schema changes. These requirements are not met by the creation of a new domain tree. For more information, see either Creating a new forest. or "Design Considerations
for Delegation of Administration in Active Directory" on the Microsoft Web site.


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. As a best practice, you create new
domains as children of the forest root domain.
You can create a new child domain by creating a new domain under a parent domain using the Active Directory Installation Wizard. For information about how to create a
new child domain, see Create a new child domain.
After you create the child domain, you can create additional domain controllers in the child domain for fault tolerance and high availability of Active Directory. For more
information, see Creating an additional domain controller.


When you create the first domain controller in your organization, you are creating the first domain (also called the forest root domain) and the first forest.
The top-level Active Directory container is called a forest. A forest consists of one or more domains that share a common schema and global catalog. An organization can
have multiple forests.
A forest is the security and administrative boundary for all objects that reside within the forest. In contrast, a domain is the administrative boundary for managing objects,
such as users, groups, and computers. In addition, each domain has individual security policies and trust relationships with other domains.
Multiple domain trees within a single forest do not form a contiguous namespace; that is, they have noncontiguous DNS domain names. Although trees in a forest do not
share a namespace, a forest does have a single root domain, called the forest root domain. The forest root domain is, by definition, the first domain created in the forest.
The Enterprise Admins and Schema Admins groups are located in this domain. By default, members of these two groups have forest-wide administrative credentials.
When to create a new forest

A first step in the Active Directory design process is to determine how many forests your organization needs. For most organizations, a single forest design is the
preferred model and the simplest to administer. However, a single forest may not be practical for every organization.
With a single forest, users do not need to be aware of directory structure because all users see a single directory through the global catalog. When adding a new domain
to a forest, no additional trust configuration is required because all domains in a forest are connected by two-way, transitive trusts. In a forest with multiple domains,
configuration changes need be applied only once to update all domains.
However, there are scenarios in which you might want to create more than one forest:
When upgrading a Windows NT domain to a Windows Server 2003 forest. You can upgrade a Windows NT domain to become the first domain in a new
Windows Server 2003 forest. To do this, you must first upgrade the primary domain controller in that domain. Then, you can upgrade backup domain controllers,
member servers, and client computers at any time.
You can also keep a Windows NT domain and create a new Windows Server 2003 forest by installing Active Directory on a member server running Windows
Server 2003. For more information, see Upgrading from a Windows NT domain.
To provide administrative autonomy. You can create a new forest when you need to segment your network for purposes of administrative autonomy.
Administrators who currently manage the IT infrastructure for autonomous divisions within the organization may want to assume the role of forest owner and
proceed with their own forest design. However, in other situations, potential forest owners may choose to merge their autonomous divisions into a single forest to
reduce the cost of designing and operating their own Active Directory or to facilitate resource sharing. Another alternative is to provide for some delegation of
administrative authority that enables the benefits of both approaches. For more information, see "Best Practice Active Directory Design for Managing Windows
Networks" on the Microsoft Web site or "Design Considerations for Delegation of Administration in Active Directory", also available on the Microsoft Web site.
Operations master roles in a new forest

When you create the first forest in your organization, all five operations master roles are automatically assigned to the first domain controller in the forest. As new child
domains are added to the forest, the first domain controller in each of the new child domains is automatically assigned the following roles:
Relative identifier master

Primary domain controller (PDC) emulator
Because there can be only one schema master and one domain naming master in a forest, these roles remain in the forest root domain. In an Active Directory forest with
only one domain and one domain controller, that domain controller owns all the operations master roles. For more information, see Operations master roles.
Adding new domains to your forest

A domain stores only the information about objects located in that domain, so by creating multiple domains within a new forest, you are partitioning or segmenting Active
Directory to better serve a disparate user base.
The easiest domain structure to administer is a single domain within a single forest. When planning, you should start with a single domain and only add additional domains
when the single domain model no longer meets your needs. For more information about creating domains, see Domains.
Before creating a new forest

Active Directory requires DNS to function and both share the same hierarchical domain structure. For example, microsoft.com is a DNS domain and an Active Directory
domain. Because of the reliance that Active Directory has on DNS you must thoroughly understand Active Directory and DNS concepts before creating a new forest. For
more information, see Checklist: Creating a new forest.


Upgrading overview
Upgrading from a Windows NT domain
Upgrading from a Windows 2000 domain
Converting groups
Upgrading overview
Upgrading overview
The Active Directory directory service is compatible with Microsoft Windows NT and supports a mix of operations that support domain controllers running
Windows NT 4.0, Windows 2000, and Windows Server 2003. This allows you to 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 or Windows Server 2003 domains. To clients running Windows 95, Windows 98, or Windows NT that are not running Active Directory client
software, a Windows 2000 or Windows Server 2003 domain appears to be a Windows NT 4.0 domain. For more information, see Active Directory clients.
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. For more information, see Upgrading from a Windows NT
domain.
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.


See the following recommended steps for upgrading from a Windows NT domain.
Plan and implement a namespace and DNS infrastructure

Because 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 to use the Active Directory Installation Wizard to automatically install the DNS service. For more information, see DNS integration and
Namespace planning for DNS.
Determine forest functionality

Forest functionality determines the type of Active Directory features that can be enabled within the scope of a single forest. Each forest functional level has a set of specific
minimum requirements for the versions of operating systems that domain controllers throughout the forest can run. For example, the Windows Server 2003 forest
functional level requires that all domain controllers run a product in the Windows Server 2003 family.
When you are upgrading your first Windows NT domain to become the first Windows Server 2003 domain, it is recommended that you set the forest functional level to the
Windows Server 2003 interim forest functional level, which you will be prompted to set during the upgrade. This level contains all of the features used in the Windows 2000
forest functional level, including the following two important Active Directory replication enhancements:
Improved replication efficiency and scalability. For more information, see Replication overview.
Linked value replication for more efficient replication of group memberships. For more information, see How replication works.

The Windows Server 2003 interim functional level is an option only when upgrading the first Windows NT domain to a new forest and can be manually configured after the
upgrade. For more information about how to manually set this functional level, see "Upgrading Windows NT 4.0 Domains to Windows Server 2003" at the Microsoft
Windows Resource Kits Web site. The Windows Server 2003 interim forest functional level only supports domain controllers running Windows Server 2003 and
Windows NT, not domain controllers running Windows 2000. You cannot install Active Directory on servers running Windows 2000 in a forest with the functional level set to
Windows Server 2003 interim. For more information about forest functionality, see Domain and forest functionality.
Upgrade the primary domain controller

The first server you must upgrade is the primary domain controller (PDC) running Windows NT 4.0 or earlier. During the upgrade, the Active Directory Installation Wizard
requires that you choose to join an existing domain tree or forest or create 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: Creating a new forest, Checklist: Creating a new child domain, or Checklist: Creating a new
domain tree.
The Active Directory Installation Wizard installs all the necessary components on the domain controller, such as the directory data store and the Kerberos V5 protocol
authentication software. Once the Kerberos V5 protocol is installed, the installation process starts the authentication service and the ticket granting service.
If this is a new child domain, then a transitive trust relationship is established with the parent domain. Eventually, the domain controller from the parent domain copies all
schema and configuration information to the new child domain controller. The existing Security Accounts Manager (SAM) objects will be copied from the registry to the
new data store. These objects are security principals.
During the upgrade, container objects are created to contain the accounts and groups from the Windows NT domain. The container objects are named Users, Computers,
and Builtin and are displayed as folders in Active Directory Users and Computers. User accounts and predefined groups are routed to the Users container. Computer
accounts are routed to the Computers container. Built-in groups are routed to the Builtin container.
Existing Windows NT 4.0 and earlier groups are located in different folders depending on the nature of the group. Windows NT 4.0 and earlier built-in local groups (such
as Administrators and Server Operators) are located in the Builtin container. Windows NT 4.0 and earlier global groups (such as Domain Admins), any user-created local
groups, and global groups are located in the Users container.
The upgraded PDC can synchronize security principal changes to remaining backup domain controllers (BDCs) running Windows NT 4.0 or earlier. The upgraded PDC is
recognized as the domain master by BDCs running Windows NT Server 4.0 or earlier.
The upgraded domain controller is a fully functional member of the 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.
Upgrade any remaining backup domain controllers

Once you have upgraded the PDC running Windows NT 4.0 or earlier, you can proceed to upgrade all remaining BDCs. During the upgrade process, you might want to
remove one BDC from the network to guarantee a backup if any problems develop. This BDC will store a secure copy of your current domain database.
If any problems arise during the upgrade, you can remove all domain controllers running Windows Server 2003 from the production environment, and then bring the BDC
back into your network and make it the new PDC. This new PDC will then replicate its data throughout the domain so that the domain is returned to its previous state.
The only drawback to 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 upgrade process to update its safe copy of the directory.
If a domain controller running Windows Server 2003 becomes unavailable and no other domain controllers running Windows Server 2003 exist in the domain, a BDC
running Windows NT can be promoted to a PDC to fill the role for the offline domain controller running Windows Server 2003.
When upgrading Windows NT 4.0 and earlier domains, only one domain controller running Windows Server 2003 can create security principals (users, groups, and
computer accounts). This single domain controller is configured as a PDC emulator master. The PDC emulator master emulates a Windows NT 4.0 or earlier PDC. For more
information about the PDC emulator role, see Operations master roles.
Complete the upgrade of the domain

After you have upgraded all existing Windows NT 4.0 and earlier primary and backup domain controllers to a Windows Server 2003 operating system, and you have no
plans to use Windows NT 4.0 and earlier domain controllers, you can raise the domain functional level from Windows 2000 mixed to Windows 2000 native. For more
information about how to raise the domain functional level, see Raise the domain functional level.
Several things happen when you raise the domain functional level to Windows 2000 native:
Domain controllers no longer support NTLM replication.

The domain controller that is emulating the PDC operations master cannot synchronize data with a BDC running Windows NT 4.0 or earlier.
Domain controllers running Windows NT 4.0 and earlier cannot be added to the domain. You can add new domain controllers running Windows 2000 or Windows
Server 2003.
Users and computers using previous versions of Windows begin to benefit from the transitive trusts of Active Directory and can access resources anywhere in the
forest with the appropriate permissions. 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.
After upgrading a Windows NT 4.0 domain to an Active Directory domain, it is recommended that you delete and recreate all previously existing trusts with Active Directory
domains. Even though the domain has been upgraded, the trust remains a Windows NT 4.0 trust. Internet protocol security (IPSec) does not work over a Windows NT 4.0
trust.
Install Active Directory client software on older client computers

Computers running Active Directory client software can use Active Directory features, such as authentication, to access resources in the domain tree or forest and to query
the directory. By default, client computers running Windows 2000 Professional and Windows XP Professional have the client software built in and can access Active
Directory resources normally.
Computers running previous versions of Windows (Windows 95, Windows 98, and Windows NT) require installation of the Active Directory client software before access to
Active Directory resources is available. Without the client software, previous versions of Windows can only access the domain as if it were a Windows NT 4.0 and earlier
domain, finding only those resources available through Windows NT 4.0 and earlier one-way trusts. For more information about the Active Directory client software, see
Active Directory clients.


Before upgrading a domain controller running Windows 2000 to Windows Server 2003, or installing Active Directory on the first domain controller running Windows
Server 2003, ensure that your server, your forest, and your domain are ready. This process involves checking the upgrade compatibility of your server, preparing the
forest, and preparing the domain, all of which can be accomplished using command-line tools.
To check the upgrade compatibility of the server and to copy any updated Setup files, run the winnt32 command, using the winnt32 /checkupgradeonly command. For
more information about the winnt32 command, see Winnt32.
To prepare the forest, run the adprep command on the schema operations master, using the adprep /forestprep command. Running adprep on the schema master will
update the schema, which will in turn replicate to all of the other domain controllers in the forest. The time it takes to replicate these changes will vary, depending on the
replication schedule for your organization.
After the changes made by adprep /forestprep have replicated to the infrastructure operations master, you are ready to prepare the domain. To prepare the domain, run
adprep on the infrastructure operations master, this time using the adprep /domainprep command.
On Windows Server 2003 domain controllers with no service pack installed adprep /domainprep can cause significant replication traffic due to synchronization of the
Group Policy objects (GPOs) in the SYSVOL shared folder.
Windows Server 2003 with Service Pack 1 (SP1) includes a new adprep command, adprep /domainprep /gpprep, which you can run separately from adprep /domainprep
and which you can run anytime to synchronize the GPOs that are located in the SYSVOL shared folder.
Therefore, if you are upgrading a Windows 2000 Server environment to Windows Server 2003 with SP1, prepare the forest using adprep /forestprep and prepare each
domain using adprep /domainprep. Then, when network conditions are optimal, use adprep /domainprep /gpprep to add inheritable access control entries (ACEs) to the
GPOs in the SYSVOL shared folder and to synchronize the contents of the SYSVOL shared folder among the domain controllers in the domain.
The Adprep command-line tool is available from the I386 directory on the operating system installation CD.
Important
You cannot upgrade domain controllers running Windows 2000 to Windows Server 2003 or Windows Server 2003 with SP1, or add domain controllers running
Windows Server 2003 or Windows Server 2003 with SP1 to Windows 2000 domains, until you have used adprep to prepare the forest and the domains within the
forest.
For more information about the enhancements to Adprep.exe in Windows Server 2003 with SP1, see article 324392, Enhancements to Adprep.exe in Windows Server 2003
Service Pack 1 and in hotfix 324392, in the Microsoft Knowledge Base.
For more information about how to prepare your forest and domains using Adprep.exe, see "Overview: Upgrading Windows 2000 Domain Controllers to
Windows Server 2003" in article 325379, How to Upgrade Windows 2000 Domain Controllers to Windows Server 2003, in the Microsoft Knowledge Base.
See Also
Concepts
Checklist: Performing an upgrade
Adprep
Converting groups
Converting groups
When you upgrade a primary domain controller (PDC) running Windows NT Server 4.0 or earlier to a server running Windows Server 2003, existing Windows NT groups
are converted in the following ways:
Windows NT local groups are converted to domain local groups on servers running Windows Server 2003.
Windows NT global groups are converted to global groups on servers running Windows Server 2003.
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 global group on a server running Windows Server 2003, 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 servers running Windows Server 2003

Client computers that do not run Active Directory client software identify groups with universal scope on servers running Windows Server 2003 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 global groups on servers running Windows Server 2003.
In a Windows Server 2003 domain that is set to a domain functional level of Windows 2000 native, all the domain controllers must be running on servers running Windows
Server 2003. 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 Server 2003 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 server running Windows Server 2003 and using its Windows Server 2003 Administration Tools Pack to access the server running
Windows NT Server 4.0. You can use the Administration Tools Pack to display the domain local groups and assign to them permissions to resources on the server running
Windows NT Server 4.0.


Using Run as
Using saved queries
Managing Active Directory from MMC
Managing Active Directory from the command line
Finding directory information
Administering other domains
Delegating administration
Publishing resources
Managing COM+ partitions in Active Directory
Managing COM+ partition sets in Active Directory
Using Run as
Using Run as
Logging onto your computer using administrative credentials can pose a security risk to your computer and network. Therefore, as a security best practice, it is
recommended that you do not log on to your computer with administrative credentials. Instead, you can use Run as to accomplish administrative tasks without having to
log on to your computer with administrative credentials. For information about the security risks associated with being logged on as an administrator, see Why you should
not run your computer as an administrator.
Using Run as, you can open and run a program using a different account and security context than the one you are logged on with. So, you can log on using a regular user
account, then, using Run as, open an administrative program in the context of an administrative account. The administrative context is only used for that specific program
and is only available until that program is closed.
It is especially important for domain administrators to use Run as to accomplish administrative tasks. Running your computer as a domain administrator in Active Directory
makes your domain (and forest) vulnerable to Trojan horses and other security risks that target the logon sequence.
You can use Run as through the user interface or as a command-line tool.
User interface
The Run as feature built into the user interface is a shortcut that is accessed on the right-click menu for some programs (.exe), some Control Panel (.cpl) items, and
Microsoft Management Console (MMC) (.msc) consoles. Run as will prompt you for a user account and password before starting a program, Control Panel item, or
MMC console. Some programs and administrative tasks, such as upgrading the operating system or configuring system parameters, do not support Run as. These
tasks require an interactive logon. For more information about how to use the Run as feature, see Run a program with administrative credentials.
Command-line tool
In addition to the built-in Run as feature, the runas command provides the same capabilities. For more information about the runas command, see Runas. You can
also create a custom shortcut using the runas command. For more information about creating shortcuts, see Create a shortcut using the runas command.
Tip
For more options and examples, see the TechNet Wiki topic How to Run with Alternate Credentials and Open Elevated Command Prompts
(http://social.technet.microsoft.com/wiki/contents/articles/how-to-run-with-alternate-credentials-and-open-elevated-command-prompts.aspx).
Using saved queries

Using saved queries

Saved queries provide a quick and consistent way for administrators to access a common set of directory objects on which to perform specific tasks or to monitor. Saved
queries use predefined LDAP strings to search only the specified domain partition, and searches can be narrowed down to a single container object. You can also create a
customized saved query that contains a LDAP search filter. For more information about saving queries, see Create a saved query. For more information about LDAP search
filters, see the Internet Engineering Task Force Web site and search for "Representation of LDAP Search Filters."
Active Directory Users and Computers provides a Saved Queries folder in which administrators can create, edit, save, and organize saved queries. Before saved queries,
administrators were required to create custom ADSI scripts that would perform a query on common objects. This was an often lengthy process that required knowledge of
how ADSI utilizes LDAP search filters to resolve a query.
All queries located in the Saved Queries folder are stored in Active Directory Users and Computers (dsa.msc). Once you have successfully created your customized set of
queries you can copy the .msc file to other domain controllers running Windows Server 2003 (located in the same domain) and use the same set of saved queries. You can
also export saved queries to an .xml file and import them into other Active Directory User and Computer consoles located on domain controllers running Windows
Server 2003 (within the same domain). For more information about saving console files, see Saving consoles.
You can save queries to search for disabled user or computer accounts, number of days since the last user logon, users with non-expiring Passwords, and many other
commonly used queries. Once a saved query is executed and the desired objects are displayed, each object can then be modified directly through a query results screen.
You can then select multiple objects and perform a task on them. For example, you can use a drag-and-drop operation to move two or more displayed objects onto a
group.
Note


The Active Directory administrative tools 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 Working with MMC console files.
The Active Directory administrative tools can only be used from a computer with access to a domain. The following Active Directory administrative tools are available on
the Administrative Tools menu:

You can also remotely administer Active Directory from a computer that is not a domain controller, such as a computer running Windows XP Professional. To do this, you
must install the Windows Server 2003 Administration Tools Pack. For more information, see Windows Server 2003 Administration Tools Pack Overview.
The Active Directory Schema snap-in is an Active Directory administrative tool for managing the schema. It is not available by default on the Administrative Tools menu, and
must be added manually. 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 operating system installation media. For more
information about the sample scripts, see Using the Windows Deployment and Resource Kits. For more information about using ADSI, see Programming interfaces.
Customizing how data is displayed in Active Directory administrative tools and snap-ins
The Active Directory administrative tools, such as Active Directory Users and Computers, and the Windows shell extensions use display specifiers to dynamically create
context menu items and property pages. Display specifiers permit localization of class and attribute names, context menus, and property pages, and also support new
classes and attributes. You can add and modify classes and attributes in the schema and extend both the administrative tools and the Windows shell in many ways by
modifying attributes in display specifiers. For more information the Active Directory schema and display specifiers, see the Active Directory programmer's Guide at the
Microsoft Web site.
Using Active Directory Users and Computers

You can change how directory objects are displayed in Active Directory Users and Computers by selecting commands on the View menu of the console. Menu commands
include the ability to toggle features on and off, such as the console tree, description bar, status bar, large icons, small icons, and so on.
When you start Active Directory Users and Computers and expand the domain node, several containers are displayed in the console tree. If you have just created a domain
controller, the containers that are displayed by default are:
Builtin: Contains objects that define the default built-in groups, such as Account Operators or Administrators.
Computers: Contains Windows 2000, Windows XP, and Windows Server 2003 computer objects, including computer accounts that were originally created using
application programming interfaces (APIs) that could not use Active Directory. Computer objects are moved to the Computer container when Windows NT domains
are upgraded to Windows 2000 or a Windows Server 2003 operating system.
Domain Controllers: Contains computer objects for domain controllers running Windows 2000 or Windows Server 2003.
Users: Contains user accounts and groups that were originally created using APIs that could not use Active Directory. User accounts and groups are moved to the
Users container when Windows NT domains are upgraded to Windows 2000 or a Windows Server 2003 operating system. You can use the Windows NT 4.0 User
Manager (Usrmgr) tool to modify users and groups created using the APIs that could not use Active Directory.
When you select Advanced Features on the View menu, two additional folders are displayed in the console:
LostAndFound: Contains objects whose containers were deleted at the same time that the object was created. If an object has been created in or moved to a
location that is missing after replication, the lost object is added to the LostAndFound container. The LostAndFoundConfig container in the configuration directory
partition serves the same purpose for forest-wide objects.
System: Contains built-in system settings for the various system service containers and objects. For more information about the System container, see Using the
Windows Deployment and Resource Kits.
When you select Filter options on the View menu, you can show all objects, show only selected objects, configure the number of items that can be displayed for each
folder, or create custom filters using object attributes and LDAP queries.
Starting Active Directory MMC consoles from the command-line

Active Directory MMC consoles, including Active Directory Users and Computers (dsa.msc), Active Directory Domains and Trusts (domain.msc) and Active Directory Sites
and Services (dssite.msc), provide command-line options that allow you to start a console 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= FullyQualifiedDomainName
/domain= NetBIOSDomainName
/server= FullyQualifiedDomainControllerName
/server= NetBIOSDomainControllerName
You can use these command-line options to run the Active Directory MMC consoles directly from the command line, or you can create a shortcut to start a console and
add the appropriate command-line options to the shortcut. You can also use the command-line options with any custom consoles that you create. For more information
about creating and saving console files, see Windows interface administrative tool reference A-Z: Microsoft Management Console.
Command-line examples:
To start Active Directory Users and Computers focused on domain1, type:

dsa.msc /domain=domain1
To start Active Directory Users and Computers focused on server1, type:
dsa.msc /server=server1.domain1
To start Active Directory Sites and Services focused on server1, type:
dssite.msc /server=server1.domain1
To start Active Directory Domains and Trusts focused on server1, type:
domain.msc /server=server1.domain1
Notes
Do not use both a /domain and /server command-line option at the same time.
The /domain options can only be used with Active Directory Users and Computers.


The following command-line tools can be used to manage Active Directory.
Name
Description
CSVDE
Import and export Active Directory data using comma-separated format.
Dsadd
Add users, groups, computers, contacts, and organizational units to Active Directory.
Dsmod
Modify an existing object of a specific type in the directory. The types of objects that can be modified are: users, groups, computers, servers, contacts, and
organizational units.
Dsrm
Remove objects of the specified type from Active Directory.
Dsmove
Rename an object without moving it in the directory tree, or move an object from its current location in the directory to a new location within a single domain
controller. (For cross-domain moves, use the Movetree command-line tool.)
Dsquery
Query and find a list of objects in the directory using specified search criteria. Use in a generic mode to query for any type of object or in a specialized
mode to query for for selected object types. The specific types of objects that can be queried through this command are: computers, contacts, subnets,
groups, organizational units, sites, servers and users.
Dsget
Display selected attributes of specific object types in Active Directory. Attributes of the following object types can be viewed: computers, contacts, subnets,
groups, organizational units, servers, sites, and users.
LDIFDE
Ceate, modify, and delete directory objects. This tool can also be used to extend the schema, export Active Directory user and group information to other
applications or services, and populate Active Directory with data from other directory services.
Ntdsutil
General purpose Active Directory management tool. Use Ntdsutil to perform database maintenance of Active Directory, to manage single master operations,
and remove metadata left behind by domain controllers that were removed from the network without being properly uninstalled.
Additional command-line tools are available in the Support tools folder of the product compact disc and from the Resource Kit
For information about other command-line tools, see Command-line reference A-Z. For more information about manageability, see Management Strategies and Tools.


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. 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. For information about publishing information in
the directory, see Publishing resources.
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. 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 The role of the global catalog.
Restricting directory information access

In some cases, such as for security or privacy reasons, you may want to restrict access to certain directory information. Access control permissions provide you with
detailed control over the visibility of information stored in Active Directory. Using permissions, you can ensure that only users who need particular directory information
have access to it. For information on assigning permissions to Active Directory objects or properties, see Assign, change, or remove permissions on Active Directory
objects or attributes. In addition, see Best practices for assigning permissions on Active Directory objects.
Efficient search tools

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 more information, see Search Active Directory.
Additionally, administrators can add objects to groups quickly and with minimal network impact by utilizing browse-less queries to help find likely members. For more
information, see Add a member to a group.


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 credentials in another domain

Logging on with a user account with the necessary permissions
Using Run as to start an administrative tool targeted on the particular domain (recommended)
A secure method of controlling administrative access to a particular domain is to tightly control the number of accounts that are added to the Domain Admins group for
that domain and the number of people aware of those accounts. Only members of the Domain Admins group (or Enterprise Admins group) can make broad administrative
changes to the domain.
For example, if a domain administrator in one domain wanted to establish a shortcut trust with another domain, the domain administrator could establish the trust
relationship in that domain by communicating with the domain administrator of the other domain, agreeing on a common strong password for the trust, and having the
administrator of the other domain create the trust in that domain.
A more convenient, but less secure method of administering more than one domain is to logon interactively with a user account that has administrative credentials 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. Logging on to a
computer with a user account that has broad administrative access is not recommended. For more information, see Why you should not run your computer as an
administrator.
Run as, when used with the appropriate user name and password, can be used to securely administer domains in any forest in your organization. For more information,
see Using Run as.
Notes
It is a security best practice to never log on with an account that has more rights and permissions than you need for the task you are currently performing.
It is also a security best practice to limit the scope of a particular administrator's rights and permissions to include only those tasks that the administrator commonly
performs.
You cannot administer a Windows Server 2003 domain or forest using the Windows 2000 Administrative Tools Pack. For more information, see Windows Server
2003 Administration Tools Pack Overview.
By delegating administration, you can assign a range of administrative tasks to the appropriate users and groups. You can assign basic administrative tasks to regular
users or groups, and leave domain-wide and forest-wide administration to members of the Domain Admins and Enterprise Admins groups. By delegating administration,
you can allow groups within your organization to take more control of their local network resources. You also help secure your network from accidental or malicious
damage by limiting the membership of administrator groups.
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 might want to create an organizational unit that enables you to assign a user the administrative control for all user and computer accounts in all branches
of a department, such as Human Resources. Or, you might want to assign a user administrative control only to some resources within a department, for example, computer
accounts. Another possible delegation of administrative control would be to assign a user the administrative control for the Human Resources organizational unit, but not
any organizational units contained within the Human Resources organizational unit.
Active Directory defines 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, which could be an entire domain, all
organizational units within a domain, or a single organizational unit.
Administrative control can be assigned to a user or group by using the Delegation of Control Wizard or through the Authorization Manager console. Both of these tools
allow you to assign rights or permissions to particular users or groups.
For example, a user can be given permissions to modify the Owner Of Accounts property, without being assigned the permissions to delete accounts in that organizational
unit. The Delegation of Control Wizard, as its name suggests, allows you to delegate administrative tasks using a wizard that steps you through the entire process. The
Authorization Manager is a Microsoft Management Console (MMC) console that also allows you to delegate administration. The Authorization Manager provides greater
flexibility than the Delegation of Control Wizard, at the cost of greater complexity.
For more information about using the Delegation of Control Wizard, see To delegate control. For more information about using Authorization Manager, see Authorization
Manager.
Delegating administration safely

Delegate administration carefully and document all your delegated assignments. Before you delegate any tasks, ensure adequate training for users who will be assigned
administrative control of objects. To review Active Directory security concepts, including permissions and inheritance, see Access control in Active Directory.
For more information about delegating administration safely, see Designing the Active Directory Logical Structure.
Customizing MMC consoles for specific groups

You can use Microsoft Management Console (MMC) 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
the console modes.
For more information about customizing a console and using console modes, 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 a particular 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 or Remove Programs. The next
time the members of the group open Add or 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 then 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, see Group Policy (pre-GPMC).
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 about
how to package an application, see Using the Windows Deployment and Resource Kits.
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 overview.
To help users locate the network resources they need, you can publish searchable information about these resources in Active Directory. Resources that can be published
include users, computers, printers, shared folders, and network services. Some commonly used directory information, like user and computer names, is published by
default when the objects are created. Other directory information, such as information about shared folders, must be published manually. For information about searching
the directory, see Finding directory information.
Using access control permissions, you can control which users and groups can search and view published information. Access control permissions give you detailed
control over directory information at both the resource and the property levels. For example, you can use permissions to prevent a particular group from viewing any user
information published in the directory. Or, you can use permissions to allow that group to view user names, but no other user information. For an overview of permissions,
see Access control overview. For information about assigning permissions to Active Directory objects and properties, see Assign, change, or remove permissions on Active
Directory objects or attributes.
Publishing users and computers

User and computer accounts are added to the directory using Active Directory Users and Computers and are automatically published to the directory upon creation.
Commonly used account information, such as account names, is published by default. Other information, such as account security information, is only visible to
administrators. For information about creating new accounts, see Create a new user account and Create a new computer account.
Publishing shared printers

You can also publish information about shared printers in Active Directory. Information about printers shared from Windows NT must be published manually. Information
about printers shared from the Windows Server 2003 family or the Windows 2000 Server family is published to the directory automatically when you create a shared
printer. You use Active Directory Users and Computers to manually publish shared printer information. For more information about publishing printers, see Manually
publish a printer in Active Directory.
Publishing shared folders

To help users find shared folders more easily, you can publish information about shared folders in Active Directory. You use Active Directory Users and Computers to
manually publish shared folder information. For more information about publishing shared folders, see Publish a shared folder.
Publishing services
A service is an application that makes data or operations available to network users. Publishing a service in Active Directory enables users and administrators to move from
a machine-centric view of the network to a service-centric view. 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.
Some services, such as Certificate Services, are automatically published in Active Directory when they are installed. Other services can be published in the directory using
programming interfaces. For more information, see Programming interfaces. Administrators can manage published services using Active Directory Sites and Services. For
more information about services and how to publish them, see the Service Publication page at the Microsoft Web site. (http://msdn.microsoft.com/)
Categories of service information

Binding and configuration information are the two types of service 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, connections can be automatically established with services. Machine-centric services are typically handled on a service-byservice 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 intrasite replication, the maximum replication period is fifteen minutes, and for intersite 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.


COM+ partitions stored in Active Directory are used to map a local COM+ partition, which stores the actual COM+ application, to specific users or organizational units
within your enterprise. COM+ applications are groups of COM components developed to work together to make use of COM+ services such as queuing, role-based
security, and so on.
There are two types of COM+ partitions: COM+ partitions stored in Active Directory and local COM+ partitions stored on application servers. Using COM+ partitions
stored in Active Directory, you can assign domain users and entire organizational units to applications stored in local COM+ partitions. Local COM+ partitions are
application containers used to manage multiple instances of COM+ applications on a single application server.
A local COM+ partition can only store one instance of an application. In other words, if you needed to make two or more versions of the same application (AppX 1.0 and
AppX 2.0) available to domain users, then you would need to create two separate local COM+ partitions on an application server and associate (or link) them with two
separate COM+ partitions in Active Directory. For more information about associating COM+ partitions, see Managing COM+ partition sets in Active Directory.
Each COM+ partition is configured and managed separately, according to the specific needs of its users.
Note
COM+ partitions in Active Directory are not available from domain controllers running Windows 2000.


COM+ partition sets stored in Active Directory can contain one or more COM+ partitions and are used to assign one or more applications, residing on an application
server, to domain users or organizational units. For more information about COM+ partitions, see Managing COM+ partitions in Active Directory.
Each COM+ partition set defines the COM+ partitions for which a domain user is permitted to access.
COM+ partition sets provide the following advantages to both administrators and application programmers:
Administering distributed applications becomes much easier because you can tailor access of a particular set of domain users to a specific set of applications.
Security policies can be applied to domain users and organizational units within each partition set.
Before assigning COM+ partition sets, you must first logically group one or more COM+ partitions into a single COM+ partition set. Once a COM+ partition set has been
defined, you can make applications available throughout the domain by mapping COM+ partition sets to domain users or organizational units. To do this, you must
perform tasks on both the domain controller where Active Directory resides and on the application server where the COM+ application is installed.
Tasks to perform on a domain controller

You must first create a COM+ partition within Active Directory by using Active Directory Users and Computers or, programmatically, by using Active Directory Service
Interfaces (ADSI). For more information, see Create a COM+ partition in Active Directory. Once you have created and configured your COM+ partitions in Active Directory,
you can use Component Services on an application server to associate a local COM+ partition with a COM+ partition stored in Active Directory.
After the COM+ partition is created and you have associated it with a local COM+ partition, you need to create a COM+ partition set. When creating a COM+ partition set,
you can define the COM+ partitions that comprise that set. Creating a COM+ partition set is done either by using Active Directory Users and Computers or,
programmatically, by using Active Directory Service Interfaces (ADSI). For more information, see Create a COM+ partition set in Active Directory.
Finally, you map domain users or organizational units to the newly created COM+ partition set. You can associate multiple users or organizational units with a COM+
partition set at one time instead of having to map multiple user identities or organizational units. For more information, see Map a user or organizational unit to a COM+
partition set.
Tasks to perform on Application servers

Using Component Services you can link a single COM+ application stored locally on an application server to a single COM+ partition stored in Active Directory. You can do
this by creating a local COM+ partition on the application server, through Component Services, and changing the local COM+ partition ID to reflect the COM+ partition ID
located in Active Directory.
Each COM+ partition in Active Directory has a general description, a unique name, and a unique partition ID. The partition ID is what associates the local COM+ partition to
the COM+ partition defined in Active Directory. The COM+ partitions defined in Active Directory are intended to be unique across an enterprise. A local COM+ partition is
necessary in order to store the COM+ application on an application server, which may also have multiple versions of a specific application installed.
You can define a local COM+ partition ID on the application server and then later revise the partition ID in Active Directory to match it. Or, you can define a COM+ partition
ID in Active Directory and then later revise the partition ID on the application server to match the one in Active Directory.
Note
Local COM+ partitions are sometimes referred to as Empty Partitions in the Component Services user interface.
Active Directory Resources

Resources
Web resources
Active Directory support tools
Programming interfaces
Web resources
Web resources
The following items provide links to more information on the Web related to Active Directory:
For information about deploying Active Directory, see "Identifying an Active Directory Deployment Strategy" at the Microsoft Windows Resource Kits Web site.
For information about domain trust, see "Domain Trust" at the Microsoft Windows Resource Kits Web site.
For information about establishing domain trusts, see "Designing an Authorization Strategy" at the Microsoft Windows Resource Kits Web site.
For information about monitoring Active Directory, see "Monitoring Active Directory" at the Microsoft Windows Resource Kits Web site.
For information about delegating enterprise administrator operations, see "Delegating Enterprise Administrator Operations" at the Microsoft Windows Resource
Kits Web site.
For development information about Active Directory, see the Active Directory Programmer's Guide at the Microsoft Web site.
For development information about Lightweight Directory Access Protocol (LDAP), see the Lightweight Directory Access Protocol API at the Microsoft Web site.
For information about obtaining valid object identifiers, see Active Directory Naming Registration at the Microsoft Web site.
For information about Request for Comments (RFCs) and Internet drafts, see the Internet Engineering Task Force Web site.
Note


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 installation CD in the \Support\Tools folder.
Note
You can find downloadable versions of the Support Tools at the following locations:
Windows Server 2003 Service Pack 1 32-bit Support Tools (http://go.microsoft.com/fwlink/?LinkId=70775)
Windows Server 2003 Service Pack 2 32-bit Support Tools (http://go.microsoft.com/fwlink/?LinkId=168625)
List and description of tools

In addition, the Active Directory Migration Tool (ADMT) is available to help you migrate user accounts, groups, and computer accounts from Windows NT 4.0 domains to
Active Directory domains. The Active Directory Migration Tool is a Microsoft Management Console (MMC) snap-in and is available on the installation compact disk in the
\i386\ADMT folder.
Tool
Description
Movetree
Move objects from one domain to another.
SIDWalk
Set the access control lists on objects previously owned by accounts that were moved, orphaned, or deleted.
LDP
Allows LDAP operations to be performed against Active Directory. This tool has a graphical user interface (GUI).
Dnscmd
Enables administrator to check presence of domain controller locator records in DNS, add or delete such records and perform configuration of
DNS servers, zones and records.
DSACLS
View or modify the access control lists of directory objects.
Netdom
Batch management of trusts, joining computers to domains, verifying trusts and secure channels.
NETDiag
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 (GUI).
DSAStat
Compare directory information on domain controllers and detect differences.
ADSI Edit
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 assigned or denied access to a directory object. It can also be used to reset access control lists to their
default state.
DFSUtil
Command-line utility for managing all aspects of Distributed File System (DFS), checking the configuration concurrency of DFS servers, and
displaying the DFS topology.
Dcdiag
Analyzes the state of domain controllers in a forest or enterprise and reports any problems to assist in troubleshooting.
Active Directory
Migration Tool
(ADMT)
A Microsoft Management Console (MMC) snap-in used to migrate user accounts, groups, and computer accounts from Windows NT 4.0 domains
to Active Directory domains (available on the installation compact disk in the \i386\ADMT folder).
For more information, see Install Windows Support Tools and Using the Windows Deployment and Resource Kits.
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, 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 Active Directory Programmer's Guide at the Microsoft Web site and the Using the Windows Deployment and Resource Kits.
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 as a lower-level interface for C programmers. For more information, see the Lightweight Directory Access Protocol
(LDAP) API at the Microsoft Web site.

Understanding Active Directory

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Understanding Active Directory

Diunggah oleh

Hak Cipta:

Format Tersedia

My Collection

Understanding Active Directory

Understanding Active Directory

Securing Active Directory

2014 Microsoft. All rights reserved.

Securing Active Directory

Securing Active Directory

Force domain users to use strong passwords.

Public key infrastructure

Promote a secure operating environment by running your computer without administrative

Provide tamper-resistant user authentication and e-mail security.

2014 Microsoft. All rights reserved.

Access control in Active Directory

Access control in Active Directory

Active Directory naming

Active Directory naming

Directory data store

Directory data store

Quotas and directory partitions

Directory access protocol

Directory access protocol

Lightweight Directory Access Protocol

LDAP and interoperability

2014 Microsoft. All rights reserved.

User and computer accounts

User and computer accounts

Authenticate the identity of a user or computer.

Securing user accounts

2014 Microsoft. All rights reserved.

Unique identification of each object (instance of a class) in a directory data store

Computers running Windows Server 2003 and Windows 2000 can

NetBIOS = 15 characters, or 15 bytes depending upon the

63 characters, or 63 bytes depending upon the character set;

Active Directory server roles

Active Directory server roles

2014 Microsoft. All rights reserved.

Active Directory clients

Active Directory clients

Understanding Domains and Forests

Understanding Domains and Forests

2014 Microsoft. All rights reserved.

Determining the number of domain controllers you need

Backing up domain controllers

Back up Active Directory while the domain controller is online.

Upgrading domain controllers

Renaming domain controllers

Renaming domain controllers

Restructure your network for organizational and business needs.

2014 Microsoft. All rights reserved.

Connecting to domain controllers running Windows 2000

Connecting to domain controllers running Windows 2000

Active Directory Users and Computers

Planning for multiple domains

Different password requirements between departments or divisions

Trust relationships between domains

Domain and forest functionality

Domain and forest functionality

Domain functional level

Domain controllers supported

Windows 2000 mixed (default)

Windows 2000 native

Windows Server 2003 interim

Windows Server 2003

Windows Server 2003 family