The Active Directory schema is composed of a hierarchy of classes that define the types of objects that can be created within Active Directory, as well as the different attributes they can possess. These classes support inheritance, which enables developers to reuse existing class definitions for more than one type of object; for example, the description attribute is available with every type of AD object, but the attribute itself is defined only once within the schema. At the top of the inheritance tree is the top class, from which every class in the schema is derived. Table 4-1 contains a list of some of the attributes that are available from the top class, and subsequently are defined on every object that is created in Active Directory.

You want to view attributes of the RootDSE, which can be useful for discovering basic information about a forest, domain, or domain controller without hardcoding the name of a particular naming context into a query.

The RootDSE was originally defined in RFC 2251 as part of the LDAPv3 specification. It is not part of the Active Directory namespace per se. It is a synthetic object that is maintained separately by each domain controller.

The RootDSE can be accessed anonymously using LDP; the command-line and PowerShell solutions use the credentials of the currently logged-on user unless you specify an alternate username and password. In the CLI and PowerShell solutions, serverless binds were used against the RootDSE. In that case, the DC Locator process is used to find a domain controller in the domain you authenticate against. This can also be accomplished with LDP by not entering a server name from the Connect dialog box.

The RootDSE is key to writing portable AD-enabled applications. It provides a mechanism to programmatically determine the distinguished names of the various naming contexts (among other things), which means that you do not need to hardcode that information in scripts and programs.

RFC 2251; MS KB 219005 (Windows 2000: LDAPv3 RootDSE); MSDN: IADsPropertyEntry; MSDN: IADsProperty Value; MSDN: IADs::Get MSDN: IADs::GetEx

You want to view one or more attributes of an object.

Objects in Active Directory are made up of a collection of attributes. Attributes can be single- or multivalued. Each attribute also has an associated syntax that is defined in the schema. See Adding a New Attribute for a complete list of syntaxes.

Adding a New Attribute; MSDN: IADsPropertyEntry; MSDN: IADsPropertyList; MSDN: ADSTYPEENUM; MSDN: IADs::GetInfo; Active Directory, Fifth Edition, by Brian Desmond et al. (O’Reilly)

You want to retrieve the number of directory objects that meet the result of an LDAP query.

You want to use an LDAP control as part of an LDAP operation.

LDAP controls were defined in the LDAPv3 specification as a way to extend LDAP and its operations without breaking the protocol. Many controls have been implemented, some of which are used when searching the directory (e.g., paged searching, Virtual List View [VLV], finding deleted objects, and attribute scoped query), and some are needed to do certain modifications to the directory (e.g., cross-domain object moves, tree delete, and permissive modify). Controls can be marked as critical, which means they must be processed with the request or an error is returned. If an unsupported control is not flagged as critical, the server can continue to process the request and ignore the control.

The complete list of controls supported by Active Directory is included in Table 4-2.

Searching for Objects in a Domain; Using the STATS Control to View LDAP Query Statistics; RFC 2251 (Lightweight Directory Access Protocol [v3]) for a description of LDAP controls; 3.1.1.3.4.1 LDAP Extended Controls; MSDN: Using Controls

You want to perform an LDAP bind using a concurrent bind, also known as a fast bind. Concurrent binds are typically used in situations where you need to authenticate a lot of users, and either those users do not need to directly access the directory or the directory access is done with another account.

Unlike simple binding, concurrent binding does not generate a security token or determine a user’s group memberships during the authentication process. It determines only whether the authenticating user has a valid enabled account and password, which makes it much faster than a typical bind. This is usually used programmatically for AD-enabled applications to improve the speed of AD authentication; it’s not something that you’ll typically do on the fly. Concurrent binding is implemented as a session option that is set after you establish a connection to a domain controller, but before any bind attempts are made. After the option has been set, any bind attempt made with the connection will be a concurrent bind.

