guy.netlify.com

I previously posted 'quick-hitter' blogs about the schema versions in Windows 8 Developers Preview, Windows Server 8 Beta Windows Server 2012 was released today!! The schema version did not change from the RC version. The final version is 56 I once again used adfind to quickly find the schema version. Below is a list of OS versions and related schema versions. Find out the current schema version by inspecting the objectVersion property of CN=Schema,CN=Configuration, For example, to find out the current schema version, use a tool like ADSIEDIT or dsquery, e.g.: dsquery. CN=Schema,CN=Configuration, -scope base –attr objectVersion or use PowerShell: Get-ADObject (Get-ADRootDSE.

• Active Directory Schema Versions
• Active Directory Schema Version Table Of Word
• Check Schema Version Active Directory

Home > Articles > Operating Systems, Server > Microsoft Servers

Expand the schema node in the navigation pane, and then click ms-Exch-Schema-Version-Pt. If the ms-Exch-Schema-Version-Pt schema attribute is not listed, click General on the Options menu, increase the value of the Max children buffer size, click OK, and then repeat the previous step. This should be 1,000 by default.

1. Schema

Schema

In this section we explain the role of the schema, its location, and its inspection. We also explain briefly the topics of subschema subentry and schema cache.

Role of the 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. Table 8.1 explains these uses of the schema.

Table 8.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 8.2. We explore the topics introduced in Table 8.1 and Table 8.2 in the later sections 'Classes' and 'Attributes and Syntaxes.'

TABLE 8.1 Uses of the Schema

TABLE 8.2 Inside Uses of the Schema

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.

NOTE

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

As you learned in Chapter 5, 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.

You also learned that 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 (as explained in Chapter 5).

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:WinntNTDS.

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

NOTE

You may also come up with a file schema.ini (in C:WinntSystem32). Despite its name, it doesn't initialize the schema in any way. Instead, it contains the information for the initial objects in your tree—mostly for the domain and configuration partitions.

The Logical Location of the Schema

All the 1,005 schema objects (142 classes and 863 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. Figure 8.3 shows the location of the schema container in the directory tree.

Figure 8.3 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.

NOTE

Although there seems to be a CN=Configuration object under your root domain, you won't see it in the Users and Computers snap-in, even with Advanced Features turned on. That snap-in is meant to show contents of only domain partitions.

Inspecting the Schema with ADSI Edit

Now that you know that the schema is implemented as a number of objects and you know where to find them, we can start studying them in the user interface. The two main tools for the job are as follows:

• ADSI Edit, a general tool for viewing all the objects in Active Directory

• The Schema Manager snap-in, a specialized tool for viewing and managing the schema

We begin our discussion of these two tools with ADSI Edit. Because it is a general tool, it nicely shows you the general picture and the location of the schema objects, not just the schema contents.

NOTE

There are other tools that you can use to view the schema. For example, Support Tools contains LDP, which enables you to do various LDAP operations—among others, to view the schema.

We mentioned previously that with the Users and Computers snap-in you see only part of the objects and only part of the attributes of each object. With ADSI Edit you see all the objects and all of their attributes.

ADSI Edit is part of Support Tools, which you have to install separately. Locate the folder SupportTools on your Windows 2000 CD and run Setup.Exe. After the installation, you will find the tool by clicking the Start button and then selecting Programs, Windows 2000 Support Tools, Tools.

Figure 8.4 shows the screen that opens when you launch ADSI Edit. ADSI Edit shows container objects with yellow folder icons and leaf objects with white icons similar to the icons used for text documents in Windows Explorer. The left pane shows only container objects, and the right pane shows both container and leaf objects.

Figure 8.4 When you first start ADSI Edit, it shows three partitions (aka naming contexts). Under the Schema container you can see all the class and attribute objects.

To familiarize yourself with ADSI Edit, it's a good idea to first check the properties (or attributes) of one of your users before you start to explore the schema objects.

Gundam ms 08th episode 1. KissAnime, you can watch Mobile Suit Gundam: The 08th MS Team (Sub) Episode 1 'War for Two' Anime online free and more Anime online Free in high quality, without downloading. Watch Mobile Suit Gundam: The 08th MS Team (Dub) Episode 1 Online for Free without Advertisements only on AnimeVibe. Alternate Titles: 機動戦士ガンダム 第08MS小隊 Mobile Suit Gundam: The 08th MS Team Kidou Senshi Gundam: Dai 08 MS Shotai,Kidou Senshi Gundam: Dai 08 MS Shoutai.

Inspecting Attributes of Classes and Attributes

When you are ready to move to the schema objects, you can start inspecting their attributes. For example, you can check the attributes of the user class schema object (see Figure 8.5).

Figure 8.5 When you select Properties in the context menu of any object, ADSI Edit opens a dialog box that enables you to browse all the attributes of that object. From the first drop-down list, you can choose Mandatory, or Optional, or Both.

WARNING

ADSI Edit enables you to change the attribute values. When you study schema objects, be sure to click Cancel at the end. Do not click OK or Apply.

Note that because all objects contain attributes, classSchema and attributeSchema objects also contain attributes. For example, the object CN=Jack Brown has an attribute givenName, with the value 'Jack.' The schema contains the object CN=Given-Name, which in turn contains such attributes as schemaIDGUID and attributeSyntax.

We discuss the contents of classSchema objects a little later in the section 'Classes' and attributeSchema objects in the section 'Attributes and Syntaxes.'

NOTE

ADSI Edit displays all the attributes of a class or attribute object, but only some of them are meaningful to the schema. Most of the attributes are the same ones that all objects in Active Directory have, such as uSNChanged, which helps to track replication.

TIP

SchemaIDGUID and some other attributes use OctetString syntax, which is about the same as binary. If you want to see just the bytes without '0x's, you can copy and paste the string to Notepad and then replace all '0x's with nothing.

Various Attribute Names

You may have noticed that each attribute has two slightly different names. Table 8.3 summarizes the two naming conventions together with the administrative tool name.

TABLE 8.3 Various Attribute Names

NOTE

Unlike the example in Table 8.3, the three attribute names may be quite different, such as 'Surname'—'sn'—'Last name' or 'WWW-Page-Other'—'url'—'Web Page Address (Others).' This is the case especially with attributes that have long-established X.500 names.

Just as attributes do, classes have both common names and LDAP names.

Sometimes the common name and LDAP name are the same, but they refer to different attributes. Table 8.4 gives two examples of this (using four attributes).

TABLE 8.4 Some Confusing Name Pairs

The attribute names that you see in administrative snap-ins, such as Users and Computers, are not usually stored in the schema. Instead, you find them under the DisplaySpecifiers container, which in turn is under the Configuration container. In this container, first locate the object with your locale identifier (e.g., 409 for 'English (United States)'). Then open the properties for CN=user-Display and select the attribute attributeDisplayNames. It is a multivalued attribute that contains pairs of LDAP names and display names.

NOTE

The list of name pairs is not likely to contain display names for all attributes. For names that are not on the list, each attribute schema object has an attribute adminDisplayName, which the administrative tools can use instead.

NOTE

In reality, the Users and Computers snap-in doesn't use all the display specifier attributes (even though it is suggested here and in Microsoft's documentation). For example, most of the field names in user properties (such as Description or Office) are hard-coded in the tool instead of readable from the attributeDisplayNames attribute.

We use mainly LDAP names in this book for three reasons:

• If you use ADSI scripts, you need LDAP names. Age regression the process.

• If you use LDAP filters, you need LDAP names.

• The Schema Manager snap-in, Replication Monitor, and many other administration tools use LDAP names.

Inspecting the Schema with the Schema Manager Snap-In

The Schema Manager snap-in is made specifically for viewing and managing the schema. Because Microsoft doesn't make it available to casual users, you have to take some extra steps to access it.

WARNING

Just as with ADSI Edit, do not select OK or Apply in the Schema Manager snap-in dialog boxes. Always exit by clicking Cancel.

TIP

If you want to run the Schema Manager snap-in in a workstation, you must first install the Admin Pak. Locate the file AdminPak.MSI in the I386 folder of a Windows 2000 Server CD. When you double-click that file, it will install the Admin Pak.

1. In the Run window (click the Start button and select Run) or at the command prompt, enter the command regsvr32 schmmgmt.dll and press Enter. You should get a message indicating that the registration was successful.

2. Start MMC (Microsoft Management Console) by typing mmc and press Enter (again, either in the Run window or at the command prompt).

3. In the Console menu, select Add/Remove Snap-in. In the dialog box that opens, click Add.

4. From the list of snap-ins, select Active Directory Schema, click Add, and click Close. Click OK to close the original dialog box.

5. To save what you just did, in Console menu select Save As, select the name and location of the .msc file that you want, and click Save. Next time you want to start the snap-in, double-click the .msc file you just saved.

Now you are ready to take a look at your schema from a slightly different view than what you saw with ADSI Edit. Figure 8.6 and Figure 8.7 illustrate this view.

Figure 8.6 When you start the Schema Manager snap-in, it shows two containers: one for all the classes and one for attributes. Unlike with ADSI Edit, the objects are listed by their LDAP names.

Figure 8.7 When you select a class in the left pane, the right pane shows the attributes for that class. Again, they are listed by their LDAP names. The text in the description column is usually the same as the common name you can see with ADSI Edit.

Using the Schema Manager snap-in, you can also see the mandatory and optional attributes for any class, which would be quite cumbersome with ADSI Edit. Note that this time we don't mean the attributes of a classSchema object, such as schemaIDGUID, but the attributes that the instances of the class may use, such as homeDirectory or givenName.

In addition to the lists in the screen shots in Figure 8.6 and Figure 8.7, you can open a properties dialog box for any class or attribute. We show those dialog boxes and discuss them in the later sections 'Classes' and 'Attributes and Syntaxes.'

NOTE

You must select an attribute in the Attributes container to be able to open the properties dialog box for it. If you select the attribute from the list shown in Figure 8.7, you will see just one item, Help, when you right-click the attribute.

Dumping the Schema to a Spreadsheet

Although the two graphical tools we just described are nice to use to explore the schema, they both have one problem: You can see the attributes for only one classSchema or attributeSchema object at a time.

In this section we explain how you can dump all the information in your schema to a spreadsheet. It allows a broader view to the schema contents. Also, you can sort and filter the data, which gives you a better idea of how the various attributes are used. As you read on in this chapter, you can use the tables created here as a reference.

We use Excel in our explanation of how to dump the schema into a spreadsheet, but you can use other spreadsheet and database applications. First, you dump all your classSchema and attributeSchema objects into two text files, and then import those text files to Excel.

At a domain controller, you must type the following two commands at the command prompt (click the Start button and select Programs, Accessories, Command Prompt)and press Enter after each command:

You should see output like the following for each command:

Each of the two commands specifies an output file, a base distinguished name from which to dump, and an LDAP filter.

NOTE

You can also use the CSVDE tool on a workstation. See its online help for more information.

Next you must launch Excel and perform the following steps for both of your text files:

1. Select File, Open.

2. Select one of your newly created text files and click Open. A text import wizard should start up.

3. Specify that your data is delimited (instead of fixed width).

4. Specify that the delimiter is a comma.

5. Click Finish to complete the wizard. You should now have about 30 columns of data, one column for each attribute.

6. Click cell A2 to activate it. Choose Freeze Panes in the Window menu. Now your first row with the column labels (i.e., attribute names) stays visible, even if you scroll down the sheet.

7. Adjust the width of each column as you like. You can also double-click the right border of each column header (F, G, H, and so on) to autosize the columns. Note that some of the data values may be longer than the width of your screen. If you cannot resize a wide column by dragging its right border with a mouse, you can use the Format menu option Column, Width.

8. If they are present, remove the columns uSNChanged, uSNCreated, whenChanged, whenCreated, dITContentRules, extendedClassInfo, modifyTimeStamp, and extendedAttributeInfo. You are not interested in them because they don't define schema characteristics.

9. Open the Data menu and select Filter, AutoFilter. This turns each column header into a drop-down list filter. When you open a list, you see all the distinct values for that column (i.e., attributes). If you select a value, your sheet will be filtered to show only the lines with that value.

10. Save the sheet in XLS format.

Figure 8.8 shows an Excel sheet that results from the preceding steps. We haven't sorted the lines—you might want to sort them by the lDAPDisplayName column (using the Sort feature in the Data menu of Excel).

Figure 8.8 After you have all the class definitions in Excel, you can filter in just the classes you specify—for example, classes that have defaultHidingValue = False.

Subschema Subentry

Active Directory supports LDAPv3, which requires a directory service to expose its schema in a single subSchema object. Active Directory stores this object in the Schema container with the name CN=Aggregate.

The Aggregate object contains some multivalued attributes, which list the classes and attributes available in the schema. If you want to take a look, those attributes are as follows:

• objectClasses
• attributeTypes
• extendedClassInfo
• extendedAttributeInfo
• dITContentRules

In Chapter 10 and Chapter 11, we use the ADSI interface for directory access. When you specify a path such as LDAP://sanao.com/schema for ADSI, or just LDAP://schema, ADSI will expose the subSchema object as one container with 142 classes, 863 attributes, and 33 syntaxes under it. The properties for these 'virtual objects' are more limited than those with the real Schema container, but they have some advantages for scripting.

NOTE

Active Directory supports 23 syntaxes, as discussed later in this chapter. The ADSI interface is using 33 syntaxes because it must support other environments also—most notably, NetWare. The ADSI syntaxes are listed in Chapter 10.

Schema Cache

Because the schema guards the structure and content of Active Directory objects, it is needed every time any object (such as the user Jack Brown) is added or modified. Accessing the schema from the ntds.dit file would be too slow; therefore, every domain controller holds a copy of the schema in RAM. This copy is called the schema cache.

Internally the schema cache is not an identical copy of the bytes on disk; it is structured a little differently for easy and fast access.

Naturally the schema cache is built based on the information in the disk version each time the domain controller starts. If a change is made to the schema on the schema master, the change starts to replicate to other domain controllers, just as any change to Active Directory does. In each domain controller, the change goes first to the schema on disk and then, after a 5-minute delay, the schema cache is updated.

You cannot use most of the schema changes until they are in the schema cache of the domain controller you are using. Consequently, there is an additional 5-minute wait after the possible replication latency from the schema master to your domain controller. During this waiting period, applications continue to use the old schema cache.

The 5-minute delay here is for the same reason as with replication. After one change, usually more changes soon follow. Because each schema cache update consumes quite a few bytes of memory, it is more efficient to wait a little and make them all at once.

NOTE

The 5-minute period is counted from the first change, and it doesn't reset if there is another change 1 minute later. Therefore, that latter change has to wait only 4 minutes to get into the schema cache.

The extra memory consumption in schema reload is due to the fact that when a new schema version is reloaded in cache, the old schema cache stays in memory for all the threads that were already running. Once all the old threads have exited, the older schema cache copy is released from memory. This also means that if you test schema changes, you probably need to restart your admin tools, so that they start to use the new schema cache and therefore can see the changes.

Triggering the Schema Cache Update

If 5 minutes is too long for you to wait, you can trigger the cache update immediately with the Schema Manager snap-in. In the left pane, right-click the node Active Directory Schema and select Reload the Schema. There is also a programmatic way to trigger the schema cache update. You must write the value 1 to an attribute schemaUpdateNow residing in a special rootDSE virtual object. We cover this in later chapters:

• Chapter 9 contains an example of adding a new attribute and class to the schema and triggering the update using the LDIFDE tool.

• Chapter 10 describes the rootDSE object in more detail.

• Chapter 11 contains an example of adding a new attribute and class to the schema and triggering the update using the ADSI interface in a script.

Before we conclude our discussion about the schema in general, we'll mention the constructed attributes.

Constructed Attributes

Not all attributes for an object are stored in the schema on disk. Instead, they are built from other attributes. Twenty-two of the 863 attributes in the base schema are constructed.

The 22 constructed attributes are as follows:

Related Resources

• Book $47.99

• eBook (Watermarked) $38.39

• Book $47.99

Active Directory (AD) is a directory service developed by Microsoft for Windows domain networks. It is included in most Windows Serveroperating systems as a set of processes and services.^[1][2] Initially, Active Directory was only in charge of centralized domain management. Starting with Windows Server 2008, however, Active Directory became an umbrella title for a broad range of directory-based identity-related services.^[3]

A server running Active Directory Domain Service (AD DS) is called a domain controller. It authenticates and authorizes all users and computers in a Windows domain type network—assigning and enforcing security policies for all computers and installing or updating software. For example, when a user logs into a computer that is part of a Windows domain, Active Directory checks the submitted password and determines whether the user is a system administrator or normal user.^[4] Also, it allows management and storage of information, provides authentication and authorization mechanisms, and establishes a framework to deploy other related services: Certificate Services, Active Directory Federation Services, Lightweight Directory Services and Rights Management Services.^[5]

Active Directory uses Lightweight Directory Access Protocol (LDAP) versions 2 and 3, Microsoft's version of Kerberos, and DNS.

• 2Active Directory Services
• 3Logical structure
  • 3.2Forests, trees and domains
    • 3.2.1Organizational units
• 4Physical structure
• 7Trusting

History[edit]

Active Directory, like many information-technology efforts, originated out of a democratization of design using Request for Comments or RFCs. The Internet Engineering Task Force (IETF), which oversees the RFC process, has accepted numerous RFCs initiated by widespread participants. Active Directory incorporates decades of communication technologies into the overarching Active Directory concept then makes improvements upon them.^{[citation needed]} For example, LDAP underpins Active Directory. Also X.500 directories and the Organizational Unit preceded the Active Directory concept that makes use of those methods. The LDAP concept began to emerge even before the founding of Microsoft in April 1975, with RFCs as early as 1971. RFCs contributing to LDAP include RFC 1823 (on the LDAP API, August 1995),^[6]RFC 2307, RFC 3062, and RFC 4533.^[7][8][9]

Microsoft previewed Active Directory in 1999, released it first with Windows 2000 Server edition, and revised it to extend functionality and improve administration in Windows Server 2003. Additional improvements came with subsequent versions of Windows Server. In Windows Server 2008, additional services were added to Active Directory, such as Active Directory Federation Services.^[10] The part of the directory in charge of management of domains, which was previously a core part of the operating system,^[10] was renamed Active Directory Domain Services (ADDS) and became a server role like others.^[3] 'Active Directory' became the umbrella title of a broader range of directory-based services.^[11] According to Bryon Hynes, everything related to identity was brought under Active Directory's banner.^[3]

Active Directory Services[edit]

Active Directory Services consist of multiple directory services. The best known is Active Directory Domain Services, commonly abbreviated as AD DS or simply AD.^[12]

Domain Services[edit]

Active Directory Domain Services (AD DS) is the cornerstone of every Windows domain network. It stores information about members of the domain, including devices and users, verifies their credentials and defines their access rights. The server running this service is called a domain controller. A domain controller is contacted when a user logs into a device, accesses another device across the network, or runs a line-of-business Metro-style appsideloaded into a device.

Other Active Directory services (excluding LDS, as described below) as well as most of Microsoft server technologies rely on or use Domain Services; examples include Group Policy, Encrypting File System, BitLocker, Domain Name Services, Remote Desktop Services, Exchange Server and SharePoint Server.

Lightweight Directory Services[edit]

Active Directory Lightweight Directory Services (AD LDS), formerly known as Active Directory Application Mode (ADAM),^[13] is a light-weight implementation of AD DS.^[14] AD LDS runs as a service on Windows Server. AD LDS shares the code base with AD DS and provides the same functionality, including an identical API, but does not require the creation of domains or domain controllers. It provides a Data Store for storage of directory data and a Directory Service with an LDAP Directory Service Interface. Unlike AD DS, however, multiple AD LDS instances can run on the same server.

Certificate Services[edit]

Active Directory Certificate Services (AD CS) establishes an on-premises public key infrastructure. It can create, validate and revoke public key certificates for internal uses of an organization. These certificates can be used to encrypt files (when used with Encrypting File System), emails (per S/MIME standard), and network traffic (when used by virtual private networks, Transport Layer Security protocol or IPSec protocol).

AD CS predates Windows Server 2008, but its name was simply Certificate Services.^[15]

AD CS requires an AD DS infrastructure.^[16]

Federation Services[edit]

Active Directory Federation Services (AD FS) is a single sign-on service. With an AD FS infrastructure in place, users may use several web-based services (e.g. internet forum, blog, online shopping, webmail) or network resources using only one set of credentials stored at a central location, as opposed to having to be granted a dedicated set of credentials for each service. AD FS's purpose is an extension of that of AD DS: The latter enables users to authenticate with and use the devices that are part of the same network, using one set of credentials. The former enables them to use the same set of credentials in a different network.

As the name suggests, AD FS works based on the concept of federated identity.

AD FS requires an AD DS infrastructure, although its federation partner may not.^[17]

Rights Management Services[edit]

Active Directory Rights Management Services (AD RMS, known as Rights Management Services or RMS before Windows Server 2008) is a server software for information rights management shipped with Windows Server. It uses encryption and a form of selective functionality denial for limiting access to documents such as corporate e-mails, Microsoft Word documents, and web pages, and the operations authorized users can perform on them.

Logical structure[edit]

As a directory service, an Active Directory instance consists of a database and corresponding executable code responsible for servicing requests and maintaining the database. The executable part, known as Directory System Agent, is a collection of Windows services and processes that run on Windows 2000 and later.^[1] Objects in Active Directory databases can be accessed via LDAP, ADSI (a component object model interface), messaging API and Security Accounts Manager services.^[2]

Objects[edit]

Active Directory structures are arrangements of information about objects. The objects fall into two broad categories: resources (e.g., printers) and security principals (user or computer accounts and groups). Security principals are assigned unique security identifiers (SIDs).

Each object represents a single entity—whether a user, a computer, a printer, or a group—and its attributes. Certain objects can contain other objects. An object is uniquely identified by its name and has a set of attributes—the characteristics and information that the object represents— defined by a schema, which also determines the kinds of objects that can be stored in Active Directory.

The schema object lets administrators extend or modify the schema when necessary. However, because each schema object is integral to the definition of Active Directory objects, deactivating or changing these objects can fundamentally change or disrupt a deployment. Schema changes automatically propagate throughout the system. Once created, an object can only be deactivated—not deleted. Changing the schema usually requires planning.^[18]

Forests, trees and domains[edit]

The Active Directory framework that holds the objects can be viewed at a number of levels. The forest, tree, and domain are the logical divisions in an Active Directory network.

Within a deployment, objects are grouped into domains. The objects for a single domain are stored in a single database (which can be replicated). Domains are identified by their DNS name structure, the namespace.

A domain is defined as a logical group of network objects (computers, users, devices) that share the same Active Directory database.

A tree is a collection of one or more domains and domain trees in a contiguous namespace, and is linked in a transitive trust hierarchy.

At the top of the structure is the forest. A forest is a collection of trees that share a common global catalog, directory schema, logical structure, and directory configuration. The forest represents the security boundary within which users, computers, groups, and other objects are accessible.

Organizational units[edit]

The objects held within a domain can be grouped into Organizational Units (OUs).^[19] OUs can provide hierarchy to a domain, ease its administration, and can resemble the organization's structure in managerial or geographical terms. OUs can contain other OUs—domains are containers in this sense. Microsoft recommends using OUs rather than domains for structure and to simplify the implementation of policies and administration. The OU is the recommended level at which to apply group policies, which are Active Directory objects formally named Group Policy Objects (GPOs), although policies can also be applied to domains or sites (see below). The OU is the level at which administrative powers are commonly delegated, but delegation can be performed on individual objects or attributes as well.

Organizational units do not each have a separate namespace. As a consequence, for compatibility with Legacy NetBios implementations, user accounts with an identical sAMAccountName are not allowed within the same domain even if the accounts objects are in separate OUs. This is because sAMAccountName, a user object attribute, must be unique within the domain.^[20]. However, two users in different OUs can have the same Common Name (CN), the name under which they are stored in the directory itself such as 'fred.staff-ou.domain' and 'fred.student-ou.domain', where 'staff-ou' and 'student-ou' are the OUs.

In general the reason for this lack of allowance for duplicate names through hierarchical directory placement, is that Microsoft primarily relies on the principles of NetBIOS, which is a flat-file method of network object management that for Microsoft software, goes all the way back to Windows NT 3.1 and MS-DOSLAN Manager. Allowing for duplication of object names in the directory, or completely removing the use of NetBIOS names, would prevent backward compatibility with legacy software and equipment. However, disallowing duplicate object names in this way is a violation of the LDAP RFCs on which Active Directory is supposedly based.

As the number of users in a domain increases, conventions such as 'first initial, middle initial, last name' (Western order) or the reverse (Eastern order) fail for common family names like Li (李), Smith or Garcia. Workarounds include adding a digit to the end of the username. Alternatives include creating a separate ID system of unique employee/student id numbers to use as account names in place of actual user's names, and allowing users to nominate their preferred word sequence within an acceptable use policy.

Because duplicate usernames cannot exist within a domain, account name generation poses a significant challenge for large organizations that cannot be easily subdivided into separate domains, such as students in a public school system or university who must be able to use any computer across the network.

Shadow groups[edit]

In Microsoft's Active Directory, OUs do not confer access permissions, and objects placed within OUs are not automatically assigned access privileges based on their containing OU. This is a design limitation specific to Active Directory. Other competing directories such as Novell NDS are able to assign access privileges through object placement within an OU.

Active Directory requires a separate step for an administrator to assign an object in an OU as a member of a group also within that OU. Relying on OU location alone to determine access permissions is unreliable, because the object may not have been assigned to the group object for that OU.

A common workaround for an Active Directory administrator is to write a custom PowerShell or Visual Basic script to automatically create and maintain a user group for each OU in their directory. The scripts are run periodically to update the group to match the OU's account membership, but are unable to instantly update the security groups anytime the directory changes, as occurs in competing directories where security is directly implemented into the directory itself. Such groups are known as Shadow Groups. Once created, these shadow groups are selectable in place of the OU in the administrative tools.

Microsoft refers to shadow groups in the Server 2008 Reference documentation, but does not explain how to create them. There are no built-in server methods or console snap-ins for managing shadow groups.^[21]

The division of an organization's information infrastructure into a hierarchy of one or more domains and top-level OUs is a key decision. Common models are by business unit, by geographical location, by IT Service, or by object type and hybrids of these. OUs should be structured primarily to facilitate administrative delegation, and secondarily, to facilitate group policy application. Although OUs form an administrative boundary, the only true security boundary is the forest itself and an administrator of any domain in the forest must be trusted across all domains in the forest.^[22]

Partitions[edit]

The Active Directory database is organized in partitions, each holding specific object types and following a specific replication pattern. Microsoft often refers to these partitions as 'naming contexts'.^[23] The 'Schema' partition contains the definition of object classes and attributes within the Forest. The 'Configuration' partition contains information on the physical structure and configuration of the forest (such as the site topology). Both replicate to all domains in the Forest. The 'Domain' partition holds all objects created in that domain and replicates only within its domain.

Physical structure[edit]

Sites are physical (rather than logical) groupings defined by one or more IP subnets.^[24] AD also holds the definitions of connections, distinguishing low-speed (e.g., WAN, VPN) from high-speed (e.g., LAN) links. Site definitions are independent of the domain and OU structure and are common across the forest. Sites are used to control network traffic generated by replication and also to refer clients to the nearest domain controllers (DCs). Microsoft Exchange Server 2007 uses the site topology for mail routing. Policies can also be defined at the site level.

Physically, the Active Directory information is held on one or more peer domain controllers, replacing the NTPDC/BDC model. Each DC has a copy of the Active Directory. Servers joined to Active Directory that are not domain controllers are called Member Servers.^[25] A subset of objects in the domain partition replicate to domain controllers that are configured as global catalogs. Global catalog (GC) servers provide a global listing of all objects in the Forest.^[26][27]Global Catalog servers replicate to themselves all objects from all domains and hence, provide a global listing of objects in the forest. However, to minimize replication traffic and keep the GC's database small, only selected attributes of each object are replicated. This is called the partial attribute set (PAS). The PAS can be modified by modifying the schema and marking attributes for replication to the GC.^[28] Earlier versions of Windows used NetBIOS to communicate. Active Directory is fully integrated with DNS and requires TCP/IP—DNS. To be fully functional, the DNS server must support SRV resource records, also known as service records.

Replication[edit]

Active Directory synchronizes changes using multi-master replication.^[29] Replication by default is 'pull' rather than 'push', meaning that replicas pull changes from the server where the change was effected.^[30] The Knowledge Consistency Checker (KCC) creates a replication topology of site links using the defined sites to manage traffic. Intrasite replication is frequent and automatic as a result of change notification, which triggers peers to begin a pull replication cycle. Intersite replication intervals are typically less frequent and do not use change notification by default, although this is configurable and can be made identical to intrasite replication.

Each link can have a 'cost' (e.g., DS3, T1, ISDN etc.) and the KCC alters the site link topology accordingly. Replication may occur transitively through several site links on same-protocol site link bridges, if the cost is low, although KCC automatically costs a direct site-to-site link lower than transitive connections. Site-to-site replication can be configured to occur between a bridgehead server in each site, which then replicates the changes to other DCs within the site. Replication for Active Directory zones is automatically configured when DNS is activated in the domain based by site.

Replication of Active Directory uses Remote Procedure Calls (RPC) over IP (RPC/IP). Between Sites SMTP can be used for replication, but only for changes in the Schema, Configuration, or Partial Attribute Set (Global Catalog) GCs. SMTP cannot be used for replicating the default Domain partition.^[31]

Implementation[edit]

In general, a network utilizing Active Directory has more than one licensed Windows server computer. Backup and restore of Active Directory is possible for a network with a single domain controller,^[32] but Microsoft recommends more than one domain controller to provide automatic failover protection of the directory.^[33] Domain controllers are also ideally single-purpose for directory operations only, and should not run any other software or role.^[34]

Certain Microsoft products such as SQL Server^[35][36] and Exchange^[37] can interfere with the operation of a domain controller, necessitating isolation of these products on additional Windows servers. Combining them can make configuration or troubleshooting of either the domain controller or the other installed software more difficult.^[38] A business intending to implement Active Directory is therefore recommended to purchase a number of Windows server licenses, to provide for at least two separate domain controllers, and optionally, additional domain controllers for performance or redundancy, a separate file server, a separate Exchange server, a separate SQL Server,^[39] and so forth to support the various server roles.

Physical hardware costs for the many separate servers can be reduced through the use of virtualization, although for proper failover protection, Microsoft recommends not running multiple virtualized domain controllers on the same physical hardware.^[40]

Database[edit]

The Active-Directory database, the directory store, in Windows 2000 Server uses the JET Blue-based Extensible Storage Engine (ESE98) and is limited to 16 terabytes and 2 billion objects (but only 1 billion security principals) in each domain controller's database. Microsoft has created NTDS databases with more than 2 billion objects.^[41] (NT4's Security Account Manager could support no more than 40,000 objects). Called NTDS.DIT, it has two main tables: the data table and the link table. Windows Server 2003 added a third main table for security descriptor single instancing.^[41]

