Active Directory Domain Services (AD DS) Overview

아티클
1/17/2024

In Windows Server 2008 and later, the directory service is called Active Directory Domain Services (AD DS). In earlier versions of Windows Server, the directory service is called Active Directory.

Active Directory Domain Services Overview

Applies To: Windows Server 2008, Windows Server 2008 R2

By using the Active Directory® Domain Services (AD DS) server role, you can create a scalable, secure, and manageable infrastructure for user and resource management, and you can provide support for directory-enabled applications, such as Microsoft® Exchange Server.

In the following sections, learn more about AD DS, features in AD DS, and software and hardware considerations. For more information about planning, deploying, and operating the AD DS server role, see Active Directory Domain Services (http://go.microsoft.com/fwlink/?LinkID=48547).

What is a Directory?

A directory, in the most generic sense, is a comprehensive listing of objects. A phone book is a type of directory that stores information about people, businesses, and government organizations. Phone books typically record names, addresses, and phone numbers. AD DS is similar to a phone book in several ways, and it is far more flexible. AD DS will store information about organizations, sites, computers, users, shares, and just about any other network object that you can imagine. Not all objects are as similar to each other as those stored in the phone book, so AD DS includes the ability to record different types of information about different objects.

Lightweight Directory Access Protocol (LDAP)

AD DS reflects Microsoft's trend toward relying on standard protocols. The Lightweight Directory Access Protocol (LDAP) is a product of the IETF (Internet Engineering Task Force). It defines how clients and servers exchange information about a directory. LDAP version 2 and version 3 are used in AD DS .

Distinguished Names

It is very important to understand the structure of distinguished names, as you will be referring to them often in the course of your job. My distinguished name is /O=Internet/DC=COM/DC=Microsoft/ DC=MSPress/CN=Users/CN=Tony Northrup. Consider the following figure, which shows how I fit into a sample AD DS tree. The distinguished name I gave starts to make some sense—it identifies each container from the very top down to my specific object. Each container is separated by a slash and an identifier. For example, COM, Microsoft, and MSPress are each preceded by /DC=. The DC stands for Domain Component, which identifies a DNS domain.

http://i.technet.microsoft.com/Bb742424.f11ih09(en-us,TechNet.10).gif

Distinguished names describe the location of an object in a tree.

To simplify distinguished names, relative distinguished names can also be used. The relative distinguished name of the previous example is CN=Tony Northrup, identifying the user name but not the context in which it resides. The context must be known already for the relative distinguished name to be an effective identifier.

User Principal Name

Distinguished names are great for computers but too cumbersome for people to remember. People have grown accustomed to e-mail addresses, so AD DS provides these addresses as a shortcut to the full object name. In Figure 11-9, Tony Northrup is a user of the mspress.microsoft.com domain. An administrator could create a user principal name within the microsoft.com domain to allow simpler access to my user account and hold a place for my e-mail address, like northrup@microsoft.com.

Users will rely on their user principal name to log onto their computers. In other words, user principal names will replace the user names used in older Windows networks. Obviously, this helps the users by saving them the trouble of typing their distinguished names. However, it also benefits users because the user principal name will stay the same even if administrators move or rename the underlying user account.

What is the AD DS server role?

AD DS provides a distributed database that stores and manages information about network resources and application-specific data from directory-enabled applications. Administrators can use AD DS to organize elements of a network, such as users, computers, and other devices, into a hierarchical containment structure. The hierarchical containment structure includes the AD DS forest, domains in the forest, and organizational units (OUs) in each domain. A server that is running AD DS is called a domain controller.

Organizing network elements into a hierarchical containment structure provides the following benefits:

The forest acts as a security boundary for an organization and defines the scope of authority for administrators. By default, a forest contains a single domain, which is known as the forest root domain.
Additional domains can be created in the forest to provide partitioning of AD DS data, which enables organizations to replicate data only where it is needed. This makes it possible for AD DS to scale globally over a network that has limited available bandwidth. An AD DS domain also supports a number of other core functions that are related to administration, including network-wide user identity, authentication, and trust relationships.
OUs simplify the delegation of authority to facilitate the management of large numbers of objects. Through delegation, owners can transfer full or limited authority over objects to other users or groups. Delegation is important because it helps to distribute the management of large numbers of objects to a number of people who are trusted to perform management tasks.

Features in AD DS

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

Additional AD DS features include the following:

A set of rules, the schema, that defines the classes of objects and attributes that are contained in the directory, the constraints and limits on instances of these objects, and the format of their names.
A global catalog that contains information about every object in the directory. Users and administrators can use the global catalog to find directory information, regardless of which domain in the directory actually contains the data.
A query and index mechanism, so that objects and their properties can be published and found by network users or applications.
A replication service that distributes directory data across a network. All writable 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.
Operations master roles (also known as flexible single master operations or FSMO). Domain controllers that hold operations master roles are designated to perform specific tasks to ensure consistency and eliminate conflicting entries in the directory.

Identity Management for UNIX

Identity Management for UNIX is a role service of AD DS that can be installed only on domain controllers. Two Identity Management for UNIX technologies, Server for NIS and Password Synchronization, make it easier to integrate computers running Microsoft Windows® into your existing UNIX enterprise. AD DS administrators can use Server for NIS to manage Network Information Service (NIS) domains. Password Synchronization automatically synchronizes passwords between Windows and UNIX operating systems.

New AD DS features in Windows Server 2008 R2

Feature	Description
Active Directory Administrative Center	Active Directory Administrative Center provides users and network administrators with an improved data management experience and a rich graphical user interface (GUI) to perform common Active Directory object management tasks. Built on Windows PowerShell™ technology, Active Directory Administrative Center makes it possible for users and network administrators to administer directory service objects through both data-driven navigation and task-oriented navigation.
Active Directory module for Windows PowerShell	The Active Directory module for Windows PowerShell is a command-line interface that administrators can use to configure and diagnose all instances of Active Directory Domain Services (AD DS) and Active Directory Lightweight Directory Services (AD LDS) in their environments. This feature includes a set of Windows PowerShell cmdlets and a provider. The provider exposes the Active Directory database through a hierarchical navigation system, which is very similar to the file system. As with drives in a file system (C:, D:), you can connect Windows PowerShell drives to Active Directory domains and AD LDS instances, as well as Active Directory snapshots.
Active Directory Recycle Bin	Active Directory Recycle Bin minimizes directory service downtime by improving the ability to preserve and restore accidentally deleted Active Directory objects without having to restore Active Directory data from backups, restart AD DS, or restart domain controllers. When Active Directory Recycle Bin is enabled, all link-valued and non-link-valued attributes of the deleted objects are preserved and the objects are restored in their entirety to the same consistent logical state that they were in immediately before deletion. For example, restored user accounts automatically regain all group memberships and corresponding access rights that they had within and across domains immediately before deletion. Active Directory Recycle Bin is functional for both AD DS and AD LDS environments. Active Directory Recycle Bin requires the Windows Server 2008 R2 forest functional level, and it is disabled by default. To enable it, you can use Ldp.exe or the Windows PowerShell Enable-ADOptionalFeature cmdlet.
Active Directory Web Services (ADWS)	ADWS is a Windows service that provides a Web service interface to AD DS and AD LDS directory service instances and to Active Directory snapshots that are running on the same Windows Server 2008 R2 server as ADWS. ADWS is installed automatically when you add the AD DS or AD LDS server roles to your Windows Server 2008 R2 server.
Authentication Mechanism Assurance	Authentication Mechanism Assurance packages information about the type of logon method (smart card or user name/password) that is used to authenticate domain users inside each user’s Kerberos token. When this feature is enabled in a network environment that has deployed a federated identity management infrastructure, such as Active Directory Federation Services (AD FS), the information in the token can then be extracted whenever a user attempts to access any claims-aware application that has been developed to determine authorization based on a user’s logon method. Authentication Mechanism Assurance requires the Windows Server 2008 R2 domain functional level.
Offline domain join	An offline domain join is a new process that computers running Windows® 7 or Windows Server 2008 R2 can use to join a domain. The offline domain join process can complete the domain join operation without network connectivity.

Installing the AD DS server role

After you finish installing the operating system, you can use Initial Configuration Tasks or Server Manager to install server roles. To install the AD DS server role, click Add roles to start the Add Roles Wizard, and then click Active Directory Domain Services. Follow the steps in the Add Roles Wizard to install the files for the AD DS server role. After you complete the Add Roles Wizard, click the link to start the Active Directory Domain Services Installation Wizard.

Follow the steps in the Active Directory Domain Services Installation Wizard to complete the installation and configuration of your domain controller. Most wizard pages have a Help link for more information about the settings that you can configure.

To automate domain controller installations, you can use an answer file or you can specify unattended installation parameters at the command line. For more information about installing AD DS, see the AD DS Installation and Removal Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=110897).

