- AD에서 LDAP Query 테스트 방법  : 
   1. "Active Directory 사용자 및 컴퓨터" Tool에서 Domain을 선택 후 ( 하위 메뉴에서도 가능 ) 오른쪽 마우스를 클릭하여 "찾기" 메뉴를 클릭 
   2. "사용자,연락처, 그룹 찾기" 창이 팝업 메뉴로 출력
   3. 찾기 메뉴에서 "사용자 지정 검색" 선택 
   4. "고급" 탭을 클릭하면 "LDAP 쿼리 입력" TextBox가 나오며 LDAP Query 입력 후 "지금 찾기"를 클릭하면 LDAP Query를 테스트 할 수 있다.
   5. "보기" 메뉴의 "열 선택..." 메뉴를 클릭하면 검색 결과 창에 나오는 필드를 선택할 수 있으며 "X500 고유 이름" 을 추가하면 LDAP 고유 값을 확인할 수 있다.

- LDAP 문법
   & : AND , | : OR 조건이며 
   ()를 기준으로 묶어 가며 AND OR를 적용한다.

- LDAP Filter Query 
  1. 특정 ID의 사용자 검색
      - (&(sAMAccountName={0})(objectclass=user))
        AD 의 사용자 로그인 이름이 {0} ( 위 값은 Spring Security에서 입력된 ID 값으로 대체 됨 )인 사용자를 검색
  2. 특정 ID이며 특정 그룹에 속하는 사용자 검색
      - (&(sAMAccountName={0})(|(memberOf=CN=B3 Approval,CN=Users,DC=dev,DC=247realmedia,DC=local)(memberOf=CN=B3 Reader,CN=Users,DC=dev,DC=247realmedia,DC=local)))
        memberOf 는 특정 Group의 멤버 여부를 체크한다. 따라서 위의 문법은 B3 Approval 이나 B3 Reader Group의 member이며 sAMAccountName ( AD의 사용자 로그인 이름 ) 이 {0}인 사용자를 검색한다.

& : and

| : or

= : equal

! : not

>= , <= 같은 비교문도 사용 가능

사용예)

- cn 값이 aaa가 아닌 개체 검색

(&(!cn=aaa))

- 사용자 개체 속성 중 메일 주소가 @aaa.com으로 끝나는 사용자 검색

(&(objectCategory=user)(mail=*@aaa.com))

- AD에서 LDAP Query 테스트 방법  : 
   1. "Active Directory 사용자 및 컴퓨터" Tool에서 Domain을 선택 후 ( 하위 메뉴에서도 가능 ) 오른쪽 마우스를 클릭하여 "찾기" 메뉴를 클릭

 
   2. "사용자,연락처, 그룹 찾기" 창이 팝업 메뉴로 출력

   3. 찾기 메뉴에서 "사용자 지정 검색" 선택

   4. "고급" 탭을 클릭하면 "LDAP 쿼리 입력" TextBox가 나오며 LDAP Query 입력 후 "지금 찾기"를 클릭하면 LDAP Query를 테스트 할 수 있다.

   5. "보기" 메뉴의 "열 선택..." 메뉴를 클릭하면 검색 결과 창에 나오는 필드를 선택할 수 있으며 "X500 고유 이름" 을 추가하면 LDAP 고유 값을 확인할 수 있다.

- 쿼리 만드는 방법

(ADSI EDIT 를 이용해서 쿼리를 만드는 방법을 소개한다.)

1. 시작 - 실행 - adsiedit.msc (없는 경우 MS사이트에서 다운받아 설치한다.)

2. 동작 - 연결대상을 클릭하여 기본 명명 컨텍스트를 만든다.

3. 생성된 기본 명명 컨텍스트에서 마우스 오른쪽 클릭하여 새로 만들기 - 쿼리를 선택

4. 검색 루트를 선택한 후 쿼리 편집을 통해 원하는 조건을 설정한다.

   예) 사용자 지정 검색 -> 필드 클릭 -> 사용자 - 로그온 이름 선택 -> 조건(정확히 일치) 선택 ->

         검색할 값을 선택 -> 조건 목록으로 추가 -> 확인

         쿼리 문자열에 다음과 같이 표시됨 : (&(objectCategory=user)(objectClass=user)(userPrincipalName=))

5. 쿼리 문자열에 쿼리가 표시됨

http://msdn.microsoft.com/en-us/library/aa746475%28v=vs.85%29.aspx 

Search Filter Syntax

Search filters enable you to define search criteria and provide more efficient and effective searches.

