<< RFC 2251 – Lightweight Directory Access Protocol (v3) >>

1. Status of this Memo

IESG Note

이 문서는 읽기 접근과 수정 접근을 제공하는 directory access protocol를 설명한다. 수정 접근은 안전한 인증을 요구하나 여기서는 어떠한 만족스러운 인증 mechanism의 구현은 다루지 않는다.

2. Abstract

- X.500 DAP의 리소스 요구사항을 따르지 않아도 X.500을 지원하는 directories에 대한 접근을 제공하기 위해 디자인된 protocol

- Directories에 대한 읽기/쓰기 상호 접근을 제공하는 applications와 browser applications을 다루는 것을 특별히 목표로 한 protocol

LDAP v3의 key aspects:

- LDAP v2의 모든 구성요소 지원

- 대부분의 protocol data 구성요소가 ordinary string으로 encoding 가능

- 다른 서버로의 referrals

- association security service를 지원하기 위해 LDAP과 함께 SASL mechanism 사용

- Attribute value와 DN은 ISO 10646 character set을 사용하여 국제화

- 확장성

- directory 내부에 Schema가 배포되어 clients에 의해 사용

3. Models

3.1. Protocol Model

- 이 protocol에 작용된 general model은 clients중 하나가 서버에 대하여 protocol operation을 수행한다는 것. Client가 operation request protocol을 보내면 server가 directory에서 operation 수행하고 결과를 client에게 response.

- directory를 사용할 수 있는 applications의 광범위한 deployment를 수월하게 하기 위해 clients의 복잡성을 최소화

- 각각의 clients와 servers 사이의 동기성은 필수적이지 않다. Multiple operation을 위한 request와 response는 어떠한 순서 없이 client와 server사이에서 상호 교환. Client는 궁극적으로 요구 요청에 대한 response를 받는다.

- server가 client를 다른 서버로 referrals (not in v1,v2)

- core protocol operations는 X.500 directory abstract service의 strict subset이고, 따라서 LDAP에 의해 정확히 지원 가능. LDAP protocol operations와 DAP operations은 1:1 대칭은 되지 않으나 X.500 directory의 gateway로 행동하도록 서버 구현에서 multiple DAP requests를 만들 필요가 있다.

3.2. Data Model

- LDAP protocol은 Directory Information Tree(DIT)에 접근을 연합하여 제공하는 하나 이상의 서버가 있다고 가정. Trees는 entries로 구성. Entries은 names을 갖는다.(RDN, DN) RDN은 같은 sibling에서는 유일해야 한다.

- 일부 server는 entries의 cache나 shadow copies를 보유하여 search나 comparison 질의에 대한 응답에 사용가능하나 modification operation에서는 referrals 리턴하거나 다른 서버로 contact

- caching이나 shadowing을 수행하는 서버는 originating server에 의해 data에 적용된 접근 제어 규정에 위반되어서는 안 된다,

- 가장 큰 entries의 집합은 하나의 특정 서버에 의해 mastered된 entry의 출발점. 모든 하위 내용을 포함. naming context. DIT의 root는 DSA-specific Entry (DSE)이고 어떠한 naming context도 가지지 않는다. 각 서버는 rootDSE에서 다른 attribute value를 갖는다.

3.2.1. Attribute of Entries

- entries는 attribute set을 가지며 Attribute은 하나의 type과 관련된 value를 갖는다.

attribute type &agrave; short descriptive name, OID로 구분

하나 또는 여러 value 여부. Syntax

- Schema : attribute type definition, object class definition과 다른 정보들의 collection.

- objectClass : 각 entry에 반듯이 포함. entry의 object classes를 정의. 변경 가능, 삭제 불가능

- object class definition에 의해 허가 되지 않은 attribute를 entry에 추가하는 것은 불허. objectClass가 ‘extensibleObject’인 경우는 모든 user attributes를 가질 수 있다.

- entries는 아래의 operational attributes를 가질 수 있다.(server가 관리)

creatorName : directory에 해당 entry를 추가한 user의 DN

createTimpstamp : directory에 이 entry가 추가된 시간

modifiersName : 이 entry를 최종 수정한 user의 DN

modifyTimestamp : 최종 수정된 시간

subschemaSubentry : 이 entry의 schema를 관리하는 subschema entry(또는 subentry)의 DN

3.2.2. Subschema Entries and Subentries

- subschema entries &agrave; directory schema(특정 object class와 directory servers에 의해 지원되는 attributes type에 있어서)대한 관리 정보를 위해 사용

- 모든 subschema entries에서 필수적인 속성

cn : subschema entry의 RDN을 이루는데 사용

objectClass : 적어도 “top”과 “subschema”를 포함

objectClasses : 서버에게 알려진 object class를 정의하는 속성의 각 value

attributeTypes : 서버에게 알려진 attribute type을 정의하는 속성의 각 value

- matchingRules, matchingRuleUse, dITStructureRules, dITContentRules, nameForms, ldapSyntaxes 포함

- 서버는 clients가 그들의 schema information의 caches를 관리하도록 하기 위해 subchema entries안에 createTimestamp와 modifyTimestamp attribute를 제공해야 한다.

- clients는 subschema entry로부터 속성들을 얻는다. (search filter &agrave; “(objectClass=subschema)”)