Welcome, Guest

Understanding Active Directory in Windows

Options

Previous Topic

Next Topic

	codeling 1599 - 6654
	@2016-12-30 21:00:23

In distributed computing environments, networked computers and other devices communicate over remote connections to accomplish tasks through client/server applications. Distributed environments require a central repository of information and integrated services that provide the means to manage network users, services, devices, and additional information that administrators want to store.

Organizations operating a distributed environment need to have a way to manage network resources and services. As the organization grows, the need for a secure and centralized management system becomes more critical.

A directory service provides a centralized location to store information in a distributed environment about networked devices and services and the people who use them. A directory service also implements the services that make this information available to users, computers, and applications. A directory service is both a database storage system (directory store) and a set of services that provide the means to securely add, modify, delete, and locate data in the directory store.

Active Directory directory service is the distributed directory service that is included with Microsoft Microsoft Windows 2000 Server, Windows Server 2003 and later operating systems. Active Directory enables centralized, secure management of an entire network, which might span a building, a city, or multiple locations throughout the world.

The following figure shows Active Directory as the focal point of the Windows Server network used to manage identities and broker relationships between distributed resources so they can work together.

Active Directory on a Windows Server 2003 Network

Active Directory provides:

A central location for network administration and delegation of administrative authority. You have access to objects representing all network users, devices, and resources and the ability to group objects for ease of management and application of security and Group Policy.
Information security and single sign-on for user access to network resources. Tight integration with security eliminates costly tracking of accounts for authentication and authorization between systems. A single user name and password combination can identify each network user, and this identity follows the user throughout the network.
Scalability. Active Directory includes one or more domains, each with one or more domain controllers, enabling you to scale the directory to meet any network requirements.
Flexible and global searching. Users and administrators can use desktop tools to search Active Directory. By default, searches are directed to the global catalog, which provides forest-wide search capabilities.
Storage for application data. Active Directory provides a central location to store data that is shared between applications and with applications that need to distribute their data across entire Windows networks.
Systematic synchronization of directory updates. Updates are distributed throughout the network through secure and cost-efficient replication between domain controllers.
Remote administration. You can connect to any domain controller remotely from any Windows-based computer that has administrative tools installed.
Single, modifiable, and extensible schema. The schema is a set of objects and rules that provide the structure requirements for Active Directory objects. You can modify the schema to implement new types of objects or object properties.
Integration of object names with Domain Name System (DNS), the Internet-standard computer location system. Active Directory uses DNS to implement an IP-based naming system so that Active Directory services and domain controllers are locatable over standard IP both on intranets and the Internet.
Lightweight Directory Access Protocol (LDAP) support. LDAP is the industry standard directory access protocol, making Active Directory widely accessible to management and query applications. Active Directory supports LDAPv3 and LDAPv2.

@2016-12-30 21:14:57

Parts of an Active Directory

The Windows Active Directory system comprises several pieces that are used to store and retrieve the network objects for the domain.

Domains

An AD domain contains a group of network resources sharing the same database structure and security policy. In the AD system, network administrators use a hierarchical database to organize network resources within directory contexts in the domain. This makes domain management much simpler than the Windows NT domain method.

In most AD networks, the organization’s DNS name is used as the domain name. An organization with a single DNS domain name can be configured within a single AD domain. The following figure shows how this works.

Figure 1: A single Active Directory domain

A domain is maintained by one or more domain controllers. The domain controllers of one domain may reside in one or more physical locations.

Organizational Units

Domains themselves can be subdivided into smaller entities. Organizational Units (OUs) are the containers within the domain used to group related objects (similar to the directory context in LDAP). Often the OU is based on the business structure of the organization, keeping network resource objects in each business unit (or division) in its own OU container.

One nice feature of OUs is that AD allows the network administrator to delegate local administrators at that level. You can assign a user from a local OU to manage all of the resources within the organizational unit, without having to worry about granting them security privileges to other parts of the AD database. However, you cannot assign permissions to OUs, This means that if you have an OU that contains 30 users, you problably need to create a security group and put those users in this group in order to give them permissions for specific folders or other resources.

Trees

In the Windows NT domain system, accessing network resources located in another domain meant having the network administrator arrange a complicated configuration of domain security rules. Each domain that required access to resources in another domain had to establish a trust relationship with the remote domain.

A trust relationship is the set of rules configured in a domain that allows users (or other network objects) from one domain to access network resources in another domain. For an organization with multiple domains to allow each domain access to resources in all of the other domains, a trust relationship has to be created between every combination of domains. This can quickly grow into a huge administration nightmare.

To solve this problem, the AD system created the concept of trees. A tree is an interconnection of separate domains, all within the control of a single AD database. One domain is designated as the main domain in the tree (called the root domain), and all other domains are configured as objects under the root domain (similar to the basic LDAP structure). All of the domains in the tree share the common naming space of the root domain.