ADSI supports the LDAP search filters as defined in RFC2254. These search filters are represented by Unicode strings. The following table lists some examples of LDAP search filters.

These search filters use one of the following formats.

<filter>=(<attribute><operator><value>)

or

(<operator><filter1><filter2>)

The ADSI search filters are used in two ways. They form a part of the LDAP dialect for submitting queries through the OLE DB provider. They are also used with the IDirectorySearch interface.

Operators

The following table lists frequently used search filter operators.

In addition to the operators above, LDAP defines two matching rule object identifiers (OIDs) that can be used to perform bitwise comparisons of numeric values. Matching rules have the following syntax.

<attribute name>:<matching rule OID>:=<value>

"<attribute name>" is the lDAPDisplayName of the attribute, "<rule OID>" is the OID for the matching rule, and "<value>" is the value to use for comparison. Be aware that spaces cannot be used in this string. "<value>" must be a decimal number; it cannot be a hexadecimal number or a constant name such as ADS_GROUP_TYPE_SECURITY_ENABLED.

The following table lists the matching rule OIDs implemented by LDAP.

The following example query string searches for group objects that have the ADS_GROUP_TYPE_SECURITY_ENABLED flag set. Be aware that the decimal value of ADS_GROUP_TYPE_SECURITY_ENABLED (0x80000000 = 2147483648) is used for the comparison value.

(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483648))

The LDAP_MATCHING_RULE_IN_CHAIN is a matching rule OID that is designed to provide a method to look up the ancestry of an object. Many applications using AD and AD LDS usually work with hierarchical data, which is ordered by parent-child relationships. Previously, applications performed transitive group expansion to figure out group membership, which used too much network bandwidth; applications needed to make multiple roundtrips to figure out if an object fell "in the chain" if a link is traversed through to the end.

An example of such a query is one designed to check if a user "user1" is a member of group "group1". You would set the base to the user DN (cn=user1, cn=users, dc=x) and the scope to base, and use the following query.

(memberof:1.2.840.113556.1.4.1941:=(cn=Group1,OU=groupsOU,DC=x))

Similarly, to find all the groups that "user1" is a member of, set the base to the groups container DN; for example (OU=groupsOU, dc=x) and the scope to subtree, and use the following filter.

(member:1.2.840.113556.1.4.1941:=(cn=user1,cn=users,DC=x))

Note that when using LDAP_MATCHING_RULE_IN_CHAIN, scope is not limited—it can be base, one-level, or subtree. Some such queries on subtrees may be more processor intensive, such as chasing links with a high fan-out; that is, listing all the groups that a user is a member of. Inefficient searches will log appropriate event log messages, as with any other type of query.

Wildcards

You can also add wildcards and conditions to an LDAP search filter. The following examples show substrings that can be used to search the directory.

Get all entries:

(objectClass=*)

Get entries containing "bob" somewhere in the common name:

(cn=*bob*)

Get entries with a common name greater than or equal to "bob":

(cn>='bob')

Get all users with an email attribute:

(&(objectClass=user)(email=*))

Get all user entries with an email attribute and a surname equal to "smith":

(&(sn=smith)(objectClass=user)(email=*))

Get all user entries with a common name that starts with "andy", "steve", or "margaret":

(&(objectClass=user)(| (cn=andy*)(cn=steve*)(cn=margaret*)))

Get all entries without an email attribute:

(!(email=*))

The formal definition of the search filter is as follows (from RFC 1960):

<filter> ::= '(' <filtercomp> ')'
<filtercomp> ::= <and> | <or> | <not> | <item>
<and> ::= '&' <filterlist>
<or> ::= '|' <filterlist>
<not> ::= '!' <filter>
<filterlist> ::= <filter> | <filter> <filterlist>
<item> ::= <simple> | <present> | <substring>
<simple> ::= <attr> <filtertype> <value> 
<filtertype> ::= <equal> | <approx> | <ge> | <le>
<equal> ::= '='
<approx> ::= '~='
<ge> ::= '>='
<le> ::= '<='
<present> ::= <attr> '=*'
<substring> ::= <attr> '=' <initial> <any> <final>
<initial> ::= NULL | <value>
<any> ::= '*' <starval>
<starval> ::= NULL | <value> '*' <starval>
<final> ::= NULL | <value>

The token <attr> is a string that represents an AttributeType. The token <value> is a string that represents an AttributeValue whose format is defined by the underlying directory service.

If a <value> must contain the asterisk (*), left parenthesis ((), or right parenthesis ()) character, the character should be preceded by the backslash escape character (\).

Special Characters

If any of the following special characters must appear in the search filter as literals, they must be replaced by the listed escape sequence.