Programs may access the features of Active Directory^[42] via the COM interfaces provided by Active Directory Service Interfaces.^[43]

Trusting[edit]

To allow users in one domain to access resources in another, Active Directory uses trusts.^[44]

Trusts inside a forest are automatically created when domains are created. The forest sets the default boundaries of trust, and implicit, transitive trust is automatic for all domains within a forest.

Terminology[edit]

One-way trust

One domain allows access to users on another domain, but the other domain does not allow access to users on the first domain.

Two-way trust

Two domains allow access to users on both domains.

Trusted domain

The domain that is trusted; whose users have access to the trusting domain.

Transitive trust

A trust that can extend beyond two domains to other trusted domains in the forest.

Intransitive trust

A one way trust that does not extend beyond two domains.

Explicit trust

A trust that an admin creates. It is not transitive and is one way only.

Cross-link trust

An explicit trust between domains in different trees or in the same tree when a descendant/ancestor (child/parent) relationship does not exist between the two domains.

Shortcut

Joins two domains in different trees, transitive, one- or two-way.

Forest trust

Applies to the entire forest. Transitive, one- or two-way.

Realm

Can be transitive or nontransitive (intransitive), one- or two-way.

External

Connect to other forests or non-AD domains. Nontransitive, one- or two-way.^[45]

