LDAP

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

LDAP(Lightweight Directory Access Protocol)는 디렉터리 서비스에 접근하기 위한 개방형, 산업 표준 응용 프로그램 프로토콜이다. 1990년대 초 X.500 디렉터리 서비스에 접근하기 위한 경량 대안으로 개발되었으며, TCP/IP 프로토콜 스택을 사용하여 X.500의 DAP(Directory Access Protocol)보다 간단하게 구현되었다. LDAP는 디렉터리 구조를 제공하며, 클라이언트와 서버 간의 통신을 위한 다양한 연산과 디렉터리 구조를 정의하는 스키마를 포함한다. LDAP는 X.500, Active Directory 등 다양한 후속 프로토콜 및 서비스에 영향을 미쳤으며, 인증, 권한 부여 등 다양한 사용 사례에 활용된다.

더 읽어볼만한 페이지

디렉토리 서비스 - 액티브 디렉터리
액티브 디렉터리는 마이크로소프트에서 개발한 디렉터리 서비스로, 윈도우 도메인 네트워크의 핵심 기반이며, 사용자, 컴퓨터, 그룹 등 네트워크 리소스에 대한 중앙 집중식 관리, 인증 및 접근 권한 제어를 제공하고, AD DS, AD LDS, AD CS, AD FS, AD RMS 등의 서비스로 구성되어 포리스트, 트리, 도메인으로 구성된 계층 구조를 가진다.
디렉토리 서비스 - X.500
X.500은 ITU-T가 정의한 디렉터리 서비스 표준으로, 분산 환경에서 정보 접근을 위한 프로토콜과 데이터 모델을 제공하며, 경량 디렉터리 접근 프로토콜(LDAP)과 X.509 인증 프레임워크에 영향을 주었다.
오픈 그룹 표준 - POSIX
POSIX는 유닉스 기반의 이식 가능한 운영체제 인터페이스를 표준화하기 위한 IEEE 표준군으로, 프로세스 관리, 파일 시스템 접근, 스레드 처리 등 핵심 서비스들을 규정하며 운영체제 간 호환성을 높이는 데 기여한다.
오픈 그룹 표준 - X 윈도 시스템
X 윈도 시스템은 네트워크 기반 분산형 윈도 시스템으로, 다양한 운영체제에서 GUI 환경을 제공하며 클라이언트-서버 모델 기반의 네트워크 투명성을 특징으로 한다.
인터넷 프로토콜 - IPTV
IPTV는 인터넷 프로토콜을 사용하여 실시간 방송, VOD 등 다양한 콘텐츠를 제공하는 텔레비전 서비스이며, 고속통신망과의 통합, 양방향 서비스 등의 장점을 가지지만 망 사업자 제한 등의 제한 사항도 존재한다.
인터넷 프로토콜 - DNSSEC
DNSSEC는 DNS의 보안 취약점을 개선하기 위해 도메인 정보에 디지털 서명을 추가하여 응답 레코드의 무결성을 보장하고 DNS 위장 공격을 막는 기술로, RRSIG, DNSKEY 등 다양한 리소스 레코드 유형을 사용하여 인증 체인을 구성하며 공개 키 암호 방식을 활용한다.

LDAP
프로토콜 개요
이름	경량 디렉터리 접근 프로토콜
영어 이름	Lightweight Directory Access Protocol (LDAP)
목적	디렉터리 서비스
기반	X.500
OSI 모델 계층	응용 계층
포트	389 (ldap), 636 (ldaps)
RFC	RFC 4510 RFC 4511

2. 역사

통신 회사들은 약 70년간의 전화번호부 제작 및 관리를 통해 디렉터리 요구 사항에 대한 이해도가 높았다. 이들은 1980년대 국제전기통신연합(ITU)에서 제작한 프로토콜 모음인 포괄적인 X.500 규격을 만들었다.^[6]

X.500 디렉터리 서비스는 전통적으로 X.500 디렉터리 액세스 프로토콜(DAP)을 통해 액세스되었으며, 이는 개방형 시스템 상호 연결(OSI) 프로토콜 스택을 필요로 했다. LDAP는 원래 더 간단한 (그리고 현재 널리 사용되는) TCP/IP 프로토콜 스택을 통해 X.500 디렉터리 서비스에 액세스하기 위한 경량 대안 프로토콜로 의도되었다. 이러한 디렉터리 액세스 모델은 DIXIE 및 디렉터리 지원 서비스 프로토콜에서 차용되었다.

이 프로토콜은 원래 1993년경에 미시간 대학교의 Tim Howes, Isode Limited의 Steve Kille, Nexor의 Colin Robbins, Performance Systems International의 Wengyik Yeong에 의해 DIXIE 및 DAS의 후속 프로토콜로 제작되었다.^[7]^[8] Critical Angle Inc.의 Mark Wahl, Tim Howes, Steve Kille은 1996년에 인터넷 엔지니어링 태스크 포스(IETF)의 후원 하에 새로운 버전의 LDAP인 LDAPv3 작업을 시작했다. 1997년에 처음 게시된 LDAPv3는 LDAPv2를 대체하고 확장성 지원을 추가했으며, 단순 인증 및 보안 계층을 통합하고 X.500의 1993년판에 프로토콜을 더 잘 맞추었다. LDAPv3 사양 자체의 추가 개발과 LDAPv3에 기능을 추가하는 수많은 확장은 IETF를 통해 이루어졌다.

