The following list shows many of the LDAP controls that Active Directory supports with relation to searching, as well as how to use the more common controls with AdFind:
Specifying this LDAP control instructs the domain controller that it can return more results than can fit in a single page. This is useful when searching for large result sets and should generally always be included in an Active Directory search.
DirSync is an LDAP feature that allows you to ask Active Directory for all the objects in a given naming context that have changed since the last time the search was performed. Changes are tracked with a cookie that is returned by the server.
The DirSync control will only return modified attributes. If you want to return the full object when any attribute of that object has been modified, and you are running
Windows Server 2012 or later, use the LDAP_SERVER_DIRSYNC_EX_OID (1.2.840.113522.214.171.1240) version of this control instead.
Applications such as Microsoft Forefront Identity Manager (FIM) use the DirSync LDAP feature to track changes. For more information on this feature, refer to this link.
To make sure that the domain controller does not return referrals to result sets that are stored on other servers, include this LDAP control in your request.
When this LDAP control is enabled, Active Directory will return the SID and objectGUID of each result as prefixes to the object’s DN in the result set. For more information, refer to this link.
This extremely useful LDAP control instructs Active Directory to return statistics about how the query processor will perform the requested search, as well as per‐ formance statistics about the result. We’ll discuss this feature in more detail later in this chapter.
When this control is specified, Active Directory won’t return a result until the re‐ quested object is modified. This is useful for tracking changes to specific objects in the directory and responding to them. For more information, refer to this link.
Similar to the paged results control mentioned earlier, this is typically a control you will always want to specify. The ranged results control is used when you need to retrieve values in a multivalued attribute in excess of the maximum number of values a DC will return by default. You can use the LDAP_SERVER_RANGE_RETRIEV AL_NOERR_OID (1.2.840.1135126.96.36.1998) alternate implementation of this LDAP control to ensure that errors will not be returned if you request more values than are available.
Use this control to tell the domain controller which components of an object’s ntSecurityDescriptor (the ACL) to retrieve. Depending on the permissions of the user performing the query, not all of the components of the ACL may be read‐ able. For more information, refer to this link.
This generic control’s most useful function is called phantom root. The phantom root feature enables you to perform a search across all of the naming contexts (application NCs excluded) hosted on a global catalog. If you have a multidomain
forest with disjointed namespaces, use this control to search across all of the do‐ mains at once. Use the -pr switch to enable this function in AdFind.
This control instructs the domain controller to include deleted objects and tomb‐ stones in the result set. If you have enabled the Active Directory Recycle Bin, this will only include objects that are currently recoverable. To include objects that have transitioned out of the Recycle Bin, you must also include the LDAP_SERV ER_SHOW_RECYCLED_OID (1.2.840.1135188.8.131.524) control.
Active Directory treats deactivated linked values (links to objects that are in the Recycle Bin) differently. If you want to include deactivated links in your results, add the LDAP_SERVER_SHOW_DEACTIVATED_LINK_OID (1.2.840.1135184.108.40.2065) con‐ trol.
To include deleted objects in AdFind, append the -showdel switch. If you also want to include objects that have transitioned out of the Recycle Bin, also append the -showrecycled switch. To include deactivated links, append -showdelobjlinks.
This control instructs the server to sort the results based on one attribute before returning the result set. You can request search results to be sorted with AdFind by using the -sort and -rsort (reverse order) parameters. This document provides a great deal more information about sorting, especially with regard to the language- specific ordering of a result set and phonetic sort functionality on Japanese- language domain controllers.
Server-side sorting requires the use of a temporary table in the Active Directory database when the attribute being sorted on is not indexed. Temporary tables are limited in size. Consequently, server-side sorting of large result sets with unindexed attributes will likely fail due to the size constraints of the temporary table.
Virtual list view (VLV) searches are useful for large searches that will be paged through in a format similar to scrolling through an address book or phone directory. In fact, some versions of Microsoft Exchange use VLV for building the address books shown in email clients. For more information, refer to this link.
Attribute scoped queries (ASQs) are useful when you want to perform a query based on a linked attribute’s value(s). For example, you might want to return all of the users who are members of a group called All Users. You can do this using AdFind with this syntax:
adfind -asq member -b "cn=All Users,ou=Groups,dc=cohovines,dc=com" -f "objectClass=user"
- Alfresco Cluster Properties (for Hazelcast)
- Alfresco User Attributes
- LDAP userAccountControl Values
- LDAP Error table
- LDAP Alfresco (global properties)
- Alfresco in a Perth Summer
- GreenScreen Updates
- [MAP] Housing Offices… in progress
- Selection Criteria – Which one got me a job and which one didnt?
- Case Law in the Office