There are a couple of caveats when using concurrent binds. First, you cannot enable signing or encryption, which means that all data for concurrent binds will be sent over the network in clear text. Second, because the user’s security token is not generated, access to the directory is done anonymously and access restrictions are based on the ANONYMOUS LOGON principal.

It is worth mentioning that there is another type of fast bind that is completely different from the procedure just described. This fast bind is implemented within ADSI, and it simply means that when you fast-bind to an object, the objectClass attribute for the object is not retrieved; therefore, the object-specific IADs class interfaces are not available. For example, if you bind to a user object using an ADSI fast bind, then only the basic IADs interfaces will be available, not the IADsUser interfaces.

This is the complete list of interfaces that are available for objects retrieved with fast binds:

You must use the IADsOpenDSObject::OpenDSObject interface to enable fast binds. If you call IADsContainer::GetObject on a child object of a parent you used a fast bind with, the same fast bind behavior applies. Unlike concurrent binds, ADSI fast binds do not impose any restrictions on the authenticating user. This means that the object-specific IADs interfaces will not be available. Also, no check is done to verify the object exists when you call OpenDSObject.

ADSI fast binds are useful when you need to make a lot of updates to objects that you know exist (perhaps from an ADO query that returned a list of DNs) and you do not need any IADs-specific interfaces. Instead of two trips over the network per object binding, there would be only one.

MSDN: Using Concurrent Binding; MSDN: ADS_AUTHENTICATION_ENUM

You want to bind to a container using its globally unique identifier (GUID).

Each object in Active Directory has a GUID associated with it, stored in the objectGUID attribute. The GUID is, for most purposes, a unique identifier that retains its value even if an object is updated, renamed, or moved. This makes the GUID the preferable means of binding to an object, rather than hardcoding a reference to an object name that might change or by using a potentially complex LDAP query.

“‘GUIDs’ or ‘Having unique in the name doesn’t make it so...’” for a more in-depth discussion of the objectGUID attribute; MSDN: IADs.GUID; MSDN: Using objectGUID to Bind to an Object; Connecting to a Well-Known GUID

You want to connect to LDAP using one of the well-known GUIDs in Active Directory.

The Domain NC in Active Directory contains a number of well-known GUIDs that correspond to containers that exist in every AD implementation. These GUIDs are stored as wellKnownObjects attributes within the <DomainDN> object, and they allow administrators and developers to consistently connect to critical containers even if they are moved or renamed. The <DomainDN> container possesses the following objects that correspond to well-known GUIDs:

The Configuration NC adds these additional WKGUIDs:

MSDN: Binding to Well-Known Objects Using WKGUID

You want to find objects in a domain that match certain criteria.

Most tools that can be used to search Active Directory require a basic understanding of how to perform LDAP searches using a base DN, search scope, and search filter, as described in RFC 2251 and RFC 2254. The base DN is where the search begins in the directory tree. The search scope defines how far down in the tree to search from the base DN. The search filter is a prefix notation string that contains equality comparisons of attribute and value pairs.

The scope can be base, onelevel (or one), or subtree (or sub). A base scope will match only the base DN, onelevel will match only objects that are contained directly under the base DN, and subtree will match everything from the base DN and any objects beneath it.

The search filter syntax is a powerful way to represent simple and complex queries. For example, a filter that matches all of the user objects would be (&(objectclass=user)(objectcategory=Person)). For more information on filters, see RFC 2254.

Viewing the Attributes of an Object for viewing attributes of objects; Searching the Global Catalog for setting advanced ADO options; RFC 2251 (Lightweight Directory Access Protocol [v3]); RFC 2254 (Lightweight Directory Access Protocol [v3]); “LDAP Query Basics”

You want to perform a forest-wide search using the global catalog.

The global catalog facilitates forest-wide searches. When you perform a normal LDAP search over port 389, you are searching against a particular partition within Active Directory, whether that is the Domain naming context, Configuration naming context, Schema naming context, or an application partition. If you have multiple domains in your forest, this type of search will not search against all domains; it will search only the domain that you specify.