LDAP의 초기 엔지니어링 단계에서는 ''경량 디렉터리 브라우징 프로토콜'' 또는 ''LDBP''로 알려졌다. 디렉터리 브라우징 및 검색을 넘어 디렉터리 업데이트 기능을 포함하도록 프로토콜의 범위를 확장하면서 이름이 변경되었다. DAP 이전 버전보다 네트워크 집약적이지 않아 비교적 적은 대역폭 사용량으로 인해 인터넷을 통해 더 쉽게 구현할 수 있었기 때문에 "경량"이라는 이름이 붙었다.

LDAP는 X.500의 후속 버전, XML 사용 디렉터리(XED), 디렉터리 서비스 마크업 언어(DSML), 서비스 프로비저닝 마크업 언어(SPML), 서비스 위치 프로토콜(SLP)을 포함한 후속 인터넷 프로토콜에 영향을 미쳤다. 또한 마이크로소프트의 Active Directory의 기반으로 사용된다.

3. LDAP과 X.500의 차이점

LDAP는 X.500의 DAP를 경량화한 것이다.^[6] X.500에는 DAP 외에도 DSP, DOP, DISP 프로토콜이 규정되어 있지만, LDAP에는 이 세 가지 프로토콜이 존재하지 않는다.

프로토콜	설명
DUA(Directory User Agent)	디렉터리 사용자를 대신하여 디렉터리에 접근하는 기능(프로그램, 명령, 라이브러리)
DSA(Directory Service Agent)	디렉터리 정보를 관리하는 개별 시스템. 디렉토리는 DSA의 집합체로 구성된다.
DAP(Directory Access Protocol)	DSA가 DUA에게 디렉터리 서비스를 제공하기 위한 프로토콜
DSP(Directory System Protocol)	DSA 간에 분산 협조 동작(연쇄 및 소개)을 수행하기 위한 프로토콜
DOP(Directory Operational binding management Protocol)	디렉터리 운영 결합 관리 프로토콜. DSA 간의 운영 결합의 규정 내용 및 상태 교환에 사용되는 프로토콜
DISP(Directory Information Shadowing Protocol)	DSA 간에 복제 정보를 교환하기 위한 프로토콜

X.500의 DAP는 개방형 시스템 상호 연결(OSI) 각 계층의 표준 프로토콜을 사용한다. LDAP는 TCP/IP 위에 구현되므로 DAP에 있는 ROSE, RTSE, ACSE를 구현하지 않는다. (이러한 기능은 TCP/IP 내에서 구현되므로 LDAP에서는 불필요하다)

ROSE(Remote Operation Service Element): 원격 조작 서비스 요소, 처리 요청과 결과 통지라는 통신 메커니즘을 실현하는 프로토콜 요소
RTSE(Reliable Transfer Service Element): 고신뢰 전송 서비스 요소, 통신 경로 장애 등으로 인해 정보 손실 또는 중복이 발생하지 않도록 하는 프로토콜 요소
ACSE(Association Control Service Element): 어소시에이션 제어 서비스 요소, 커넥션의 확립, 정상 해제, 이상 해제를 수행하는 서비스 요소

4. 프로토콜 개요

클라이언트는 기본적으로 TCP 및 UDP 포트 389 또는 LDAPS(TLS/SSL을 통한 LDAP)의 경우 포트 636을 통해 디렉터리 시스템 에이전트(DSA)라고 하는 LDAP 서버에 연결하여 LDAP 세션을 시작한다.^[9] 클라이언트는 서버에 작업 요청을 보내고, 서버는 응답을 반환한다. 클라이언트는 다음 요청을 보내기 전에 응답을 기다릴 필요가 없으며 서버는 응답을 임의의 순서로 보낼 수 있다. 모든 정보는 기본 인코딩 규칙(BER)을 사용하여 전송된다.^[9]

LDAP는 X.500의 경량화된 버전으로, TCP/IP 환경에서 디렉터리 서비스에 접근하기 위해 설계되었다. 1993년 미시간 대학교 등에서 DIXIE 및 DAS의 후속 프로토콜로 개발되었으며,^[7]^[8] 1996년 인터넷 엔지니어링 태스크 포스(IETF)의 후원으로 LDAPv3가 개발되었다.^[6] LDAPv3는 LDAPv2를 대체하고 확장성 지원 및 단순 인증 및 보안 계층 통합 등을 통해 X.500에 더 잘 맞도록 개선되었다.

4. 1. 클라이언트 요청

클라이언트는 서버에 다음과 같은 작업을 요청할 수 있다.

