An interesting feature of Active Directory not common among other LDAP implementations is that the schema is stored within Active Directory itself as a set of objects. This means that you can use similar interfaces and programs to manage the schema as you would any other type of object without any need to shut down or restart Active Directory.

All schema objects are stored in the Schema container (cn=schema,cn=configuration,<ForestRootDN>). The schema consists of two classes of objects, classSchema and attributeSchema. Not surprisingly, the classSchema objects define classes and attributeSchema objects define attributes. The Schema container contains a third type of object called subSchema, also known as the abstract schema, which is defined in the LDAP version 3 specification (RFC 2251). There is only a single subSchema object in the Schema container, named cn=Aggregate, and it contains a summary of the entire schema.

Table 10-1 and Table 10-2 contain useful attributes of classSchema objects and attributeSchema objects, respectively.

You want to use the Active Directory Schema MMC snap-in for the first time on an administrative computer.

Before you can use the Active Directory Schema MMC snap-in, you have to register the .dll associated with it. This can be done with the regsvr32 utility using the following command:

> regsvr32 schmmgmt.dll

If the command is successful, you’ll see the following message:

DllRegisterServer in schmmgmt.dll succeeded.

Most of the Active Directory MMC snap-ins do not require that you manually register the associated .dll. Microsoft requires this with the Active Directory Schema snap-in, however, due to the sensitive nature of modifying the schema. This doesn’t actually do much to prevent users from using it, but at least it isn’t available by default. And regardless, only members of the Schema Admins group have permission to modify the schema anyway, so making this snap-in available should not pose any risk.

The schmmgmt.dll file is installed as part of the AD DS Tools feature (specifically, the AD DS Snap-Ins and Command-Line Tools subfeature), or else it is installed by default on domain controllers when they are first promoted. If you want to use the Schema snap-in on a domain member server or workstation machine and you have not installed the feature, you’ll need to specify the full path to schmmgmt.dll when using regsvr32.

You want to generate an OID to use with a new class or attribute that you intend to add to the schema.

To implement schema extensions for production use, you should use an OID from your company or organization’s OID branch. To determine whether your company already has an assigned OID, see these sites:

If your organization does not have an assigned OID, go to your country’s national registry to request one.

Once you have a base OID, you can create branches from that OID however you want. For example, if you had a base OID of 1.2.3.4, you could start new class OIDs under 1.2.3.4.1 and new attributes under 1.2.3.4.2. In that case, the first class OID you would create would be 1.2.3.4.1.1, and the first attribute OID would be 1.2.3.4.2.1.

An OID is nothing more than a string of numbers separated by periods (.). OIDs were initially defined by the ITU-T in X.208 and have been used to uniquely identify a variety of things, including SNMP MIB objects and LDAP schema classes and attributes. OIDs are hierarchical, and the national registries are responsible for managing and assigning OID branches.

You want to extend the schema to support new classes and attributes in Active Directory.

Extending the schema is a straightforward process that consists of adding new classes or attributes, or modifying existing ones in the schema. While extending the schema is not hard, due to the sensitive nature of the schema you should implement a schema extension process that thoroughly tests any extensions before you put them in your production forest. Here is a suggested summary of what your schema extension process should entail:

For more information on defining a schema extension process, see Active Directory, Fifth Edition, by Brian Desmond et al. (O’Reilly).

One thing to be cautious of when developing a schema extension process is not to make it an overly bureaucratic process that can require months to complete. At the same time, you want to ensure that any schema changes that you make are well thought out, tested, and documented thoroughly to avoid encountering issues later. While some organizations may want to strictly limit schema extensions, there is nothing inherently bad about properly extending the schema.

Adding a New Attribute for adding a new attribute; Adding a New Class for adding a new class; “Extending the schema”

You want to prepare the Active Directory schema for an Active Directory upgrade.