Managing the AD DS server role

You can manage server roles with Microsoft Management Console (MMC) snap-ins. To manage a domain controller (that is, a server that is running AD DS), click Start, click Control Panel, click Administrative Tools, and then double-click the appropriate snap-in:

To manage Active Directory objects by using the newest GUI tool, with improved options for viewing and managing Active Directory data, click Active Directory Administrative Center.
To manage Active Directory objects by using a predefined set of Windows PowerShell cmdlets and a provider, click Active Directory Module for Windows PowerShell.
To manage user and computer accounts, click Active Directory Users and Computers (dsa.msc).
To manage Active Directory trusts, functional levels, and forest-wide operations master roles, click Active Directory Domains and Trusts (domain.msc).
To manage Active Directory sites and site links, click Active Directory Sites and Services (dssite.msc).

As an alternative, you can double-click the appropriate snap-in on the Active Directory Domain Services page in Server Manager.

Security

AD DS plays an important role in the future of Windows networking. Administrators must be able to protect their directory from attackers and users, while delegating tasks to other administrators where necessary. This is all possible using the AD DS security model, which associates an access control list (ACL) with each container, object, and object attribute within the directory. The following figure shows a step from the Delegation Of Control wizard, a helpful utility for assigning permissions to AD DS objects.

http://i.technet.microsoft.com/Bb742424.f11ih01(en-us,TechNet.10).gif