StartTLS - 보안 접속을 위해 LDAPv3 전송 계층 보안(TLS) 확장을 사용한다.^[9]
Bind - 인증 및 LDAP 프로토콜 버전을 지정한다.
Search - 디렉터리 엔트리를 검색 및 확인한다.
Compare - 명명된 엔트리가 주어진 특성 값을 포함하는지 시험한다.
새로운 엔트리를 추가한다.
엔트리를 지운다.
엔트리를 수정한다.
DN(Distinguished Name)을 수정한다 - 엔트리를 이동하거나 엔트리의 이름을 바꾼다.
Abandon - 이전의 요청을 중단한다.
Extended Operation - 다른 오퍼레이션을 정의하기 위해 사용되는 일반적인 오퍼레이션이다.
Unbind - 연결을 닫는다 (Bind의 반대가 아님).^[9]

클라이언트는 기본적으로 TCP 및 UDP 포트 389 또는 LDAPS(TLS/SSL을 통한 LDAP)의 경우 포트 636을 통해 디렉터리 시스템 에이전트(DSA)라고 하는 LDAP 서버에 연결하여 LDAP 세션을 시작한다.^[9] 그런 다음 클라이언트는 서버에 작업 요청을 보내고, 서버는 응답을 반환한다. 몇 가지 예외를 제외하고 클라이언트는 다음 요청을 보내기 전에 응답을 기다릴 필요가 없으며 서버는 응답을 임의의 순서로 보낼 수 있다. 모든 정보는 기본 인코딩 규칙(BER)을 사용하여 전송된다.^[9]

또한 서버는 임의의 요청에 대한 응답이 아닌 "요청하지 않은 알림"을 보낼 수 있다 (예: 연결 시간 초과 전).^[9]

LDAP 통신을 보호하는 일반적인 대안은 SSL 터널링 프로토콜을 사용하는 것이다. SSL을 통한 LDAP의 기본 포트는 636이다. SSL을 통한 LDAP은 LDAP 버전 2(LDAPv2)에서 일반적이었지만 공식적인 사양으로 표준화되지 않았다. 이 사용법은 2003년에 공식적으로 폐기된 LDAPv2와 함께 더 이상 사용되지 않는다.^[10]

4. 2. 추가 요청

서버는 임의의 요청에 대한 응답이 아닌 "요청하지 않은 알림"을 보낼 수 있다 (예: 연결 시간 초과 전).^[9]

LDAP 통신을 보호하는 일반적인 대안은 SSL 터널링 프로토콜을 사용하는 것이다. SSL을 통한 LDAP의 기본 포트는 636이다. SSL을 통한 LDAP은 LDAP 버전 2(LDAPv2)에서 일반적이었지만 공식적인 사양으로 표준화되지 않았다. 이 사용법은 2003년에 공식적으로 폐기된 LDAPv2와 함께 더 이상 사용되지 않는다.^[10]

5. 디렉터리 구조

LDAP 프로토콜은 1993년판 X.500 모델을 따르는 디렉터리에 대한 인터페이스를 제공한다.^[6]

항목은 일련의 속성으로 구성된다.
속성은 이름(''속성 유형'' 또는 ''속성 설명'')과 하나 이상의 값을 갖는다. 속성은 ''스키마''에 정의되어 있다.
각 항목은 고유한 식별자를 갖는데, 이는 ''고유 이름''(DN)이다. DN은 항목의 일부 속성으로 구성된 ''상대 고유 이름''(RDN)과 그 뒤에 오는 상위 항목의 DN으로 구성된다. DN을 전체 파일 경로로, RDN을 상위 폴더 내의 상대 파일 이름으로 생각하면 된다(예: `/foo/bar/myfile.txt`가 DN이라면, `myfile.txt`는 RDN이 된다).

DN은 항목이 트리 내에서 이동하는 경우와 같이 항목의 수명 동안 변경될 수 있다.^[6] 항목을 안정적이고 모호하지 않게 식별하기 위해 UUID가 항목의 ''운영 속성'' 집합에 제공될 수 있다.^[6]

항목은 LDAP 데이터 교환 형식 (LDIF)으로 표현될 수 있다. LDIF는 일반 텍스트 형식이다.^[6]

```ldif

dn: cn=John Doe,dc=example,dc=com

cn: John Doe

givenName: John

sn: Doe

telephoneNumber: +1 888 555 6789

telephoneNumber: +1 888 555 1232

mail: john@example.com

manager: cn=Barbara Doe,dc=example,dc=com

objectClass: inetOrgPerson

objectClass: organizationalPerson

objectClass: person

objectClass: top

```

"dn^영어"은 항목의 고유 이름이며, 속성도 항목의 일부도 아니다. "cn=John Doe"는 항목의 RDN(상대 고유 이름)이고, "dc=example,dc=com"은 상위 항목의 DN이며, 여기서 "dc"는 '도메인 구성 요소'를 나타낸다. 다른 줄은 항목의 속성을 보여준다. 속성 이름은 일반적으로 일반 이름의 cn^영어, 도메인 구성 요소의 dc^영어, 이메일 주소의 mail^영어, 성의 sn^영어과 같은 기억하기 쉬운 문자열이다.^[11]