PAM trust

A one-way trust used by Microsoft Identity Manager from a (possibly low-level) production forest to a (Windows Server 2016 functionality level) 'bastion' forest, which issues time-limited group memberships.^[46][47]

Management solutions[edit]

Microsoft Active Directory management tools include:

• Active Directory Administrative Center (Introduced with Windows Server 2012 and above),
• Active Directory Users and Computers,
• Active Directory Domains and Trusts,
• Active Directory Sites and Services,
• ADSI Edit,
• Local Users and Groups,
• Active Directory Schema snap-ins for Microsoft Management Console (MMC),

These management tools may not provide enough functionality for efficient workflow in large environments. Some third-party solutions extend the administration and management capabilities. They provide essential features for a more convenient administration processes, such as automation, reports, integration with other services, etc.

Unix integration[edit]

Active Directory Schema Versions

Varying levels of interoperability with Active Directory can be achieved on most Unix-like operating systems (including Unix, Linux, Mac OS X or Java and Unix-based programs) through standards-compliant LDAP clients, but these systems usually do not interpret many attributes associated with Windows components, such as Group Policy and support for one-way trusts.

Third parties offer Active Directory integration for Unix-like platforms, including:

• PowerBroker Identity Services, formerly Likewise (BeyondTrust, formerly Likewise Software) – Allows a non-Windows client to join Active Directory^[48]
• ADmitMac (Thursby Software Systems)^[48]
• Samba – Can act as a domain controller^[49][50]

