Lightweight 디렉토리 액세스 프로토콜

Lightweight Directory Access Protocol
Lightweight 디렉토리 액세스 프로토콜
통신 프로토콜
목적디렉토리 서비스
에 기반을 둔X.500
포트389(표준), 636(랩)
RFCRFC 4510, RFC 4511
인터넷 프로토콜 스위트
응용 프로그램레이어
트랜스포트 레이어
인터넷 레이어
링크 레이어

Lightweight Directory Access Protocol (LDAP / ldældép/ )는 Internet Protocol (IP)[1] 네트워크를 통해 분산 디렉토리 정보 서비스에 액세스 및 유지보수하기 위한 개방적이고 벤더 중립적인 업계 표준 애플리케이션 프로토콜입니다.디렉토리 서비스는 네트워크 전체에서 사용자, 시스템, 네트워크,[2] 서비스 및 응용 프로그램에 대한 정보를 공유할 수 있도록 함으로써 인트라넷 및 인터넷응용 프로그램을 개발하는 데 중요한 역할을 합니다.예를 들어 디렉터리 서비스는 종종 회사 전자 메일 디렉토리와 같은 계층 구조를 가진 구성된 레코드 세트를 제공할 수 있습니다.마찬가지로 전화번호부란 주소와 전화번호를 가진 사용자의 목록입니다.

LDAP는 설명 언어 ASN.1을 사용하여 Request for Comments(RFC; 댓글 요구)라고 불리는 일련의 Internet Engineering Task Force(IETF; 인터넷 기술 특별 조사위원회) Standard Track에서 지정됩니다.최신 사양은 버전3으로 RFC 4511로[3] 공개되어 있습니다(기술사양 로드맵은 RFC4510에 기재되어 있습니다).

LDAP 의 일반적인 용도는, 유저명과 패스워드를 격납하는 중앙의 장소를 제공하는 것입니다.이것에 의해, 많은 다른 애플리케이션이나 서비스를 LDAP 서버에 접속해 [4]유저를 검증할 수 있습니다.

LDAP 는, X.500 표준에 포함되는 보다 심플한 표준의 서브셋에 근거하고 있습니다.이 관계로 LDAP는 X.500-lite라고 [5]불리기도 합니다.

역사

통신사의 디렉토리 요건에 대한 이해는 약 70년간 전화번호부를 제작 및 관리한 후 잘 발달했다.이들 기업은 정보 테크놀로지와 컴퓨터 네트워킹에 디렉토리 서비스의 개념을 도입했습니다.이 개념은 1980년대에 국제전기통신연합(ITU)에 의해 제조된 프로토콜 스위트인 포괄적인 X.500 [6]사양에 의해 정점에 도달했습니다.

X.500 디렉토리 서비스는 기존에는 X.500 Directory Access Protocol(DAP)을 통해 액세스되어 OSI(Open Systems Interconnection) 프로토콜 스택이 필요했습니다.LDAP는 원래 보다 단순한(지금은 널리 보급된) TCP/IP 프로토콜 스택을 통해 X.500 디렉터리 서비스에 액세스하기 위한 경량 대체 프로토콜로 의도되었습니다.이 디렉토리 액세스 모델은 DIXIE 및 Directory Assistance Service 프로토콜에서 차용되었습니다.

이[7] 프로토콜은 원래 DIXIE와 DAS의 후계자로[8] 미시간 대학의 Tim Howes, Isode Limited 대학의 Steve Kille, Nexor의 Colin Robbins 및 Performance Systems International의 Wengyik Young에 의해 1993년경에 만들어졌습니다.Critical Angle Inc.의 Mark Wahl, Tim Howes 및 Steve Kille은 1996년에 Internet Engineering Task Force(IETF; 인터넷 기술 특별 조사위원회)의 지원을 받아 LDAPv3의 새로운 버전을 개발하기 시작했습니다.1997년에 처음 발행된 LDAPv3는 LDAPv2를 대체하고 확장성에 대한 지원을 추가했으며 Simple Authentication and Security Layer를 통합했으며 프로토콜을 1993년 X.500 에디션에 더 잘 맞춥니다.LDAPv3 사양 자체 및 LDAPv3에 기능을 추가하는 수많은 확장 기능의 추가 개발은 IETF를 통해 이루어졌습니다.

LDAP의 초기 엔지니어링 단계에서는 Lightweight Directory Browsing Protocol(LDBP)로 알려져 있었습니다.디렉터리 검색 및 검색을 넘어 프로토콜의 범위가 확장되면서 디렉터리 업데이트 기능을 포함하도록 이름이 변경되었습니다.Lightweight라는 이름은 이전 DAP만큼 네트워크 부하가 높지 않기 때문에 비교적 적은 대역폭 사용률로 인해 인터넷을 통해 구현이 용이했기 때문에 붙여졌습니다.

