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 ContentsChapter 1

Understanding Active Directory

Active Directory Concepts

http://technet.microsoft.com/en-us/library/cc781408(v=ws.10).aspx


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

Understanding Active DirectoryActive 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


Securing Active DirectoryActive 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.



http://go.microsoft.com/fwlink/?LinkId=4564















http://go.microsoft.com/fwlink/?LinkID=7582






Access control in Active DirectoryAdministrators 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 descriptorsAccess 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 inheritanceBy 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 authenticationActive 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 namingActive Directory domain names are usually the full Domain Name System (DNS) name of the domain. However, for backward compatibility, each domain also has a pre-

Windows 2000 name for use by computers running pre-Windows 2000 operating systems. The pre-Windows 2000 domain name can be used to log on to a Windows

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 accountsIn 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 [email protected]. 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 accountsEach 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.










Directory data storeThe 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 partitionsQuotas, 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 thispartition, 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.








Directory access protocolActive 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 ProtocolLDAP 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 interoperabilityLDAP 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


User and computer accountsActive 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 accountsThe 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

accountDescription

Administrator

account

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 accountsIf 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 optionsEach 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 accountsActive 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 accountsEvery 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 namesEvery 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.








Organizational unitsA 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.







Active Directory server rolesComputers 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 serversA 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 controllersA 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.










Active Directory clientsWith 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.








Understanding Domains and ForestsThis section covers:

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 controllersWhen 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 you’ll need, the physical security of those domaincontrollers, a plan for backing up the domain data, and upgrading domain controllers.

Determining the number of domain controllers you needA 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 securityPhysical 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 controllersYou 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 controllersOn 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


Renaming domain controllersThe 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.




http://support.microsoft.com/kb/316826

http://technet.microsoft.com/library/cc794759(v=ws.10).aspx




Connecting to domain controllers running Windows 2000When 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



DomainsDomains 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 domainYou 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 domainsSome 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 domainIn 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 domainsTrust 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 domainsThe 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 restructuringUsing 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 functionalityDomain 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 functionalityDomain 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 Windows Server 2003 family

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.


Update logon timestamp

For more information about the lastLogonTimestamp

attribute, see User and computer accounts.


User password on InetOrgPerson object

For more information about InetOrgPerson objects, see

User and computer accounts.


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 functionalityForest 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 Domain controllers supported

Windows 2000 (default) Windows NT 4.0

Windows 2000





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.

Forest feature Windows 2000Windows

Server 2003

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















Raising domain and forest functional levelsWhen 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.








Application directory partitionsAn 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 namingAn 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 replicationThe 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 domainEvery 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 controllerdemotion



Application directory partitions and domain controller demotionIf 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 partitionTo 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 replicaRemoving 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 applicationMost 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 NtdsutilRefer 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.











Managing application directory partitionsYou 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 partitionWhen 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 partitionWhen 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 partitionAn 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 domainThe 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 delaysChanges 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 informationAny 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 partitionsThere 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

Operations master rolesActive 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 rolesEvery 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 masterThe 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.

Domain naming masterThe 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 rolesEvery 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 masterThe 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 masterThe 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).

Infrastructure masterAt 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 operations master rolesTransferring 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 Active Directory Schema

Domain naming master Active Directory Domains and Trusts

RID master Active Directory Users and Computers

PDC emulator master Active Directory Users and Computers

Infrastructure master Active Directory Users and Computers

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

Responding to operations master failuresSome 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 failureTemporary 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 failureTemporary 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 failureTemporary 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 failureThe 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 failureTemporary 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 groupsThis section covers:

Groups

Group scope

Group types

Default groups

Nesting groups

Special identities

Where groups can be created









Groups



GroupsA 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 scopeAny 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

Group can include as members… Group can be assigned permissions in… Group scope can be converted to…

UniversalAccounts from any domain within the forest in

which this Universal Group resides

Global groups from any domain within the

forest in which this Universal Group resides

Universal groups from any domain within the


Any domain or forestDomain local

Global (as long as no other

universal groups exist as

members)

GlobalAccounts from the same domain as the parent

global group