The Delegation Of Control wizard makes it simple to assign permissions to objects.

This high level of control allows an administrator to grant individual users and groups varying levels of permissions for objects and their properties. Administrators can even add attributes to objects and hide those attributes from certain groups of users. For example, the administrator could set the ACLs such that only managers can view the home phone numbers of other users. Nonmanagers would not even know that the attribute existed.

A concept new to Windows Server is delegated administration. This allows administrators to assign administrative tasks to other users, while not granting those users more power than necessary. Delegated administration can be assigned over specific objects or contiguous subtrees of a directory. This is a much more effective method of giving authority over the networks; rather than granting someone the all powerful Domain Administrator permissions, he or she can be given permissions for just those computers and users within a specific subtree. AD DS supports inheritance, so any new objects inherit the ACL of their container.

Try to forget what you've learned about Windows NT domain trusts. The term trusts is still used, but trusts have very different functionality. There is no distinction between one-way and two-way trusts because all AD DS trusts are bidirectional. Further, all trusts are transitive. So, if Domain A trusts Domain B, and Domain B trusts Domain C, then there is an automatic implicit trust between Domain A and Domain C. This new functionality is shown in the following figure.

http://i.technet.microsoft.com/Bb742424.f11ih02(en-us,TechNet.10).gif

Windows Server trusts are bidirectional and transitive.

Another AD DS security feature is auditing. Just as you can audit NTFS partitions, objects and containers within AD DS can be audited. This is a useful way to determine who is attempting to access objects, and whether or not they succeed.

Use of DNS (Domain Name System)

Domain Name System, or DNS, is necessary to any Internet-connected organization. DNS provides name resolution between common names, such as mspress.microsoft.com, and the raw IP addresses that network layer components use to communicate. AD DS makes extensive use of DNS technology and relies on DNS to locate objects within AD DS. This is a substantial change from previous Windows operating systems that require NetBIOS names to be resolved to IP addresses, and to rely on WINS or another NetBIOS name resolution technique.