LDAP는 X.500, XML Enabled Directory(XED), Directory Service Markup Language(DSML), Service Provisioning Markup Language(SML), Service Location Protocol(SLP) 등의 후속 인터넷 프로토콜에 영향을 주었습니다.Microsoft 의 Active Directory 의 베이스로서도 사용됩니다.

프로토콜 개요

클라이언트는 Directory System Agent(DSA; 디렉토리 시스템에이전트)라고 불리는 LDAP 서버에 접속하여 LDAP 세션을 시작합니다.디폴트로는 TCP 및 UDP 포트 389 또는 LDAPS의 경우 포트 636(LDAP over TLS/SSL, [9]이하 참조).그런 다음 클라이언트는 서버에 작업 요청을 보내고 서버는 응답을 보냅니다.일부 예외를 제외하고 클라이언트는 다음 요청을 보내기 전에 응답을 기다릴 필요가 없으며 서버는 임의의 순서로 응답을 보낼 수 있습니다.모든 정보는 Basic Encoding Rules(BER; 기본 부호화 규칙)를 사용하여 전송됩니다.

클라이언트는, 다음의 조작을 요구할 수 있습니다.

  • StartTLS – LDAPv3 Transport Layer Security(TLS; 트랜스포트층 보안) 확장을 사용하여 안전한 접속을 실현합니다.
  • 바인드 – LDAP 프로토콜 버전 인증 및 지정
  • 검색 – 디렉토리 엔트리 검색 및/또는 검색
  • Compare – 이름 있는 엔트리에 지정된 속성 값이 포함되어 있는지 테스트합니다.
  • 새 항목 추가
  • 엔트리를 삭제하다
  • 엔트리를 수정하다
  • 인정자명(DN) 변경– 엔트리의 이동 또는 이름 변경
  • 포기 – 이전 요청을 중단합니다.
  • 확장 동작 – 다른 동작을 정의하기 위해 사용되는 일반적인 동작
  • 언바인드 – 접속을 닫습니다(바인드의 역방향 아님).

또한 서버는 어떤 요청에 대한 응답도 아닌 "요청되지 않은 통지"를 보낼 수 있습니다(예: 연결 시간이 초과되기 전).

LDAP 통신을 보호하는 일반적인 대체 방법은 SSL 터널을 사용하는 것입니다.LDAP over SSL 기본 포트는 636입니다.LDAP Version 2(LDAPv2)에서는 LDAP over SSL을 사용하는 것이 일반적이지만 정식 사양에서는 표준화되지 않았습니다.이 사용법은 [10]2003년에 공식적으로 폐기된 LDAPv2와 함께 폐지되었습니다.

디렉토리 구조

이 프로토콜은 X.500 모델의 1993년 에디션을 따르는 디렉토리와의 인터페이스를 제공합니다.

  • 엔트리는 속성 세트로 구성됩니다.
  • 속성에는 이름(속성 유형 또는 속성 설명)과 하나 이상의 값이 있습니다.속성은 스키마로 정의됩니다(아래 참조).
  • 각 엔트리에는 고유 식별자(DN)가 있습니다.이것은 엔트리의 일부 Atribute로 구성된 RDN(Relative Distinguished Name)과 그 뒤에 이어지는 부모 엔트리의 DN으로 구성됩니다.DN은 풀 파일 경로로, RDN은 부모 폴더 내의 상대 파일명으로 간주합니다(예:/foo/bar/myfile.txtDN 이었던 것 같습니다.myfile.txtRDN이 됩니다).

예를 들어 엔트리가 트리 내에서 이동하는 경우 등 엔트리의 라이프 타임에 걸쳐 DN이 변경될 수 있습니다.엔트리를 확실하고 명확하게 식별하기 위해 엔트리의 동작 속성 세트에 UUID를 제공할 수 있습니다.

LDAP Data Interchange Format(LDIF; 데이터 교환 포맷)으로 표시되는 엔트리는 다음과 같습니다(LDAP 자체는 바이너리 프로토콜입니다). 

dn: cn=John Doe, dc=com cn: John Doe givenName:John sn: Doe 전화번호: +1 888 555 6789 전화번호: +1 888 555 1232 메일: john@example.com 관리자: cn=Doe, dc=dc=com 객체클래스: inetOrgPerson 객체클래스: organizational 객체클래스: person 객체클래스: 상위