Global groups 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)

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

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)

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 scopeGroups 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 scopeUse 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 scopeUse 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 scopeWhen 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 serversSome 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 typesGroups 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 groupsDistribution 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 groupsUsed 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 groupsA 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 groupsDefault 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 containerThe 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 No default user rights.








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.


Pre-

Windows 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 containerThe 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



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. No default user rights.

Domain Guests This group contains all domain guests. No default user rights.

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



performance; Remove computer from docking station; Restore files and directories;


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 AlsoConceptsUsing Run as

Create a shortcut using the runas command

Why you should not run your computer as an administrator

Other ResourcesRun a program with administrative credentials






Nesting groups



Nesting groupsUsing 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 identitiesIn 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.






Where groups can be createdIn 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 trustsThis section covers:

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



TrustsA 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 NTIn 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 systemsAll 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 protocolsA 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 objectsTrusted 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 typesCommunication 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 trustsBy 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

typeTransitivity 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.

Tree-

root

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 trustsFour 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


External Nontransitive One-way

or two-

way

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 two-

way

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 two-

way

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 two-

way

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 directionThe 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 trustA 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 trustAll 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 transitivityTransitivity 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 trustsEach 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 trustA 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.











When to create an external trustYou 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 trustsTo 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 worksWhen 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 threatIf 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 quarantiningSID 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 quarantiningAlthough 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 trustsIf 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.







When to create a shortcut trustShortcut 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 trustsA 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 trustsA 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.







When to create a realm trustA 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.






When to create a forest trustA 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 trustsA 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 trustsA 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 trustsIn 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 environmentForest 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 controlActive 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 forestsYou 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.






Accessing resources across domainsSince 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 domainsIt 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 domainsBy 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 trustUsing 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


Accessing resources across forestsWhen 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 hintsRouting 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 forestsIt 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 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 forestsBy 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 forestsUsing 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.








Routing name suffixes across forestsName 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 detectionWhen 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 replicationThis section covers:

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 overviewSites in Active Directory® represent the physical structure, or topology, of your network. Active Directory uses topology information, stored as site and site link objects inthe 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 sitesSites 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 subnetsIn 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 sitesComputers 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 domainsIn 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.






Replication overviewExcept 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. ActiveDirectory 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 replicationData 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 sitesTo 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 topologyThe 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 familyThe Microsoft® Windows Server 2003 family includes enhancements to make replication both more efficient, as well as more scalable across a larger number of domainsand 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."







http://go.microsoft.com/fwlink/?linkID=28523




How replication worksTo 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 dataActive 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 replicationOnce 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 changesIt 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 efficiencyIntroduced 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.










Replication within a siteActive 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 topologyThe 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 occursDirectory 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.








Replication between sitesActive 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 topologyActive 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 occursActive 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.












When to establish a single or separate sitesYou 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 importantWithin 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 siteIf 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 sitesWhen 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



BandwidthBandwidth 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.






Managing replicationActive 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 linksYou 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 costThe 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 frequencyThe 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 availabilityThe 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 bridgesBy 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 serversWhen 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 catalogThis section covers:

The role of the global catalog

Global catalog replication

Customizing the global catalog

Global catalogs and sites









The role of the global catalogA 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 user’saccount is located in example1.microsoft.com and the user decides to log on with a user principal name of [email protected] from a computer

located in example2.microsoft.com, the domain controller in example2.microsoft.com will be unable to find the user’s account, and will then contact a global catalogto 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 user’s 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.












Global catalog replicationReplication 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 attributesActive 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 dataSpecial 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 replicationGroups 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.








Customizing the global catalogThere 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 object’s most common attributes for every object in the entire forest, whichapplications 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.








Global catalogs and sitesTo 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 cachingDue 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.






Interoperating with DNS and Group PolicyThis section covers:

DNS integration

Group Policy integration




DNS integration



DNS integrationActive 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 integrationGroup 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 schemaThis section covers:

Schema

Schema classes and attributes

Schema object names

Deactivating a class or attribute

Extending the schema







Schema



SchemaThe 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 definedIn 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 storedEach 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 cacheTo 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 schemaLike 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.













Schema classes and attributesEvery 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.

ClassesClassSchema 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 typesThree 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.

