Chapter 10. Schema

Introduction

The Active Directory schema contains the blueprint for how objects are structured and secured, what data they can contain, and even how they can be viewed. Having a good understanding of the schema is paramount for any Active Directory administrator, designer, or architect. Understanding key concepts, such as class inheritance, class types, attribute syntax, and attribute indexing options is critical to being able to adequately design an Active Directory infrastructure and should be considered mandatory for any developer who is writing applications or automation scripts that utilize Active Directory.

If you are one of the lucky few who is designated as a schema administrator (i.e., a member of the Schema Admins group), then the importance of the schema is already well known to you. This chapter serves as a guide to accomplishing many of the day-to-day tasks of schema administrators. For a more in-depth discussion of the schema, we suggest reading Active Directory, Fifth Edition, by Brian Desmond et al. (O’Reilly).

The Anatomy of Schema Objects

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.

Table 10-1. Attributes of classSchema objects

Attribute

Description

adminDescription

Description of the class.

auxiliaryClass

Multivalued attribute containing any auxiliary classes defined for the class.

cn

Relative distinguished name of the class.

defaultHidingValue

Boolean that determines whether objects of this class are hidden by default in administrative GUIs.

defaultSecurityDescriptor

Default security descriptor applied to objects of this class.

governsID

OID for the class.

isDefunct

Boolean that indicates whether the class is defunct (i.e., deactivated).

lDAPDisplayName

Name used when referencing the class in searches or when instantiating or modifying objects of this class.

mayContain

Multivalued attribute that contains a list of attributes that can be optionally set on the class.

mustContain

Multivalued attribute that contains a list of attributes that must be set on the class.

objectClassCategory

Integer representing the class’s type. Can be one of 1 (structural), 2 (abstract), 3 (auxiliary), or 0 (88).

possibleInferiors

Multivalued list of other object classes this object can contain.

possSuperiors

Multivalued list of object classes this object can be subordinate to.

rDNAttID

Naming attribute (i.e., RDN) of instances of the class.

schemaIDGUID

GUID of the class.

showInAdvancedViewOnly

Boolean that indicates whether instances of this class should be shown only in Advanced mode in the administrative GUIs.

subClassOf

Parent class.

systemAuxiliaryClass

Multivalued attribute containing any auxiliary classes defined for the class. This can be modified only internally by Active Directory.

systemFlags

Integer representing additional properties of the class.

systemMayContain

Multivalued attribute that contains a list of attributes that can be optionally set on the class. This can be modified only internally by Active Directory.

systemMustContain

Multivalued attribute that contains a list of attributes that must be set on the class. This can be modified only internally by Active Directory.

systemPossSuperiors

Multivalued list of object classes this object can be subordinate to. This can be modified only internally by Active Directory.

Table 10-2. Attributes of attributeSchema objects

Attribute

Description

adminDescription

Description of the attribute.

attributeID

OID for the attribute.

attributeSecurityGUID

GUID of the property set (if any) that an attribute is a member of.

attributeSyntax

OID representing the syntax of the attribute. This is used in conjunction with oMSyntax to define a unique syntax.

cn

Relative distinguished name of the attribute.

isDefunct

Boolean that indicates if the attribute is defunct (i.e., deactivated).

isMemberOfPartialAttributeSet

Boolean that indicates if the attribute is a member of the partial attribute set (i.e., the global catalog).

isSingleValued

Boolean that indicates whether the attribute is single-valued or multivalued.

linkID

If populated, will contain an integer that represents a link (either forward or backward) to another attribute.

lDAPDisplayName

Name used when referencing the attribute in searches or when populating it on objects. Note that this value may not be the same as cn.

oMSyntax

An integer representing the OSI Abstract Data Manipulation (OM) type of the attribute. This is used in conjunction with attributeSyntax to determine a unique syntax for the attribute.

schemaIDGUID

GUID of the attribute.

searchFlags

Integer representing special properties related to searching with the attribute. This includes how the attribute is indexed and if it is used in ANR searches.

systemFlags

Integer representing additional properties of the attribute.

Registering the Active Directory Schema MMC Snap-in

Problem

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

Solution

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.

Discussion

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.

Generating an OID to Use for a New Class or Attribute

Problem

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

Solution

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.

Discussion

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.

Extending the Schema

Problem

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

Solution

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:

  1. Meet with staff and determine whether there is a business justification for integrating the application with Active Directory. Determine whether there are any existing attributes that would fulfill the desired requirements instead.

  2. Examine the extensions and determine what impact, if any, they will have on your Active Directory environment (e.g., adding an attribute to the global catalog).

  3. Update your test environment with the extensions and then test your core applications and services.

  4. Document the extensions.

  5. Extend the schema in your production Active Directory.

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

Discussion

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.

See Also

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

Preparing the Schema for an Active Directory Upgrade

Problem

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

Solution

From a graphical user interface

To prepare your Active Directory forest for a Windows upgrade, do the following:

  1. Log on to a server or a domain controller in the AD forest. Copy the installation media of the new Windows operating system to the domain controller.

  2. Open an elevated command prompt and navigate to the installation media. For example, if the installation media is at the root of the D: volume, you would navigate to D:supportadprep.

  3. Run the command adprep /forestprep. Read the warning message that appears and press C, followed by Enter.

To determine whether adprep /forestprep has completed, see Determining Whether AdPrep Has Completed.