"dn"는 엔트리의 인정자 이름입니다.아트리뷰트도 엔트리의 일부도 아닙니다."cn=John Doe"는 엔트리의 RDN(상대 인정자명)이며, "dc=example,dc=com" 는 부모 엔트리의 DN 입니다.dc"는 '도메인 컴포넌트'를 나타냅니다.다른 행은 엔트리의 속성을 나타냅니다.속성명은 일반적으로 "와 같은 니모닉 문자열입니다.cn일반적인 이름일 경우,dc도메인 컴포넌트의 경우,mail이메일 주소의 경우, 그리고 "sn"는 성을 나타냅니다.

서버는 특정 엔트리에서 시작하는 서브트리를 보유하고 있습니다.예를 들어 다음과 같습니다.dc=example,dc=com"와 그 자식들.서버는 다른 서버에 대한 참조를 보유할 수도 있기 때문에, 「」에의 액세스를 시도합니다.ou=department,dc=example,dc=com" 는 디렉토리 트리의 해당 부분을 보유하고 있는 서버에 대한 참조 또는 계속 참조를 반환할 수 있습니다.클라이언트는 다른 서버에 접속할 수 있습니다.일부 서버는 체인을 지원합니다.즉, 서버가 다른 서버에 접속하여 결과를 클라이언트에 반환하는 것을 의미합니다.

LDAP 에서는 순서가 정의되어 있는 경우는 거의 없습니다.서버는 속성 값, 엔트리의 속성 및 검색 조작에 의해 발견된 엔트리를 임의의 순서로 반환할 수 있습니다.이것은 정식 정의에서 이어집니다.엔트리는 Atribute 세트로 정의되며 Atribute는 값 세트이므로 세트를 정렬할 필요가 없습니다.

운용

더하다

ADD 조작에 의해, 디렉토리 서버 [11]데이터베이스에 새로운 엔트리가 삽입됩니다.추가요구의 식별명이 디렉토리에 이미 존재하는 경우 서버는 중복된 엔트리를 추가하지 않고 결과 코드를 10진수 68로 설정합니다.존재"[12]

  • LDAP 준거 서버는 엔트리를 검색하려고 할 때 추가 요청으로 전송된 인정자 이름을 참조 해제하지 않습니다.즉, 인정자 이름은 에일리어스 해제되지 않습니다.
  • LDAP 준거 서버는, 인정자명과 모든 어트리뷰트가 명명 표준에 준거하고 있는 것을 확인합니다.
  • 추가할 항목이 없어야 하며 직속 상위 항목이 있어야 합니다.
dn: uid=user,ou=people,dc=com changetype:add objectClass:top objectClass:person uid:user sn: last-name cn: common-name userPassword: 비밀번호 추가

위의 예에서는uid=user,ou=people,dc=example,dc=com존재하지 않아야 합니다.ou=people,dc=example,dc=com존재해야 합니다.

바인드(인증)

LDAP 세션이 작성되면, 즉 LDAP 클라이언트가 서버에 접속하면, 세션의 인증 스테이트는 어나니머스로 설정됩니다.BIND 조작은 세션의 인증 상태를 확립합니다.

Simple BIND 및 SASL PLINE은 사용자의 DN 및 비밀번호를 평문으로 전송할 수 있으므로 Simple 또는 SASL PLINE을 사용하는 연결은 TLS(Transport Layer Security)를 사용하여 암호화해야 합니다.서버는 일반적으로 패스워드를userPasswordAtribute를 지정합니다.익명 BIND(빈 DN 및 비밀번호)는 접속을 익명 상태로 리셋합니다.

SASL(Simple Authentication and Security Layer) BIND는 Kerberos나 [13]TLS와 함께 전송되는 클라이언트 증명서 등 다양한 메커니즘을 통해 인증 서비스를 제공합니다.

또한 BIND는 버전 번호를 정수 형식으로 전송하여 LDAP 프로토콜 버전을 설정합니다.클라이언트가 서버가 지원하지 않는 버전을 요구하는 경우 서버는 BIND 응답에서 프로토콜 오류에 대한 코드에 대한 결과 코드를 설정해야 합니다.일반적으로 클라이언트는 LDAPv3를 사용해야 합니다.이것은 프로토콜에서는 기본값이지만 LDAP 라이브러리에서는 항상 그렇지는 않습니다.

BIND는 LDAPv2 세션의 첫 번째 동작이어야 하지만 LDAPv3에서는 필요하지 않습니다.LDAPv3에서는 BIND 요구가 성공할 때마다 세션의 인증 상태가 변경되고 BIND 요구가 실패할 때마다 세션의 인증 상태가 리셋됩니다.

삭제