Note  In cases where a MultiByte Character Set is being used, the escape sequences listed above must be used if the search is performed by ADO with the SQL dialect.

In addition, arbitrary binary data may be represented by using the escape sequence syntax by encoding each byte of binary data with the backslash (\) followed by two hexadecimal digits. For example, the four-byte value 0x00000004 is encoded as \00\00\00\04 in a filter string.

http://www.ldapexplorer.com/en/manual/109010000-ldap-filter-syntax.htm

LDAP Filter Syntax

This topic deals with the syntax and rules for an LDAP filter, which is a normal string which expresses the criteria for the filter. You need knowledge about LDAP filters if you want to search objects and filter objects in the LDAP browser LEX.

You can get even more information about LDAP filters in the SelfADSI scripting Tutorial article about LDAP filters.

Basic LDAP Filter Syntax and Operators

LDAP filters consist of one or more criteria. If one than more criterion exist in one filter definition, they can be concatenated by logical AND or OR operators. The logical operators are always placed in front of the operands (i.e. the criteria). This is the so-called 'Polish Notation'. 

The search criteria have to be put in parentheses and then the whole term has to be bracketed one more time.

The search criteria consist of a requirement for an LDAP attribute, e.g. (givenName=Sandra). Following rules should be considered:

Further rules:

Filtering for Hex Numbers and Binary Values

Filtering for Bit Fields

By using LDAP filters it's also possible to find objects for which a specific bit either is or is not set within a bit field. In this case, an strange looking syntax has to be followed:

   <Attribute name>:<BitFilterRule-ID>:=<decimal comparative value>

There are exactly two BitFilterRule IDs: One for bit-wise AND comparisons and one for bit-wise OR comparisons:

   LDAP_MATCHING_RULE_BIT_AND           1.2.840.113556.1.4.803
   LDAP_MATCHING_RULE_BIT_OR             1.2.840.113556.1.4.804 

An example:

For the attribute 'groupType' following bit mask is important in ADS group objects:

ADS_GROUP_TYPE_GLOBAL_GROUP     = 0x00000002
ADS_GROUP_TYPE_LOCAL_GROUP      = 0x00000004
ADS_GROUP_TYPE_UNIVERSAL_GROUP  = 0x00000008
ADS_GROUP_TYPE_SECURITY_ENABLED = 0x80000000

A filter for universal groups has to search for those objects in whose attributes the 4th least significant bit is set. This can be checked by equating the attribute of the value 0x00000008 (this represents the 4th bit) in an AND filter: 

Caution: In LDAP filters the hex value of the bit filter must be decimal at this point! So if all security groups (and not the distribution groups) are to be found, it has to be filtered for the 8th bit (0x80000000 = 2147483648):

An example for an OR filter: We search all users which don't need a password (userAccountControl is set on 0x20 - 32) or whose passwords never expires (userAccountControl is set on 0x10000 = 65536). So we have to build a filter with the value 65568 (=65536 + 32):

Please note that bit-wise filtering is a much more complex procedure for a server. For this reason you should take into consideration the use of normal equity criteria. If looking e.g. for universal security groups, the two flags 0x80000000 and 0x00000008 can be added up and then be filtered for the according decimal value 2147483656:

Please note that the LEX dialogs for editing LDAP Filters let's you set such bitmap filter syntaxes very easily.

Filtering with Ambiguous Name Resolution (ANR)

The Ambiguous Name Resolution is able to find users or contacts in Active Directory environments whose names are only partly known. In this case not only the object name but also the display name, first and last name as well as the diverse mail addresses are involved in the search. As an Outlook user you can have a look at the ANR filtering search by using e.g. the option 'Check names' for getting the best hit while searching for an address.

Which attributes are integrated exactly in the ANR search is specified by the attribute search flags in the directory schema. By doing so, a so-called ANR set of attributes is declared. Following attributes are part of the ANR set by default:

• Relative Distinguished Name (RDN), this could be for example the values for cn=.... or ou=...
• givenName (first name)
• sn (last name)
• displayName (display name)
• legacyExchangeDN (after migrations the Exchange 5.5 directory name of the old mailbox is shown here)
• proxyAddresses (mail addresses)
• physicalDeliveryOfficeName (office address)

The syntax of ANR filters is as follows:

   (anr=Philipp) or (anr=p f) or (anr=Foeck)

All these filters would find the user 'Foeckeler, Philipp'. The second one is able to find 'Philipp Foeckeler' as well as 'Fritz Paul'. This is because the ANR filter checks the first name and last name in both directions.