To extend an Active Directory domain to prepare for an upgrade, follow these steps:

  1. Log on to a server or domain controller in the domain. Copy the installation media of the new Windows operating system to the domain controller.

  2. Open an elevated command prompt and navigate to the installation media. For example, if the installation media is at the root of the D: volume, you would navigate to D:supportadprep.

  3. Run the command adprep /domainprep. Read the warning message that appears and press C, followed by Enter.

Discussion

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.

See Also

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

Documenting Schema Extensions

Problem

You want to document your schema extensions.

Solution

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:

  1. Open a command prompt and navigate to the WindowsADAM directory. Run the program adschemaanalyzer.exe from the command prompt.

  2. Click File→Load target schema. To load the current Active Directory schema, enter your username, password, and domain name, and then click OK.

  3. Place a checkmark next to each class, attribute, and property set that you wish to export.

  4. Click File→Create LDIF file. Enter a path and name of the file to export, and click Save.

Discussion

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.

See Also

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

Adding a New Attribute

Problem

You want to add a new attribute to the schema.

Solution

Using a graphical user interface

  1. Open the Active Directory Schema snap-in.

  2. In the left pane, expand Active Directory Schema, and then right-click on the Attributes folder and select Create Attribute.

  3. Click the Continue button to confirm that you want to extend the schema.

  4. Enter the information for the new attribute.

  5. Click OK.

Using a command-line interface

You can create new attributes by using ldifde and an LDIF file that contains the properties to be set on the attribute. The following code shows a sample LDIF file called create_attr.ldf that creates an attribute called adatum-LanguagesSpoken:

dn: cn=adatum-LanguagesSpoken,cn=schema,cn=configuration,<ForestRootDN>
changetype: add
objectclass: attributeSchema
lDAPDisplayName: adatumLanguagesSpoken
attributeId: 1.3.6.1.4.1.999.1.1.28.3
oMSyntax: 20
attributeSyntax: 2.5.5.4
isSingleValued: FALSE
searchFlags: 1
description: "Languages a user speaks"

Then run the following command:

> ldifde -v -i -f create_attr.ldf

You can also use AdMod to add a schema attribute as follows:

> admod -schema -rb cn=adatumLanguagesSpoken
  objectClass::attributeSchema
     lDAPDisplayName::adatumLanguagesSpoken
     attributeId::1.3.6.1.4.1.999.1.1.28.3
     omSyntax::20
     attributeSyntax::2.5.5.4
     isSingleValued::FALSE
     searchFlags::1
     description::"Languages a user speaks"
     -add

Using PowerShell

To create a schema attribute by using PowerShell, use the following syntax:

New-ADObject -Name "Custom60" -Type "attributeSchema" -OtherAttributes @{distinguishedName="cn=Custom60,cn=Schema,cn=Configuration,<ForestRootDN>";LDAPDisplayName="Custom60";attributeId="1.3.6.1.4.1.999.1.1.28.3";oMSyntax="20";attributeSyntax="2.5.5.4";isSingleValued=$false;Description="Custom class #60";searchFlags="1"}

Discussion

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.

Table 10-3. attributeSyntax and oMSyntax combinations

Name

attributeSyntax

oMSyntax

Description

AccessPointDN

2.5.5.14

127

Type of distinguished name taken from X.500.

Boolean

2.5.5.8

1

TRUE or FALSE value.

CaseExactString

2.5.5.3

27

Case-sensitive string.

CaseIgnoreString

2.5.5.4

20

Case-insensitive string.

DirectoryString

2.5.5.12

64

Case-insensitive Unicode string.

DN

2.5.5.1

127

String representing a distinguished name.

DNWithBinary

2.5.5.7

127

Octet string that has the following format: B:CharCount:BinaryValue:ObjectDN, where CharCount is the number of hexadecimal digits in BinaryValue, BinaryValue is the hexadecimal representation of the binary value, and ObjectDN is a distinguished name.

DNWithString

2.5.5.14

127

Octet string that contains a string value and a DN. A value with this syntax has the following format: S:CharCount:StringValue:ObjectDN, where CharCount is the number of characters in the StringValue string and ObjectDN is a distinguished name of an object in Active Directory.

Enumeration

2.5.5.9

10

Defined in X.500 and treated as an integer.

GeneralizedTime

2.5.5.11

24

Time-string format defined by ASN.1 standards. See ISO 8601 and X.680.

IA5String

2.5.5.5

22

Case-sensitive string containing characters from the IA5 character set.

Integer

2.5.5.9

2

32-bit integer.

Integer8

2.5.5.16

65

64-bit integer, also known as a large integer.

NTSecurityDescriptor

2.5.5.15

66

Octet string that contains a security descriptor.

NumericString

2.5.5.6

18

String that contains digits.

OctetString

2.5.5.10

4

Array of bytes used to store binary data.

OID

2.5.5.2

6

String that contains digits (0–9) and decimal points (.).

ORName

2.5.5.7

127

Taken from X.400; used for X.400 to RFC 822 map ping.

PresentationAddress

2.5.5.13

127

String that contains OSI presentation addresses.

PrintableString

2.5.5.5

19

Case-sensitive string that contains characters from the printable character set.

ReplicaLink

2.5.5.10

127

Used by Active Directory internally.

Sid

2.5.5.17

4

Octet string that contains a security identifier (SID).

UTCTime

2.5.5.11

23

Time-string format defined by ASN.1 standards.

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