엔트리를 삭제하기 위해서 LDAP 클라이언트는 적절한 형식의 삭제 요구를 [14]서버에 송신합니다.

  • 삭제 요청에는 삭제할 항목의 고유 이름이 포함되어야 합니다.
  • 요청 제어는 삭제 요청에 첨부될 수도 있습니다.
  • 서버가 삭제 요청을 처리할 때 별칭을 참조 해제하지 않음
  • 삭제 요구에 의해 삭제할 수 있는 것은 리프 엔트리(하위 항목이 없는 엔트리)뿐입니다.일부 서버는 운영 속성을 지원합니다.hasSubordinates이 값은 엔트리에 하위 엔트리가 있는지 여부를 나타내며 일부 서버는 동작 속성을 지원합니다.numSubordinates[15] 를 포함하는 엔트리에 종속되는 엔트리의 수를 나타냅니다.numSubordinates기여하다.
  • 일부 서버에서는 서브트리 삭제 요구 제어를 지원하므로 접근컨트롤에 따라 DN 및 DN에 종속된 모든 오브젝트를 삭제할 수 있습니다.삭제 요구는 액세스컨트롤의 대상이 됩니다.즉, 특정 인증 스테이트의 접속이 특정 엔트리를 삭제할 수 있는지 여부는 서버 고유의 액세스컨트롤 메커니즘에 의해 제어됩니다.

검색 및 비교

검색 작업은 항목 검색 및 읽기에 모두 사용됩니다.파라미터는 다음과 같습니다.

base 오브젝트
검색이 실행되는 기본 개체 항목(또는 루트)의 이름입니다.
범위
검색할 baseObject 아래에 있는 요소.이 경우BaseObject(일반적으로 하나의 엔트리를 읽기 위해 사용되는 이름 있는 엔트리만 검색합니다).singleLevel(기본 DN 바로 아래에 입력) 또는wholeSubtree(기본 DN에서 시작하는 서브트리 전체).
필터
범위 내 요소 선택에 사용할 기준입니다.예를 들어 필터는(&(objectClass=person)( (givenName=John)(mail=john*)))persons(objectClass의 요소)를 선택합니다.person)의 매칭 규칙입니다.givenName그리고.mail이러한 Atribute의 값이 필터 어설션과 일치하는지 여부를 확인합니다.LDAP 데이터는 대소문자를 구분하지만 실제로는 일치 규칙과 순서 규칙이 일치, 비교 및 상대적 가치 관계를 결정하는 것으로 오해하는 경우가 많습니다.속성값의 대소문자를 일치시키기 위해 예제 필터가 필요한 경우 다음과 같이 확장 가능한 일치 필터를 사용해야 합니다.(&(objectClass=person)( (givenName:caseExactMatch:=John)(mail:caseExactSubstringsMatch:=john*)))
에일리어스 해제
에일리어스 엔트리(다른 엔트리를 참조하는 엔트리)의 후속 여부와 방법,
특성
결과 엔트리에 반환되는 속성.
size Limit, time Limit
반환할 최대 항목 수 및 검색 실행을 허용하는 최대 시간.단, 이러한 값은 서버가 크기 제한 및 시간 제한에 대해 설정한 제한을 덮어쓸 수 없습니다.
유형만
Atribute Type만 반환하고 Atribute 값은 반환하지 않습니다.

서버는 일치하는 엔트리 및 잠재적으로 계속 참조를 반환합니다.이것들은 어떤 순서로든 반품될 수 있습니다.최종 결과에는 결과 코드가 포함됩니다.

Compare 조작은 DN, Atribute 이름 및 Atribute 값을 취득하여 이름 있는 엔트리에 해당 값의 Atribute가 포함되어 있는지 여부를 확인합니다.

수정하다

MODIFY 조작은 LDAP 클라이언트가 LDAP 서버에 기존 [16]엔트리의 변경을 요구하기 위해 사용합니다.존재하지 않는 엔트리를 변경하려고 하면 실패합니다.MODIFY 요청은 서버에 의해 구현된 접근컨트롤의 대상이 됩니다

MODIFY 조작에서는 엔트리의 Distinguished Name(DN; 인정자명)과 일련의 변경을 지정해야 합니다.시퀀스의 각 변경은 다음 중 하나여야 합니다.

  • add (Atribute에 아직 존재하지 않는 새로운 값을 추가)
  • delete(기존 값 삭제)
  • replace(기존 값을 새 값으로 바꿉니다)

Atribute에 값을 추가하는 LDIF의 예:

dn: dc=dc, dc=com changetype: modify add: cn cn: 추가할 새 cn 값 -