AttributesAttributeSchema 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 attributesAttributes 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 attributesBoth 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 namesWhen 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 nameThe 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 nameThe 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 identifierAn 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 rulesTo 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 aliasesA 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












Deactivating a class or attributeDomain 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 classA 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 attributeAn 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.






Extending the schemaWhen 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 schemaBefore 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 schemaYou 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 forestA 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



ConceptsThis 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 overviewA 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





Introduction to Active Directory



Introduction to Active DirectoryActive Directory can be installed on servers running Microsoft® Windows Server® 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and WindowsServer 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 tocomputers running Windows 95, Windows 98, and Windows NT® Server 4.0. To client computers not running Active Directory client software, the directory willappear 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 2003With the new Active Directory features available in Microsoft® Windows Server® 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and WindowsServer 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 featuresNew 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.





















Security information for Active Directory



Security information for Active DirectoryActive Directory® provides a secure directory environment for your organization using built-in logon authentication and user authorization, which are core features of theLocal 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 networkActive 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.















Understanding Active DirectoryActive 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
































Securing Active DirectoryActive 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.
























Access control in Active DirectoryAdministrators 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 descriptorsAccess 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 inheritanceBy 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 authenticationActive 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 namingActive Directory domain names are usually the full Domain Name System (DNS) name of the domain. However, for backward compatibility, each domain also has a pre-

Windows 2000 name for use by computers running pre-Windows 2000 operating systems. The pre-Windows 2000 domain name can be used to log on to a Windows

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 accountsIn 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 [email protected]. 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 accountsEach 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.










Directory data storeThe 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 partitionsQuotas, 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 thispartition, 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.








Directory access protocolActive 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 ProtocolLDAP 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 interoperabilityLDAP 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


User and computer accountsActive 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 accountsThe 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

accountDescription

Administrator

account

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 accountsIf 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 optionsEach 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 accountsActive 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 accountsEvery 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 namesEvery 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.








Organizational unitsA 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.







Active Directory server rolesComputers 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 serversA 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 controllersA 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












Active Directory clientsWith 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.








Understanding Domains and ForestsThis section covers:

Domain controllers



Domains

Renaming domains




Application directory partitions and domain controller demotion



















Domain controllers



Domain controllersWhen 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 you’ll need, the physical security of those domaincontrollers, a plan for backing up the domain data, and upgrading domain controllers.

Determining the number of domain controllers you needA 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 securityPhysical 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 controllersYou 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 controllersOn 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.






Renaming domain controllersThe 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.




http://support.microsoft.com/kb/316826

http://technet.microsoft.com/library/cc794759(v=ws.10).aspx




Connecting to domain controllers running Windows 2000When 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 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



DomainsDomains 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 domainYou 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 domainsSome 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 domainIn 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 domainsTrust 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 domainsThe 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 restructuringUsing 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 functionalityDomain 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 functionalityDomain 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 2000 native Windows 2000





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.


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.


Update logon timestamp

For more information about the lastLogonTimestamp

attribute, see User and computer accounts.


User password on InetOrgPerson object

For more information about InetOrgPerson objects, see

User and computer accounts.


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 functionalityForest 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 Domain controllers supported

Windows 2000 (default) Windows NT 4.0

Windows 2000





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.

Forest feature Windows 2000Windows

Server 2003

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















Raising domain and forest functional levelsWhen 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.








Application directory partitionsAn 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 namingAn 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 replicationThe 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 domainEvery 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 controllerdemotion



Application directory partitions and domain controller demotionIf 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 partitionTo 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 replicaRemoving 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 applicationMost 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 NtdsutilRefer 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.











Managing application directory partitionsYou 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 partitionWhen 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 partitionWhen 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 partitionAn 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 domainThe 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 delaysChanges 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 informationAny 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 partitionsThere 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

Operations master rolesActive 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 rolesEvery 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 masterThe 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.

Domain naming masterThe 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 rolesEvery 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 masterThe 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 masterThe 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).

Infrastructure masterAt 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 operations master rolesTransferring 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 Active Directory Schema

Domain naming master Active Directory Domains and Trusts

RID master Active Directory Users and Computers

PDC emulator master Active Directory Users and Computers

Infrastructure master Active Directory Users and Computers

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