서버는 "dc=example,dc=com"과 그 자식 항목과 같이 특정 항목에서 시작하는 하위 트리를 보유한다. 서버는 다른 서버에 대한 참조를 보유할 수도 있으므로, "ou=department,dc=example,dc=com"에 대한 접근 시도는 디렉터리 트리의 해당 부분을 보유하는 서버에 대한 ''참조'' 또는 ''연속 참조''를 반환할 수 있다. 그러면 클라이언트는 다른 서버에 연락할 수 있다. 일부 서버는 서버가 다른 서버에 연락하여 클라이언트에게 결과를 반환하는 ''체이닝''도 지원한다.^[6]

LDAP는 순서를 거의 정의하지 않는다. 서버는 속성의 값, 항목의 속성, 검색 작업으로 찾은 항목을 어떤 순서로든 반환할 수 있다. 이는 공식 정의에서 비롯된다. 항목은 속성의 집합으로 정의되고, 속성은 값의 집합으로 정의되며, 집합은 정렬될 필요가 없다.^[6]

6. 연산

클라이언트는 다음과 같은 작업을 요청할 수 있다.

'''StartTLS''' - 보안 접속을 위해 LDAPv3 TLS 확장을 사용한다.
'''Bind''' - 인증 및 LDAP 프로토콜 버전을 지정한다.
'''Search''' - 디렉터리 엔트리를 검색하고 확인한다.
'''Compare''' - 명명된 엔트리가 주어진 특성 값을 포함하는지 시험한다.
새로운 엔트리를 추가한다.
엔트리를 지운다.
엔트리를 수정한다.
'''DN(Distinguished Name)을 수정''' - 엔트리를 이동하거나 엔트리의 이름을 바꾼다.
'''Abandon''' - 이전의 요청을 중단한다.
'''Extended Operation''' - 다른 오퍼레이션을 정의하기 위해 사용되는 일반적인 오퍼레이션이다.
'''Unbind''' - 연결을 닫는다. (Bind의 반대가 아님)

클라이언트는 기본적으로 TCP 및 UDP 포트 389 또는 LDAPS(TLS/SSL을 통한 LDAP)의 경우 포트 636을 통해 디렉터리 시스템 에이전트(DSA)라고 하는 LDAP 서버에 연결하여 LDAP 세션을 시작한다.^[9] 그런 다음 클라이언트는 서버에 작업 요청을 보내고, 서버는 응답을 반환한다. 몇 가지 예외를 제외하고 클라이언트는 다음 요청을 보내기 전에 응답을 기다릴 필요가 없으며 서버는 응답을 임의의 순서로 보낼 수 있다. 모든 정보는 기본 인코딩 규칙(BER)을 사용하여 전송된다.

또한 서버는 임의의 요청에 대한 응답이 아닌 "요청하지 않은 알림"을 보낼 수 있다 (예: 연결 시간 초과 전).

LDAP 통신을 보호하는 일반적인 대안은 SSL 터널링 프로토콜을 사용하는 것이다. SSL을 통한 LDAP의 기본 포트는 636이다. SSL을 통한 LDAP은 LDAP 버전 2(LDAPv2)에서 일반적이었지만 공식적인 사양으로 표준화되지 않았다. 이 사용법은 2003년에 공식적으로 폐기된 LDAPv2와 함께 더 이상 사용되지 않는다.^[10]

6. 1. Add

ADD 연산은 디렉터리 서버 데이터베이스에 새로운 항목을 삽입한다.^[12] 추가 요청의 고유 이름이 디렉터리에 이미 존재하는 경우, 서버는 중복 항목을 추가하지 않는다.^[13]

LDAP을 준수하는 서버는 다음을 보장한다.

항목을 찾으려고 시도할 때 추가 요청으로 전송된 고유 이름을 절대 참조 해제하지 않는다.
고유 이름과 모든 속성이 명명 표준을 준수한다.
추가할 항목이 존재하지 않아야 하고, 바로 상위 항목이 존재해야 한다.

```text

dn: uid=user,ou=people,dc=example,dc=com

changetype: add

objectClass: top

objectClass: person

uid: user

sn: last-name

cn: common-name

userPassword: password

```

위 예에서 `uid=user,ou=people,dc=example,dc=com`은 존재하지 않아야 하며 `ou=people,dc=example,dc=com`은 존재해야 한다.

6. 2. Bind (인증)

LDAP 세션이 생성될 때 (즉, LDAP 클라이언트가 서버에 연결될 때) 세션의 인증 상태는 익명으로 설정된다.^[9] BIND 작업은 세션의 인증 상태를 설정한다.

단순 BIND 및 SASL PLAIN은 사용자의 DN과 비밀번호를 평문으로 전송할 수 있으므로, 단순 또는 SASL PLAIN을 사용하는 연결은 전송 계층 보안(TLS)을 사용하여 암호화해야 한다. 서버는 일반적으로 명명된 항목의 `userPassword` 속성에 대해 비밀번호를 확인한다. 익명 BIND (빈 DN 및 비밀번호 사용)는 연결을 익명 상태로 재설정한다.

SASL BIND는 Kerberos 또는 TLS와 함께 전송되는 클라이언트 인증서와 같은 광범위한 메커니즘을 통해 인증 서비스를 제공한다.^[14]

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