Major upgrades to the Windows operating system on domain controllers will usually require that the Active Directory schema be extended with new classes and attributes. To automate this process, Active Directory includes the adprep utility to perform these modifications. adprep needs to be run once for the entire forest using the /forestprep switch and once for each domain that will be upgraded using the /domainprep switch. In the case of a Windows Server 2012 upgrade, you can view the schema extensions that will be performed by this utility by looking at the .ldf files in the supportadprep directory in the installation media. These files contain LDIF entries for adding and modifying new and existing classes and attributes. Since the /forestprep process extends and modifies the schema, you must perform this task using credentials that belong to both the Schema Admins and Enterprise Admins groups.

After /forestprep has completed, /domainprep will create new containers and objects within each Domain NC, as well as modify ACLs on some objects and the behavior of the Everyone security principal. Before you can run /domainprep, you need to ensure that the updates from /forestprep have replicated to all domain controllers in the forest using the method described in this recipe. /domainprep needs to have connectivity to the Infrastructure Master of the domain, using Domain Admin credentials.

One major change that Windows Server 2012 introduced is the integration of adprep into the domain controller promotion process. For some environments, this is seen as a nifty new feature that saves time and hassle. For large enterprise environments, this is sometimes seen as a dangerous thing and a potential violation of change control. Some enterprise environments are opting to prepare the forest and domain ahead of time, prior to the promotion of the first Windows Server 2012 server.

Verifying the Promotion of a Domain Controller for more on verifying the promotion of a domain controller

You want to document your schema extensions.

There are several different ways you can document schema extensions. If you require LDIF files of the schema extensions before you extend the schema, you can use the files themselves as a simple self-documenting system. You can put comments in LDIF files by putting # at the beginning of a line, or else use the AD Schema Analyzer available with Active Directory Lightweight Directory Service (AD LDS). We recommend a combination of these options, and recommend that any company that needs to extend its schema include LDIF files, regardless of whether you use that method to actually extend the schema.

The AD Schema Analyzer is a useful tool that can document your existing schema, as well as create a file to help you modify the schema. To use the Schema Analyzer to create an LDIF file, do the following:

There are no hard-and-fast rules for documenting schema extensions. Documenting schema extensions in some fashion, even a rudimentary one, should be a requirement of any schema extension process you adopt. If you have the resources and time, you can even develop a much more elaborate documentation system.

RFC 2849 (The LDAP Data Interchange Format (LDIF)—Technical Specification); “Windows Server 2012: Changes to Adprep.exe”

You want to add a new attribute to the schema.

The GUI solution requires that the .dll file for the Active Directory Schema snap-in has been registered. See Registering the Active Directory Schema MMC Snap-in for more information.

To create an attribute, you need to add an attributeSchema object to the Schema container. Typically, when you extend the schema you perform several additions or modifications at once. The order of your extensions is very important. You can’t create a class, assign an attribute, and then create the attribute; you obviously need to create the attribute before it can be assigned to the class. Even if you create the attribute before you assign it to a class, you must reload the schema before doing the class assignment. Reloading the schema is described in more detail in Reloading the Schema Cache.

Most of the attributes that can be set on attributeSchema objects are pretty straightforward, but a couple of them require a little explanation. The attributeSyntax and oMSyntax attributes together define the syntax, or the type of data that can be contained in the attribute. Table 10-3 shows the possible combinations of these two attributes and the resultant syntax.

The searchFlags attribute is a bit flag that defines special properties related to searching with the attribute. Table 10-4 contains the values that can be set for this attribute. The values are cumulative, so to index an attribute and include it in ANR searches, you would set a value of 5 (1 + 4).

Modifying a Bit-Flag Attribute for setting a bit flag; Adding a New Class for adding a new class; Reloading the Schema Cache for reloading the schema

You want to view the properties of an attribute.

The GUI solution requires that the .dll file for the Active Directory Schema snap-in has been registered. See Registering the Active Directory Schema MMC Snap-in for more information.

In the CLI solutions, we mention that you need to specify the common name (or cn) of the attribute you want to view. The common name is a source of confusion for many people. For example, the surname attribute has the following distinguished name in the adatum.com forest:

cn=surname,cn=schema,cn=configuration,dc=adatum,dc=com

The problem is that most applications refer to attributes by their LDAP display name as defined in the lDAPDisplayName attribute for the attributeSchema object, which is typically different from the cn attribute. As an example, the surname attribute uses surname for its common name (cn), but sn for its LDAP display name (lDAPDisplayName).