Table 10-4. searchFlags bit values

Value

Description

1

Index over attribute. See Indexing an Attribute for more information.

2

Index over container and attribute.

4

Include as part of Ambiguous Name Resolution (ANR). Should be used in addition to 1. See Modifying the Attributes Included with ANR for more information.

8

Preserve attribute in tombstone objects. This will ensure that the value of a particular attribute will be retained when the object is tombstoned, so that it will be repopulated automatically if you need to reanimate the object.

16

Copy attribute when duplicating an object. See Modifying the Attributes That Are Copied When Duplicating a User for more information.

32

Create a tuple index for this attribute. This improves the response time for searches that put a wildcard in front of the search string for the attribute (e.g., givenname=*on).

64

Create an index on which to assist with VLV performance.

128

Set the confidential bit on this attribute, which requires normal users to be assigned additional permissions to be able to read its contents.

256

Disable security auditing for the attribute. Applicable to Windows Server 2008 and later.

512

Attribute should be added to the Read-Only Filtered Attribute Set (RO-FAS), preventing the attribute from being replicated to any RODCs in the environment.

See Also

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

Viewing an Attribute

Problem

You want to view the properties of an attribute.

Solution

Using a graphical user interface

  1. Open the Active Directory Schema snap-in.

  2. In the left pane, expand Active Directory Schema and then click on the Attributes folder.

  3. In the right pane, double-click the attribute you want to view.

  4. Click on each tab to view the available properties.

Using a command-line interface

In the following command, replace <AttrCommonName> with the common name (not the LDAP display name) of the attribute you want to view:

> dsquery * cn=schema,cn=configuration,<ForestRootDN> -scope onelevel -attr * -filter "(&(objectcategory=attributeSchema)(cn=<AttrCommonName>))"

For example, to view the properties of the Surname attribute in the adatum.com domain, you would run the following command:

> dsquery * cn=schema,cn=configuration,dc=adatum,dc=com -scope onelevel -attr * -filter "(&(objectcategory=attributeSchema)(cn=surname))"

You can also use AdFind to view the properties of an attribute, as follows:

> adfind -schema -f (ldapdisplayname=<AttributeName>)

You can also use shortcut syntax for this command, as follows:

> adfind -sc s:<AttributeName>

Using PowerShell

You can view the properties of a schema attribute using PowerShell, as follows:

Get-ADObject -Identity "<ObjectDN>" -Properties * | FL

For example, to view the properties of the Surname attribute, you would run the following PowerShell command:

Get-ADObject -Identity "cn=surname,cn=schema,cn=configuration,dc=adatum,dc=com" -Properties * | FL

Discussion

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.

Table 10-5. systemFlags bit values

Value

Description

1

Not replicated among domain controllers.

4

Dynamically constructed by Active Directory.

16

Part of the base Active Directory installation. This value cannot be set.

See Also

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

Adding a New Class

Problem

You want to add a new class to the schema.

Solution

Using a graphical user interface

  1. Open the Active Directory Schema snap-in.

  2. In the left pane, expand Active Directory Schema and then right-click on the Classes folder and select “Create Class”.

  3. Click the Continue button to confirm that you want to extend the schema.

  4. Enter the information for the new class and click Next.

  5. Enter any mandatory and optional attributes and click Finish.

Using a command-line interface

You can create new classes by using ldifde and an LDIF file that contains the properties to be set on the class. The following code shows a sample LDIF file called create_class.ldf that creates a class called adatum-SalesUser:

dn: cn=adatum-SalesUser,cn=schema,cn=configuration,<ForestRootDN>
changetype: add
objectclass: classSchema
lDAPDisplayName: adatum-SalesUser
governsId: 1.3.6.1.4.1.999.1.1.28.4
objectClassCategory: 3
subClassOf: top
description: Auxiliary class for Sales user attributes
adminDescription: Auxiliary class for Sales user
attributes
mayContain: adatum-Building
mayContain: adatum-Theatre

Then run the following command:

> ldifde -v -i -f create_class.ldf

You can also add a new class using AdMod, as follows:

> admod -schema -rb cn=adatum-SalesUser↵
objectclass::classSchema lDAPDisplayName::adatum-SalesUser↵
governsId::1.3.6.1.4.1.999.1.1.28.4 objectClassCategory::3↵
subClassOf::top↵
description::"Auxiliary class for Sales user"↵
adminDescription::"Auxiliary class for Sales user"↵
mayContain::adatum-Building;adatum-Theatre↵
-add

Using PowerShell

To create a schema class by using PowerShell, use the following syntax:

New-ADObject -Name "adatum-SalesUser " -Description "Custom Class" -Type "classSchema" -OtherAttributes @{distinguishedname="cn=Custom24,cn=Schema,cn=Configuration,<ForestRootDN>";LDAPDisplayName="adatum-SalesUser";governsId="1.3.6.1.4.1.999.1.1.28.4";objectCategory="3";subClassOf="top";adminDescription="Auxilliary class for Sales user attributes"}

Discussion

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

governsId

Defines the OID for the class

objectClassCategory

Defines the class type

subClassOf

Defines the parent class

mayContain and mustContain

Define any optional and mandatory attributes for instantiated objects of the class

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 Also

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

Viewing a Class

Problem

You want to view the attributes of a class.

Solution

Using a graphical user interface

  1. Open the Active Directory Schema snap-in.

  2. In the left pane, expand Active Directory Schema and then click on the Classes folder.

  3. In the right pane, double-click the class you want to view.

  4. Click on each tab to view the available properties.