기존 애트리뷰트 값을 치환하려면replace키워드를 지정합니다.속성이 다중 값인 경우 클라이언트는 업데이트할 속성 값을 지정해야 합니다.

엔트리에서 속성을 삭제하려면 키워드를 사용합니다.delete및 변경 유형 지정자modify속성이 다중값인 경우 클라이언트는 삭제할 속성 값을 지정해야 합니다.

Modify-Increment 확장도[17] 있어 증가 가능한 속성 값을 지정된 양만큼 늘릴 수 있습니다.다음으로 LDIF 증분을 사용하는 예를 나타냅니다.employeeNumber타고5:

dn: uid=user.0,ou=people,dc=people,dc=com changetype:수정인크리먼트:employeeNumber:5 -

LDAP 서버가 복제된 토폴로지에 있는 경우 LDAP 클라이언트는 업데이트 [18]후 검색이 아닌 사후 읽기 제어를 사용하여 업데이트를 확인하는 것을 고려해야 합니다.읽기 후 제어는 갱신 후 어플리케이션이 검색 요구를 발행할 필요가 없도록 설계되어 있습니다.복제의 최종적인 일관성 모델에 의해 갱신이 기능했는지 확인하기 위해서만 엔트리를 취득하는 것은 잘못된 형식입니다.설계자가 LDAP 클라이언트와 서버 사이에 로드밸런서 또는 LDAP 프록시 또는 둘 다 배치되어 있을 가능성이 있기 때문에 LDAP 클라이언트는 각 요구에 대해 같은 디렉토리 서버에 접속하고 있다고 가정해서는 안 됩니다.

DN 변경

Modify DN(Move/rename entry)은 새 RDN(Relative Distinguished Name), 새 상위 DN(선택 사항) 및 이전 RDN과 일치하는 항목의 값을 삭제할지 여부를 나타내는 플래그를 사용합니다.서버는 디렉토리 서브트리 전체의 이름을 변경할 수 있습니다.

업데이트 작업은 atomic:다른 작업에서는 새 항목 또는 이전 항목이 표시됩니다.한편, LDAP 에서는, 복수의 조작의 트랜잭션은 정의되지 않습니다.항목을 읽은 후 수정할 경우 다른 클라이언트가 그 사이에 항목을 업데이트했을 수 있습니다.단, 서버는 이를 지원하는 확장을 구현할[19] 수 있습니다.

확장 운용

확장 작업은 원래 프로토콜 사양에 포함되지 않은 새 작업을 정의할 수 있는 일반 LDAP 작업입니다.StartTLS는 가장 중요한 확장 중 하나입니다.기타 예로는 Cancel 및 Password Modify가 있습니다.

시작 TLS

시작TLS 조작에 의해서, 접속상에서 트랜스포트층 시큐러티(SSL 의 하위)가 확립됩니다.데이터 기밀성(타사의 데이터 감시로부터 데이터를 보호) 및/또는 데이터 무결성 보호(데이터 조작으로부터 데이터를 보호)를 제공할 수 있습니다.TLS 네고시에이션중에, 서버는 자신의 ID를 증명하기 위해서 X.509 증명서를 송신합니다.클라이언트는 자신의 ID를 증명하는 증명서를 송신할 수도 있습니다.그 후, 클라이언트는 SASL/EXTERNAL 을 사용할 수 있습니다.클라이언트는 SASL/EXTERNAL을 사용함으로써 하위 레벨에서 제공되는 자격 정보(TLS 등)에서 식별 정보를 얻도록 서버에 요구합니다.기술적으로는 서버는 하위 수준에서 확립된 ID 정보를 사용할 수 있지만 일반적으로 서버는 TLS에 의해 확립된 ID 정보를 사용합니다.

서버에서는, 디폴트로는, 다른 포토상에서 표준이 아닌 「LDAPS」(일반적으로 「LDAP over SSL」) 프로토콜도 서포트하고 있습니다.LDAPS는 LDAP와 2가지 점에서 다릅니다.1) 접속 시 클라이언트와 서버는 LDAP 메시지가 전송되기 전에 TLS를 확립합니다(Start 없이).TLS 동작) 및 2) TLS 종료 시 LDAPS 접속을 닫아야 합니다.

일부 "LDAPS" 클라이언트 라이브러리는 통신만 암호화하고 제공된 [20]인증서 이름과 호스트 이름을 확인하지 않습니다.

버리다

포기 조작은 서버에 메시지 ID로 명명된 조작을 중단하도록 요구합니다.서버는 요구를 받아들일 필요가 없습니다.포기 조작도 정상적으로 포기 조작도 응답을 송신하지 않습니다.유사한 Cancel 확장 조작은 응답을 전송하지만 모든 구현에서 이를 지원하는 것은 아닙니다.