The schema additions shipped with Windows Server 2003 R2 include attributes that map closely enough to RFC 2307 to be generally usable. The reference implementation of RFC 2307, nss_ldap and pam_ldap provided by PADL.com, support these attributes directly. The default schema for group membership complies with RFC 2307bis (proposed).^[51] Windows Server 2003 R2 includes a Microsoft Management Console snap-in that creates and edits the attributes.

An alternative option is to use another directory service as non-Windows clients authenticate to this while Windows Clients authenticate to AD. Non-Windows clients include 389 Directory Server (formerly Fedora Directory Server, FDS), ViewDS Identity Solutions - ViewDS v7.2 XML Enabled Directory and Sun Microsystems Sun Java System Directory Server. The latter two both being able to perform two-way synchronization with AD and thus provide a 'deflected' integration.

Another option is to use OpenLDAP with its translucent overlay, which can extend entries in any remote LDAP server with additional attributes stored in a local database. Clients pointed at the local database see entries containing both the remote and local attributes, while the remote database remains completely untouched.^{[citation needed]}

Administration (querying, modifying, and monitoring) of Active Directory can be achieved via many scripting languages, including PowerShell, VBScript, JScript/JavaScript, Perl, Python, and Ruby.^{[52][53][54][55]} Free and non-free AD administration tools can help to simplify and possibly automate AD management tasks.