AD DS works best when used with Windows Server–based DNS servers. Microsoft has made it easy for administrators to transition to Windows Server–based DNS servers by providing migration wizards that walk the administrator through the process. Other DNS servers can be used, but administrators will need to spend more time managing the DNS databases. If you decide not to use Windows Server–based DNS servers, you should make sure your DNS servers comply with the new DNS dynamic update protocol. AD DS servers rely on dynamic update to update their pointer records, and clients rely on these records to locate domain controllers. If dynamic update is not supported, you will have to update the databases manually.

Note: DNS dynamic update protocol is defined in RFC 2136.

Windows domains and Internet domains are now completely compatible. A domain name such as mspress.microsoft.com will identify AD DS domain controllers responsible for the domain, so any client with DNS access can locate a domain controller. AD DS clients can use DNS resolution to locate any number of services because AD DS servers publish a list of addresses to DNS using the new features of dynamic update. These addresses identify both the domain and the service being provided and are published via Service Resource Records (SRV RRs). SRV RRs follow this format:

service.protocol.domain

AD DS servers provide the LDAP service for object location, and LDAP relies on TCP as the underlying transport-layer protocol. Therefore, a client searching for an AD DS server within the mspress.microsoft.com domain would look up the DNS record for ldap.tcp.mspress.microsoft.com.

Global Catalog

AD DS provides a global catalog (GC). No, this does not mean that you can find any piece of information on the planet—but it is still very significant. AD DS provides a single source to locate any object within an organization's network.

The global catalog is a service within Windows Server that allows users to find any objects to which they have been granted access. This functionality far surpasses that of the Find Computer application included in previous versions of Windows, because users can search for any object within AD DS: servers, printers, users, and applications. For example, the following figure shows how a user can search for all color printers in his or her building that have the capability to print double-sided documents.

http://i.technet.microsoft.com/Bb742424.f11ih03(en-us,TechNet.10).gif

The global catalog helps users find network resources.

This feature is especially important because of the complexity of LDAP names. Older versions of Windows relied on 15-character NetBIOS computer names, which users could often remember. Few people would be able to recall LDAP names, such as the following:

/O=Internet/DC=COM/DC=Microsoft
/DC=MSPress/CN=Computers/CN=Server1.

Because users can easily search for objects, remembering names is much less important.

The GC is an index stored on AD DS servers. It contains the names of all objects in the AD DS server, regardless of how the server has been partitioned. The GC also contains a handful of searchable attributes for each object. For example, the GC would store the distinguished names, first names, and last names of all users—allowing someone to search for anyone named Tony and find the distinguished name of the user. The global catalog is a subset of AD DS, and stores only those attributes that users tend to search on. Useful defaults are provided by Microsoft, and administrators can specify other attributes to be searchable by using the AD DS Schema, described later in this chapter.

Not All Indexes Are Created Equal!

If you have done any database administration, you already know that some types of information are more useful to index than other types. Naturally, you should index attributes that will be searched for often, but there are other factors involved. Indexes take up space, so it is not efficient to index everything. Indexes also slow down updates and inserts—if an indexed attribute is modified, the index must be modified as well. Indexing works better when the data being stored varies from user to user. Therefore, never index true or false attributes or any attribute with less than five possible values. Names are an excellent attribute to index since they are almost unique for each user. Finally, don't index attributes that aren't usually filled in. If few users enter a value for their middle name, the indexing of that attribute is a waste.

As new objects are created in AD DS, they are assigned a unique number called a GUID (globally unique identifier). The GUID is useful because it stays the same for any given object, regardless of where the object is moved. The GUID is a 128-bit identifier, which isn't particularly meaningful to users, but applications that reference objects in AD DS can record the GUIDs for objects and use the global catalog to find them even after they've moved.

Replication

Administrators who implement AD DS will quickly discover that their network relies heavily on its services. This reliance means that AD DS must be available on multiple servers—so that if a single server fails, clients can contact a server with duplicate services and information. Unlike the Windows NT domain databases used with previous versions of Windows NT, updates to the database can be sent to any of the AD DS servers. While this complicates the replication process, it eliminates the possibility that the failure of a single domain controller would stop updates to the databases. It also reduces the high load placed on Windows NT 4.0 primary domain controllers.