The global catalog, by contrast, contains a subset of the attributes for all objects in the forest (excluding objects in application partitions). Think of it as a subset of all the naming contexts combined. Every object in the directory will be contained in the global catalog (except for objects contained within application partitions), but only some of the attributes of those objects will be available. For that reason, if you perform a global catalog search and do not get values for attributes you were expecting to, make sure those attributes are included in the global catalog, also known as the partial attribute set (PAS). See Modifying the Set of Attributes Stored on a Global Catalog for more information on adding information to the PAS. As an alternative, you can query a DC within the domain containing the object to return a list of all attributes configured for that object. Note that the Active Directory Administrative Center provides a method to easily change the scope of a search to be a global catalog search.

Searching for Objects in a Domain for searching for objects; Modifying the Set of Attributes Stored on a Global Catalog

Your search is returning exactly 1,000 objects, which is only a subset of the objects you expected, and you want it to return all matching objects.

You might notice, when using some tools, that searches with large numbers of matches stop displaying after 1,000. By default, domain controllers return a maximum of 1,000 entries from a search unless paging is enabled. This is done to prevent queries from consuming excessive resources on domain controllers by retrieving the results all at once instead of in pages or batches. The following examples are variations of Searching for Objects in a Domain, which will show how to enable paging and return all matching entries.

> dsquery * <BaseDN> -limit 0 -scope <Scope> -filter "<Filter>" -attr "<AttrList>"

Get-ADObject -SearchBase "cn=users,dc=adatum,dc=com" -Filter * -ResultSetSize 12000

Paged searching support is implemented via an LDAP control. LDAP controls were defined in RFC 2251 and the Paged control in RFC 2696. Controls are extensions to LDAP that were not built into the protocol, so not all directory vendors support the same ones.

Active Directory will return a maximum of 256 KB of data even when paged searching is enabled. This value is defined in the LDAP query policy and can be modified like the maximum page size (see Modifying the Default LDAP Query Policy).

Searching for Objects in a Domain for searching for objects; Modifying the Default LDAP Query Policy for viewing the default LDAP policy; RFC 2251 (Lightweight Directory Access Protocol [v3]); RFC 2696 (LDAP Control Extension for Simple Paged Results Manipulation)

You want to perform a search using an individual value within a multivalued attribute as part of the search criteria. An attribute-scoped query can do this in a single query, instead of the previous method, which required multiple queries.

When dealing with group objects, you may have encountered the problem where you wanted to search against the members of a group to find a subset or to retrieve certain attributes about each member. This normally involved performing a query to retrieve all of the members, and additional queries to retrieve whatever attributes you needed for each member. This was less than ideal, so an alternative was developed.

With an attribute-scoped query, you can perform a single query against the group object and return whatever properties you need from the member’s object, or return only a subset of the members based on certain criteria. Let’s look at the LDAP search parameters for an attribute-scoped query:

When performing an attribute-scoped query against a member attribute, it’s important to remember that primary group membership is handled as a special case; as such you may experience unpredictable results in this situation.

Using LDAP Controls; MSDN: Performing an Attribute Scoped Query

You want to search against an attribute that contains a bit flag, which requires you to use a bitwise filter to perform the search.

Many attributes in Active Directory are composed of bit flags. A bit flag is often used to encode properties about an object into a single attribute. For example, the groupType attribute on group objects is a bit flag that is used to determine the group scope and type.

The userAccountControl attribute on user and computer objects is used to describe a whole series of properties, including account status (i.e., enabled or disabled), account lockout, password not required, smartcard authentication required, and so on.

The searchFlags and systemFlags attributes on attributeSchema objects define, among other things, whether an attribute is constructed, indexed, and included as part of Ambiguous Name Resolution (ANR).

To search against these types of attributes, you need to use bitwise search filters. There are two types of bitwise search filters you can use, one that represents a logical OR and one that represents a logical AND. This is implemented within a search filter as a matching rule. A matching rule is simply a way to inform the LDAP server (in this case, a domain controller) to treat part of the filter differently. Here is an example of what a matching rule looks like:

