Ldp.exe: LDP Tool Options

codeling 1264 - 5430
@2016-12-30 22:53:30

Searching for Objects

The LDP utility is very useful for searching and filtering on specific objects if you understand its query syntax.

When you click Search on the Browse menu, a dialog box is displayed in which you can set the Base DN, Filter, and Scope settings for your query.

The Base DN setting defines where in the directory tree the search begins. If you use the file system folder analogy, the Base DN setting defines the subfolder at which the search begins. The most commonly used base DN for an Active Directory search is the CN=Users,DC=.... container.

NOTE: You can cut and paste from RootDSE information or other results information to avoid typing long base DN values.

The Scope setting determines how far down in the directory tree to search. By default, the Scope is set to One Level, which is like searching the current folder in a file system. A one level search does not include the base DN object itself. To see the attributes of the base DN object, you must set the Scope to Base, or double-click the Base object in the directory tree view. If you set the Scope to Subtree, it is like searching the current folder and all of the subfolders of a file system.

The Filter box allows you to construct queries. The following table lists the most commonly used LDAP query operators.

&	logical and 
|	logical or  
!	logical not
=	equal to 
~=	approximately equal to
>=	equal to or greater than
<=	less than or equal to
					

Most people find that the syntax of LDAP queries takes some getting used to, because operators are usually placed before rather than between operands. If an LDAP query expresses 2 + 2 = 4, it is written (+(2)(2)) = 4.

All of the query filters are enclosed by opening and closing parentheses. Complex filters often contain several nested levels of parentheses. You must be sure that you supply all of the required parentheses, or your search does not work.

The logical AND and OR operators always refer to two or more search terms, and are placed before the terms that they affect. A simple visual rule may help you use AND and OR correctly; AND and OR should always be immediately followed by an open parenthesis, rather than placed directly next to an attribute name.

For example, if you want to search for all of the users who have first names of John AND last names of either Smith OR Jones, the filter is similar to the following:

(&(objectClass=user)(givenName=John)(|(sn=Smith)(sn=Jones)))
					

The ! sign (the NOT operator) can be applied to a single term, as in the following example:

(&(objectClass=user)(sn=Jones)(!givenName=John)(!givenName=Jane)(!logonCount<=100))
					

The above filter finds users who have the surname Jones whose given name is neither John nor Mary and who have logged on no less than 101 times.

Queries also support asterisk wildcards. The following search returns all of the users who have surnames that start with the letter J:

(&(objectClass=user)(sn=j*))
					

The LDP utility searches are not case sensitive, and you can search by using leading and trailing asterisks (*string*) to find substrings in the middle of a value. Such searches take much longer to complete. When possible, use either a leading or trailing wildcard character, but not both.

You can use a wildcard by itself to test for the existence or absence of a given attribute. If you want to find all of the users who do not have an Exchange Server mailbox, you can find them by using the following query because these users lack an msExchHomeServerName value:

(&(objectClass=user)(!msExchHomeServerName=*))
					

The escape character in a query is the backslash (\). This is a reserved character, along with * ( ) and NUL. To search for reserved characters as part of an attribute value, you must precede the reserved characters with the escape character and one of the following numeric codes for each reserved character:

*     2a
(     28
)     29
\     5c
NUL   00
					

For example, if you want to search for all of the users whose display names end in a close parenthesis character, use the following search:

(&(objectClass=user)(displayName=*\29))
					

If you want to find users whose home directories are G:\Accounting, use the following search:

(&(objectClass=user)(home-directory=G:\5cACCOUNTING*))
					

In an LDAP query, a backslash always signifies an escape character, never an actual backslash.

If you are interested in only a particular attribute or few attributes, you can filter the rest so that they are not displayed in the results window by clicking Options in the Search dialog box. In Options, list the attributes that you want to be displayed, and separate each with a semicolon. For example:

msExchHomeServerName;DisplayName;Home-Directory;

If you leave the Attributes list blank or if it is an asterisk, all of the attributes to which you have access are displayed for every object returned by a query.

NOTE: The LDP utility does not separate the objects that are returned by a query with a blank line. When you look through search results, look for the leading >> characters to indicate the beginning of the next object in the list.


codeling 1264 - 5430
@2016-12-30 22:58:04

How to Tell If an Attribute Is Already Indexed

There are several ways to check to see if an attribute is already indexed or not.  I would first suggest searching MSDN for the default schema definition for that attribute.  A comprehensive list is here.

An alternate method, one that is more definitive for your individual environment, would be to look at that schema attribute using LDP.EXE.  The basic idea is that if the searchFlags value is 1 then the attribute will be indexed, like below:

Viewing Whether Indexed in LDP

Search-Flags attribute

This attribute can be zero or a combination of one or more of the following values.

Value Description
1 (0x00000001) Create an index for the attribute.
2 (0x00000002) Create an index for the attribute in each container.
4 (0x00000004) Add this attribute to the Ambiguous Name Resolution (ANR) set. This is used to assist in finding an object when only partial information is given. For example, if the LDAP filter is (ANR=JEFF), the search will find each object where the first name, last name, email address, or other ANR attribute is equal to JEFF. Bit 0 must be set for this index take affect.
8 (0x00000008) Preserve this attribute in the tombstone object for deleted objects.
16 (0x00000010) Copy the value for this attribute when the object is copied.
32 (0x00000020) Create a tuple index for the attribute. This will improve searches where the wildcard appears at the front of the search string. For example, (sn=*mith).
64(0x00000040) Supported beginning with ADAM. Creates an index to greatly help VLV performance on arbitrary attributes.
128 (0x00000080) Mark attribute as confidential. Ignored for base schema attributes (systemFlags=0x10).
64 (0x00000040) Supported beginning with Windows Server 2008. Create an index to improve VLV search performance on this attribute.

codeling 1264 - 5430
@2017-01-14 09:02:26

The following filter can be used to find accounts created bwtween Jan. 1, 2017 and Jan. 10, 2017 UTC (Coordinated Universal Time):

(&(objectCategory=Person)(objectClass=User)(whenCreated>=20170101000000.0Z)(whenCreated<=20170110000000.0Z))

The key to making it work is the syntax of the whenCreated portion of the LDAP query, which breaks down like this:

YYYY MM DD HH mm ss.s Z
2017 01 01 00 00 00.0 Z

“0Z” indicates that there’s no time differential from GMT. (The “Z,” incidentally, stands for Zulu, which is a nickname for UTC.) It’s important to note that the value of this attribute is stored in AD in the form of UTC time, so you might need to take your time zone and daylight saving time (DST) differentials into account when evaluating or querying this attribute.

Users browsing this topic
Guest