Using a command-line interface

In the following command, replace <ClassCommonName> with the common name (not LDAP display name) of the class you want to view:

> dsquery * cn=<ClassCommonName>,cn=schema,cn=configuration,<ForestRootDN> -scope base -attr *

You can also use AdFind to view the properties of a class, as follows:

> adfind -schema -rb cn=<ClassCommonName>

In addition, you can use shortcut syntax for this command, as follows:

> adfind -sc s:<ClassCommonName or ClassLDAPDisplayName>

Using PowerShell

Get-ADObject -Identity "cn=<ClassName>,cn=schema,cn=configuration,<ForestRootDN>" -Properties * | FL

Discussion

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.

See Also

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

Indexing an Attribute

Problem

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

Solution

Using a graphical user interface

  1. Open the Active Directory Schema snap-in.

  2. In the left pane, expand Active Directory Schema and then click on the Attributes folder.

  3. In the right pane, double-click the attribute you want to index.

  4. Check the box beside “Index this attribute.”

  5. Click OK.

Using a command-line interface

You can index an attribute by using the ldifde utility and an LDIF file that contains the following:

dn: cn=<AttrCommonName>,cn=schema,cn=configuration,<ForestRootDN>
changetype: modify
replace: searchFlags
searchFlags: 1
-

If the LDIF file were named index_attribute.ldf, you would run the following command:

> ldifde -v -i -f index_attribute.ldf

You can also enable the appropriate searchFlags value using admod, as follows:

> admod -schema -rb cn=<AttrCommonName> searchFlags::1

Note

The CLI solution and the PowerShell solution assume that searchFlags wasn’t previously set; if a value is present, it just blindly overwrites it. See Modifying a Bit-Flag Attribute for a better solution that will enable the bit value you want without overwriting any previous settings.

Using PowerShell

To set the searchFlags bit value by using PowerShell, use the following syntax:

Set-ADObject "<AttributeDN>" -Replace @{"searchFlags"="1"}

Discussion

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:

Base

cn=Schema,cn=Configuration,<ForestRootDN>

Filter

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

Scope

onelevel

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

Note

Since Windows Server 2008, the objectClass attribute is now indexed by default. This allows you to perform simpler searches by querying directly against objectClass, rather than using the more complex query of "(&(objectCategory=ABC)(objectClass=XYZ))". Note that some searches require a more complex query as the results may differ if only relying on the objectClass attribute.

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

adfind -sc indexed

See Also

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

Modifying the Attributes That Are Copied When Duplicating a User

Problem

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

Solution

Using a graphical user interface

  1. Open the Active Directory Schema snap-in.

  2. In the left pane, expand Active Directory Schema and then click on the Attributes folder.

  3. In the right pane, double-click the attribute you want to edit.

  4. Check the box beside “Attribute is copied when duplicating a user.”

  5. Click OK.

Using a command-line interface

You can cause an attribute to get copied when duplicating a user by using the ldifde utility and an LDIF file that contains the following:

dn: cn=adatum-LanguagesSpoken,cn=schema,cn=configuration,<ForestRootDN>
changetype: modify
replace: searchFlags
searchFlags: 16
-

If the LDIF file were named add_dup_user_attr.ldf, you would run the following command:

> ldifde -v -i -f add_dup_user_attr.ldf

You can also modify the searchFlags attribute using AdMod, as follows:

> admod -b <AttributeDN> searchFlags::16

Note

The CLI solution and the PowerShell solution assume that searchFlags wasn’t previously set; if a value is present, it just blindly overwrites it. See Modifying a Bit-Flag Attribute for a better solution that will enable the bit you want without overwriting any previous settings.

Using PowerShell

To set the searchFlags bit value by using PowerShell, use the following syntax:

Set-ADObject "<AttributeDN>" -Replace @{"searchFlags"="16"}

Discussion

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:

Base

cn=Schema,cn=Configuration,<ForestRootDN>

Filter

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

Scope

onelevel

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

See Also

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

Modifying the Attributes Included with ANR

Problem

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

Solution

Using a graphical user interface

  1. To proceed, you must have first indexed the attribute.

  2. Open the Active Directory Schema snap-in.

  3. In the left pane, click on the Attributes folder.

  4. In the right pane, double-click the attribute you want to edit.

  5. Check the box beside Ambiguous Name Resolution (ANR).

  6. Click OK.

Using a command-line interface

You can include an attribute as part of ANR by using the ldifde utility and an LDIF file that contains the following:

dn: cn=adatum-LanguagesSpoken,cn=schema,cn=configuration,<ForestRootDN>
changetype: modify
replace: searchFlags
searchFlags: 5
-

If the LDIF file were named add_anr_attr.ldf, you’d run the following command:

> ldifde -v -i -f add_anr_attr.ldf

You can also modify the searchFlags attribute using AdMod, as follows:

> admod -b <AttributeDN> searchFlags::5

Note

The CLI solution and the PowerShell solution assume that searchFlags wasn’t previously set; if a value is present, it just blindly overwrites it. Check out Modifying a Bit-Flag Attribute for a better solution that will enable the bit you want without overwriting any previous settings.

Using PowerShell

To set the ANR bit value by using PowerShell, use the following syntax:

Set-ADObject "<AttributeDN>" -Replace @{"searchFlags"="5"}