In the CLI solution, to use the LDAP display name instead of cn when using DSQuery, simply change (cn=<AttrCommonName>) to (lDAPDisplayName= <AttrLDAPName>).

AdFind includes the shortcut adfind -sc s:<name>, which will check both the LDAP Display Name and the cn automatically. Additionally, this shortcut will decode various properties when it produces its output.

One attribute of note that is defined on attributeSchema objects is the systemFlags bit flag, which is used to define a few miscellaneous properties about an attribute. Table 10-5 contains the bits associated with systemFlags. The values are cumulative, so a value of 17 (1 + 16) would indicate that the attribute is part of the base Active Directory installation and is not replicated.

Viewing the Attributes of an Object for viewing the attributes of an object; Searching with a Bitwise Filter for searching with a bitwise filter

You want to add a new class to the schema.

To create a new class, you need to create a classSchema object in the Schema container. The important attributes to set include:

The lDAPDisplayName also needs to be set and should be equal to the common name (cn) as a general rule. Even though many of the default classes do not use the same name for the common name and LDAP display name, using the same name is highly recommended to avoid confusion when referencing the class. Another good practice is to set the schemaIDGUID of the class.

See Introduction for attributes of classSchema objects; Generating an OID to Use for a New Class or Attribute for generating an OID; Finding the Structural, Auxiliary, Abstract, and 88 Classes for more on object class type; Modifying the Default Security of a Class for setting the default security for a class; Reloading the Schema Cache for reloading the schema cache

You want to view the attributes of a class.

The GUI solution requires that the .dll file for the Active Directory Schema snap-in has been registered. See Registering the Active Directory Schema MMC Snap-in for more information.

See Table 10-1, at the beginning of this chapter, for a list of the important classSchema attributes and their descriptions.

Viewing the Attributes of an Object for viewing the attributes of an object

You want to index an attribute so that searches using that attribute are faster.

To index an attribute, you need to set bit 0 (0001) in the searchFlags attribute for the attributeSchema object.

searchFlags is a bit-flag attribute that is used to set various properties related to searching with the attribute. Table 10-5, earlier in this chapter, contains the various bit flags that can be set with searchFlags. When setting searchFlags, you may often need to set a couple of bits together. For example, all Ambiguous Name Resolution (ANR) attributes must also be indexed, which means searchFlags should be set to 5 (1 + 4).

You can find the attributes that are indexed in the schema by using the following search criteria:

Alternatively, to find attributes that aren’t indexed, change the previous search filter to the following:

(&(objectcategory=attributeSchema)(!(searchFlags:1.2.840.113556.1.4.803:=1)))

You can also find indexed attributes using AdFind, as follows:

adfind -sc indexed

Modifying a Bit-Flag Attribute for modifying a bit-flag attribute; Adding a New Attribute for adding a new attribute

You want to add an attribute to the list of attributes that are copied when duplicating a user with the ADUC snap-in.

The GUI solution requires that the .dll file for the Active Directory Schema snap-in has been registered. See Registering the Active Directory Schema MMC Snap-in for more information.

The Active Directory Users and Computers snap-in queries the schema for the list of attributes that should be copied whenever you right-click on a user and select Copy. This flag is purely informational and does not impose any restrictions.

To find out which attributes are copied when duplicating a user, use the following search criteria:

Alternatively, to find attributes that aren’t copied, change the previous search filter to the following:

(&(objectcategory=attributeSchema)(!(searchFlags:1.2.840.113556.1.4.803:=16)))

You can also find a list of these attributes using AdFind, as follows:

adfind -sc copy

Modifying a Bit-Flag Attribute for modifying a bit-flag attribute; Adding a New Attribute for adding a new attribute

You want to modify the attributes that are included as part of ANR.

ANR is an efficient search algorithm that allows for a complex search filter to be written using a single comparison. For example, a search for (anr=Jim Smith) would translate into the following query:

These filters are ORed together and then processed by Active Directory. Since all ANR attributes are also indexed, the query return should come back quickly.

Here is a list of the default attributes that are included as part of ANR searches. The LDAP display name of the attribute is shown first, with the common name in parentheses:

