- 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.
| Search filter | Description |
|---|
| "(objectClass=*)" | All objects. |
| "(&(objectCategory=person)(objectClass=user)(!cn=andy))" | All user objects but "andy". |
| "(sn=sm*)" | All objects with a surname that starts with "sm". |
| "(&(objectCategory=person)(objectClass=contact)(|(sn=Smith)(sn=Johnson)))" | All contacts with a surname equal to "Smith" or "Johnson". |
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.
| Logical operator | Description |
|---|
| = | Equal to |
| ~= | Approximately equal to |
| <= | Lexicographically less than or equal to |
| >= | Lexicographically greater than or equal to |
| & | AND |
| | | OR |
| ! | NOT |
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.
| Matching rule OID | String identifier (from Ntldap.h) | Description |
|---|
| 1.2.840.113556.1.4.803 | LDAP_MATCHING_RULE_BIT_AND | A match is found only if all bits from the attribute match the value. This rule is equivalent to a bitwise AND operator. |
| 1.2.840.113556.1.4.804 | LDAP_MATCHING_RULE_BIT_OR | A match is found if any bits from the attribute match the value. This rule is equivalent to a bitwise OR operator. |
| 1.2.840.113556.1.4.1941 | LDAP_MATCHING_RULE_IN_CHAIN | This rule is limited to filters that apply to the DN. This is a special "extended match operator that walks the chain of ancestry in objects all the way to the root until it finds a match. |
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:
Get entries containing "bob" somewhere in the common name:
Get entries with a common name greater than or equal to "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:
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.
| ASCII character | Escape sequence substitute |
|---|
| * | \2a |
| ( | \28 |
| ) | \29 |
| \ | \5c |
| NUL | \00 |
| / | \2f |
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.
AND Operation:
(& (...K1...) (...K2...)) or with more than two criteria: (& (...K1...) (...K2...) (...K3...) (...K4...))
OR Operation:
(| (...K1...) (...K2...)) or with more than two criteria: (| (...K1...) (...K2...) (...K3...) (...K4...))
Nested Operation:
Every AND/OR operation can also be understood as a single criterion:
(|(& (...K1...) (...K2...))(& (...K3...) (...K4...))) means: (K1 AND K2) OR (K3 AND K4)
The search criteria consist of a requirement for an LDAP attribute, e.g. (givenName=Sandra). Following rules should be considered:
| Equality: | (attribute=abc) , e.g. (&(objectclass=user)(displayName=Foeckeler) |
| Negation: | (!(attribute=abc)) , e.g. (!objectClass=group) |
| Presence: | (attribute=*) , e.g. (mailNickName=*) |
| Absence: | (!(attribute=*)) , e.g. (!proxyAddresses=*) |
| Greater than: | (attribute>=abc) , e.g. (mdbStorageQuota>=100000) |
| Less than: | (attribute<=abc) , e.g. (mdbStorageQuota<=100000) |
| Proximity: | (attribute~=abc) , e.g. (displayName~=Foeckeler) Caution: ~= is treated as = in ADS environments !! |
| Wildcards: | e.g. (sn=F*) or (mail=*@cerrotorre.de) or (givenName=*Paul*) |
Further rules:
| Real attributes only | Only standard attributes can be used for LDAP filters. When specifying an LDAP search filter, you cannot use object properties of the ADSI objects that aren't LDAP database attributes but interface properties of the regarding object. A list of the affected properties can be viewed in the SelfADSI Scripting Tutorial under the topic 'Object Properties of ADSI Objects'.
|
| No quotation marks | Comparative strings do NOT appear in quotation marks. A filter for the displayName 'Philipp Foeckeler' would read as follows: (displayName=Philipp Foeckeler).
|
| Upper/lower case | If you want to filter boolean attributes the consideration of the upper/ lower case will be crucial. The use of TRUE or FALSE is absolutely necessary for filtering such booleans. However, most other string attributes are case-insensitiv, i.e. a hit will be found even if the upper and lower case differs from your search filter.
Especially in Exchange 5.5 directories most of the attributes are case sensitive. There are only few exceptions which can be viewed under the SelfADSI Scripting Tutorial topic 'Directory Attributes with CaseIgnoreString Syntax'.
|
DN-String attributes
| Regarding match algorithms of LDAP filters, LDAP directory systems comply with the specifications of the original X.500 standards. According to these matching rules you can't use wildcards in LDAP filters for attributes containing LDAP distinguished names (attributes with DN-string syntax / ADSI attribute data type ADSTYPE_DN_STRING = 1). The same applies for ADS: Filters in which DN attributes are searched with wildcards do not work.
This can be quite irritating. You can't e.g. search for all users that are members in groups that contain a certain string in their group names. The reason for this is that the user attribute memberOf has the data type DN-string.
Even more important could be the search for objects in a specific OU. Especially, when only the declaration of a pure filter string is allowed and when there is no possibility to specify the search base of an LDAP search. This might well be so e.g. for the definition of recipient policies in Microsoft Exchange environments. Thus, the following filter won't work!
(distinguishedName=*,ou=Sydney,dc=cerrotorre,dc=org)
In this case we have to use a script-based solution which provides a workaround for this LDAP filter limitation.
|
| Special characters | LDAP filters can be specified by unicode characters. You may, for example, use German umlauts - if it makes sense (if the filtered attribute is an unicode string). However, the characters ( ) & | = ! > < ~ * / \ play a special role for the declaration of LDAP filters.
If you search for or want to compare these characters within an attribute string, you'll have to use a prefixed backslash and the corresponding hexadecimal ASCII code:
| ( | \28 | | ) | \29 | | & | \26 | | | | \7c | | = | \3d | | > | \3e | | < | \3c | | ~ | \7e | | * | \2a | | / | \2f | | \ | \5c | | | |
An example: We want to retrieve all objects whose attributes "displayName" start with "*" :
(displayName=\2a)
The character zero (\00) may also be required occasionally.
|
| Multivalued attributes.... | It's also possible to filter for certain values in multivalue attributes. An example is the attribute objectClass. Due to the hierarchical structure of the directory schema, an object will always be an instance of several object classes. An ADS user e.g. is an object of the class types top, person, organizationalPerson und user. Thus, a filter could be:
(objectClass=user)
However, you need to take into consideration that such filtering always costs more server performance than an ordinary 'one-dimensional' attribute search does. |
Filtering for Hex Numbers and Binary Values
| Hex Numbers | In cases where attributes of the type integer or long integer are compared and filtered for specific hex numbers, the correspondent decimal coded number has always to be used in the LDAP filter. An example: If you look for local security groups in the ADS following two flags will have to be set for the groupType attribute:
ADS_GROUP_TYPE_LOCAL_GROUP (0x00000004)
ADS_GROUP_TYPE_SECURITY_ENABLED (0x80000000)
The addition of these values is the hex value 0x80000004, calculated in the decimal number 2147483652 - this has to be used in the LDAP filter:
(groupType=2147483652)
|
| Binary Values | It's a completely different thing if you want to compose filters for attributes whose data types appear as binary hex values (the according data type is often referred to as 'Octet String').
If you are going to filter for such binary attributes, it is mandatory to declare every single byte that has to be compared in hex code. For instance, if you search for objects with the attribute 'Inventory' which has the value 0x01AAF5EF, then the appropriate filter will have to read:
(Inventory=\01\aa\f5\ef)
Unfortunately, wildcard search is not allowed when searching for binary attributes! |
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:
'All universal groups:
(groupType:1.2.840.113556.1.4.803:=8)
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):
'All security enabled groups:
(groupType:1.2.840.113556.1.4.803:=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):
'All users which don't need a password OR whose passwords don't expire:
(userAccountControl:1.2.840.113556.1.4.804:=65568)
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:
'All universal security groups:
(groupType=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.