(userAccountControl:1.2.840.113556.1.4.803:=514)

The format is (attributename:MatchingRuleOID:=value), though AdFind allows you to use an easier syntax for bitwise queries. As mentioned, there are two bitwise matching rules, which are defined by OIDs. The logical AND matching rule OID is 1.2.840.113556.1.4.803, and the logical OR matching rule OID is 1.2.840.113556.1.4.804. These OIDs instruct the server to perform special processing on the filter. A logical OR filter will return success if any bit specified by value is stored in attributename. Alternatively, the logical AND filter will return success if all bits specified by value match the value of attributename. Perhaps an example will help clarify this.

To create a normal user account, you have to set userAccountControl to 514. The number 514 was calculated by adding the normal user account flag of 512 together with the disabled account flag of 2 (512 + 2 = 514). If you use the following logical OR matching rule against the 514 value, as shown here:

(useraccountcontrol:1.2.840.113556.1.4.804:=514)

then all normal user accounts (flag 512) OR disabled accounts (flag 2) would be returned. This would include enabled user accounts (from flag 512), disabled computer accounts (from flag 2), and disabled user accounts (from flag 2). In the case of userAccountControl, flag 2 can apply to both user and computer accounts, which is why both would be included in the returned entries.

One of the benefits of bitwise matching rules is that they allow you to combine a bunch of comparisons into a single filter. In fact, it may help to think that the OR filter could also be written using two expressions:

(|(useraccountcontrol:1.2.840.113556.1.4.804:=2)
(useraccountcontrol:1.2.840.113556.1.4.804:=512))

Just as before, this will match userAccountControl attributes that contain either the 2 or 512 flag; we’re performing two OR operations against the same value, first ORing the value against 2, then against 512.

For the logical AND operator, similar principles apply. Instead of any of the bits in the flag being a possible match, all of the bits in the flag must match for it to return a success. If the userAccountControl example was changed to use logical AND, it would look like this:

(useraccountcontrol:1.2.840.113556.1.4.803:=514)

In this case, only normal user accounts that are also disabled would be returned. The same filter could be rewritten using the & operator instead of | as in the following:

(&(useraccountcontrol:1.2.840.113556.1.4.803:=2)
(useraccountcontrol:1.2.840.113556.1.4.803:=512))

An important subtlety to note is that when you are comparing only a single bit-flag value, the logical OR and logical AND matching rules would return the same result. So, if you wanted to find any normal user accounts, you could search on the single bit flag of 512 using either of the following:

(useraccountcontrol:1.2.840.113556.1.4.803:=512)

(useraccountcontrol:1.2.840.113556.1.4.804:=512)

MSDN: Enumerating Groups by Scope or Type in a Domain; MSDN: Determining Which Properties Are Non-Replicated, Constructed, Global Catalog, and Indexed; MS KB 305144 (How to Use the UserAccountControl Flags to Manipulate User Account Properties)

You want to create an object.

In each solution in this recipe, an example of adding a user object is shown. Modify the examples as needed to include whatever class and attributes you need to create.

dn: cn=jsmith,cn=users,dc=adatum,dc=com
changetype: add
objectClass: user
samaccountname: jsmith

> ldifde -v -i -f create_object.ldf

> admod -b "cn=Joe Smith,cn=users,dc=adatum,dc=com" objectclass::user samaccountname::jsmith -add

New-ADObject -Path "OU=Workstations,dc=adatum,dc=com" -Type Computer -Name "Kiosk2" -Description "Computer in lobby" -OtherAttributes @{SamAccountName="Kiosk2"}

To create an object in Active Directory, you have to specify the objectClass, RDN value, and any other mandatory attributes that are not automatically set by Active Directory. Some of the automatically generated attributes include objectGUID, instanceType, and objectCategory.