Discussion

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:

  • An OR filter with every attribute in the ANR set against Jim Smith*

  • A filter for givenName = Jim* and sn = Smith*

  • A filter for givenName = Smith* and sn = Jim*

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:

  • displayName (Display-Name)

  • givenName (Given-Name)

  • legacyExchangeDN (Legacy-Exchange-DN)

  • msDS-AdditionalSamAccountName (ms-DS-Additional-Sam-Account-Name)

  • physicalDeliveryOfficeName (Physical-Delivery-Office-Name)

  • name (RDN)

  • sAMAccountName (SAM-Account-Name)

  • sn (Surname)

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:

Base

cn=Schema,cn=Configuration,<ForestRootDN>

Filter

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

Scope

onelevel

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

See Also

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”

Modifying the Set of Attributes Stored on a Global Catalog

Problem

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

Solution

Using a graphical user interface

  1. Open the Active Directory Schema snap-in.

  2. In the left pane, expand Active Directory Schema and then click on the Attributes folder.

  3. In the right pane, double-click the attribute you want to edit.

  4. Check the box beside “Replicate this attribute to the Global Catalog” to add the attribute to the global catalog, or uncheck to remove the attribute from the global catalog.

  5. Click OK.

Using a command-line interface

You can add an attribute to the global catalog by using the ldifde utility and an LDIF file that contains the following:

dn: cn=<AttrCommonName>,cn=schema,cn=configuration,<ForestRootDN>
changetype: modify
replace:
isMemberOfPartialAttributeSet
isMemberOfPartialAttributeSet: TRUE
-

If the LDIF file were named add_gc_attr.ldf, you would run the following command:

> ldifde -v -i -f add_gc_attr.ldf

You can also modify this property using AdMod, as follows:

> admod -schema -rb cn=<AttrCommonName> isMemberOfPartialAttributeSet::TRUE

Using PowerShell

To add an attribute to the Partial Attribute Set by using PowerShell, use the following syntax:

Set-ADObject "<AttributeDN>" -Replace @{"isMemberOfPartialAttributeSet"=$True}

Discussion

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:

Base

cn=Schema,cn=Configuration,<ForestRootDN>

Filter

(&(objectcategory=attributeSchema)(isMemberOfPartialAttributeSet=TRUE))

Scope

onelevel

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)

Finding Nonreplicated and Constructed Attributes

Problem

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

Solution

Using a graphical user interface

  1. Open LDP.

  2. From the menu, select Connection→Connect.

  3. For Server, enter the name or IP address of a domain controller or domain that contains the object.

  4. For Port, enter 389.

  5. Click OK.

  6. From the menu, select Connection→Bind.

  7. Accept the default and bind as the currently logged on user or select the option to bind with credentials and then enter the credentials.

  8. Click OK.

  9. From the menu, select Browse→Search.

  10. For Base DN, enter the Schema container DN (e.g., cn=schema,cn=configuration,dc=adatum,dc=com).

  11. For Scope, select One Level.

  12. To find nonreplicated attributes, use the following for Attributes:

    (&(objectcategory=attributeSchema)(systemFlags:1.2.840.113556.1.4.803:=1))
  13. To find constructed attributes, use the following for Attributes:

    (&(objectcategory=attributeSchema)(systemFlags:1.2.840.113556.1.4.803:=4))
  14. Click Run to display the results.

Using a command-line interface

To find the nonreplicated attributes using DSQuery, use the following command:

> dsquery * cn=schema,cn=configuration,<ForestRootDN> -attr "cn" -filter"(&(objectcategory=attributeSchema)(systemFlags:1.2.840.113556.1.4.803:=1))" -limit 0

To find the nonreplicated attributes using AdFind, use the following:

> adfind -sc norepl

To find the constructed attributes using DSQuery, use the following command:

> dsquery * cn=schema,cn=configuration,<ForestRootDN> -attr "cn" -filter "(&(objectcategory=attributeSchema)(systemFlags:1.2.840.113556.1.4.803:=4))"

To find the constructed attributes using AdFind, use the following:

> adfind -sc constructed

Using PowerShell

You can obtain information about nonreplicated attributes by using PowerShell, as follows:

Get-ADObject -SearchBase "cn=schema,cn=configuration,<ForestRootDN>" -LDAPFilter "(&(objectCategory=attributeSchema)(systemFlags:1.2.840.113556.1.4.803:=1))" | FL

You can obtain information about constructed attributes by using PowerShell, as follows:

Get-ADObject -SearchBase "cn=schema,cn=configuration,<ForestRootDN>" -LDAPFilter "(&(objectCategory=attributeSchema)(systemFlags:1.2.840.113556.1.4.803:=4))" | FL

Discussion

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.

See Also

Searching with a Bitwise Filter for searching with a bitwise filter

Finding the Linked Attributes

Problem

You want to find attributes that are linked.

Solution

Using a graphical user interface

  1. Open LDP.

  2. From the menu, select Connection→Connect.

  3. For Server, enter the name or IP address of a domain controller or domain that contains the object.

  4. For Port, enter 389.

  5. Click OK.

  6. From the menu, select Connection→Bind.

  7. Accept the default and bind as the currently logged on user or select the option to bind with credentials and then enter the credentials.

  8. Click OK.

  9. From the menu, select Browse→Search.

  10. For Base DN, enter the Schema container DN (e.g., cn=schema, cn=configuration,dc=adatum,dc=com).

  11. For Scope, select One Level.

  12. To find linked attributes, use the following for Filter:

    (&(objectcategory=attributeSchema)(linkid=*))
  13. Click Run.

