ldap 쿼리 질문 드립니다

ou는 core.schema에 정의된 attributetype이지 objectClass가 아닙니다.

objectClass는 이런 attributetype들의 집합이죠.

다시 말해, objectClass가 organizationalUnit인 것은 entry 자체가 ou라고 보시면 됩니다..

하지만 attributetype으로 ou를 갖는 것은 entry가 organizationalUnitName이라는 식별자 역할의 attributetype을 갖는다는 것이구요.

사설을 좀 덧대자면...

각 entry는 여러 objectClass를 가질 수 있음을 아실 것입니다.

예를 들어 한 entry가 inetOrgPerson objectClass를 포함한다고 해볼까요?

이 inetOrgPerson은 RFC 2798 명세에 따라 organizationalPerson objectClass를 상위로 하고, 또 organizationalPerson은 person을 상위로 합니다.

그리고 organizationalPerson objectClass는 MAY attributetype으로 ou를 갖습니다.

따라서 inetOrgPerson을 포함하는 것만으로 ou라는 attributetype을 가질 수가 있게 되는 것이고, 이 ou라는 녀석으로 해당 entry가 소속되는 조직 단위를 지정하는 것이죠.

core.schema를 열어보신다면 organizationalUnitName을 비롯하여 cn, sn과 같은 attributetype의 정의를 보실 수 있는데, 가만보시면 name이라는 속성이 이들의 상위 속성이라는 공통점이 있습니다.

그리고 이 name이라는 속성은 DN 외에도 LDAP 질의 과정에서 추가 식별자로 사용될 수 있도록 제정한 속성입니다. 따라서 이 속성은 entry 자체의 속성일 뿐만이 아니라 질의를 위한 기저의 일부로써도 사용이 가능한 것이죠.

위 속성을 통해 어떻게 질의가 이루어지는가를 좀 더 자세히 알고 싶으시다면 RFC 4511을 참조하시고, DN 자체에 대한 표기는 4514를 참조하시면 되겠습니다.

(&(objectClass=person)(name=*)(|(objectClass=*)))

앞에서부터 차근차근 보시면 될 것 같습니다.

처음 괄호를 기준으로 3개의 하위 조건이 존재합니다.

1. (objectClass=person)
2. (name=*)
3. (|(objectClass=*))

1번과 2번으로 objectClass가 person이고 name 속성이 있는 entry들이 걸러집니다.

3번째 조건을 보시면 새로운 괄호가 열려 OR로 objectClass=*라는 조건이 있네요.

일반적으로는, (&(objectClass=person)(name=*)(|(cn=potatogim)(ou=potato field*)) 와 같이 앞의 AND를 충족하는 entry들에게 2차적인 조건을 부여하는 형식인데 의도적인 경우가 아니고선 저렇게 다시 objectClass를 조건으로 거르는 동작을 취할 이유가 없을 것 같습니다.

과장하면 특정 서버 구현의 취약점을 노린 질의가 아닐까 싶네요...;;