BIND는 LDAPv2에서 세션의 첫 번째 작업이어야 했지만, LDAPv3에서는 필요하지 않다. LDAPv3에서 각 성공적인 BIND 요청은 세션의 인증 상태를 변경하고, 각 실패한 BIND 요청은 세션의 인증 상태를 재설정한다.

6. 3. Delete

LDAP 클라이언트는 적절하게 구성된 삭제 요청을 서버로 전송하여 엔트리를 삭제한다.^[15] 삭제 요청에는 다음 사항이 포함되어야 한다.

삭제할 엔트리의 고유 이름
요청 제어 (선택 사항)

서버는 삭제 요청을 처리할 때 별칭을 참조하지 않는다. 삭제 요청으로는 하위 항목이 없는 리프 엔트리만 삭제할 수 있다. 일부 서버는 엔트리에 하위 항목이 있는지 여부를 나타내는 운영 속성 `hasSubordinates`를 지원하며, 종속된 엔트리의 수를 나타내는 `numSubordinates` 속성을 지원하기도 한다.^[16]

일부 서버는 접근 제어에 따라 DN 및 DN에 종속된 모든 객체의 삭제를 허용하는 하위 트리 삭제 요청 제어를 지원한다. 삭제 요청은 접근 제어의 적용을 받으며, 주어진 인증 상태의 연결이 주어진 엔트리를 삭제할 수 있는지 여부는 서버별 접근 제어 메커니즘에 의해 관리된다.

6. 4. Search and Compare

클라이언트는 서버에 작업 요청을 보내고, 서버는 이에 대한 응답을 반환한다. 클라이언트는 검색(Search) 및 비교(Compare) 작업을 요청할 수 있다.

검색 작업은 항목을 검색하고 읽는 데 사용된다. 서버는 일치하는 항목과 지속 참조(Continuation Reference)를 반환하며, 이들은 어떤 순서로든 반환될 수 있다. 최종 결과에는 결과 코드가 포함된다.^[9]

검색 작업의 매개변수는 다음과 같다.

매개변수	설명
baseObject	검색을 수행할 기준 객체 항목(또는 루트)의 이름
scope	baseObject 아래에서 검색할 요소. `BaseObject`(명명된 항목만 검색), `singleLevel`(base DN 바로 아래 항목), `wholeSubtree`(base DN에서 시작하는 전체 하위 트리) 중 하나
filter	(givenName=John)(mail=john*)))` 필터는 "person" 객체 클래스 중 `givenName`이 "John"이거나 `mail`이 "john"으로 시작하는 항목을 선택.
derefAliases	별칭 항목(다른 항목을 참조하는 항목)을 따를지 여부와 방법
attributes	결과 항목에서 반환할 속성
sizeLimit, timeLimit	반환할 항목의 최대 수와 검색 실행 최대 시간 (서버 설정에 따라 무시될 수 있음)
typesOnly	속성 값 대신 속성 유형만 반환

비교 작업은 DN, 속성 이름, 속성 값을 받아, 명명된 항목에 해당 속성이 해당 값을 가지고 있는지 확인한다.^[9]

6. 5. Modify

MODIFY 작업은 LDAP 클라이언트가 LDAP 서버에 기존 항목을 변경하도록 요청하는 데 사용된다.^[17] 존재하지 않는 항목을 수정하려는 시도는 실패한다. MODIFY 요청은 서버에서 구현된 접근 제어에 따른다.

MODIFY 작업은 항목의 고유 이름(DN)과 일련의 변경 사항을 지정해야 한다. 각 변경 사항은 다음 중 하나여야 한다.

add (새 값을 추가, 속성에 이미 존재하지 않아야 함)
delete (기존 값 삭제)
replace (기존 값을 새 값으로 대체)

LDIF 속성에 값을 추가하는 예는 다음과 같다.

```text

dn: dc=example,dc=com

changetype: modify

add: cn

cn: the-new-cn-value-to-be-added

```

기존 속성의 값을 바꾸려면 `replace` 키워드를 사용한다. 속성이 다중 값인 경우, 클라이언트는 업데이트할 속성의 값을 지정해야 한다.

항목에서 속성을 삭제하려면 `delete` 키워드와 변경 유형 지정자 `modify`를 사용한다. 속성이 다중 값인 경우, 클라이언트는 삭제할 속성의 값을 지정해야 한다.

또한 지정된 양만큼 증가 가능한 속성 값을 증가시킬 수 있는 Modify-Increment 확장^[18]이 있다. LDIF를 사용하는 다음 예에서는 `employeeNumber`를 `5`만큼 증가시킨다.

```text

dn: uid=user.0,ou=people,dc=example,dc=com

changetype: modify

increment: employeeNumber

employeeNumber: 5