Responding to operations master failuresSome 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 failureTemporary 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 failureTemporary 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 failureTemporary 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 failureThe 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 failureTemporary 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 groupsThis section covers:

Groups

Group scope

Group types

Default groups

Nesting groups

Special identities










Groups



GroupsA 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 scopeAny 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

Group can include as members… Group can be assigned permissions in… Group scope can be converted to…

UniversalAccounts from any domain within the forest in

which this Universal Group resides

Global groups from any domain within the


Universal groups from any domain within the


Any domain or forestDomain local

Global (as long as no other

universal groups exist as

members)

GlobalAccounts from the same domain as the parent

global group

Global groups 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)

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

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)

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 scopeGroups 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 scopeUse 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 scopeUse 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 scopeWhen 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 serversSome 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 typesGroups 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 groupsDistribution 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 groupsUsed 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 groupsA 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 groupsDefault 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 containerThe 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



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 No default user rights.








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.


Pre-

Windows 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 containerThe 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



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. performance; Remove computer from docking station; Restore files and directories;


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. No default user rights.

Domain Guests This group contains all domain guests. No default user rights.

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



performance; Remove computer from docking station; Restore files and directories;


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 AlsoConceptsUsing Run as

Create a shortcut using the runas command

Why you should not run your computer as an administrator

Other ResourcesRun a program with administrative credentials






Nesting groups



Nesting groupsUsing 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 identitiesIn 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.






Where groups can be createdIn 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 trustsThis section covers:

Trusts

Trust types

Trust direction

Trust transitivity





Forest trusts

















Trusts



TrustsA 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 NTIn 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 systemsAll 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 protocolsA 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 objectsTrusted 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 typesCommunication 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 trustsBy 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


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.

Tree-

root

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 trustsFour 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


External Nontransitive One-way

or two-

way

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 two-

way

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 two-

way

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 two-

way

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 directionThe 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 trustA 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 trustAll 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 transitivityTransitivity 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 trustsEach 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 trustA 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.











When to create an external trustYou 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 trustsTo 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 worksWhen 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 threatIf 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 quarantiningSID 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 quarantiningAlthough 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 trustsIf 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.







When to create a shortcut trustShortcut 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 trustsA 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 trustsA 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.







When to create a realm trustA 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.






When to create a forest trustA 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 trustsA 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 trustsA 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 trustsIn 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 environmentForest 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 controlActive 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 forestsYou 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.






Accessing resources across domainsSince 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 domainsIt 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.











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 domainsBy 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 trustUsing 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


Accessing resources across forestsWhen 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 hintsRouting 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 forestsIt 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 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 forestsBy 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 forestsUsing 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.








Routing name suffixes across forestsName 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 detectionWhen 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 replicationThis section covers:

Sites overview






Bandwidth











Sites overview



Sites overviewSites in Active Directory® represent the physical structure, or topology, of your network. Active Directory uses topology information, stored as site and site link objects inthe 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 sitesSites 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 subnetsIn 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 sitesComputers 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 domainsIn 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.






Replication overviewExcept 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. ActiveDirectory 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 replicationData 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 sitesTo 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 topologyThe 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 familyThe Microsoft® Windows Server 2003 family includes enhancements to make replication both more efficient, as well as more scalable across a larger number of domainsand 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."











How replication worksTo 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 dataActive 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 replicationOnce 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 changesIt 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 efficiencyIntroduced 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.










Replication within a siteActive 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 topologyThe 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 occursDirectory 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.








Replication between sitesActive 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 topologyActive 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 occursActive 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.












When to establish a single or separate sitesYou 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 importantWithin 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 siteIf 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 sitesWhen 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



BandwidthBandwidth 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.






Managing replicationActive 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 linksYou 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 costThe 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 frequencyThe 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 availabilityThe 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 bridgesBy 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 serversWhen 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 catalogThis section covers:













The role of the global catalogA 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 user’saccount is located in example1.microsoft.com and the user decides to log on with a user principal name of [email protected] from a computer

located in example2.microsoft.com, the domain controller in example2.microsoft.com will be unable to find the user’s account, and will then contact a global catalogto 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 user’s 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.












Global catalog replicationReplication 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 attributesActive 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 dataSpecial 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 replicationGroups 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.