Using a command-line interface

You can return a list of linked attributes using either the built-in DSQuery tool or AdMod. To use DSQuery, use the following syntax:

> dsquery * cn=schema,cn=configuration,<ForestRootDN> -scope onelevel -filter"(&(objectcategory=attributeSchema)(linkid=*))" -attr cn linkID

To return a list of linked attributes with AdFind, use the following:

> adfind -sc linked

Using PowerShell

You can obtain linked attribute information by using PowerShell, as follows:

Get-ADObject -SearchBase "cn=schema,cn=configuration,<ForestRootDN>" -LDAPFilter "($(objectCategory=attributeSchema)(linkID=*))"

Discussion

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

Finding the Structural, Auxiliary, Abstract, and 88 Classes

Problem

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

Solution

Using a graphical user interface

  1. Open the Active Directory Schema snap-in.

  2. In the left pane, expand Active Directory Schema and then click on the Classes folder.

  3. In the right pane, view the list of the classes.

Using a command-line interface

You can return the list of Active Directory classes using either DSQuery or AdFind. DSQuery takes the following syntax:

> dsquery * cn=schema,cn=configuration,<ForestRootDN> -limit 0 -scope onelevel-filter "(objectcategory=classSchema)" -attr lDAPDisplayName objectclasscategory

AdFind requires the following syntax:

> adfind -schema -f "(objectcategory=classSchema)" lDAPDisplayName objectClassCategory

Using PowerShell

You can obtain information about different class types using PowerShell.

To obtain structural class type objects, use the following syntax:

Get-ADObject -SearchBase "cn=schema,cn=configuration,<ForestRootDN>" -LDAPFilter "(&(objectcategory=classSchema)(objectClassCategory=1))"

To obtain auxiliary class type objects, use the following syntax:

Get-ADObject -SearchBase "cn=schema,cn=configuration,<ForestRootDN>" -LDAPFilter "(&(objectcategory=classSchema)(objectClassCategory=3))"

To obtain abstract class type objects, use the following syntax:

Get-ADObject -SearchBase "cn=schema,cn=configuration,<ForestRootDN>" -LDAPFilter "(&(objectcategory=classSchema)(objectClassCategory=2))"

To obtain 88 class type objects, use the following syntax:

Get-ADObject -SearchBase "cn=schema,cn=configuration,<ForestRootDN>" -LDAPFilter "(&(objectcategory=classSchema)(objectClassCategory=0))"

Discussion

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.

Table 10-6. Object class category values

Name

Value

Description

88

0

Legacy class type defined by the original X.500 standards. It should not be used for new classes.

Structural

1

Used for instantiating objects. Can consist of abstract, auxiliary, and other structural classes.

Abstract

2

Used to define a high-level grouping of attributes that can be used as part of other abstract or structural class definitions. Objects cannot be instantiated using an abstract class.

Auxiliary

3

Used as a collection of attributes that can be applied to other abstract, auxiliary, or structural classes.

Finding the Mandatory and Optional Attributes of a Class

Problem

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

Solution

Using a graphical user interface

  1. Open the Active Directory Schema snap-in.

  2. In the left pane, expand Active Directory Schema and then click on the Classes folder.

  3. In the right pane, double-click the class you want to view.

  4. Click on the Attributes tab and then view the mandatory and optional attributes.

Using a command-line interface

You can enumerate the mandatory and optional attributes of a class using either DSQuery or AdFind. DSQuery takes the following syntax:

> dsquery * cn=<ClassCommonName>,cn=schema,cn=configuration,<ForestRootDN> -l-attr mayContain mustContain systemMayContain systemMustContain

To list these attributes using AdFind, use the following syntax:

> adfind -schema -rb cn=<ClassCommonName> mayContain mustContain systemMayContain systemMustContain

Using PowerShell

To view the mandatory and optional attributes with PowerShell, use the following syntax:

Get-ADObject -Identity "cn=<ClassName>,cn=schema,cn=configuration,<ForestRootDN>" -Properties * | foreach {(Write-Output "mayContain:" $_.mayContain " "), (Write-Output "systemMayContain:" $_.systemMayContain " "), (Write-Output "mustContain:" $_.mustContain " "), (Write-Output "systemMustContain:" $_.systemMustContain " ")}

Discussion

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.

Modifying the Default Security of a Class

Problem

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

Solution

Using a graphical user interface

  1. Open the Active Directory Schema snap-in.

  2. In the left pane, expand Active Directory Schema and then click on the Classes folder.

  3. In the right pane, double-click the class you want to modify the security for.

  4. Click the Default Security tab.

  5. Modify the security as necessary.

  6. Click OK.

Using a command-line interface

> admod -schema -rb cn=<ClassShortName>defaultSecurityDescriptor::"O:AOG:DAD:(A;;RPWPCCDCLCSWRCWDWOGA;;;S-1-0-0)"

Using PowerShell

Set-ADObject "cn=<ClassName>,cn=schema,cn=configuration,<ForestRootDN>" -Replace @{"defaultSecurityDescriptor"="O:AOG:DAD:(A;;RPWPCCDCLCSWRCWDWOGA;;;S-1-0-0)"}

Discussion

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.

Using a command-line interface