In the jsmith example, the object class was user, the RDN value was jsmith, and the only other attribute set was sAMAccountName. Admittedly, this user object is unusable in its current state because it will be disabled by default and no password was set, but it should give you an idea of how to create an object. In the case of a user object, you’ll need to configure a password that meets any existing password complexity requirements before enabling the user.

Exporting Objects to an LDIF File; Importing Objects Using an LDIF File for importing objects with LDIF; MSDN: IADsContainer::GetObject; MSDN: IADsContainer::Create; MSDN: IADs::Put; MSDN: IADs::SetInfo

You want to modify one or more attributes of an object.

The following example sets the employeeID attribute for a user object.

dn: cn=jsmith,cn=users,dc=adatum,dc=com
changetype: modify
replace: employeeID
employeeID: 17320
-

> ldifde -v -i -f modify_object.ldf

> admod -b <ObjectDN> <attribute>:<operation>:<value>

> admod -b cn="Joe Smith,cn=Users,dc=adatum,dc=com" description::Consultant

Set-ADObject -Identity <"ObjectDN"> -Replace @{<property>=<"value">}

MSDN: IADs::Put; MSDN: IADs::PutEx; MSDN: IADs::SetInfo; MSDN: ADS_ PROPERTY_OPERATION_ENUM

You want to safely modify an attribute that contains a bit flag, without blindly overwriting its existing contents. The solutions in this recipe modify a new attribute named adatum-UserProperties that was previously added to the schema.

Searching with a Bitwise Filter described how to search against attributes that contain a bit flag, which is used to encode various settings about an object in a single attribute. As a quick recap, you need to use a logical OR operation to match any bits being searched against, and a logical AND to match a specific set of bits. If you want to set an attribute that is a bit flag, you need to take special precautions to ensure that you don’t overwrite an existing bit. Let’s consider an example. Adatum wants to secretly store some politically incorrect information about their users, such as whether the user is really old or has big feet. They don’t want to create attributes such as adatum-UserHasBigFeet, so they decide to encode the properties in a single bit-flag attribute. They decide to call the attribute adatum-UserProperties with the possible bit values shown in Table 4-3.

After they extend the schema to include the new attribute, Adatum needs to initially populate the attribute for all their users. To do so they can simply logically OR the values together that apply to each user. So, if settings 4 and 8 apply to the jsmith user, his adatum-UserProperties would be set to 12 (4 OR 8). No big deal so far. The issue comes in when they need to modify the attribute in the future.

They later find out that jsmith was a former basketball player and is 6′8″. They need to set the 2 bit (for being tall) in his adatum-UserProperties attribute. To set the 2 bit they need to first determine whether it has already been set. If it has already been set, then there is nothing to do. If the 2 bit hasn’t been set, they need to logical OR 2 with the existing value of jsmith’s adatum-UserProperties attribute. If they simply set the attribute to 2, it would overwrite the 4 and 8 bits that had been set previously. In the VBScript solution, they could use the CalcBit function to determine the new value:

intBitsCalc = CalcBit(intBitsOrig, 2, TRUE)

The result would be 14 (12 OR 2).

The same logic applies if they want to remove a bit, except the XOR logical operator is used.

You should note that it’s certainly possible to modify bitwise attributes using a GUI tool like ADSI Edit or a command-line tool like DSMod. However, it will require a certain amount of manual effort, as you’ll first need to make note of the existing attribute value and then calculate the new value using a calculator or some other method. The VBScript solution presented here simply automates that process by performing the lookup and calculations for you.

Searching with a Bitwise Filter for searching with a bitwise filter

You want to dynamically link an auxiliary class to an existing object instance.

In each solution in this recipe, an example of adding the custom adatum-SalesUser auxiliary class to the jsmith user object will be described.

dn: cn=jsmith,cn=users,dc=adatum,dc=com
changetype: modify
add: objectClass
objectClass: adatum-SalesUser
-

> ldifde -v -i -f dynamically_link_class.ldf

> admod -b <ObjectDN> objectClass:+:<Dynamic Object Class>