```

LDAP 서버가 복제된 토폴로지에 있는 경우, LDAP 클라이언트는 업데이트 후 검색 대신 사후 읽기 제어를 사용하여 업데이트를 확인하는 것을 고려해야 한다.^[19] 사후 읽기 제어는 애플리케이션이 업데이트 후 검색 요청을 발행할 필요가 없도록 설계되었다. 복제 결과적 일관성 모델 때문에 업데이트가 작동했는지 확인하기 위한 목적으로만 항목을 검색하는 것은 좋지 않다. LDAP 클라이언트는 아키텍처가 LDAP 클라이언트와 서버 사이에 로드 밸런서 또는 LDAP 프록시 또는 둘 다 배치했을 수 있으므로 각 요청에 대해 동일한 디렉터리 서버에 연결한다고 가정해서는 안 된다.

6. 6. Modify DN

Modify DN(항목 이동/이름 변경)은 새로운 RDN, 선택적으로 새로운 상위 항목의 DN, 그리고 이전 RDN과 일치하는 항목의 값을 삭제할지 여부를 나타내는 플래그를 사용한다. 서버는 전체 디렉터리 하위 트리의 이름 변경을 지원할 수 있다.^[10]

6. 7. Extended operations

확장 작업(Extended Operation)은 원래 프로토콜 사양에 포함되지 않은 새로운 작업을 정의할 수 있는 일반적인 LDAP 작업이다. StartTLS는 가장 중요한 확장 중 하나이다. 다른 예로는 취소 및 암호 수정이 있다.^[10]

6. 7. 1. StartTLS

StartTLS 작업은 연결에 전송 계층 보안(SSL의 후속 기술)을 설정한다. 이는 데이터 기밀성(제3자에 의한 데이터 관찰을 방지) 및/또는 데이터 무결성 보호(데이터 변조 방지)를 제공할 수 있다.^[10] TLS 협상 중에 서버는 자신의 X.509 인증서를 전송하여 신원을 증명한다. 클라이언트도 신원을 증명하기 위해 인증서를 전송할 수 있다. 그렇게 한 후 클라이언트는 SASL/EXTERNAL을 사용할 수 있다. SASL/EXTERNAL을 사용하여 클라이언트는 서버가 하위 수준(예: TLS)에서 제공된 자격 증명에서 신원을 파생하도록 요청한다. 기술적으로 서버는 하위 수준에서 설정된 모든 신원 정보를 사용할 수 있지만, 일반적으로 서버는 TLS에 의해 설정된 신원 정보를 사용한다.

서버는 또한 별도의 포트(기본적으로 636)에서 비표준 "LDAPS"("보안 LDAP", 일반적으로 "SSL over LDAP"으로 알려짐) 프로토콜을 지원하는 경우가 많다. LDAPS는 다음과 같은 두 가지 면에서 LDAP과 다르다.^[21]

1. 연결 시 클라이언트와 서버는 LDAP 메시지가 전송되기 전에 TLS를 설정한다(StartTLS 작업 없이).

2. LDAPS 연결은 TLS 종료 시 닫혀야 한다.

6. 8. Abandon

클라이언트는 Abandon 연산을 통해 서버에게 메시지 ID로 지정된 특정 연산을 중단하도록 요청할 수 있다. 그러나 서버가 이 요청을 반드시 따라야 하는 것은 아니다.^[9] Abandon 연산이나 이 연산으로 인해 성공적으로 중단된 연산은 응답을 반환하지 않는다. 이와 유사한 Cancel 확장 연산은 응답을 보내지만, 모든 서버 구현에서 지원하는 것은 아니다.^[9]

6. 9. Unbind

Unbind 작업은 진행 중인 모든 작업을 중단하고 연결을 닫는다. 응답은 없다. 이 이름은 역사적인 기원에서 유래되었으며, Bind 작업의 정반대는 ''아니다''.^[22]

클라이언트는 단순히 연결을 닫아 세션을 중단할 수 있지만, Unbind를 사용하는 것이 좋다.^[23] Unbind를 사용하면 서버가 연결을 정상적으로 닫고, 그렇지 않으면 클라이언트가 연결을 포기했음을 발견할 때까지 일정 시간 동안 유지할 자원을 해제할 수 있다. 또한 서버에게 취소할 수 있는 작업을 취소하고, 취소할 수 없는 작업에 대한 응답을 보내지 않도록 지시한다.^[24]

7. URI 스킴

LDAP URI 스킴은 클라이언트가 다양한 수준으로 지원하며, 서버는 참조 및 연속 참조에서 이를 반환한다.^[9] 이 스킴의 형식은 다음과 같다.

`ldap://host:port/DN?attributes?scope?filter?extensions`

대부분의 구성 요소는 선택 사항이다.

`host`: 검색할 LDAP 서버의 FQDN 또는 IP 주소.
`port`: LDAP 서버의 네트워크 포트 (기본 포트 389).
`DN`: 검색 기반으로 사용할 고유 이름.
`attributes`: 검색할 속성의 쉼표로 구분된 목록.
`scope`: 검색 범위를 지정하며 "base"(기본값), "one" 또는 "sub" 중 하나.
`filter`: 검색 필터 (예: RFC 4515에 정의된 `(objectClass=*)`).
`extensions`: LDAP URL 형식의 확장.

예를 들어, `ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com`은 `ldap.example.com`의 John Doe 항목에 있는 모든 사용자 속성을 참조한다. 반면 `ldap:///dc=example,dc=com??sub?(givenName=John)`은 기본 서버에서 해당 항목을 검색한다 (호스트 생략은 슬래시 3개, 속성 생략은 물음표 2개로 표시). 다른 URL과 마찬가지로 특수 문자는 퍼센트 인코딩해야 한다.