언바인드

언바인드 조작은, 미결의 조작을 모두 폐기하고, 접속을 종료합니다.응답이 없습니다.이름은 이력에서 유래한 것으로 Bind [21]조작의 반대는 아닙니다.

클라이언트는 단순히 연결을 닫는 것만으로 세션을 중단할 수 있지만 [22]Unbind를 사용해야 합니다.Unbind를 사용하면 서버는 정상적으로 접속을 닫고 클라이언트가 접속을 포기했음을 검출할 때까지 일정 시간 동안 자원을 해방할 수 있습니다.또한 취소할 수 있는 작업을 취소하고 [23]취소할 수 없는 작업에 대한 응답을 보내지 않도록 서버에 지시합니다.

URI 방식

LDAP Uniform Resource Identifier(URI; 유니폼자원 식별자) 방식이 존재하며 클라이언트는 이를 다양한 수준으로 지원하며 서버는 참조 및 계속 참조로 반환됩니다(RFC 4516 참조).

ldap://host: 포트/DN?아트리뷰트?스코프?필터?확장

다음에 설명하는 대부분의 컴포넌트는 옵션입니다.

  • host는 검색할 LDAP 서버의 FQDN 또는 IP 주소입니다.
  • port는 LDAP 서버의 네트워크 포트(기본 포트 389)입니다.
  • DN은 검색 기준으로 사용할 고유 이름입니다.
  • attributes는 취득하는 Atribute의 쉼표로 구분된 목록입니다.
  • scope는 검색 범위를 지정하고 "base"(기본값), "one" 또는 "sub"일 수 있습니다.
  • filter는 검색 필터입니다.예를들면,(objectClass=*)RFC 4515에 정의되어 있습니다.
  • 확장자는 LDAP URL 형식의 확장자입니다.

예를 들어 "ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com"는 John Doe의 엔트리에 있는 모든 사용자 속성을 나타냅니다.ldap.example.com한편,ldap:///dc=example,dc=com??sub?(givenName=John)디폴트 서버내의 엔트리를 검색합니다(트리플 슬래시, 호스트 생략, 더블 물음표, 속성 생략).다른 URL과 마찬가지로 특수문자는 퍼센트로 인코딩해야 합니다.

유사한 비표준이 있습니다.ldapsLDAP over SSL의 URI 스킴.이것은, TLS 를 사용한LDAP 와 혼동하지 말아 주세요.LDAP 는 Start 를 사용하여 실현됩니다.표준을 사용한 TLS 동작ldap스킴을 설정합니다.

스키마

서브트리의 엔트리의 내용은 디렉토리 스키마, 디렉토리 정보 트리(DIT)의 구조에 관한 일련의 정의 및 제약에 의해 제어됩니다.

디렉토리 서버의 스키마는 서버가 보유할 수 있는 정보의 종류를 제어하는 일련의 규칙을 정의합니다.여기에는 다음과 같은 여러 요소가 있습니다.

  • [Attribute Syntaxes] : Atribute에 저장할 수 있는 정보의 종류에 대한 정보를 제공합니다.
  • [Matching Rules] : Atribute 값과 비교하는 방법에 대한 정보를 제공합니다.
  • 일치 규칙 사용:특정 일치 규칙과 함께 사용할 수 있는 속성 유형을 지정합니다.
  • [Attribute Types] : 특정 Atribute를 참조할 수 있는 Object Identifier(OID) 및 이름 세트를 정의하고 해당 Atribute를 구문 및 일치 규칙 세트와 관련짓습니다.
  • 오브젝트 클래스: 이름 있는 Atribute 컬렉션을 정의하고 그것들을 필수 Atribute 세트와 임의 Atribute 세트로 분류합니다.
  • [Name Forms] : 엔트리의 RDN에 포함해야 할 속성 세트의 규칙을 정의합니다.
  • [Content Rules] : 엔트리와 함께 사용할 수 있는 오브젝트클래스 및 Atribute에 대한 추가 제약을 정의합니다.
  • [Structure Rule] : 특정 엔트리가 가질 수 있는 하위 엔트리의 종류를 제어하는 규칙을 정의합니다.

속성은 디렉토리에 정보를 저장하는 요소이며 스키마는 엔트리에서 사용할 수 있는 Atribute의 규칙, Atribute의 종류 및 클라이언트가 이러한 값과 상호 작용하는 방법을 정의합니다.

클라이언트는 적절한 서브헤마 서브엔트리를 취득함으로써 서버가 지원하는 스키마 요소에 대해 학습할 수 있습니다.