Set-ADObject -Identity "cn=jsmith,cn=users,dc=adatum,dc=com" -Add @{ObjectClass="adatum-SalesUser"}

Dynamically linking an auxiliary class to an object is an easy way to use new attributes without modifying the existing object class definition in the schema.

A situation in which it makes more sense to dynamically link auxiliary classes than to link them statically is when several organizations or divisions within a company maintain their own user objects and want to add new attributes to the user class.

It is also worth mentioning that extensive use of dynamically linked auxiliary classes can lead to problems. If several groups are using different auxiliary classes, it might become hard to determine what attributes you can expect on your user objects. Essentially, you could end up with many variations of a user class that each group has implemented through the use of dynamic auxiliary classes. For this reason, use of dynamic auxiliary classes should be closely monitored. In addition, some tools that access Active Directory may not work properly with auxiliary classes.

Modifying an Object for modifying an object

You want to create an object that is automatically expired and removed from the directory after a period of time.

The ability to create dynamic objects allows you to create objects that have a limited lifespan before they are automatically removed from the directory. To create a dynamic object, you simply need to specify the objectClass to have a value of dynamicObject in addition to its structural objectClass (e.g., user) value when instantiating the object. The entryTTL attribute can also be set to the number of seconds before the object is automatically deleted. If entryTTL is not set, the object will use the dynamicObjectDefaultTTL attribute specified in the domain. The entryTTL cannot be lower than the dynamicObjectMinTTL for the domain. See Modifying the Default TTL Settings for Dynamic Objects for more information on how to view and modify these default values.

Dynamic objects have a few special properties worth noting:

Refreshing a Dynamic Object for refreshing a dynamic object; Modifying the Default TTL Settings for Dynamic Objects for modifying the default dynamic object properties

You want to refresh a dynamic object to keep it from expiring and getting deleted from Active Directory.

In each solution in this recipe, an example of adding a user object is used. Modify the examples as needed to refresh whatever object is needed.

dn: cn=jsmith,cn=users,dc=adatum,dc=com
changetype: modify
replace: entryTTL
entryTTL: 1800
-

> ldifde -v -i -f refresh_dynamic_object.ldf

> admod -b <ObjectDN> entryTTL::<TTL in Seconds>

Set-ADObject -Identity "cn=jsmith,cn=users,dc=adatum,dc=com" -Replace @{entryTTL="1800"}

Dynamic objects expire after their TTL becomes 0. You can determine when a dynamic object will expire by looking at the current value of an object’s entryTTL attribute or by querying msDS-Entry-Time-To-Die, which contains the seconds remaining until expiration. If you’ve created a dynamic object and need to refresh it so that it will not get deleted, you must reset the entryTTL attribute to a new value. There is no limit to the number of times you can refresh a dynamic object. As long as the entryTTL value does not reach 0, the object will remain in Active Directory.

Modifying an Object for modifying an object; “Dynamic Objects (Windows)”; Creating a Dynamic Object for creating a dynamic object

You want to modify the minimum and default TTLs for dynamic objects.

In each solution in this recipe, we’ll show how to set the DynamicObjectDefaultTTL setting to 172800. Modifying the DynamicObjectMinTTL can be done in the same manner.

> ntdsutil "config settings" connections "connect to server <DomainControllerName>" q "show values" "set DynamicObjectDefaultTTL to 172800""commit changes"
"show values" q q

Two configuration settings apply to dynamic objects:

Unfortunately, these two settings are not stored as discrete attributes. Instead, they are stored as attribute value assertions (AVAs) in the msDS-Other-Settings attribute on the cn=DirectoryServices,cn=WindowsNT,cn=Configuration,<ForestRootDN> object. AVAs are used occasionally in Active Directory on multivalued attributes, in which the values take the form of Setting1=Value1,Setting2=Value2, and so on.

For this reason, you cannot simply manipulate AVA attributes as you would another attribute. You have to be sure to add or replace values with the same format, as they existed previously.

Modifying an Object for modifying an object; MSDN: Regular Expression (RegExp) Object