The defaultSecurityDescriptor attribute is stored in Active Directory using the Security Descriptor Definition Language (SDDL) format and will return data formatted similar to the following:

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

For more information on formulating SDDL strings, see the Platform Software Development Kit (SDK) or MSDN.

Note

When creating Active Directory classes, we recommend against setting a default security descriptor, as this feature can create issues when working with delegated permissions.

When modifying the defaultSecurityDescriptor attribute, it’s important to remember that this is a single-valued attribute. This means that if you put any value into this attribute, it will overwrite all existing security descriptors that have been defined on the object. If you wish to append a new entry onto the default security descriptor, you will need to retrieve the existing value in the attribute, append the new entry that you wish to add, and then write the full string back to the attribute.

See Also

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

Managing the Confidentiality Bit

Problem

You want to manage the confidentiality of a schema attribute.

Solution

Using a command-line interface

admod -schema -rb cn=<AttrName> searchFlags::128

Using PowerShell

To set the searchFlags bit value by using PowerShell, use the following syntax:

Set-ADObject "cn=<AttrName>,cn=schema,cn=configuration,dc=<ForestRootDN>" -Replace @{"searchFlags"="128"}

Discussion

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.

See Also

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

Adding an Attribute to the Read-Only Filtered Attribute Set (RO-FAS)

Problem

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.

Solution

Using a command-line interface

admod -schema -rb cn=<AttrName> searchFlags::512

Using PowerShell

To set the searchFlags bit value by using PowerShell, use the following syntax:

Set-ADObject "cn=<AttrName>,cn=schema,cn=configuration,dc=<ForestRootDN>" -Replace @{"searchFlags"="512"}

Discussion

As discussed in Chapter 3, Read-Only Domain Controllers contain a read-only copy of all partitions that are held by a writable domain controller, with the exception of attributes that are configured as part of the RO-FAS, as well as user credentials, except for those that are specifically configured so that they are allowed to be cached to one or more RODCs.

Attributes that are configured as part of the RO-FAS are not replicated to any RODCs within an Active Directory forest. Because this data is not replicated to RODCs, the data will not be resident on an RODC if it is compromised or stolen. Administrators can add any attribute to the RO-FAS that is not a system-critical attribute; that is, any attribute that does not have a schemaFlagsEx attribute of TRUE.

Microsoft recommends that the forest functional level be set to Windows Server 2008 or later before configuring the RO-FAS, and that any attributes destined for the RO-FAS be configured as such before any RODCs are deployed in the environment. Both of these recommendations will ensure that data contained in the RO-FAS will never be replicated to an RODC. Additionally, any attribute that is configured as part of the RO-FAS should also be configured with the confidentiality bit for further security.

For additional information on Read-Only Domain Controllers and the RO-FAS, we suggest reading Active Directory, Fifth Edition, by Brian Desmond et al. (O’Reilly).

See Also

Managing the Confidentiality Bit for more on managing confidential data in Active Directory

Deactivating Classes and Attributes

Problem

You want to deactivate a class or attribute in the schema because you no longer need it.

Solution

Using a graphical user interface

  1. Open the Active Directory Schema snap-in.

  2. In the left pane, expand Active Directory Schema and then click on the Classes folder or the Attributes folder.

  3. In the right pane, double-click the class or attribute you want to deactivate.

  4. Uncheck the box beside “Class is active” or “Attribute is active.”

  5. Click OK.

Using a command-line interface

You can deactivate a class using the ldifde utility and an LDIF file that contains the following lines:

dn: cn=<SchemaObjectCommonName>,cn=schema,cn=configuration,<ForestRootDN>
changetype: modify
replace: isDefunct
isDefunct: TRUE
-

If the LDIF file were named deactivate_class.ldf, you would run the following command:

> ldifde -v -i -f deactivate_class.ldf

You can also deactivate a class using AdMod, as follows:

> admod -schema -rb cn=<SchemaObjectCommonName> isDefunct::TRUE

Using PowerShell

To deactivate a schema attribute or class by using PowerShell, use the following syntax:

Set-ADObject "cn=<ObjectName>,cn=schema,cn=configuration,<ForestRootDN>" -Replace @{"isDefunct"=$True}

Discussion

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 is no supported way to delete classes or attributes defined in the schema. You can, however, deactivate them, also known as making them defunct. Before you deactivate a class, make sure that no instantiated objects of that class exist. If you want to deactivate an attribute, you should make sure no object classes define the attribute as mandatory. After you’ve verified the class or attribute is no longer being used, you can deactivate it by setting the isDefunct attribute to TRUE. You can always reactivate it at a later time by simply setting isDefunct to FALSE. You can even redefine the class or attribute while it is defunct. This gives you some flexibility over reusing classes or attributes you may have added before but no longer want.

See Also

Redefining Classes and Attributes for more on redefining classes and attributes

Redefining Classes and Attributes

Problem

You want to redefine a class or attribute that was created previously.

Solution

To redefine a class or attribute, you must first deactivate it by setting the isDefunct attribute to TRUE (see Deactivating Classes and Attributes for more details). If you are deactivating a class, make sure that no objects are instantiated that use the class. If you are deactivating an attribute, make sure that it isn’t populated on any objects and remove it from any classes that have it defined as part of mayContain and mustContain. After the class or attribute has been deactivated, you can modify (i.e., redefine) the LDAP display name (lDAPDisplayName), the OID (governsID or attributeID), the syntax (attributeSyntax and oMSyntax), and the schemaIDGUID. The one attribute that you cannot modify is the common name.