SSL을 통한 LDAP을 위한 비표준 `ldaps` URI 스킴도 있다. 이는 표준 `ldap` 스킴을 사용하고 StartTLS 작업을 통해 수행되는 TLS를 사용하는 LDAP과는 다르다.^[10]

8. 스키마

디렉터리 하위 트리의 항목 내용은 디렉터리 스키마에 의해 관리되며, 이는 디렉터리 정보 트리(DIT)의 구조에 관한 정의와 제약 조건 집합이다.^[11]

디렉터리 서버의 스키마는 서버가 보유할 수 있는 정보의 종류를 관리하는 규칙 집합을 정의한다. 여기에는 다음과 같은 여러 요소가 포함된다.^[11]

속성 구문 - 속성에 저장할 수 있는 정보의 종류에 대한 정보를 제공한다.
매칭 규칙 - 속성 값에 대한 비교를 수행하는 방법에 대한 정보를 제공한다.
매칭 규칙 사용 - 특정 매칭 규칙과 함께 사용할 수 있는 속성 유형을 나타낸다.
속성 유형 - 객체 식별자(OID)와 주어진 속성을 참조할 수 있는 이름 집합을 정의하고, 해당 속성을 구문 및 매칭 규칙 집합과 연결한다.
객체 클래스 - 속성의 명명된 컬렉션을 정의하고, 필수 속성 및 선택적 속성 집합으로 분류한다.
이름 형식 - 항목에 대한 RDN에 포함되어야 하는 속성 집합에 대한 규칙을 정의한다.
콘텐츠 규칙 - 항목과 함께 사용할 수 있는 객체 클래스 및 속성에 대한 추가 제약 조건을 정의한다.
구조 규칙 - 주어진 항목이 가질 수 있는 하위 항목의 종류를 관리하는 규칙을 정의한다.

속성은 디렉터리에 정보를 저장하는 역할을 하며, 스키마는 항목에서 사용할 수 있는 속성, 해당 속성이 가질 수 있는 값의 종류, 그리고 클라이언트가 해당 값과 상호 작용할 수 있는 방법에 대한 규칙을 정의한다.^[11]

클라이언트는 적절한 하위 스키마 하위 항목을 검색하여 서버가 지원하는 스키마 요소에 대해 알 수 있다.^[11]

스키마는 ''객체 클래스''를 정의한다. 각 항목에는 스키마에 정의된 명명된 클래스를 포함하는 objectClass 속성이 있어야 한다.^[11] 항목의 클래스에 대한 스키마 정의는 항목이 나타낼 수 있는 객체의 종류(예: 사람, 조직 또는 도메인)를 정의한다. 객체 클래스 정의는 또한 값을 포함해야 하는 속성 목록과 값을 포함할 수 있는 속성 목록을 정의한다.^[11]

예를 들어, 사람을 나타내는 항목은 "top" 및 "person" 클래스에 속할 수 있다. "person" 클래스에 속하면 항목이 "sn" 및 "cn" 속성을 포함해야 하며, 항목이 "userPassword", "telephoneNumber" 및 기타 속성도 포함할 수 있다. 항목은 여러 ObjectClasses 값을 가질 수 있으므로, 각 항목은 나타내는 객체 클래스의 합집합으로 형성된 선택적 및 필수 속성 집합의 복합체를 갖는다. ObjectClasses는 상속될 수 있으며, 단일 항목은 항목 자체의 사용 가능한 필수 속성을 정의하는 여러 ObjectClasses 값을 가질 수 있다. objectClass의 스키마와 병렬되는 것은 각각 LDAP objectClass와 LDAP 항목을 나타내는 클래스 정의와 인스턴스 객체 지향 프로그래밍이다.^[11]

디렉터리 서버는 항목의 subschemaSubentry 운영 속성에 의해 주어진 기본 DN에서 항목을 제어하는 디렉터리 스키마를 게시할 수 있다. (''운영 속성''은 사용자 정보가 아닌 디렉터리의 작동 방식을 설명하며, 명시적으로 요청된 경우에만 검색에서 반환된다.)^[11]

서버 관리자는 제공된 스키마 요소 외에 추가 스키마 항목을 추가할 수 있다. 조직 내 개인을 나타내기 위한 스키마는 화이트 페이지 스키마라고 한다.^[11]

9. 기타 데이터 모델

LDAP가 인기를 얻으면서, 여러 벤더들이 다른 서비스에 접근하기 위한 프로토콜로 LDAP를 제공하기 시작했다. 이러한 구현은 데이터를 LDAP/X.500 모델을 따르도록 재구성하지만, 모델을 얼마나 엄격하게 따르는지는 다양하다. 예를 들어, LDAP를 통해 SQL 데이터베이스에 접근하는 소프트웨어도 존재한다.^[25] X.500 서버 역시 LDAP를 지원할 수 있다.