Since October 2017 Amazon AWS offers integration with Microsoft Active Directory.^[56]

See also[edit]

• AGDLP (implementing role based access controls using nested groups)

References[edit]

1. ^ ^ab'Directory System Agent'. MSDN Library. Microsoft. Retrieved 23 April 2014.
2. ^ ^abSolomon, David A.; Russinovich, Mark (2005). 'Chapter 13'. Microsoft Windows Internals: Microsoft Windows Server 2003, Windows XP, and Windows 2000 (4th ed.). Redmond, Washington: Microsoft Press. p. 840. ISBN0-7356-1917-4.
3. ^ ^abcHynes, Byron (November 2006). 'The Future Of Windows: Directory Services in Windows Server 'Longhorn''. TechNet Magazine. Microsoft.
4. ^'Active Directory on a Windows Server 2003 Network'. Active Directory Collection. Microsoft. 13 March 2003. Retrieved 25 December 2010.
5. ^'Install Active Directory Domain Services on Windows Server 2008 R2 Enterprise 64-bit'. 27 April 2016. Retrieved 22 September 2016.
6. ^'The LDAP Application Program Interface'. Retrieved 26 November 2013.
7. ^'An Approach for Using LDAP as a Network Information Service'. Retrieved 26 November 2013.
8. ^'LDAP Password Modify Extended Operation'. Retrieved 26 November 2013.
9. ^'The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation'. Retrieved 26 November 2013.
10. ^ ^abThomas, Guy. 'Windows Server 2008 - New Features'. ComputerPerformance.co.uk. Computer Performance Ltd.
11. ^'What's New in Active Directory in Windows Server'. Windows Server 2012 R2 and Windows Server 2012 Tech Center. Microsoft.
12. ^Active Directory Services technet.microsoft.com
13. ^'AD LDS'. Microsoft. Retrieved 28 April 2009.
14. ^'AD LDS versus AD DS'. Microsoft. Retrieved 25 February 2013.
15. ^Zacker, Craig (2003). '11: Creating and Managing Digital Certificates'. In Harding, Kathy; Jean, Trenary; Linda, Zacker (eds.). Planning and Maintaining a Microsoft Windows server 2003 Network Infrastructure. Redmond, WA: Microsoft Press. pp. 11–16. ISBN0-7356-1893-3.
16. ^'Active Directory Certificate Services Overview'. Microsoft TechNet. Microsoft. Retrieved 24 November 2015.
17. ^'Step 1: Preinstallation Tasks'. TechNet. Microsoft. Retrieved 24 November 2015.
18. ^Windows Server 2003: Active Directory Infrastructure. Microsoft Press. 2003. pp. 1–8–1–9.
19. ^'Organizational Units'. Distributed Systems Resource Kit (TechNet). Microsoft. 2011. An organizational unit in Active Directory is analogous to a directory in the file system
20. ^'sAMAccountName is always unique in a Windows domain… or is it?'. Joeware. 4 January 2012. Retrieved 18 September 2013. examples of how multiple AD objects can be created with the same sAMAccountName
21. ^Microsoft Server 2008 Reference, discussing shadow groups used for fine-grained password policies: https://technet.microsoft.com/en-us/library/cc770394%28WS.10%29.aspx
22. ^'Specifying Security and Administrative Boundaries'. Microsoft Corporation. 23 January 2005. However, service administrators have abilities that cross domain boundaries. For this reason, the forest is the ultimate security boundary, not the domain.
23. ^Andreas Luther. 'Active Directory Replication Traffic'. Microsoft Corporation. Retrieved 26 May 2010. The Active Directory is made up of one or more naming contexts or partitions.
24. ^'Sites overview'. Microsoft Corporation. 21 January 2005. A site is a set of well-connected subnets.
25. ^'Planning for domain controllers and member servers'. Microsoft Corporation. 21 January 2005. [..] member servers, [..] belong to a domain but do not contain a copy of the Active Directory data.
26. ^'What Is the Global Catalog?'. Microsoft Corporation. 10 December 2009. [..] a domain controller can locate only the objects in its domain. [..] The global catalog provides the ability to locate objects from any domain [..]
27. ^'Global Catalog'. Microsoft Corporation.
28. ^'Attributes Included in the Global Catalog'. Microsoft Corporation. 26 August 2010. The isMemberOfPartialAttributeSet attribute of an attributeSchema object is set to TRUE if the attribute is replicated to the global catalog. [..] When deciding whether or not to place an attribute in the global catalog remember that you are trading increased replication and increased disk storage on global catalog servers for, potentially, faster query performance.
29. ^'Directory data store'. Microsoft Corporation. 21 January 2005. Active Directory uses four distinct directory partition types to store [..] data. Directory partitions contain domain, configuration, schema, and application data.
30. ^'What Is the Active Directory Replication Model?'. Microsoft Corporation. 28 March 2003. Domain controllers request (pull) changes rather than send (push) changes that might not be needed.
31. ^'What Is Active Directory Replication Topology?'. Microsoft Corporation. 28 March 2003. SMTP can be used to transport nondomain replication [..]
32. ^'Active Directory Backup and Restore'. TechNet. Microsoft. Retrieved 5 February 2014.
33. ^'AD DS: All domains should have at least two functioning domain controllers for redundancy'. TechNet. Microsoft. Retrieved 5 February 2014.
34. ^Posey, Brien (23 August 2010). '10 tips for effective Active Directory design'. TechRepublic. CBS Interactive. Retrieved 5 February 2014. Whenever possible, your domain controllers should run on dedicated servers (physical or virtual).
35. ^'You may encounter problems when installing SQL Server on a domain controller (Revision 3.0)'. Support. Microsoft. 7 January 2013. Retrieved 5 February 2014.
36. ^Degremont, Michel (30 June 2011). 'Can I install SQL Server on a domain controller?'. Microsoft SQL Server blog. Retrieved 5 February 2014. For security and performance reasons, we recommend that you do not install a standalone SQL Server on a domain controller.
37. ^'Installing Exchange on a domain controller is not recommended'. TechNet. Microsoft. 22 March 2013. Retrieved 5 February 2014.
38. ^'Security Considerations for a SQL Server Installation'. TechNet. Microsoft. Retrieved 5 February 2014. After SQL Server is installed on a computer, you cannot change the computer from a domain controller to a domain member. You must uninstall SQL Server before you change the host computer to a domain member.
39. ^'Exchange Server Analyzer'. TechNet. Microsoft. Retrieved 5 February 2014. Running SQL Server on the same computer as a production Exchange mailbox server is not recommended.
40. ^'Running Domain Controllers in Hyper-V'. TechNet. Microsoft. Planning to Virtualize Domain Controllers. Retrieved 5 February 2014. You should attempt to avoid creating potential single points of failure when you plan your virtual domain controller deployment.frank
41. ^ ^abefleis (8 June 2006). 'Large AD database? Probably not this large'. Blogs.technet.com. Retrieved 20 November 2011.
42. ^Berkouwer, Sander. 'Active Directory basics'. Veeam Software.
43. ^Active Directory Service Interfaces, Microsoft
44. ^'Domain and Forest Trusts Technical Reference'. Microsoft Corporation. 28 March 2003. Trusts enable [..] authentication and [..] sharing resources across domains or forests
45. ^'Domain and Forest Trusts Work'. Microsoft Corporation. 11 December 2012. Retrieved 29 January 2013. Defines several kinds of trusts. (automatic, shortcut, forest, realm, external)
46. ^Microsoft Identity Manager: Privileged Access Management for Active Directory Domain Services
47. ^TechNet: MIM 2016: Privileged Access Management (PAM) - FAQ
48. ^ ^abEdge, Charles S., Jr; Smith, Zack; Hunter, Beau (2009). 'Chapter 3: Active Directory'. Enterprise Mac Administrator's Guide. New York City: Apress. ISBN978-1-4302-2443-3.
49. ^'Samba 4.0.0 Available for Download'. SambaPeople. SAMBA Project. Archived from the original on 15 November 2010. Retrieved 9 August 2016.
50. ^'The great DRS success!'. SambaPeople. SAMBA Project. 5 October 2009. Archived from the original on 13 October 2009. Retrieved 2 November 2009.
51. ^'RFC 2307bis'. Archived from the original on 27 September 2011. Retrieved 20 November 2011.
52. ^'Active Directory Administration with Windows PowerShell'. Microsoft. Retrieved 7 June 2011.
53. ^'Using Scripts to Search Active Directory'. Microsoft. Retrieved 22 May 2012.
54. ^'ITAdminTools Perl Scripts Repository'. ITAdminTools.com. Retrieved 22 May 2012.
55. ^'Win32::OLE'. Perl Open-Source Community. Retrieved 22 May 2012.
56. ^https://aws.amazon.com/blogs/security/introducing-aws-directory-service-for-microsoft-active-directory-standard-edition/

External links[edit]

Active Directory Schema Version Table Of Word

Check Schema Version Active Directory

• Microsoft Technet: White paper: Active Directory Architecture (Single technical document that gives an overview about Active Directory.)
• Microsoft Technet: Detailed description of Active Directory on Windows Server 2003
• Microsoft MSDN Library: [MS-ADTS]: Active Directory Technical Specification (part of the Microsoft Open Specification Promise)
• Microsoft MSDN: [AD-LDS]: Active Directory Lightweight Directory Services
• Microsoft TechNet: [AD-LDS]: Active Directory Lightweight Directory Services
• Microsoft MSDN: Active Directory Schema
• Microsoft TechNet: Understanding Schema
• Microsoft TechNet Magazine: Extending the Active Directory Schema
• Microsoft MSDN: Active Directory Certificate Services
• Microsoft TechNet: Active Directory Certificate Services