스키마는 오브젝트 클래스를 정의합니다.각 엔트리에는 스키마에서 정의된 이름 있는 클래스를 포함하는 objectClass 속성이 있어야 합니다.엔트리의 클래스에 대한 스키마 정의는 엔트리가 나타낼 수 있는 오브젝트(예: 사용자, 조직 또는 도메인)의 종류를 정의합니다.오브젝트 클래스 정의에서는 값을 포함해야 하는 속성 목록과 값을 포함할 수 있는 속성 목록도 정의합니다.

예를 들어, 사용자를 나타내는 항목은 "top" 및 "person" 클래스에 속할 수 있습니다."person" 클래스의 멤버십에서는 엔트리에 "sn" 및 "cn" 속성이 포함되어 있어야 하며 엔트리에 "userPassword", "telephoneNumber" 및 기타 속성을 포함할 수도 있습니다.엔트리는 여러 ObjectClasses 값을 가질 수 있기 때문에 각 엔트리는 자신이 나타내는 오브젝트클래스의 조합으로 구성된 옵션 및 필수 속성 세트의 복합체를 가집니다.ObjectClasses는 상속할 수 있으며, 1개의 엔트리에 여러 ObjectClasses 값을 포함할 수 있습니다.이 값은 엔트리 자체의 사용 가능한 필수 속성을 정의합니다.objectClass 스키마와의 병렬은 객체 지향 프로그래밍의 클래스 정의 및 인스턴스이며 각각 LDAP objectClass와 LDAP 엔트리를 나타냅니다.

디렉토리 서버는, 엔트리의 subscemaSubentry 조작 어트리뷰트에 의해서 주어진 베이스 DN 로 엔트리를 제어하는 디렉토리 스키마를 퍼블리시 할 수 있습니다.(조작 어트리뷰트는 사용자 정보가 아닌 디렉토리의 조작을 나타내며, 명시적으로 요구되었을 때만 검색에서 반환됩니다).

서버 관리자는 제공된 스키마 요소 외에 스키마 항목을 추가할 수 있습니다.조직 내에서 개개의 사용자를 나타내는 스키마를 화이트 페이지 스키마라고 합니다.

바리에이션

서버의 조작의 대부분은, 실장자 또는 관리자에게 맡겨져 있습니다.따라서 서버는 다양한 시나리오를 지원하도록 설정할 수 있습니다.

예를 들어, 서버의 데이터 저장소가 지정되지 않았습니다. 즉, 서버가 플랫 파일이나 데이터베이스를 사용하거나 다른 서버에 대한 게이트웨이일 수 있습니다.액세스 컨트롤은 표준화되어 있지 않습니다.다만, 이것에 대한 작업이 행해지고 있어, 일반적으로 사용되는 모델이 있습니다.사용자의 비밀번호는 사용자의 엔트리 또는 다른 곳에 저장될 수 있습니다.서버가 원할 때 조작을 거부하고 다양한 제한을 가할 수 있습니다.

LDAP의 대부분은 확장 가능합니다.예:새로운 조작을 정의할 수 있습니다.컨트롤은 예를 들어 정렬된 검색 결과를 요청하도록 요청 및 응답을 수정할 수 있습니다.새로운 검색 범위와 바인드 방식을 정의할 수 있습니다.속성에는 의미를 변경할 수 있는 옵션이 있을 수 있습니다.

기타 데이터 모델

LDAP가 강화됨에 따라 공급업체는 LDAP를 다른 서비스에 대한 액세스 프로토콜로 제공하고 있습니다.그 후, 실장에서는 LDAP/X.500 모델을 모방하기 위해서 데이터를 재캐스트 합니다만, 이 모델을 얼마나 밀접하게 따르는지는 다릅니다.예를 들어 LDAP를 통해 SQL 데이터베이스에 액세스하기 위한 소프트웨어가 있지만 LDAP는 이에 [24]쉽게 적합하지 않습니다.X.500 서버는 LDAP도 지원할 수 있습니다.

마찬가지로 이전에 다른 유형의 데이터스토어에 보관되어 있던 데이터가 LDAP 디렉토리로 이동하는 경우도 있습니다.예를 들어 Unix 사용자 및 그룹 정보를 LDAP에 저장하고 PAM 및 NSS 모듈을 통해 액세스할 수 있습니다.LDAP 는 인증이나 인가(이미 인증된 사용자가 어떤 서비스에 대해 수행할 수 있는 액션)에 다른 서비스에서 자주 사용됩니다.예를 들어 Active Directory에서는 Kerberos가 인증 스텝에서 사용되고 LDAP가 인가 스텝에서 사용됩니다.

