프로그램의 세계에 4월부터Directory에 대하여 연재 합니다.
(기초부터 차근히 적어 놓아서 아마 초보자들에게도 많은 도움이 될 것입니다.
4. Elements of Protocol
- LDAP protocol은 Abstract Syntax Notation 1 (ASN.1)을 사용하여 설명되고 ASN.1 Basic Encoding Rules의 subset을 사용하여 전형적으로 이동된다.
- client는 bind request의 부분으로 지원되는 version을 지정.
- clients는 rootDSE로부터 supportedLDAPVersion attribute를 읽어 서버에서 지원하는 protocol version을 지정
4.1. Common Elements
4.1.1. Message Envelope
LDAPMessage ::= SEQUENCE {
messageID MessageID,
protocolOp CHOICE {
bindRequest BindRequest,
bindResponse BindResponse,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
modifyRequest ModifyRequest,
modifyResponse ModifyResponse,
addRequest AddRequest,
addResponse AddResponse,
delRequest DelRequest,
delResponse DelResponse,
modDNRequest ModifyDNRequest,
modDNResponse ModifyDNResponse,
compareRequest CompareRequest,
compareResponse CompareResponse,
abandonRequest AbandonRequest,
extendedReq ExtendedRequest,
extendedResp ExtendedResponse },
controls [0] Controls OPTIONAL }
MessageID ::= INTEGER (0 .. maxInt)
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
- LDAPMessage à 모든 protocol 상호교환에서 요구되는 common fields를 포함하는 envelope 제공
- common fields는 messageID와 controls만이다.
- 인식할 수 없는 LDAP SEQUENCE tag를 가진 PDU(Protocol Data Unit)을 client로부터 받으면 error
- 구분할 수 없는 PDU를 서버로부터 받으면 무시하거나 connection을 종료
4.1.1.1. Message ID
- LDAP session 안에서 다른 요구들의 것과 다른 value를 가져야 한다,
- 서버로부터 최종 응답을 받지 않은 상태에서 동일한 connection에서 동일한 Message ID를 가지고 요청해서는 안 된다.
- abandonRequest의 id나 abandoned operation의 id를 재사용 하지 말아야 한다.
4.1.2. String Types
- LDAPString ::= OCTECT STRING
- LDAPOID ::= OCTECT STRING (ex: 1.3.6.1.4.1.1466.1.2.3)
4.1.3. Distinguished Name and Relative Distinguished Name
- LDAPDN과 relativeLDAPDN은 [4]에 정의에 따라 encoding된 후 Distinguished Name과 Relative Distinguished Name의 표현으로 정의
<distinguished-name> ::= <name>
<relative-distinguished-name> ::= <name-component>
- <name>과 <name-component>는 [4]에 정의
- LDAPDN ::= LDAPString
- RelativeLDAPDN ::= LDAPString
- attribute type만이 relative distinguished name component안에 존재할 수 있다,
4.1.4. Attribute Type
- AttributeType ::= LDAPString
- 각 attribute type은 할당된 유일한 OBJECT IDENTIFIER를 갖는다. (ex: “2.5.4.10”)
- attribute type을 위한 하나나 여러 개의 texture names가 할당될 수도 있다. 문자로 시작, ASCII, 숫자, 하이픈만이 가능
- 서버가 attribute type을 위한 texture name을 갖는다면 검색결과에서 리턴되는 속성들을 위한 texture name을 사용해야 한다. 없을 경우 OBJECT IDENTIFIER만이 사용
- attribute type texture name은 non unique
- entries를 master하거나 shadow하는 서버는 attributeTypes 속성을 사용하는 subschema entries가 지원하는 모든 attribute types을 리스트 해야 한다. Attributes의 open-ended set을 지원하는 서버는 적어도 ‘objectClass’ 속성을 위한 attributeTypes 값을 가져야 한다. Clients는 OBJECT IDENTIFIER와 속성 types에 연결된 다른 정보들을 얻기 위해 subschema entries로부터 attributeTypes value를 구할 수도 있다.
- LDAP 해당 버전에서 사용되는 일부 속성 type names은 [5]에 정의. 서버들은 추가적인 attribute types을 구현할 수 있다.
4.1.5. Attribute Description
- attribute description은 AttributeType의 정의의 superset
- AttributeDescription ::= LDAPString
- <AttributeDescription> ::= <AttributeType>[“;”<options>]
<options> ::= <option> | <option> “;” <options>
<option> ::= <opt-char> <opt-char>*
<opt-char> ::= ASCII-equivalent letters, numbers and hyphen
- ex: cn
userCertificate;binary
- 모든 조합이 서버에 의해 다 지원되지 않더라도, 어떤 option이든 모든 Attribute Type에 연결 가능.
- AttributeDescription에 있는 options는 상호 배타적이지 않다.
- AttributeDecsriptionList는 0 또는 여러 개의 attribute type의 리스트를 표현한다.
AttributeDecsriptionList ::= SEQUENCE OF AttributeDescription
4.1.5.1. Binary Option
- 속성이 Basic Encoding Rules를 사용하여 encode된 binary value로 이동.binary value의 syntax는 ASN.1 data type definition이다.
- 이 option의 protocol내에서 속성 값의 이동에서만 영향
- 이 option은 syntax가 complex ASN.1 data type인 속성과 같이 사용되고 이 type의 값의 구조체가 clients에 의해 요구 (syntax 예: “Certificate” and “CertificateList”)
4.1.6. Attribute Value
- 속성의 값으로 해당 type의 AttributeDescription에 binary option 유무에 따라 AttributeValue date type으로 encoding된 string이거나 encoded binary value를 포함하는 OCTECT STRING이다.
- 다른 syntaxes와 types을 위한 string encoding 정의는 [5]에 정의
- AtrributeValue ::= OCTECT STRING
- 이 encoding의 size 제한은 없다. Protocol은 Multi-megabytes의 속성도 포함 가능
- clients는 속성 syntax에 유효하지 않은 attribute values를 요청 안에서 보내서는 안 된다.
4.1.7. Attribute Value Assertion
- attribute description과 이 type에 적합한 matching rule assertion value 포함
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
AssertionValue ::= OCTECT STRING
- assertion value syntax는 value syntax와 동일. Clients는 compare와 search filters에서 assertion values로서 attribute values를 사용할 수도 있다.
4.1.8. Attribute
- 속성은 하나의 type과 하나 이상의 값을 갖는다.
- Attribute ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
4.1.9. Matching Rule Identifier
- 추상적이 data 값을 가진 search filter안에서 받는 AssertionValue를 어떻게 비교하는 지를 설명하는 수단. assertion value의 syntax와 서버에서 수행되는 process를 정의
- X.501 Matching Rule은 LDAP protocol내에 정의 (ex: “caseIgnoreIA5Match” or “1.3.6.1.4.1.453.33.33”)
- MatchingRuleId ::= LDAPString
4.1.10. Result Message
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
authMethodNotSupported (7),
strongAuthRequired (8),
-- 9 reserved --
referral (10), -- new
adminLimitExceeded (11), -- new
unavailableCriticalExtension (12), -- new
confidentialityRequired (13), -- new
saslBindInProgress (14), -- new
noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
-- 22-31 unused --
noSuchObject (32),
aliasProblem (33),
invalidDNSyntax (34),
-- 35 reserved for undefined isLeaf --
aliasDereferencingProblem (36),
-- 37-47 unused --
inappropriateAuthentication (48),
invalidCredentials (49),
insufficientAccessRights (50),
busy (51),
unavailable (52),
unwillingToPerform (53),
loopDetect (54),
-- 55-63 unused --
namingViolation (64),
objectClassViolation (65),
notAllowedOnNonLeaf (66),
notAllowedOnRDN (67),
entryAlreadyExists (68),
objectClassModsProhibited (69),
-- 70 reserved for CLDAP --
affectsMultipleDSAs (71), -- new
-- 72-79 unused --
other (80) },
-- 81-90 reserved for APIs --
matchedDN LDAPDN,
errorMessage LDAPString,
referral [3] Referral OPTIONAL }
- 대부분의 result codes는 X.511 error data types의 problem indications에 기반.
16~21 : AttributeProblem
32,33,34,36 : NameProblem
48,49,50 : SecurityProblem
51~54 : ServiceProblem
64~69,71 : UpdateProblem
4.1.11. Referral
- 연결된 서버가 요청의 target entry를 보유하지 않을 경우로 LDAPResult의 resultcode가 referral
- LDAP이나 다른 protocol을 통해 접근할 다른 서버의 reference 포함
- Referral ::= SEQUENCE OF LDAPURL – one or more
LDAPURL ::= LDAPString – URLs에서 허용되는 문자에 제한
- client는 operation을 처리하기 위해 다른 서버에 접근하여 referral를 따르고, 모든 URLs는 operation 수행에서 사용되는 동일한 능력을 갖는다.
4.1.12. Controls
- control은 extension 정보를 정의하는 방법. 요청의 한 부분으로 보내지는 controls는 그 요청에서만 적용되며 저장되지 않는다.
Controls ::= SEQUENCE OF Control
Control ::= SEQUENCE {
controlType LDAPOID,
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTECT STRING OPTIONAL }
- controlType은 control에서 유일하게 인식되는 OBJECT IDENTIFIER의 UTF-8 encoded dotted-decimal representation. controls names과 충돌을 피한다.
- criticality field는 TRUE or FALSE
- 서버가 control type을 인식하고 operation에 적합하다면 operation을 수행할 때 control을 생성
- 서버가 control type을 인식하지 못하고 criticality가 TRUE이면 서버는 operation을 수행하지 않고 unsupportedCriticalExtension resultCode를 보낸다. Criticality가 FALSE이면 서버는 control를 무시
- controlValue는 control에 대한 정보 포함.
- control 정의 구성
control에 할당된 OBJECT IDENTIFIER
control이 항상 noncritical인지, 항상 critical인지 또는 client의 option에 따라 critical인지
control의 controlValue 내용의 format
- 서버는 rootDSE의 supprotedControl에 인식하는 controls를 리스트 한다.
4.2. Bind Operation
- client와 server간의 인증 정보를 받아들이는 기능
- Bind Request
BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice }
AuthenticationChoice ::= CHOICE {
simple [0] OCTET STRING, -- 1 and 2 reserved
sasl [3] SaslCredentials }
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
- version : 이 protocol session에서 사용되는 protocol의 version
name : client가 bind하고자 하는 directory object의 name. anonymous bind에서는 null. SASL credentials 사용에서는 credentials의 LDAPDN을 포함.
authentication : Bind Request에서 제공하는 name을 인증하는데 사용되는 정보
- 서버는 bind request를 받으면 요청한 client를 인증하고 결과를 보낼 것이다.
- authorization은 operation수행에서 인증 정보를 사용하는 것이다. Authorization은 더 낮은 계층의 보안 서비스와 같이 bind request의 외부 요소로 영향을 줄 수도 있다.
4.2.1. Sequencing of the Bind Request
- SASL 인증 메커니즘을 위해 BindRequest가 여러 번 일어날 수도 있다. Client는 다단식 bind의 부분으로써 두개의 bind 요청 사이에서 operation을 일으켜서는 안 된다.
- SaslCredentials의 mechanism 필드 안에 다른 값을 가지거나 sasl이 아닌 다른 AuthenticationChoice를 갖는 BindRequest를 보냄으로써 SASL bind negotiation을 중도 시킬 수 있다.
- client가 sasl mechanism을 빈공간으로 보내면 서버는 authMethodNotSupported의 resultCode를 갖는 BindResponse를 보낸다. 이것은 동일한 SASL mechanism으로 다시 시도하고자 한다면 clients가 처리를 중단할 수 있을 것이다.
- client가 연결의 첫번째 PDU에 BindRequest를 보낼 필요는 없다. Clients가 어떤 operation을 요청하면 서버는 인증되지 않은 상태로 처리하고 만약 서버가 client bind를 요구한다면 서버는 “operationsError” 결과를 가지고 요청을 거부한다.
- clients는 credentials를 변경하기 위해 다중 bind request를 보낼 수 있다. 이 뒤이은 bind process는 연결상에서 모든 operation을 중단하고 이전 bind를 통해 얻은 인증은 무시되며 bind가 실패하면 anonymous로 연결하게 된다. SASL transfer encryption이나 무결성 mechanism이 처리된다면 credentials의 변경은 지원되지 않으며 대신 client는 새로운 연결을 형성해야 한다.
4.2.2. Authentication and Other Security Services
- simple authentication à authentication field에 clear text password만이 포함. no authentication or encryption
- no authentication이 수행되려면 simple authentication option 선택해야 하고 password는 zero length
- sasl 선택은 SASL를 사용하는 모든 mechanism을 허가하고 mechanism field에 그 mechanism name 포함
- credentials field는 인증에서 사용되는 OCTECT STRING으로 감싼 arbitrary data가 포함
- SASL을 사용하는 다른 internet application protocol과 달리 LDAP은 text-based가 아니며 따라서 credentials위에서 base64 transformation은 수행되지 않는다.
4.2.3. Bind Response
- BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }
- Bind Request가 성공하면 resultCode가 success
- 실패했을 경우
operationsError : server가 내부 error를 발생
protocolError : 인식되지 않는 version 번호이거나 부적절한 PDU 구조체
authMethodNotSupported : 인식되지 않는 SASL mechanism name
stringAuthRequired : 서버가 SASL mechanism을 가지고 수행되는 인증 요구
referral : 서버가 bind를 받지 못하고 client는 다른 서버로 시도해야 한다.
saslBindInProgress : 인증 과정을 계속하기 위해 서버가 동일한 sasl mechanism을 가지고 새로운 bind request를 보낼 것을 요구
inappropriateAuthentication : 서버가 anonymous나 지원되는 credentials 없는 client에게 credentials를 제공할 것을 요구
invalidCredentials : 잘못된 password 또는 SASL credentials가 수행될 수 없는 경우
unavailable : 서버 shutting down
- serverSaslCreds는 client로 하여근 통신을 하거나 “challenge-response” 인증을 수행하는 서버를 인증하도록 하는 SASL-defined bind mechanism의 한 부분으로 사용된다.
4.3. Unbind Operation
- protocol session을 종료
UnbindRequest ::= [APPLICATION1] NULL
- response가 정의 되지 않는다. 서버는 session을 종료하고 모든 요청을 무시하며 연결을 닫는다.
4.4. Unsolicited Notification
- 서버가 clients에 보내는 LDAPMessage로 서버나 서버와 client간의 연결 안에서의 extraordinary condition을 전달
- messageID는 0, protocolOp는 extendedResp 형식. ExtendedResponse의 responseName field는 존재하며 LDAPOID는 이 notification에서 유일
4.4.1. Notice of Disconnection
- error condition으로 인해 서버가 연결을 닫을 경우 서버에 의해 보내진다.
- client가 error condition과 network failure를 구분하는 것을 돕는다. network failure로 connection이 닫히면 client는 directory에 대한 수정의 성공, 실패를 가정해서는 안 된다.
- responseName은 1.3.6.1.4.1.1466.20036이고 response field가 비어있으며 resultCode는 disconnection의 이유를 나타낸다.
- resultCode value
protocolError : 서버가 client로부터 LDAPMessage 구조체를 parse할 수 없는 data를 받았을 경우
strongAuthRequired : 보안의 예상치 못한 실패나 손상된 경우
unavailable : 서버가 새로운 연결과 현재 연결 상에서의 모든 operation을 받지 않고 한동안 unavailable된다. client는 다른 서버를 사용할 수 있다.
- notice를 보낸 후 서버는 연결을 닫고 client는 notice를 받은 후 연결 상에서 더 이상 전송이 안되고 갑자기 연결을 닫게 된다.
4.5. Search Operation
4.5.1. Search Request
SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2) },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeDescriptionList }
Filter ::= CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion }
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
-- at least one must be present
substrings SEQUENCE OF CHOICE {
initial [0] LDAPString,
any [1] LDAPString,
final [2] LDAPString } }
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
- baseObject : search를 수행하는 상대적인 base object entry의 LDAPDN
- scope : search의 범위
- derefAliases : alias objects가 searching에서 어떻게 다뤄지는 지에 대한 indicator
neverDerefAliases
derefInSearhching
derefFindingBaseObj
derefAlways
- sizelimit : search의 결과로 받는 entries의 최대 개수를 제한. 0은 client-requested sizelimit 제한이 없고 서버가 보내는 entries의 최대 개수를 정할 수 있다.
- timelimit : search에 부여된 최대 시간 제한. 0은 client-requested timelimit 제한이 없다는 의미
- typesOnly : 검색 결과가 속성 types과 value 모두를 또는 types만을 전달할 지의 indicator
- ‘and’, ’or’, ‘not’은 filters의 조합에 사용
- filter는 “TRUE’, “FALSE”, “Undefined”의 하나로 평가한다. 특정 entry에 대해 TRUE를 얻으면 이 entry의 속성은 검색 결과의 하나로 리턴되며, FALSE나 Undefined이면 무시한다,
- present match는 속성이나 entry에 있는 특정 attribute description의 subtype이 있으면 TRUE를 얻는다.
- extensiblematch은 LDAP v3에서 추가된 내용. matchingRule이 비어 있으면 type field가 반듯이 있어야 하며 equality match가 이 type에 대해 수행된다.type field가 비어 있고 matchingRule이 있으면 이 matchRule를 지원하는 entry의 모든 속성들에 대하여 matchValue를 비교하고 matchingRule은 assertion value의 syntax를 정의한다. type field와 matchingRule이 있으면 matchingRule은 이 type과 함께 사용되는 것만이 허가된다. DnAttributes field가 TRUE이면 match는 entry의 distinguished name의 모든 속성들에 대해서도 적용되고 또한 dn의 속성 중 적어도 하나가 filter item이 TRUE를 구한다면 TRUE가 evaluate
- attributes : search filter에 맞는 각 entry로부터 얻을 attributes의 리스트.
- client가 모든 user attributes를 요구해도 access control에 의해 검색 결과에 일부 속성들은 포함되지 않을 수 있다. 또 서버는 objecrClasses나 attributeTypes와 같은 operational attributes를 따로 지정하지 않는 한 보내지 않는다. 어떤 operational attributes는 상당히 많은 value를 가질 수도 있기 때문이다.
4.5.2. Search Result
- Search Request에 대하여 서버가 SearchResultEntry, SearchResultReference, ExtendedResponse 또는 SearchResultDone data types을 포함하는 LDAPMessage인 SearchResponses안에서 리턴하는 검색 결과
- SearchResultEntry ::= [APPLICATION 4]SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
PartialAttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL – 적어도 하나의 LDAPURL이 있어야 한다.
SearchResultDone ::= [APPLICATION 5] LDAPResult
- Search Request를 받으면 서버는 DIT의 필요한 search를 수행할 것이다..
- LDAP session이 TCP와 같은 connection-oriented transport 위에서 이루어진다면 서버는 분리된 LDAPMessage안에서 응답의 sequence를 client에게 보낼 것이다. 여기에 검색 동안 발견된 각각의 entry를 위한 SearchResultEntry를 포함하는 응답을 0 또는 여러 개 가지고 있을 수 있다. 또 검색동안 이 서버에 의해 조사되지 않은 각 지역에 대한 SearchResultReference를 포함한 응답이 0 또는 여러 개 있을 수 있다. SearchResultEntry와 SearchResultReference PDUs는 어떠한 순서를 가지고 올 수 있다. 모든 SearchResultReference 응답과 모든 SearchResultEntry 응답 뒤에 서버는 성공이나 발생한 error에 대한 상세한 설명을 갖는 indication을 포함한 SearchResultDone을 보낸다.
- 각 SearchResultEntry는 Search Request의 attributes field안에서 정한 대로 필요하다면 value를 포함한 모든 attributes를 보낸다. Attributes의 리턴은 access control과 다른 administrative policy에 따르며 일부 attributes는 binary format으로 전달된다. (binary option을 갖는 응답 안에서 AttributeDescription에 의해 indicated)
- 일부 attributes는 서버에 의해 생성되고 비록 entry의 attributes에 저장되지는 않지만 SearchResultEntry attribute list에 나타난다. Clients는 접근 제어에 의해 허가가 되더라도 모든 attributes를 변경할 수 없다.
- ExtendedResponse 형식의 LDAPMessage 응답은 client에 의해 요청된 control에 대한 정보를 저장한다.
4.5.3. Continuation Reference in the Search Result
- 서버가 baseObject에 의해 참조된 entry의 위치를 찾을 수는 있으나 baseObject의 scope안에서 모든 entries를 검색할 수 없을 경우 서버는 하나 이상의 SearchResultReference를 리턴하는데 여기에는 진행되는 operation을 위한 다른 서버들의 reference를 포함한다. baseObject를 찾지 못하면 SearchResultReference를 보내지 않으며 어떠한 entries도 검색할 수 없다. 이 경우 referral resultCode를 가진 SearchResultDone을 보낸다.
- SearchResultReference를 Referral과 같은 data type이다.
- search를 완료하기 위해 client는 리턴된 SearchResultReference 각각에 대해 새로운 search operation을 만들어야 한다. abandon operation은 client와 server 사이의 연결 상에서 보내지는 특정 operation에 대해서만 적용되고 client가 다른 서버들에 대해 다중의 검색 operations를 처리중이라면 각각의 operation에 대해 abandon해야 한다.
4.5.3.1. Example
- hosta à “O=MNN,C=WW”, “CN=Manager,O=MNN,C=WW” – contacted server
hostb à “OU=People,O=MNN,C=WW” – LDAP-capable server(master)
hostc à “OU=People,O=MNN,C=WW”– LDAP-capable server(shadow)
hostd à “OU=Roles,O=MNN,C=WW” – LDAP-capable server
- contacted server에 대한 “O=MNN,C=WW”에서의 subtree search 결과
SearchResultEntry for O=MNN,C=WW
SearchResultEntry for CN=Manager,O=MNN,C=WW
SearcjResultReference {
ldap://hostb/OU=People,O=MNN,C=WW
ldap://hostc/OU=People,O=MNN,C=WW
}
SearchResultReference {
ldap://hostd/OU=Roles,O=MNN,C=WW
}
SearchResultDone (success)
- hostb가 contacted server, “OU=People,O=MNN,C=WW”에서 subtree search 결과
SearchResultEntry for OU=People,O=MNN,C=WW
SearchResultReference {
ldap://hoste/OU=Manager,OU=People,O=MNN,C=WW
}
SeatchResultReference {
ldap://hostf/OU=Consultants,OU=People,O=MNN,C=WW
}
SearchResultDone(success)
- contacted server가 검색을 위한 base object를 가지고 있지 않을 경우의 결과
SearchResultDone(referral) {
ldap://hostg/
}
4.6. Modify Operation
- ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
modification SEQUENCE OF SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2) }
modification AttributeTypeAndValues } }
AttributeTypeAndValues ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
- object : modified될 object. entry의 DN 포함. 서버는 수정될 object 정의에서 어떠한 alias dereferencing을 수행하지 않을 것이다.
- modification : entry에 대해 수행될 modifications의 리스트. entry modifications의 전체 리스트는 나열된 순서대로 수행되어져야 한다. 각 modifications가 directory schema에 위배되더라도 수행된 modifications의 전체 리스트 이후의 결과 entry는 directory schema의 요구에 따라야 한다.
- operation field
add : 주어진 attribute에 대한 values를 추가하고 필요할 경우 attribute를 생성
delete : 주어진 attribute로부터 values를 삭제하고 연결된 values가 없거나 attribute의 모든 values가 삭제되면 attribute
replace : 주어진 attribute의 모든 values를 새로 연결된 values로 replace하고 존재하지 않으면 속성을 생성.value가 없는 replace의 경우 attribute가 존재한다면 속성은 삭제되고 attribute가 없다면 무시
- 결과
ModifyResponse ::= [APPLICATION 7] LDAPResult
- 서버는 Modify Request를 받으면 DIT에 대한 필요한 수정을 수행한다. 서버는 DIT modification의 성공적인 완료를 알리거나 실패 이유를 알리는 단일 Modify Response를 보낸다, 연결이 실패하면 modification은 일어나지 않거나 확실하지 않을 것이다.
- Modify Operation은 entry의 RDN을 구성하는 값인 distinguished values는 entry로부터 제거하기 위해 사용될 수 없다. 이것을 시도하면 notAllowedOnRDN error가 발생
- attribute type에 equality match filter가 정의되지 않으면 modification의 “delete” form으로 entry로부터 속성 values를 삭제하는 시도를 해서는 안되며 “replace” form을 사용해야 한다.
- LDAP의 단순화에 의해 LDAP ModofyRequest는 DAP ModifyEntry operation과 정확히 mapping 되지 않고 LDAP-DAP gateway의 구현이 변경을 표현하는 다른 수단으로 사용될 수 있다. 성공 시의 최종 효과는 동일해야 한다.
4.7. Add Operation
- directory에 entry 추가
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
AttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
- entry : 추가될 entry의 Distinguished Name.
- attributes : 추가될 entry의 내용을 구성하는 attributes의 리스트. client는 반듯이 distinguished values, object class, 그리고 필수적인 속성들을 포함해야 한다. createTimestamp나 creatorsName 속성은 서버가 자동으로 만들어 주므로 client가 제공해서는 안 된다.
- 추가되는 entry는 존재해서는 안되면 parent는 이미 존재해야 한다.
- 서버는 entries가 어디에 위치하는 지에 대한 제한을 두지 않는다. 일부 서버는 administrator가 directory에 추가할 entries의 classes를 제한할 수 있도록 할 수 있다.
- 결과
AddResponse ::= [APPLICATION 9] LDAPResult
|