One requirement of any new ANR attribute is that the attribute must also be indexed. ANR searches are intended to be very fast, so if a nonindexed attribute were added to the set, it could dramatically impact the performance of the searches. Therefore, Active Directory requires that each added attribute be indexed. The PowerShell solution can be run for a nonindexed attribute, but the result will be that the attribute will be set to index and will be set for ANR. The Active Directory Schema snap-in will show the ANR option as grayed out unless an attribute is already set to be indexed. Once an attribute is set to be indexed, the Active Directory Schema snap-in will allow the ANR option to be enabled.

You can use adfind with the -stats+only switch to verify what the ANR expansion actually looks like. You can find out which attributes are included in the ANR set by using the following search criteria:

You can also find attributes that are included in ANR using AdFind, as follows:

adfind -sc anr

Alternatively, to find attributes that aren’t included in ANR, change the previous search filter to the following:

(&(objectcategory=attributeSchema)(!(searchFlags:1.2.840.113556.1.4.803:=4)))

Modifying a Bit-Flag Attribute for modifying a bit-flag attribute; Adding a New Attribute for adding a new attribute; “Ambiguous Name Resolution for LDAP in Windows 2000”

You want to add or remove an attribute in the global catalog.

The GUI solution requires that the .dll file for the Active Directory Schema snap-in has been registered. See Registering the Active Directory Schema MMC Snap-in for more information.

Each domain controller in a forest replicates a copy of the Domain naming context for its own domain, as well as copies of the forest-wide Configuration and Schema partitions. However, domain controllers do not replicate Domain naming contexts for other domains in the forest. When enabled as a global catalog server, a domain controller will make partial, read-only replicas of all the objects in other domains in the forest.

Searching against the global catalog is useful when you need to perform a single search across several naming contexts at once. The global catalog stores only a subset of each object’s attributes, which is why it is considered a partial replica. Attributes stored in the global catalog are considered part of the PAS. Any attributes that you add to the PAS should be ones you’d want to use as part of global catalog searches that are not present already.

You can add to the attributes that are stored in the global catalog by setting the isMemberOfPartialAttributeSet attribute of an attributeSchema object to TRUE. Likewise, to remove an attribute from the PAS, set isMemberOfPartialAttributeSet to FALSE for the target attribute.

You can find which attributes are included in the global catalog by using a query with the following criteria:

You can also find attributes that are included in the PAS using AdFind, as follows:

adfind -sc pas

Alternatively, to find attributes that aren’t in the global catalog, you only need to change part of the previous filter to the following:

(isMemberOfPartialAttributeSet=FALSE)

“How to Modify Attributes That Replicate to the Global Catalog”

You want to find the attributes that are not replicated or that are constructed by Active Directory.

The systemFlags attribute of attributeSchema objects defines a few special attribute properties, including whether an attribute is not replicated between domain controllers and whether Active Directory constructs it dynamically.

Most attributes are replicated after they are updated on an object, but some never replicate between domain controllers. These attributes are considered nonreplicated. An example of a nonreplicated attribute you may be familiar with is the lastLogon attribute, which stores the last logon time for user and computer objects. Whenever a user or computer logs in to Active Directory, the authenticating domain controller updates the user or computer’s lastLogon attribute, but the update does not get replicated out to other domain controllers.

Constructed attributes are automatically maintained by Active Directory and cannot be set manually. A good example of a constructed attribute is the msDS-Approx-Immed-Subordinates attribute. The attribute contains the approximate number of child objects within a container. Obviously this attribute wouldn’t be of much value if you had to maintain it, so Active Directory does it automatically.

One of the downsides to constructed attributes is that you cannot search against them. For example, we cannot perform a search to find all containers that have more than 10 objects in them (i.e., msDS-Approx-Immed-Subordinates>10). This would return an operations error. Constructed attributes can be returned only as part of the attribute set for a query and cannot be used as part of the query itself.

To find the nonreplicated or constructed attributes, you have to use a bitwise LDAP filter against attributeSchema objects. A bit value of 1 indicates the attribute is nonreplicated, and a value of 4 indicates the attribute is constructed.