For organizations that use DNS domains and subdomains, it is easy to configure an AD tree for each subdomain on the network. The following figure shows a sample of how a simple subdomain system can be configured in an AD tree. Each triangle represents a self-contained AD domain, as was shown in Figure 1. The root domain, ispnet1.net, contains objects used to control the entire tree (the domain administrator user and the main AD servers). Each subdomain is a self-contained domain, including local domain user and server objects.

Figure 2: An AD tree structure

Forests

While the concept of trees allows an organization to connect contiguous domains within the organization to a single AD database, situations may (and often do) occur where an organization contains two or more trees that must be managed. To help with this situation, AD was designed to incorporate the concept of a forest. The forest is a collection of two or more trees that incorporate the same AD database. Although the trees use the same database, they do not use the same namespace, that is, each tree still maintains its own root object, and objects within the tree are referenced based on the tree root object. The following figure shows an example of this arrangement.

Figure 3: An AD forest structure with two trees

It is often difficult for network administrators to determine when to incorporate domains within trees and forests. One important item to remember is that within a forest, each tree must maintain trust relationships between any other tree that it needs access to network resources from (similar to the old NT domain trust relationship model). For organizations that merge and share substantial resources, it may be easier to bite the bullet and merge the separate trees into a single tree rather than create a forest and deal with the trust relationships.

Active Directory Objects

The AD system is similar to LDAP but uses some different terminology and concepts. The basic item within the directory structure is still called an object. The object represents a single entity in the network, such as a server, workstation, printer, or user. Each object is defined with a class, also called an object class. This is similar to the LDAP concept of the objectClass. Each object class consists of specific attributes that are used to hold information about the object.

Active Directory objects represent the physical entities that make up a network. An object is an instance of storage of a class. A class is defined in the Active Directory schema as a specific set of mandatory and optional attributes — that is, an attribute can be present in an object in Active Directory only when that attribute is permitted by the object's class. Classes also contain rules that determine which classes of objects can be superior to (parents of) a particular object of the class. Each attribute is also defined in the directory schema. The attribute definitions determine the syntax for the values the attribute can have.

When you create an object in Active Directory, you provide values for the attributes of the object in its particular class, and you do so according to the rules of the directory schema. For example, when you create a user object, you provide alphanumeric values for the user's first and last names, the logon identifier, and perhaps other values, such as telephone number and address. You cannot create the user object successfully without providing acceptable values for the user name and logon name because these attributes are mandatory, according to the directory schema.

Applications that create or modify objects in Active Directory use the directory schema to determine what attributes the object must and might have, and what those attributes can look like in terms of data structures and syntax constraints. For this reason, the directory schema is maintained forest-wide so that all objects created in the directory conform to the same rules.

Objects are either container objects or leaf objects. A container object stores other objects, and, as such, it occupies a specific level in a subtree hierarchy. An object class is a container if at least one other class specifies it as a possible superior; thus, any object class defined in the schema can become a container. A leaf object does not store other objects, and, as such, it occupies the endpoint of a subtree.

@2016-12-30 21:30:25

Active Directory Data Model

Active Directory uses the LDAP data model, which is derived from the X.500 data model and, consequently, Active Directory implements many of X.500 features. However, Active Directory is not a full X.500 directory service.

Classes, Objects, and Attributes

The schema dictates which object classes and attributes a given forest supports. The base schema that ships with Windows Server 2003 supports 191 object classes (142 in AD2000) and 1070 attributes for those classes (863 in AD2000). Each attribute has one of 23 syntaxes, such as Integer 14, Unicode string "abc", or Generalized time 04/26/2000 2:59:01 PM.

The user class uses 257 attributes of the pool of 1070. Active Directory implements most of the X.500 standard classes, but not quite all. The classes that it does not implement are alias and strongAuthenticationUser.

For example, the Jack Brown object is an instantiation of the user class. Just as the class contains a number of attributes, the instantiated object contains the values for those attributes. However, only some of the attributes for a class are mandatory, which means that they must contain a value (a single-valued attribute such as homePhone) or values (a multivalued attribute such as otherHomePhone). Most of the attributes for a given class are optional; that is, they may contain a value, but more often they don't.

Container and Leaf Objects

Active Directory objects of some classes are container objects, and the objects of the remaining classes are leaf objects. If you compare this to a file system, container objects correspond to folders and leaf objects correspond to files. We call these two types of classes container classes and leaf classes.

One obvious example of a container class is organizationalUnit. There are also many others, however, because a total of 67 classes of the base schema are container classes and 124 are leaf classes (56 and 86 in AD2000). Interestingly, user is also a container class; user objects may contain nTFRSSubscriptions and classStore objects.

Indexing and the Global Catalog

An Active Directory database can contain thousands or even millions of objects. Therefore, we obviously need indexing to locate the right object or objects fast. Of the base schema, 69 attributes are indexed (64 in AD 2000), examples being givenName, sn (Surname) and birthLocation. Searching and retrieving objects via indexed attributes is naturally much faster and efficient than using nonindexed attributes.

The global catalog helps in making local searches in a multidomain forest. 151 attributes of the base schema are part of the global catalog (138 in AD2000), including cn, userPrincipalName, givenName, sn (Surname), and printStaplingSupported.