AD DS includes a replication component that makes this a simple task for administrators. Simply adding domain controllers to an AD DS is sufficient to begin the replication process.

One of the most complex parts of making redundant servers work properly is replicating the information and ensuring that all servers have the most up-to-date content. AD DS uses multimaster replication, which is another way of stating that updates can occur on any AD DS server. Each server keeps track of which updates it has received from which servers, and can intelligently request only necessary updates in case of a failure.

How AD DS Replication Works

Each update is assigned its own 64-bit unique sequence number (USN) from a counter that is incremented whenever a change is made. These updates are system-specific, so every AD DS server maintains a separate counter.

When a server replicates an update to other AD DS domain controllers, it sends the USN along with the change. Each server maintains an internal list of replication partners and the highest USN received from them. The server receiving the update requests only those changes with USNs higher than previously received. This method has the added benefit of stopping updates from propagating endlessly between multiple AD DS domain controllers.

One problem inherent in any multimaster replication scheme is that updates to a single object can occur in multiple places at the same time. For example, if an administrator in Boston changes a user's name from "Curt" to '"Kurt" and an administrator in Chicago simultaneously changes that same user's name from "Curt" to "Kirk," a replication collision will occur. There are two problems to deal with when a collision occurs: detecting the collision and resolving the collision.

AD DS stores property version numbers to allow replication collision detection. These numbers are specific to each property of every object within AD DS and are updated every time the property is modified. These numbers are propagated through AD DS along with the change, so a server that receives two different updates to the same property with the same property version number can conclude that a replication collision has occurred.

AD DS domain controllers resolve collisions by applying the update with the later timestamp. The timestamp is created by the server that initiated the change, so it is very important to keep system time synchronized between servers.

Note: Use the built-in distributed time synchronization service to keep all servers working together!

Partitioning

Large networks can contain hundreds of thousands of objects. Windows NT required multiple domains to allow that many objects to be manageable. Administrators often divided users and resources into separate domains and created a trust between the domains. The structure of the databases simply did not allow them to grow to hundreds of thousands of objects. These size limitations are less a factor in AD DS domains, thankfully. However, supporting a very large AD DS could be an incredible burden to any single domain controller.

Active Directories can be partitioned to lessen this load. Partitioning allows different domain controllers to manage different sections of the database, reducing the load on any individual server. The clients can use resources located within different AD DS partitions transparently. Therefore, administrators can manage massive AD DS domains without requiring domain controllers to handle the entire database.

Objects

Many people are initially confused by the relationship between object classes, attributes, and the objects themselves. Objects are created based on an object class. Attributes describe an object class. When an object is created, it inherits all the attributes of its object class. Here's where it gets tricky: object classes and attributes are also objects in AD DS. Fortunately, most user interfaces hide this fact.

An object can be either a reference to something concrete or the actual useful information itself. For example, every bit of information about a user account is stored within AD DS. However, only a reference to a disk volume is stored in AD CS. While the reference is not useful by itself, it is used to locate the volume on the file server. When creating new object classes, carefully consider whether the object will store a reference to something external or whether all necessary information will be contained in the object's attributes. While AD DS is extremely convenient, it should not be used to store large amounts of information, constantly changing information, or rarely used information.

Anytime you add a user or a computer to AD DS, you are creating an object. Creating an object is often referred to as publishing, because it kicks off a process of replicating the new information across all AD DS domain controllers in the domain.

Schema: Attributes and Object Classes

A schema is a set of attributes used to describe a particular object class in AD DS. Different types of information need to be tracked for different object classes, and that's why the schema is so important. For example, the Users object class needs attributes for a first name, last name, phone number, e-mail address, and mailing address. The Printer object class must have many different attributes—users will want to know how fast a printer is and whether it can duplex or print in color. These attributes can be viewed and edited using the AD DS Schema MMC snap-in, as shown in the following figure.

Experienced programmers and system administrators can manage the AD DS schema, but the AD DS Schema snap-in is not installed by default. In addition, the Schmmgmt.dll file (regsvr32 schmmgmt.dll) must be registered from an elevated command prompt before the snap-in can be installed. The AD DS Schema does not have an icon within the Start menu; you must launch the MMC interface and add the snap-in named AD DS Schema.