Searching with a Bitwise Filter for searching with a bitwise filter

You want to find attributes that are linked.

The values of some attributes in Active Directory are linked. For example, if you set the manager attribute on one user object to be the DN of a second user object, the reports attribute on the second user object will automatically contain the first user object’s DN. In this example, the manager attribute, or the attribute that gets set, is considered the forward link, and the reports attribute, or the attribute that automatically gets calculated, is called the backlink. Another common example is group membership. The member attribute of the group object represents the forward link, while the memberOf attribute of the corresponding object (e.g., user) represents the backlink.

You can identify which attributes are linked in the schema by searching for attributeSchema objects that have a linkID attribute that contains some value. The linkID value for a forward-link attribute will be an even, positive number. The corresponding backlink attribute will be the forward linkID plus 1. For example, the manager attribute linkID is 42, and the backlink reports attribute has a linkID of 43.

LDP, by default, only returns 100 entries in a search. To display more results, modify the page size in the LDP search options (click the Options menu and then click Search to modify the search options).

You want to list the structural, auxiliary, abstract, and 88 classes.

The GUI solution requires that the .dll file for the Active Directory Schema snap-in has been registered. See Registering the Active Directory Schema MMC Snap-in for more information.

There are four supported class types in the Active Directory schema. The class type is defined by the objectClassCategory attribute on classSchema objects. Each class type is used for a different purpose relating to organizing and inheriting classes. Table 10-6 describes each type.

You want to view the mandatory and optional attributes of a class.

The GUI solution requires that the .dll file for the Active Directory Schema snap-in has been registered. See Registering the Active Directory Schema MMC Snap-in for more information.

The mayContain and systemMayContain attributes define the optional attributes for a class, while the mustContain and systemMustContain attributes contain the mandatory attributes. The systemMayContain and systemMustContain attributes are set by Active Directory itself and cannot be modified. You can only populate the mustContain attribute when a class is first created; you cannot add attributes to it after the fact. This is so that you are not inadvertently able to modify a class such that existing instances of that class become invalid.

It is also worth noting that each solution displays only the attributes defined directly on the class. It will not show any inherited attributes that are defined by inherited classes.

You want to modify the default security that is applied to objects instantiated from a particular structural class.

Whenever a new object is created in Active Directory, if a security descriptor is not specified in the object creation, a default security descriptor (SD) is applied to it. Then any inherited security from its parent container is applied. The default security descriptor is stored in the defaultSecurityDescriptor attribute of the classSchema object. If you modify the default SD, every new object will get that SD, but it does not affect any existing objects.

"O:AOG:DAD:(A;;RPWPCCDCLCSWRCWDWOGA;;;S-1-0-0)"

MS KB 265399 (How to Change Default Permissions for Objects That Are Created in the Active Directory); MSDN: Security Descriptor String Format

You want to manage the confidentiality of a schema attribute.

The confidentiality bit is a feature that allows you to restrict access to attributes that should not be accessible to all users. For example, you may have created an attribute to store users’ Social Security number information. Even though this attribute may be populated for every user object in the directory, you likely will wish to restrict access to that specific attribute to only a subset of your personnel. The confidentiality bit is set in the searchFlags attribute by setting bit 7 (128) to a value of 1. Once you’ve done this, the Read permission on that attribute will not be sufficient to access the information stored in it; you’ll need to grant the Control_Access permission to allow a user or group to view the contents of the attribute using LDP.

While the confidentiality bit is a great improvement in Active Directory security, it does have two significant limitations. First, there is no supported mechanism to set the confidentiality bit on any attributes that are a part of the base schema; you can, however, obtain a list of these attributes by searching for attributes that have bit 4 (16 in decimal) set to 1.

Second, certain default permissions included with Active Directory still will allow certain security principals to access the information stored in confidential attributes; these groups include the Administrators, Account Operators, and any user or group who has the Full Control permission on an object containing a confidential attribute.

Modifying a Bit-Flag Attribute for more on modifying a bit-flag attribute; “How the Active Directory Schema Works”

You want to add an attribute to the RO-FAS to prevent it from being replicated to any Read-Only Domain Controllers (RODCs) in your environment.