Partitions

An Active Directory domain is a unit of replication, A unit of replication is called a partition, or sometime a naming context (NC). This means that a domain is a partition. However, domain is not the only of partiition. Every domain controller holds a copy of the following three partitions:

The domain partition, where users, groups, OUs, and such reside.
The schema partition, where schema classes and attributes reside.
The configuration partition, where information on the forest structure resides, such as the sites and domains.

Information in the first partition (i.e., users, groups, and so on) is replicated among the domain controllers of one domain, whereas the schema and configuration partitions are replicated among all domain controllers in the forest. A copy of a partition in a given domain controller is called a replica.

The domain controller that are designated as global catalog servers hold a partial copy of all other domain partitions of the forest. A partial copy contains all objects, but it contains only those attributes that are part of the global catalog.

The following figure shows the partitions of one sample forest. The two right most partitions exist in every domain controller, whereas the sales.sano.com and sano.com partitions exist only in the domain controllers of the correspondling domain.

@2016-12-30 21:46:44

What is Schema

The schema contains rules for object instantiation—that is, it dictates which objects a directory can contain, their relationships, and their possible content. (This is true for other directory services as well as Active Directory.) In other words, the schema governs the structure and content of Active Directory with structure and content rules. The following table explains these uses of the schema.

TABLE 1 Uses of the Schema

Category	Description
Structure rules	Possible parent classes for each class (i.e., under what classes of objects each object can exist). For example, a user object may exist under the container types `organizationalUnit`, `domainDNS`, `builtinDomain`, `container`, and `lostAndFound`.
Content rules	The mandatory and optional attributes for each object class. For each attribute there is a certain syntax and value range, as well as the choice between single-value and multivalue.
Miscellaneous	Which attributes are indexed and which are stored in the global catalog. The default security descriptor, category, and hiding value for each new object. The name type (i.e., the naming attribute) of a class: CN, OU, or DC.

Table 1 describes why the schema is necessary to maintain a directory. In addition, the schema contains information that helps to maintain the schema itself. This is described in Table 2. We explore the topics introduced in Table 1 and Table 2 in the later sections "Classes" and "Attributes and Syntaxes."

TABLE 2 Inside Uses of the Schema

Category	Description
Naming and identification	Various names and ID numbers for schema classes, attributes, and syntaxes
Schema class hierarchy	Whether a class is structural, abstract, or auxiliary The parent of a class in the inheritance chain The auxiliary classes that give a class additional attributes
Protection	Whether a class or attribute is `system only` The security descriptor for a class or attribute

Location of the Schema

Because everything in Active Directory is stored in objects, the schema is implemented as a number of objects. There is one object for each class in the schema (classSchema objects) and one for each attribute (attributeSchema objects). However, there are no objects for the syntaxes; they are hard-coded into Active Directory. This means that classes and attributes can be created and modified, but syntaxes cannot.

A directory service vendor could implement the schema as a long text file. Microsoft chose to implement the Active Directory schema as Active Directory objects. This enables administrators and applications to query the schema contents and add or modify classes and attributes using the same object manipulation techniques as would be used with any Active Directory objects.

Consequently, the location of the schema is the location of the schema objects.

The Physical Location of the Schema

Every domain controller stores a full replica (or copy) of three partitions (or replication units): the schema, configuration, and domain partitions. Obviously, the schema (i.e., the schema objects) is physically located in the schema partition.

The schema partition is replicated to every domain controller in a forest, so that all domain controllers contain identical information. Any changes to the schema would have to be initiated on the domain controller that holds the schema master role.

Even though there are three separate partitions, their replicas in a given domain controller are stored in the same database table. That table resides in the Active Directory database file, which is called ntds.dit. The default location for the file is the folder C:\Winnt\NTDS.

There is another ntds.dit file located in C:\Winnt\System32. That file serves as the initial database file and it is copied to C:\Winnt\NTDS (or whatever location you choose) during the DCPromo process.

The Logical Location of the Schema

All the 1,261 schema objects (191 classes and 1070 attributes) are located in the Schema container. That container is of class dMD (the letters stand for "directory management domain") and its distinguished name is CN=Schema, CN= Configuration, DC=forest_root_domain. The following figure shows the location of the schema container in the directory tree.

The schema container is logically under the configuration container, which in turn is under the forest root domain. Physically, however, the three are different partitions.

Extending the Schema

Microsoft has defined the base schema that can be used by default to create your forest. Microsoft chose to store the Active Direcotory schema as objects in Active Directory itself. You (or your applications) can extend the schema, that is you can create new classes or attributes or add new attributes to existing classes. When creating classes, you would problably use the class inheritance.

Because the schema is common for the whole forest, only those who belong to the Schema Admins security group are able to extend the schema. Schema changes require careful planning and testing because many of the changes have implications for the whole enterprise.

Previous Topic

Next Topic

1 2 3 4

Comments

You must Sign In to comment on this topic.

Print this topic

Watch this topic

Normal

Threaded