Discussion

Although you cannot delete schema objects, you can work around many of the reasons that would cause you to want to delete a schema object by redefining it instead. Redefining schema objects comes in handy if you accidentally mistype an OID (governsID/attributeID) or lDAPDisplayName, or no longer need an attribute you created previously. You can reuse it by renaming the attribute and giving it a different syntax.

See Also

Deactivating Classes and Attributes for more on deactivating classes and attributes

Reloading the Schema Cache

Problem

You want to reload the schema cache so that schema extensions will take effect immediately.

Solution

Using a graphical user interface

  1. Open the Active Directory Schema snap-in.

  2. In the left pane, right-click on Active Directory Schema and select Reload the Schema.

Using a command-line interface

You can reload the schema by using the ldifde utility and an LDIF file that contains the following:

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

If the LDIF file were named reload.ldf, you would run the following command:

> ldifde -v -i -f reload.ldf

You can also reload the schema cache using AdMod, as follows:

> admod -sc refreshschema

Using PowerShell

$objRootDSE = [ADSI] "LDAP://<DCName>/RootDSE" # Specify the Schema Master FSMO
$objRootDSE.put("schemaUpdateNOW", 1)
$objRootDSE.SetInfo()

Discussion

Each domain controller maintains a complete copy of the schema in memory to make access to the schema very fast. This is called the schema cache. When you extend the schema on the Schema FSMO role owner, the change is written to the schema cache and is not committed to disk yet. The schema automatically commits any changes to the schema every five minutes if a change has taken place, but you can also do it manually/programmatically by writing to the schemaUpdateNow operational attribute of the RootDSE on the Schema FSMO role owner. Once that is done, any changes to the schema cache are written to disk.

It is necessary to force a schema cache update if your schema extensions reference newly created attributes or classes. For example, let’s say that you want to create one new auxiliary class that contains one new attribute. To do that, you would first need to create the attribute and then create the auxiliary class. As part of the auxiliary class’s definition, you would need to reference the new attribute, but unless you reload the schema cache, an error would be returned stating that the attribute does not exist. For this reason, you need to add an additional step. First create the attribute, then reload the schema cache, and finally create the auxiliary class. Here is what an LDIF representation would look like:

dn: cn=adatum-TestAttr,cn=schema,cn=configuration,dc=adatum,dc=com
changetype: add
objectclass: attributeSchema
lDAPDisplayName: adatum-TestAttr
attributeId: 1.3.6.1.4.1.999.1.1.28.312
oMSyntax: 20
attributeSyntax: 2.5.5.4
isSingleValued: FALSE
searchFlags: 1

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

dn: cn=adatum-TestClass,cn=schema,cn=configuration,dc=adatum,dc=com
changetype: add
objectclass: classSchema
lDAPDisplayName: adatum-TestClass
governsId: 1.3.6.1.4.1.999.1.1.28.311
subClassOf: top
objectClassCategory: 3
mayContain: adatum-TestAttr

See Also

Adding a New Attribute for adding a new attribute to the schema; Adding a New Class for adding a new class to the schema

Managing the Schema Master FSMO

Problem

You want to view, transfer, or seize the Schema Master FSMO for your Active Directory forest.

Solution

Using a graphical user interface

To view the current Schema Master FSMO role holder, do the following:

  1. Open the Active Directory Schema snap-in.

  2. Right-click on Active Directory Schema in the left pane and select Operations Master.

To transfer the Schema Master to another server, follow these steps:

  1. Open the Active Directory Schema snap-in. Right-click on Active Directory Schema in the left pane and select Change Active Directory Domain Controller. Select the DC that you wish to transfer the FSMO role to.

  2. Right-click on Active Directory Schema in the left pane and select Operations Master.

  3. Click the Change button.

  4. Click OK twice.

    You should see a message stating whether the transfer was successful.

Using a command-line interface

To query the owner of the Schema Master FSMO role, you can use the dsquery server or adfind command shown here:

> dsquery server -hasfsmo schema
> adfind -sc fsmo:schema

To transfer the Schema Master to another server, use the following syntax:

> ntdsutil roles conn "co t s <NewRoleOwner>" q "transfer Schema Master" q q

To forcibly seize the Schema Master to another DC, do the following:

> ntdsutil roles conn "co t s <NewRoleOwner>" q "seize Schema Master" q q

Using PowerShell

To move the Schema Master to another DC by using PowerShell, use the following syntax:

Move-ADDirectoryServerOperationMasterRole -Identity <NewRoleOwner> -OperationMasterRole schemaMaster

Discussion

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

Several Active Directory operations, such as updating the schema, are sensitive and therefore need to be restricted to a single domain controller to prevent corruption of the AD database. This is because Active Directory cannot guarantee the proper evaluation of these functions in a situation where they may be invoked from more than one DC. The FSMO mechanism is used to limit these functions to a single DC.

The first domain controller in a new forest is assigned the two forest-wide FSMO roles, the Schema Master and Domain Naming Master. The first domain controller in a new domain gets the other three domain-wide roles. If you need to decommission the domain controller that is currently the Schema Master role owner (either permanently or for a significant period of time), you’ll want to transfer the role beforehand.

If the Schema Master becomes unavailable before you can transfer it, you’ll need to seize the role (see Seizing a FSMO Role).

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.14.131.180