이전에 다른 유형의 데이터 저장소에 보관되었던 데이터가 LDAP 디렉토리로 이동되는 경우도 있다. 예를 들어, 유닉스 사용자 및 그룹 정보는 LDAP에 저장되어 PAM 및 NSS 모듈을 통해 접근할 수 있다. LDAP는 다른 서비스에서 인증 및/또는 권한 부여(이미 인증된 사용자가 특정 서비스에서 수행할 수 있는 작업)를 위해 자주 사용된다. 예를 들어, Active Directory에서는 Kerberos가 인증 단계에 사용되는 반면, LDAP는 권한 부여 단계에 사용된다.

이러한 데이터 모델의 예로는 GLUE 스키마^[26]가 있는데, 이는 LDAP 기반의 분산 정보 시스템에서 사용되어 사용자와 애플리케이션, 서비스가 그리드 인프라에 어떤 서비스가 존재하는지, 그리고 그 구조와 상태에 대한 추가 정보를 검색할 수 있게 한다.

10. 사용 예시

예를 들어, 도메인이 example.org인 조직은 최상위 LDAP DN `dc=example, dc=org`를 사용할 수 있다(여기서 'dc'는 도메인 구성 요소를 의미한다). LDAP 서버 이름이 ldap.example.org인 경우, 조직의 최상위 LDAP URL은 `ldap://ldap.example.org/dc=example,dc=org`가 된다.^[11]

ITU 사양 및 IETF RFC에는 X.500 [2008] 및 LDAPv3에서 주로 사용되는 두 가지 일반적인 명명 스타일이 문서화되어 있다.^[11] 원래 형식은 최상위 객체를 국가 객체로 사용하여 `c=US`, `c=FR`과 같다. 도메인 구성 요소 모델은 위에서 설명한 모델을 사용한다. 국가 기반 명명의 예로는 `l=지역, ou=일부 조직 단위, o=일부 조직, c=FR` 또는 미국에서 `cn=일반 이름, l=지역, ou=일부 조직 단위, o=일부 조직, st=CA, c=US`가 있다.

11. 대표적인 LDAP 구현

제조사	제품명	비고
NetIQ	NetIQ eDirectory
오라클	[http://otn.oracle.co.jp/products/oid/index.html Oracle Internet Directory]
썬 마이크로시스템즈	[http://jp.sun.com/practice/software/identity/jp/directory_srvr_ee/ Sun Java System Directory Server]
썬 마이크로시스템즈	[http://www.opends.org/ Sun OpenDS]
NEC	StarDirectory
레드햇	389 Directory Server
후지쯔	InfoDirectory
	[http://www.proofpoint.com/us/node/4053 Sendmail Directory Server]
	OpenLDAP
IBM	Tivoli Directory Server
마이크로소프트	Active Directory
	[https://directory.apache.org/ Apache Directory Server]

참조

_[1] 웹사이트 Network Working Group RFC 4511 https://tools.ietf.o[...] IETF.org 2006-06-01
_[2] 웹사이트 Directory Services LDAP https://docs.oracle.[...] Oracle.com 2014-04-04
_[3] 웹사이트 What is LDAP? http://www.gracion.c[...] Gracion.com 2013-07-17
_[4] 웹사이트 Introduction to OpenLDAP Directory Services http://www.openldap.[...] 2016-02-01
_[5] 웹사이트 LDAP - Lightweight Directory Access Protocol http://www.webopedia[...] Webopedia.com 1996-12-04
_[6] 간행물 The [[X.500]] series - ITU-T Rec. X.500 to X.521
_[7] 웹사이트 The Lightweight Directory Access Protocol: X.500 Lite http://www.openldap.[...] 2012-12-26
_[8] 웹사이트 Pre-History of LDAP http://cybermatters.[...] 2013-04-09
_[9] 웹사이트 Service Name and Transport Protocol Port Number Registry https://www.iana.org[...] IANA 2021-03-24
_[10] RFC RFC3494 http://tools.ietf.or[...]
_[11] FOLDOC Lightweight+Directory+Access+Protocol
_[12] RFC Add section of RFC4511 http://tools.ietf.or[...]
_[13] RFC LDAP result codes http://tools.ietf.or[...]
_[14] 웹사이트 SASL Mechanisms at IANA https://www.iana.org[...]
_[15] RFC RFC4511: delete request http://tools.ietf.or[...]
_[16] 문서 Boreham Draft (numSubordinates) http://tools.ietf.or[...]
_[17] RFC Modify Section of RFC4511 http://tools.ietf.or[...]
_[18] IETF LDAP Modify-Increment Extension
_[19] IETF Lightweight Directory Access Protocol (LDAP) Read Entry Controls IETF
_[20] 문서 INTERNET-DRAFT LDAP Transactions draft-zeilenga-ldap-txn-15.txt http://tools.ietf.or[...]
_[21] 문서 Shibboleth Security alert 20120227 http://shibboleth.ne[...]
_[22] 웹사이트 Tools.ietf.org http://tools.ietf.or[...]
_[23] 웹사이트 Tools.ietf.org http://tools.ietf.or[...]
_[24] 웹사이트 Tools.ietf.org http://tools.ietf.or[...]
_[25] 웹사이트 Openldap.org http://www.openldap.[...]
_[26] 웹사이트 Open Grid Forum : Project Home https://www.ogf.org/[...]