이러한 데이터 모델의 예로는 GLUE [25]Schema가 있습니다.이 스키마는 사용자, 애플리케이션 및 서비스가 그리드 인프라에 존재하는 서비스 및 그 구조와 상태에 대한 추가 정보를 검색할 수 있도록 LDAP 기반의 분산 정보 시스템에서 사용됩니다.

사용.

LDAP 서버는, 자신을 만족시킬 수 없는 요구에 대해서, 다른 서버에의 참조를 반환할 수 있습니다.여기에는 LDAP 엔트리의 이름 구조가 필요합니다.그러면 X.500 디렉토리에서 정의되어 LDAP에서도 사용되는 개념인 특정 Distinguished Name(DN; 인정자명)을 가진 서버를 검색할 수 있습니다.조직의 LDAP 서버를 찾는 또 다른 방법은 DNS 서버 레코드(SRV)입니다.

도메인이 example.org인 조직은 최상위 LDAP DN을 사용할 수 있습니다.dc=example,dc=org(dc는 도메인컴포넌트를 의미합니다).LDAP 서버의 이름도 ldap.example.org 로 되어 있는 경우, 조직의 최상위 LDAP URL 는ldap://ldap.example.org/dc=example,dc=org.

X.500 [ 2008 ]및 LDAPv3 에서는, 주로 2개의 일반적인 타입의 이름이 사용됩니다.이러한 내용은 ITU 사양 및 IETF RFC에 기재되어 있습니다.원본 형식은 다음과 같은 최상위 개체를 국가 개체로 사용합니다.c=US,c=FR도메인 컴포넌트 모델은 위에서 설명한 모델을 사용합니다.국가 기반 이름의 예는 다음과 같습니다.l=Locality, ou=Some Organizational Unit, o=Some Organization, c=FR또는 미국:cn=Common Name, l=Locality, ou=Some Organizational Unit, o=Some Organization, st=CA, c=US.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "Network Working Group RFC 4511". IETF.org. 2006-06-01. Retrieved 2014-04-04.
  2. ^ "Directory Services LDAP". Oracle.com. Retrieved 2014-04-04.
  3. ^ LDAP란?Gracion.com 를 참조해 주세요.2013-07-17에 회수.
  4. ^ "Introduction to OpenLDAP Directory Services". OpenLDAP. Retrieved 1 February 2016.
  5. ^ "LDAP - Lightweight Directory Access Protocol". Webopedia.com. 4 December 1996. Retrieved 2014-04-05.
  6. ^ X.500 시리즈 - ITU-T Rec. X.500 ~ X.521
  7. ^ Howes, Tim. "The Lightweight Directory Access Protocol: X.500 Lite" (PDF). Retrieved 26 December 2012.
  8. ^ "Pre-History of LDAP". Cyber Matters. 2013-04-09. Retrieved 5 October 2014.
  9. ^ "Service Name and Transport Protocol Port Number Registry". IANA. Retrieved 24 March 2021.
  10. ^ RFC3494
  11. ^ RFC4511의 추가 섹션
  12. ^ LDAP 결과 코드
  13. ^ IANA에서의 SASL 메커니즘
  14. ^ RFC4511: 삭제 요구
  15. ^ Boreham 드래프트(수하위)
  16. ^ RFC4511 섹션 변경
  17. ^ Zeilenga, K. LDAP Modify-Increment Extension. doi:10.17487/RFC4525. RFC 4525.
  18. ^ Zeilenga, K. Lightweight Directory Access Protocol (LDAP) Read Entry Controls. IETF. doi:10.17487/RFC4527. RFC 4527.
  19. ^ INTERNET-DRAFT LDAP 트랜잭션 draft-zeilenga-ldap-txn-15.txt
  20. ^ Shibboleth 보안 경보 20120227
  21. ^ Tools.ietf.org
  22. ^ Tools.ietf.org
  23. ^ Tools.ietf.org
  24. ^ Openldap.org
  25. ^ Open Grid Forum : 프로젝트 홈

원천

  • ITU-T Rec. X.680, "구문표기 1(ASN.1) 추상 - 기본표기 사양", 1994
  • Basic Encoding Rules (BER; 기본 부호화 규칙) - ITU-T Rec. X.690, "ASN.1 부호화 규칙의 사양: 기본 부호화 규칙, 표준 부호화 규칙, 식별 부호화 규칙", 1994
  • RFC 3641 - ASN.1 유형의 범용 문자열 인코딩 규칙(GSER)
  • RFC 4346 - TLS 프로토콜 버전 1.1
  • RFC 4422 - 심플 인증 및 보안 레이어(SASL)
  • IANA에 등록된 SASL 메커니즘

추가 정보

외부 링크