Customizing the global catalogThere 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 object’s most common attributes for every object in the entire forest, whichapplications 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.








Global catalogs and sitesTo 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 cachingDue 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.






Interoperating with DNS and Group PolicyThis section covers:

DNS integration





DNS integration



DNS integrationActive 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 integrationGroup 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 schemaThis section covers:

Schema


Schema object names









Schema



SchemaThe 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 definedIn 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 storedEach 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 cacheTo 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 schemaLike 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.













Schema classes and attributesEvery 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.

ClassesClassSchema 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 typesThree 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.

AttributesAttributeSchema 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 attributesAttributes 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 attributesBoth 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 namesWhen 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 nameThe 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 nameThe 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 identifierAn 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 rulesTo 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 aliasesA 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












Deactivating a class or attributeDomain 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 classA 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 attributeAn 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.






Extending the schemaWhen 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 schemaBefore 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 schemaYou 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 forestA 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.
















Deploying Active Directory



Deploying Active DirectoryThis section covers:

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









Deployment resources



Deployment resourcesTo 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.






Using the Active Directory Installation Wizard



Using the Active Directory Installation WizardThe 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 configurationBy 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 applicationsOn 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 non-

Microsoft 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 Pre-

Windows 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 pre-

Windows 2000 Compatible Access security group (indicating backward compatibility settings), the Anonymous Logon security group will be added as a member of the pre-

Windows 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 controllersIf 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 controllersWith 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.







Creating a new domain tree



Creating a new domain treeCreate 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.





Creating a new child domain



Creating a new child domainCreate 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.




Creating a new forest



Creating a new forestWhen 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 forestA 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 forestWhen 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 forestA 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 forestActive 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 from Windows NT or Windows 2000



Upgrading from Windows NT or Windows 2000This section covers:

Upgrading overview

Upgrading from a Windows NT domain

Upgrading from a Windows 2000 domain

Converting groups






Upgrading overview



Upgrading overviewThe Active Directory® directory service is compatible with Microsoft® Windows NT® and supports a mix of operations that support domain controllers runningWindows 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.




Upgrading from a Windows NT domain



Upgrading from a Windows NT domainSee the following recommended steps for upgrading from a Windows NT domain.

Plan and implement a namespace and DNS infrastructureBecause 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 functionalityForest 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 controllerThe 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 controllersOnce 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 domainAfter 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 computersComputers 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.





Upgrading from a Windows 2000 domain



Upgrading from a Windows 2000 domainBefore 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 2003Service 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 AlsoConceptsChecklist: Performing an upgrade


Adprep








Converting groups



Converting groupsWhen 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 ExchangeExchange 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 2003Client 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.


Administering Active Directory



Administering Active DirectoryThis section covers:

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 asLogging 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).






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 queriesSaved 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







Managing Active Directory from MMC



Managing Active Directory from MMCThe 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.



Managing Active Directory from the command line



Managing Active Directory from the command lineThe 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.













Finding directory information



Finding directory informationActive 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 accessIn 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 toolsAdministrators 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.








Administering other domains



Administering other domainsIn 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.





Delegating administration



Delegating administrationBy 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 safelyDelegate 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 groupsYou 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 consolesUsing 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.



Publishing resources



Publishing resourcesTo 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 informationBinding 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-by-

service basis and should not be published to the directory.

Configuration information can be common across client applications. Publishing this sort of information allows you to distribute current configuration information for

these applications to all clients in the domain. The configuration information is accessed by client applications as needed. This eases application configuration for

users and gives you more control over application behaviors.

Characteristics of service informationService 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.











Managing COM+ partitions in Active Directory



Managing COM+ partitions in Active DirectoryCOM+ 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.



Managing COM+ partition sets in Active Directory



Managing COM+ partition sets in Active DirectoryCOM+ 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 controllerYou 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 serversUsing 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



ResourcesThis section covers:

Web resources

Active Directory support tools

Programming interfaces





Web resources



Web resourcesThe 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








http://go.microsoft.com/fwlink/?linkid=142





Active Directory support tools



Active Directory support toolsSeveral 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.






Programming interfaces



Programming interfacesActive 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

Documents

Transcript of Understanding Active Directory