http://i.technet.microsoft.com/Bb742424.f11ih04(en-us,TechNet.10).gif

The AD DS Schema allows classes and attributes to be modified.

By default, object classes come with a logical set of attributes that will fit most organization's needs. However, many organizations will need to track additional information about particular object classes. For example, if employees are assigned a badge number, it is useful to track that information in the object class. The first step is to create an attribute called BadgeID, as shown in the following figure. The second step is to make the new attribute optional for the Users class.

http://i.technet.microsoft.com/Bb742424.f11ih05(en-us,TechNet.10).gif

Attributes can be added with the AD DS Schema snap-in.

The schema is stored within AD DS just like other objects. Therefore, the schema inherits the ability to be automatically replicated throughout a domain. It also benefits from the security features of AD DS, and allows administrators to delegate authority over the schema to different users and groups. By changing the ACLs on a schema object, an administrator can allow any user to add or modify attributes for an object class. The example in the following figure shows that the group East Coast Administrators has been granted full control over the schema.

http://i.technet.microsoft.com/Bb742424.f11ih06(en-us,TechNet.10).gif

Modifying the schema can be delegated to groups and users.

New attributes have several properties that must be set. The user creating a new attribute must define a name for the attribute (such as Badge ID #), the type of data to be stored (such as a string or a number), and the range limits (such as string length). A unique Object Identifier (OID) must also be provided. New attributes can be indexed, which adds the attributes to the global catalog. Indexes should be created for attributes that users will search with. In this example, if security needs to look up user accounts by the Badge ID number, this attribute should be indexed. For a search to occur on a nonindexed attribute, a slow and processor-intensive walk of the directory tree must be done.

Where Do Object Identifiers Come From?

The only way to ensure Object Identifiers are globally unique is to have a central agency that assigns OIDs. This is already common practice on the Internet; the InterNIC assigns domain names and the Internet Assigned Numbers Authority (IANA) assigns IP subnets. Object Identifiers are assigned by a National Registration Authority, or NRA. NRAs vary from country to country. In the United States, the American National Standards Institute (ANSI) provides NRA services. For a modest fee, ANSI can supply your organization with a root OID. Any objects created by your organization will have this root OID as the prefix, ensuring that Object Identifiers are globally unique.

A list of NRAs can be found at the International Standards Organization's Web site, at http://www.iso.ch.

The schema is cached by AD DS domain controllers for performance reasons. It will take up to five minutes for the cache to be updated after you change the schema. So, wait a few minutes before you try to create objects based on your new object classes and attributes. If you must reload the cache immediately, add the attribute schemaUpdateNow to the root object (the object without a distinguished name), and set the value to 1.

Extending the schema of AD DS is a powerful capability. However, most administrators will never need to use anything but the classes and attributes .Microsoft has provided by default.

ADSI (Active Directory Service Interface)

ADSI (Active Directory Service Interface) allows applications to interact with any directory service without being forced to know the internal details of the underlying protocols. Administrators can write programs and scripts that make use of ADSI to read or write to legacy Windows NT 4.0 directories, NetWare NDS directories, NetWare 3 binderies, and LDAP directories such as AD DS. Developers can even create applications that make use of directories at the customer's site, without previous knowledge of the type of directory being used.

For example, the following Microsoft Visual Basic code uses ADSI to display a list of users in the debug window:

Set ou = GetObject("ldap://dcserver/OU=Sales,DC=ArcadiaBay,DC=COM")
For Each obj In ou
Debug.Print obj.Name
Next

As you can see, gathering a list of users is much simpler than in previous Windows operating systems. ADSI makes use of the Component Object Model (COM), so almost any Windows development environment can immediately make use of the interface. Developers will be interested to know that they can access Active Directory through the LDAP C API and through MAPI, though ADSI is the preferred interface.

Note: The LDAP C API is defined in RFC 1823.

Active Directory Wiki Pages

[[Active Directory Replication over Firewalls]]
[[Design Considerations for Delegation of Administration in Active Directory]]

다음을 통해 공유