LDAP

LDAP(라이트웨이트 디렉터리 액세스 프로토콜)은 TCP/IP 위에서 디렉터리 서비스를 조회하고 수정하는 응용 프로토콜이다.

디렉터리는 논리, 계급 방식 속에서 조직화된, 비슷한 특성을 가진 객체들의 모임이다. 가장 일반적인 예로는 전화 번호부(telephone directory)가 있는데 가나다 순의 일련의 이름을 가지고 있고, 이름마다 전화 번호와 주소가 포함되어 있다. 이러한 기본 설계 때문에 LDAP는 인증을 위한 다른 서비스에 의해 자주 사용된다.

LDAP 디렉터리 트리는 선택된 모델에 따라 다양한 정치적, 지질학적, 조직적 경계를 반영하기도 한다. 오늘날 LDAP의 배치는 최상위 수준의 계급을 구조화하기 위해 도메인 이름 서비스의 이름을 사용하는 경향이 있다. 디렉터리 안에 들어가면 들어갈수록 사람들, 조직, 프린터, 문서, 그룹 등을 대표하는 항목들이 나타난다.

LDAP의 현재 버전은 LDAPv3이다.




LDAP 어떻게 시작됐을까?

LDAP 어떻게 시작됐을까?
시간을 조금 거슬러 올라가 80년대 말 특정 분야의 디렉토리 서비스의 개발 요구가 높아짐에 따라 CCITT(International Telegraph and Telephone Consultative Committee, 현재는 ITU다)와 ISO(International Organization for Standardization) 두 단체는 X.500이라는 디렉토리 서비스 표준을 만들기 시작했다. 90년에 이르러 CCITT는 표준을 발표했고 93년과 97년 몇 번의 수정 작업을 거쳐 현재에 이르렀다. X.500은 최초의 일반적인 목적의 디렉토리 시스템으로 다양한 쿼리를 사용하는 강력한 검색 기능을 제공했으며 서버와 데이터의 분산이 용이했다. 또한 특정한 운영체제나 네트워크, 응용프로그램에 구애받지 않고 사용될 수 있는 표준이라는 점에서 눈길을 끌 수 있었다.

하지만 X.500 개발자들은 DAP(X.500의 directory client access protocol)가 너무 방대하고 구현이 어려워 당시 일반 PC에서의 적용이 어렵다는 것을 알고 해결책을 모색하기 시작했다. 이렇게 해서 나온 것이 LDAP이다. LDAP은 DAP의 기능을 대부분 지원했고 복잡했던 부분이나 잘 쓰이지 않았던 부분은 단순화하거나 제거했다. 또한 대부분의 데이터 형식에 있어 단순한 문자열을 사용하여 구현을 단순화하고 퍼포먼스를 높일 수 있었다.

LDAP 들여다 보기
이제 본격적으로 LDAP을 이해하기 위해 그림 1, 2를 살펴보자.

그림 2, 3은 파일시스템의 구조와 LDAP 디렉토리 구조의 대표적인 예를 보여준다. 이러한 LDAP 디렉토리 트리 구조를 특별히 DIT(Directory Information Tree)라고 부른다. LDAP 트리(Tree) 구조에서 각 노드들을 엔트리(Entry)라고 부르고 엔트리는 LDAP에서 하나의 데이터를 나타낸다. RDBMS와 비교하면 하나의 레코드와 일치한다고 할 수 있다. 모든 엔트리는 자신의 위치와 고유성을 나타내는 DN(Distinguished Name)으로 구분된다. 이는 마치 파일시스템의 디렉토리 구조에서 “최상 위에 루트 디렉토리가 있고 그 아래에 /usr 디렉토리와 /home 디렉토리가 있으며, /usr 디렉토리 아래에는 /usr/local과 /usr/src 두 개의 디렉토리가 있다” 등으로 말할 수 있는 것과 비슷하다. 그림 3에서 트리 구조의 최상위 DN은 dc=database,dc=sarang,dc=net이고 이 엔트리의 아래에 는 두 개의 엔트리가 존재한다. 이 두 개의 엔트리의 DN은 각각 ou=people, dc=database, dc=sarang, dc=net과 ou=manager, dc=database, dc=sarang, dc=net이다. 이것은 파일시스템을 읽을 때 하위 디렉토리로 내려갈수록 /usr/local/bin과 같이 오른쪽으로 붙여나가는 방식과는 반대로 하위 엔트리로 내려갈수록 왼쪽으로 붙여나가는 방식이다. 그림 2, 3의 구조를 보면 ‘데이터베이스 사랑넷에 people(사람들) 그룹과 manager(관리자) 그룹으로 나뉘고 관리자 그룹에는 유저 아이디가 advance라는 관리자가 한명 있으며 사람들 그룹 아래로는 member(회원) 그룹과 guest(손님) 그룹이 존재한다’라는 식으로 이해할 수 있는 것이다. 그림 3은 각각의 엔트리 위치를 나타내기 위해 전체 DN이 아닌 ou=people 등으로 표현했는데 이것을 ‘Relative Distinguished Name’ 즉, RDN이라고 한다. 파일시스템 디렉토리 구조에 반드시 절대 패스, 상대 패스가 있는 것과 같이 LDAP도 DN, RDN으로 나타낼 수 있다. 이제 엔트리에 대해 좀더 자세히 살펴보기로 하자.
표 1은 하나의 엔트리 전체를 보여주고 있다. 하나의 엔트리는 마치 RDBMS의 필드처럼 애트리뷰트(attribute)들을 갖으며 이러한 애트리뷰트의 값들은 RDBMS의 하나의 필드 값과는 다르게 한 개 이상의 값을 가질 수 있다. 여기서 cn이란 common name을, sn은 sirname을 각각 대표한다. organization unit을 ou라고 사용 하는 것처럼 축약형을 사용하는 이유는 무엇일까? 그 이유는 ou(organization unit), o(organization), c(country), cn(common name)과 같이 dn에 쓰이는 애트리뷰트들은 보다 간결한 dn을 위해 축약될 필요가 있기 때문이다.
또 한 가지 살펴봐야 할 것은 바로 objectclass다. 모든 엔트리는 한 가지 이상의 obejctclass에 속하며 objectclass의 정의대로 애트리뷰트를 갖게 된다. 쉽게 비유하자면 objectclass란 붕어빵을 찍어내는 붕어빵 틀과 같다고 할 수 있겠다. 붕어빵 틀대로 붕어빵이 찍혀 나오듯이 앞에 objectclass를 정의한대로 엔트리가 생성되는 것이다. 전형적인 LDAP의 구조를 그림 4의 엔트리 내용을 통해 살펴보자.

공개형 LDAP 엔진 OpenLDAP

OpenLDAP이란?
OpenLDAP는 LDAP의 전신이라고 할 수 있는 Umich(미시건대학) LDAP 3.3을 기반으로 새롭게 만든 LDAP 프로젝트의 산물이다. 오픈 소스 정책을 따르면서도 상용 LDAP 서버 못지 않은 응용프로그램들과 서버 툴을 제공하겠다는 목적 아래 웹 상의 많은 개발자들이 자원해서 이 프로젝트를 돕고 있다.
현재 OpenLDAP은 1.2.x 버전의 안정 버전을 내놓고 있으며(현재는 1.2.11이 안정 버전) 2.0.x의 개발 버전을 내놓고 있다. 두 버전의 주된 차이점은 1.2.x 버전의 경우 LDAP v2 표준을 지원하는 반면 2.0.x 버전은 LDAP v3 표준을 기반으로 만들어진 것이라는 점이다.

 

OpenLDAP의 설치

버클리 DB 컴파일
소스 db-2.7.7 또는 db-3.1을 /usr/local/src 디렉토리에 풀고 루트 권한으로 작업한다.

OpenLDAP 컴파일
openldap-1.2.11 또는 openldap-2.0.7 소스 역시 /usr/local/src 디렉토리에 풀고 루트 권한에서 작업한다.
여러 가지 옵션들 존재하므로 ‘configure -help’ 명령어를 이용해 자신의 시스템에 맞는 옵션들을 골라 사용하기 바란다.

환경 설정
앞에서 /usr/local/ldap를 프리픽스로 주었기 때문에 /usr/local/ldap 디렉토리 아래에 모든 파일이 존재한다. LDAP 데몬을 띄우기 위해서는 /usr/local/ldap/etc/openldap/ slapd.conf 파일을 편집해야 한다.
설정의 기본 방식
두 개 이상의 데이터베이스 지시자로 한 개의 서버에 다중 데이터베이스를 구축할 수 있다.

전체 설정 파일
slapd.conf 파일의 내용을 간단히 살펴보자.

include /usr/local/ldap/etc/openldap/slapd.at.conf
▶ objectclass에 대한 애트리뷰트를 정의해 놓은 파일을 인클루드한다.

include /usr/local/ldap/etc/openldap/slapd.oc.conf
▶ objectclass를 정의해 놓은 파일을 인클루드한다.

schemacheck off
▶ LDAP add, modify 등을 수행할 때 입력되는 스키마 데이터가 올바른지 점검한다. off 상태로 설정하면 점검 과정이 빠지므로 그만큼 수행 속도는 빠르게 되지만 입력되는 데이터의 신뢰성에 주의해야 한다.

pidfile /usr/local/ldap/var/slapd.pid
▶ slapd 프로세스 ID 넘버

argsfile /usr/local/ldap/var/slapd.args
▶ slapd 아규먼트

기본적인 구동
slapd의 시작은 OpenLDAP의 버전에 따라 약간 다르지만 큰 차이는 없다. 다음은 모두 설치 경로(configure 스크립트의 프리픽스 설정에 따른 경로)를 /usr/local/ldap로 설정했을 때를 가정한 것이다.
① 1.2.x 버전의 slapd 구동
LDAP의 기본 서비스 포트 번호는 389번이다. 호스트 이름과 포트 번호는 생략할 수 있으며 생략하면 기본값을 사용하게 된다.

② 2.x 버전의 slapd 구동
올바로 데몬이 수행되고 있는지를 확인해보자.

$ pstree|grep slapd

이제 기본적인 설치와 설정을 모두 마쳤다.

slapd.conf 탐구
OpenLDAP의 설정 파일인 slapd.conf는 기본적으로 간단한 구조를 갖고 있지만 관리자의 설정 여하에 따라 매우 유연하고 강력한 설정을 해줄 수 있게 된다.

ACL(Access Control List)
ACL이란 파일시스템에서 파일과 디렉토리에 소유자와 권한을 설정해주는 것과 같이 각각의 엔트리에 접근 권한을 설정하는 역할을 수행한다. 또한 ACL 설정으로 LDAP 내부 각각의 엔트리, 애트리뷰트 접근에 대해 권한을 설정할 수 있으며 접근 가능한 호스트에 대한 설정을 할 수 있다. 따라서 LDAP 관리자는 반드시 데이터의 중요도에 따라 ACL을 설정해야 하며 이러한 설정이 올바르게 적용되고 있는지 확인해 주어야 한다. ACL의 기본 형식은 다음과 같다.

이제 일반적인 설정 예제(OpenLDAP 1.2.x 기준)를 살펴보자.
내용을 해석하면 기본 접근 권한을 none으로 설정한다(defaultaccess none). 그리고 ‘access to *’ 부분은 모든 엔트리(*)에 대한 접근 권한을 정의하겠다는 뜻이다. 정규 표현식을 사용해 ‘access to dn=”.+,dc=database,dc=sarang,dc=net”이라고 하면 dc=database,dc=sarang,dc=net을 dn의 한 부분으로 갖는 모든 엔트리에 대해 접근 권한을 정의하겠다는 뜻이다. ‘by self write’란 엔트리 자신(self)이 그 엔트리에 대해 쓰기 권한을 가질 수 있다는 것이다. 이제 특정 애트리뷰트를 설정해보자.
이런 식으로 애트리뷰트를 설정하면 userpassword 속성에 대해서만 접근 권한을 정의하게 된다. 이때 권한을 설정하고자 하는 것이 여러 개라면 콤마를 구분자로 다음과 같이 사용한다.

access to attrs=userpassword,uid,sn

복수개일 때 attrs로 바뀐 것에 주의하기 바란다.

패스워드 인증방식
OpenLDAP은 RFC 2307 패스워드 방식을 지원한다. 이러한 패스워드 방식은 slapd.conf 내의 루트 패스워드와 애트리뷰트인 userPassword에 사용될 수 있다. RFC 2307 패스워드 방식으로는 {SSHA} 방법이 일반적으로 널리 사용되고 있다. 반면 {CRYPT}는 특성상 운영체제에 의존적인 문제가 있고(따라서 항상 slapd가 떠있는 시스템에서 크립트해서 생성해야 하는 불편이 있다) 크랙(crack)에 약한 모습을 보여 그리 권장할만한 방식은 아니다.

① 플레인 텍스트(Plain text)
가장 단순한 방식으로 LDAP 데이터의 외부 노출이나 보안에 대해 크게 신경을 쓰지 않아도 되는 곳이라면 이 방식을 사용한다. 입력되는 데이터의 예를 살펴보자.
② 크립트(Crypt)
이 방식은 그리 권장하는 방법은 아니지만 사용이 매우 간단하다. 주의해야 할 점은 크립트 방식은 운영체제에 의존적이라 항상 slapd 데몬이 떠있는 시스템에서 패스워드 생성을 해야 한다. /etc/passwd(또는 /etc/shadow)에 있는 패스워드를 긁어서 userPassword 또는 rootpw에 ‘{CRYPT} encrypted_password’와 같이 입력한다. 직접 스크립트를 작성해 패스워드를 생성해도 좋다. 펄을 사용해 다음과 실행해보자.

perl -e 'print("{CRYPT}" . crypt("secret","salt") . “\n”);'

③ md5, smd5
다음 스크립트로 MD5 방식의 패스워드를 생성할 수 있다.

인덱싱(Indexing)
최상의 퍼포먼스를 유지하기 위해서는 인덱싱에 반드시 필요한 애트리뷰트 만을 명시하고 자료를 저장해야 한다. 인덱싱을 설정한 후 slapd 데몬을 재기동시키고 데이터 입력 작업을 하면 인덱스가 생성되기 시작한다. 하지만 이미 입력되어 있는 데이터에 대해서는 자동적으로 인덱싱을 해주지 않는다. 따라서 이미 입력된 데이터에 대해 따로 인덱싱 작업을 해줄 필요가 있다. 새로이 인덱싱이 필요한 애트리뷰트가 생겼을 경우도 마찬가지로 추가적인 인덱싱 작업을 관리자가 직접 해주어야 한다. 인덱싱은 다음과 같이 slapd.conf 파일에 명시한다.

이제 새로이 slapd 데몬을 기동시킨다. 이미 데이터가 있는 경우를 예로 들어 보면 이전까지 mail이라는 애트리뷰트에 대해 인덱싱이 이루어지지 않고 있다가 새롭게 mail 애트리뷰트를 인덱싱하도록 설정했다고 생각하자. 위와 명령을 내리면 인덱스 파일이 생성된다.
mail이라는 파라미터에서 알 수 있듯이 관리자가 수동으로 생성해줄 경우 각 애트리뷰트에 대해 각각 인덱싱을 해줘야 한다는 뜻이다. 이제 데이터 디렉토리에 mail.dbb라는 인덱싱 파일이 생긴 것을 확인할 수 있을 것이다. 속도 또한 인덱스를 쓰기 전과 달리 눈에 띄게 향상되었을 것이다.

기본적인 OpenLDAP의 콘솔 명령 사용
pstree|grep slapd로 slapd를 확인했다면 이제 ldap을 테스트할 준비가 된 셈이다. 모든 콘솔 명령어에는 공통적으로 들어가는 커맨드 라인 옵션이 있다.

ldapadd
이제 처음으로 띄운 LDAP 서버에 데이터를 넣어보도록 하자. 커맨드라인 명령을 사용할 경우 두 가지 방법으로 데이터 입력이 가능하다.

① 커맨드 라인 상에서 직접 입력
커맨드 라인에서의 입력은 대개 하나의 데이터를 입력할 때 편리하지만 사용하는 경우는 거의 없다. 입력한 데이터와 유사한 데이터를 계속 넣어야 하는 경우가 발생하면 매우 불편해지기 때문이다.

위의 작업은 DIT의 최고 상위 엔트리를 입력하는 작업이다. 이제부터 입력하는 엔트리는 모두 이 아래에 위치하게 된다.
dcobject objectclass의 스키마를 보고 요구사항에 틀리지 않도록(1.2.x 버전이라면 etc/openldap/slapd.oc.conf 파일, 2.0.x 버전의 경우 etc/openldap/schema/core.schema 파일에 정의되어 있다) 해주어야 한다. 그렇지 않을 경우 입력 과정에서 에러가 난다. 문법에 틀려도 입력이 진행된다면 slapd.conf에 schemacheck 부분이 off로 되어 있지 않은지 살펴보기 바란다(하지만 입력된 데이터의 옳고 그름을 점검하는 과정도 부하라고 할 수가 있으므로 신뢰할만한 관리자들만이 입력, 수정을 할 경우에는 off로 해놓는 것이 더 나을 수 있다).

②LDIF 파일 포맷으로 입력
LDIF(LDAP Data Interchange Format)란 LDAP의 데이터를 텍스트 형식으로 표현하는 데이터 포맷이다. LDIF 포맷의 파일로 입력하면 똑같은 타이핑 작업을 피할 수 있을 뿐 아니라 백업된 데이터의 복구에도 유용하게 사용할 수 있다. Vi 등의 편집기로 내용을 저장한다.
입력한 데이터가 제대로 입력되었는지 확인 작업으로 넘어가기 전에 주의해야 할 것이 한 가지 있다. 실수가 빈번하게 발생하는 부분으로 대개 LDIF 포맷 파일에 입력할 엔트리가 두 개 이상일 경우 발생한다. 두 개 이상의 엔트리일 경우 엔트리 간의 간격은 반드시 한 줄의 빈 라인으로 유지해야 한다. 또한 입력되는 엔트리 순서에도 신경을 써주어야 한다. 예를 들어 ‘cn=주소록,dc=database,dc=sarang, dc=net’과 같은 dn을 갖는 엔트리가 ‘cn=정재익,cn=주소록, dc=database,dc=sarang,dc=net’과 같은 엔트리보다 아래에 있다면 ldapadd 명령은 탑다운 방식으로 읽어 내려가며 입력하게 되므로 에러를 내게 된다.

ldapsearch
LDAP을 검색할 때는 SQL을 사용한 일반적인 관계형 데이터베이스의 검색과 같이 검색 조건을 설정한다.

① 서치 스코프(search scope)
서치 스코프는 LDAP의 검색 영역을 지정하는 것으로 그림 5를 살펴보자. 이것을 이해하기 위해서는 베이스 dn이라는 것을 알아야 하는데 이는 검색을 하는 기준점을 뜻한다. 무조건 베이스 dn 아래의 엔트리에서 검색을 하는데 그 종류는 세 가지로 나뉜다. 베이스란 검색하는 베이스 dn으로 제시한 엔트리 자체만을 검색한다는 뜻이다. 레벨 1은 베이스 dn 아래 한 단계 하위 엔트리들까지만 검색한다. 서브 트리는 베이스 dn 아래 모든 엔트리에서 검색을 한다.

② 서치 필터(Search filter)
LDAP의 다양한 검색 필터에 대해서 알아보자.

● equality : ‘(cn=홍길동)’과 같이 완전 매칭이 이루어지는 검색 필터를 뜻한다.
● substring : ‘(cn=*길동)’ ‘(cn=홍길*)’ ‘(cn=*길*)’과 같이 부분 문자열이 같은 것을 검색하는 필터다.
● approximate : 말뜻 그대로 유사한 단어를 검색하는데 쓰인다. 한글은 되지 않고 영어의 경우 ‘pipe’를 검색하면 piping 이라든지 유사 단어를 검색해준다.
● less than,greater than : ‘(cn>=kikibon)’ 단어순서 상의 크고 더 작은 조건을 만족하는 검색 결과를 얻을수 있게 해주는 검색 필터다.
● presence : ‘(cn=*)’와 같이 cn 애트리뷰가 있고 없고를 따지는 검색 필터다.
● and : (&(cn=구본규)(telephoneNumber=*657*))과 같이 필터 간의 AND 조건 검색을 만들어 준다.
● or : (|(cn=성재철)(telephoneNumber=019*))와 같이 필터간의 OR조건 검색을 만들어 준다.
● not : (!(cn=박*))과 같이 cn이 ‘박’으로 시작하지 않는 결과를 돌려받는데 쓰이는 검색 필터다.

③ time limit건
④ size limit건

ldapmodrdn
엔트리의 dn과 rdn을 수정하고자 하는 경우 사용한다. 수정하기 이전의 엔트리 내용은 다음과 같다.
엔트리의 dn과 rdn(cn=someone)을 수정하기 위해 다음과 같은 명령을 내린다.

ldapmodrdn -D "cn=DsnManager, dc=database, dc=sarang, dc=net" -W "cn=someone, dc=database, dc=sarang, dc=net" "cn=kikibon"
이제 어떻게 변했는지 살펴보자.
cn: someone 데이터까지 없애고자 한다면 ldapmodrdn에 -r 옵션을 주면 된다. 만일 파일로 저장한 다음 -f 옵션을 사용할 필요가 있다면 바뀌어야 할 dn과 새로운 rdn을 차례로 적고 파일로 저장한 뒤 실행시키면 된다.
DIF(LDAP Data Interchange Format)
LDAP의 엔트리 데이터를 읽고 작성 가능한 텍스트 형식으로 보여주는 것이 LDIF다. 두 개의 서로 다른 백엔드 데이터베이스를 사용하는 LDAP 서버의 데이터들도 LDIF 형식으로 익스포트(export)하면 LDAP 서버에 임포트(import!)가 가능해져 상호 데이터 호환성을 유지할 수 있다. 이렇게 되면 LDAP 서버를 교환해야 하는 상황이 와도 이전 서버에서 사용했던 데이터를 수정 작업 없이 그대로 사용할 수 있게 된다. 즉, 서로 다른 기종의 백엔드 데이터베이스를 사용하는 LDAP 서버 간의 데이터 교환이 가능해진다는 뜻이다. 이러한 LDIF의 형식에는 두 가지가 있는데 하나는 디렉토리 엔트리 데이터를 표현하는 형식이고 다른 한가지는 데이터의 수정, 삭제 등을 요구하는 데이터 변경에 관련한 형식이다.

엔트리 내용을 보여주는 LDIF

모든 애트리뷰트 값들은 이름과 콜론으로 구분되며 콜론 다음에 실질적인 값들이 나온다. cn과 같이 두 개 이상의 값을 가진 애트리뷰트들은 그 값들을 한 라인씩 사용한다(앞서 설명한대로 dn을 제외한 모든 애트리뷰트들은 두 개 이상의 값을 가질 수 있다). 또 한 가지 주목할 점은 애트리뷰트 값을 여러 줄에 나누어 쓴 description 부분이다. 위와 같이 new line 문자와 공백을 값에 넣어줌으로써 데이터를 여러 줄에 나누어 쓸 수 있다. 하지만 텍스트 에디터가 하나의 긴 라인을 지원한다면 한 줄에 써도 무방하다.
일반적인 아스키 문자로 표현할 수 없는 값을 가진 애트리뷰트를 프린트가 가능한 문자로 바꾸기 위해서는 Base 64 인코딩을 해준다. JpegPhoto 부분을 주목해서 살펴보기 바란다. 이때 구분자는 콜론이 하나가 아니라 두 개로 구분을 하고 있다. 이미지 데이터를 ldif로 변경할 때는 base 64 인코딩을 직접해도 되지만 간단하게 ‘ldif -b jpegPhoto < image.jpg > image.ldif’의 옵션을 사용해도 된다

엔트리 변경에 관련한 LDIF
LDIF는 엔트리 데이터의 표현 뿐 아니라 데이터의 변경, 수정에 관련된 정보를 포함할 수 있다.

여기서 주목해야 할 부분은 changetype이다. add를 쓰느냐 delete를 쓰느냐 modify를 쓰느냐에 따라 작업이 달라지기 때문이다. 직접 테스트해 보도록 하자.

$ ldapmodify -D "cn=DsnManager,dc=database,dc=sarang,dc= net" -W -f leeadd.ldi

이제 삭제 작업을 해보자.

dn: cn=lee woon-uk,dc=database,dc=sarang,dc=net
changetype: delete
단지 changetype이 delete로 바뀌었을 뿐이다. 지우려는 dn을 쓰고 changetype을 delete로 하면 해당 엔트리가 삭제된다.
이제 변경하는 과정을 살펴보자. 약간 복잡해 보이지만 테스트할 때와 같이 ldapmodify를 사용하면 된다.
예제 1을 보면 changetype이 modify로 바뀌었다. replace는 cn항목을 변경하겠다는 뜻이고 add는 새로운 애트리뷰트를 추가하겠다는 뜻이다. delete는 description 애트리뷰트를 삭제하겠다는 뜻이다. 그리고 ‘-’문자에 대해서도 눈여겨 볼 필요가 있다.

LDAP 스키마의 작성
기본으로 제공되는 slapd.oc.conf,slapd.at.conf(OpenLDAP 1.2.x)와 schema 디렉토리 아래에 있는 파일들(OpenLDAP 2.x)을 그대로 사용한다면 간단하겠지만 대부분 경우는 적합하지 않다. 자신이 원하는 용도에 꼭 맞는 스키마를 작성하여 최적화된 LDAP 서버를 운영해야 하는 것이다. 일단 안정 버전인 OpenLDAP 1.2.x의 slapd.oc.conf의 objectclass 정의를 살펴보자.

objectclass의 정의는 엔트리 데이터 입력시에 반드시 있어야 하는(requires) 애트리뷰트와 있어도 되고 없어도 되는(allows) 애트리뷰들로 구분하여 정의하고 있다. 상당히 직관적이므로 이해하기가 쉽다. Requires, allows는 RDBMS에서 필드를 정의할 때 null, not null을 정의하는 것과 유사해 보일 것이다. 물론 위의 애트리뷰트들은 slapd.at.conf에도 정의되어 있는 것이다.

정의 형식은 다음과 같다

attribute 정의하려는 애트리뷰트 이름 데이터형식
데이터 형식에는 bin,cis,ces,tel,dn 등이 있고 bin은 바이너리, cis는 case inexact sensitive, ces는 case exact sensitive, tel은 전화번호 형식, dn은 dn 형식이라는 의미다. 특이할 만한 사항은 cis인 애트리뷰트의 경우는 일부러 정의해주지 않아도 된다는 것이다. 애트리뷰트로 정의되지 않았으면서 objectclass의 정의에 있는 애트리뷰트에 대해서는 이 cis 룰을 적용한다. 그럼 이제 cis 룰을 바탕으로 자신에게 필요한 objectclass를 정의해 보자. 앞에서 objectclass를 붕어빵 틀에 비유했듯이 이제 입맛에 맞는 붕어빵 틀을 만들어보기로 하자. 가장 간단한 예로 유저 그룹을 생성하는 예를 들어보면 위의 person 클래스와 거의 유사하며 추가적으로 유저그룹 사용자의 사진을 갖고 있어야 하는 경우 allows 항목에 jpegPhoto를 추가해 줄 수 있다. 한 가지 주의할 점은 LDAP v3를 따르는 OpenLDAP 2.x의 경우 objectclass 간의 상속(inheritance)이 가능한 반면 LDAP v2를 따르는 OpenLDAP 1.2.x는 이런 상속 기능이 없다. 그러므로 단순히 하나의 objectclass를 정의해주면 된다. 부산 리눅스 유저 그룹(PLUG)을 예로 든다면 다음과 같이 작성할 수 있다.

만일 자신이 작성한 objectclass의 정의에 cis 속성이 아닌 새로운 애트리뷰트가 정의되어 있다면 반드시 애트리뷰트 정의를 따로 해주어야 한다. 그리고 주의할 점은 slapd.oc.conf와 slapd.at.conf 파일을 수정하지 말라는 것이다. 자신이 추가한 클래스를 인클루드하려면 slapd.conf에 objectclass정의와 애트리뷰트 정의를 쓰거나, local.oc.conf , local.at.conf 등의 파일을 만들어 slapd.conf에 인클루드 지시자를 써서 포함시키면 된다. 이제까지 OpenLDAP 1.2.x 버전에서의 스키마 작성에 대해서 알아보았다. 이제 LDAP v3를 지원하는 OpenLDAP 2.x에서의 스키마 작성에 대해서 알아보자. 이전 버전과는 달리 2.x에서는 LDAP v3 표준을 따르며 많은 변화가 있었다. etc/openldap/schema 디렉토리 아래의 스키마 파일들을 들여다 보자. 기본적으로 포함되는 파일은 core.schema파일이다. 이전 버전에서와 비교가 될 수 있도록 person 클래스를 여기에 옮겨본다.

objectclass ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL
MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description ))
뭔가 차이가 생긴 것이 느껴질 것이다. 일단 이해를 할 수 있는 부분은 MUST(requires)와 MAY(allows)일 것이다. 또한 $ 문자로 애트리뷰트들 간에 구분을 지어놓았다는 것을 알 수 있다. SUP란 top이라는 objectclass의 서브 클래스라는 뜻이다. 상속의 개념이라 생각하면 된다.

애트리뷰트도 상속의 개념이 있다. SUP name 부분을 보면 애트리뷰트나 commonName은 ‘name’ 애트리뷰트의 속성을 상속받는다. 그리고 같은 애트리뷰트가 두 가지 이상의 이름을 가질 수 있다

OpenLDAP의 관리

BackUp(백업)
첫째로 가장 기본적인 방법은 data 디렉토리를 tar로 묶어 보존하는 것이다. 그 다음 ldap 데몬들을 내리고 백업한 tar 파일을 다시 풀어 덮어쓴 다음 ldap 데몬을 재시작하면 이전의 내용이 그대로 들어 있는 것을 확인할 수 있다. 두 번째로 좀더 근사한(?) 방법은 ldbmcat 명령어로 ldif 포맷 형식으로 만들어 백업하는 방법이다.

$ ldbmcat -n data/id2entry.dbb > backup.ldif

이제 이 파일을 가지고 ldif2ldbm 명령어로 복구를 해보자.

$ ldif2ldbm -i backup.ldif
$ /etc/rc.d/init.d/ldapd restart

실제로 데이터 검색에서는 문제가 없었지만 ldapdelete 시에 오퍼레이션 에러를 경험했다.
다음은 John Lines가 메일링 리스트로 알려준 백업 스크립트(backup script)다. cron에 등록시켜두고 쓰면 편리하게 사용할 수 있다.
다음은 이운억(woonuk@pointnet.co.kr)님이 작성한 백업 펄 스크립트이다. ldbmcat -n옵션을 주지 않고 백업을 한 데이터의 경우엔 다음의 펄 스크립트를 사용하면 ldapadd 가능한 포맷으로 정렬된 ldif 파일이 생성된다.

 

퍼포먼스를 늘리기 위한 방법
① 무엇보다 LDAP의 성능을 높이기 위해서는 인덱싱을 잘해야 한다. 인덱싱이 무조건적으로 많아서도 필요한데도, 사용하지 않는 것도 좋지 않다. 꼭 필요한 애트리뷰트에 한해 인덱싱해야 하며 또한 해당 애트리뷰트의 쓰임새에 맞는 인덱싱 만을 해야한다.

② 로그(log)를 줄임으로써 속도 향상을 꾀한다. slapd.conf에 ‘loglevel 0’을 명시하여 syslogd의 CPU 사용을 줄일 수 있다. 예를 들어 다음과 같이 syslog.conf를 설정하면 펜티엄II 450MHz 머신에서 sn 검색을 할 경우 3/sec걸리던 것이 51/sec로 늘어난다고 한다.

# LDAP logs
LOCAL4.* -/var/log/ldap
③ cachesize와 dbcachesize 설정을 제대로 해야 한다. 캐시 설정 여부에 따라 속도에 큰 차이를 보인다.

cachesize 100000
dbcachesize 1000000
캐시 크기가 100만이라는 것은 100만 개의 엔트리까지를 캐시하겠다는 뜻이고 dbcachesize는 열 수 있는 각각의 인덱스 파일의 크기가 1MB까지라는 것이다.

④ 퍼포먼스에 영향을 주는 시스템 요소로 메모리, 디스크, 파일시스템이 있다. 메모리를 늘리거나 디스크를 고성능으로 교체한다든지 파일에 대한 timestamp의 수정, 접근을 막는 설정으로 퍼포먼스를 향상시킬 수 있다.

LDAP의 구현
이때까지 테스트해보았던 경험을 바탕으로 실제로 사용가능한 무엇인가를 만들어볼 차례가 되었다. 이번에 구현하고자 하는 것은 현 재 실제 사이트에서 운영중인 것으로 작업 환경은 다음과 같다. Tomcat,JDK,OpenLDAP1.2.x가 설치되어 있고 LDAP으로 접속하기 위한 JNDI가 설치된 환경이다.
DIT를 이해하기 위해서는 일단 /usr/src/linux에 위치한 커널 소스의 config.in파일들을 분석해야 했다. 이것은 관리자가 콘솔에서 자바로 프로그램을 수행시키면 /usr/src/linux/arch/Config.in을 분석하면서 자동으로 커널의 옵션들을 LDAP에 입력을 시킨다. 다음은 필자가 정의한 objectclass들이다. 직관적으로 이해가 가능하므로 설명을 생략한다.
이 objectclass들을 option.oc.conf와 같은 적당한 파일 이름으로 저장한다. 다음은 애트리뷰트의 정의를 모아놓은 option.at.conf파일이다.

이 두 파일을 slapd.conf에서 인클루드 지시자로 포함 시킨다. Suffix, rootdn, rootpw와 데이터 디렉토리, ACL, 캐쉬 사이즈 등을 설정하고 slapd를 구동시킨다. 그런 다음 KernelMaker ToLDAP 프로그램으로 커널 메뉴 내용들을 LDAP에 입력시킨다. 참고로 일단 KernelMakerToLDAP(데이터를 입력하는 부분)에 대해서는 여기에서 설명을 하지 않겠다. 전체 소스는 데이터베이스 사랑넷의 자료실에 올릴 예정이니 관심 있는 사람은 전체 소스를 받아보기 바란다. 기사에서는 LDAP에 입력된 데이터들을 보여주는 부분에 대해서만 설명하겠다. 그럼 이제 KernelOption 부분에 대해 알아보자.

LDAPConstants.java
LDAP에 접속하기 위한 주요 설정들을 여기에 스태틱(static)으로 선언해 놓는다. 이제 이 상수들을 LDAPKernelOption 클래스에서 구현(implements)하여 사용하게 될 것이다. LDAP 접속을 다루고 있는 LDAPKernelOption.java파일을 살펴보자.

LDAPKernelOption.java

이 부분은 LDAPKernelOption 클래스의 정의 부분이다. LDAPConstants클래스를 임플먼트해서 미리 정의해 놓은 상수들을 사용할 수 있게 한다.
이것은 LDAPKernelOption클래스의 생성자 함수다. Hashtable 클래스를 이용해서 LDAP에 접속한다. 이제 실질적으로 검색을 하고 결과를 벡터클래스의 인스턴스에 넣어 리턴하는 함수인 makeResultVector() 함수를 살펴보자.

리턴할 벡터 옵션리스트(optionslist)를 생성하고 주어진 dn으로 onelevel 검색을 하고 NamingEnumeration 클래스에 결과값을 받아온다.

이중 for 문에서 결과값이 있을 때까지 값을 받아오고 받은 엔트리 데이터에 대해 다시 애트리뷰트를 받아와서 엔트리의 종류에 따라 html 태그를 붙이는 작업을 한 뒤 이 문자열을 옵션리스트에 저장한다. 이렇게 저장된 문자열 벡터를 결과로 넘겨주게 된다. 이제 이러한 LDAP 접속 검색 기능을 이용하는 실질적인 클래스를 살펴보자.

MenuConfig.java
MenuConfig클래스는 LDAP의 접속, 주어진 dn을 one level로 검색한 뒤 결과를 벡터에 넣어 리턴하는 LDAPKernelOption클래스를 멤버 변수로 갖고 이 클래스를 이용하여 LDAP과 통신한다.
예제 2는 MenuConfig의 생성자 함수다. 초기의 dn을 ‘dc=kernel, dc=pe, dc=kr’로 설정하고 리턴받을 벡터 옵션리스트를 초기화한 뒤 LDAPKernelOption 멤버 변수를 초기화하여 실질적으로 LDAP을 사용할 준비를 한다.

실질적으로 주어진 dn 이하의 onelevel 검색 결과를 받아 옵션리스트에 저장한다.

넘겨받은 옵션리스트의 index 위치(index위치의 엔트리 내용)의 결과를 리턴한다.
자, 이제 MenuConfig클래스를 사용해 웹에 뿌려주는 Menu ConfigView.jsp 파일을 살펴보기로 하자.

MenuConfigView.jsp

jsp파일은 매우 간단하다. 초기 dn으로 MenuConfig클래스의 인스턴스를 생성하고 받아온 결과 값(optionslist 벡터에 들어있는 결과값)을 화면에 뿌린다.
이상으로 LDAP 서버에 접속하여 넘겨준 dn으로 one level 검색을 하는 아주 간단한 예제를 살펴보았다,

LDAP로 무엇을 할까?

■브라우저로 LDAP서버를 검색
넷스케이프 웹 브라우저를 사용해 LDAP 서버의 엔트리를 검색할 수 있다. 브라우저의 URL입력창에 다음과 같은 형식의 LDAP url을 입력하면 서버의 데이터를 검색할 수 있다.

ldap://Server[:Port]/[BaseDN]?[Attributes]?[Scope]?[Filter]?[Extensions]

스코프(Scope)에는 sub, one, base 이렇게 세 가지 값이 들어간다. 돌려받는 애트리뷰트에서 전체 엔트리 정보를 모두 받고 싶을 경우 아무것도 쓰지 않고 비워두면 된다. BaseDn의 Dn 사이 사이의 콤마의 앞뒤로 공백이 들어가도 상관없으며 Dn 값에 콤마(,)가 있을 경우 역슬래시를 붙여준다.

■넷트케이프 로밍(Roaming)
http://www.linuxworld.com/linuxworld/lw-1999-09/lw-09-ldap-netscape.html
위의 리눅스 월드 문서는 OpenLDAP 소스에 패치를 가해야 하지만 OpenLDAP 1.2.10 버전부터는 이미 갖추어져 있으므로 할 필요가 없다.

■넷스케이프 캘린더
http://www.openldap.org/faq/data/cache/194.html

■마이크로소프트 애플리케이션(아웃룩, 넷미팅)
http://www.openldap.org/faq/data/cache/295.html

■PAM을 이용한 LDAP 인증
·http://www.padl.com
데이터베이스 사랑넷 : 백종규님께서 쓰신 LDAP 활용 문서
·mod_auth_ldap for apache 모듈 설치 및 이용법
·LDAP starting guide for beginner
·ftp 사용자 인증시 LDAP를 사용하는 방법

LDAP References, Documents and Sites

LDAP RFC 문서들
LDAP에 관련한 모든 RFC 문서들은 http://www.ietf.org/ rfc.html에서 구할 수 있다.

LDAP 벤치마크 관련 문서들
◆ Characterization of LDAP Performance on Various Host Operating Systems
http://www.globus.org/testing/dmark_results.html

◆ LDAP Server Performance Report
http://isglabs.rainbow.com/isglabs/NSDS31-CSv2-NT+Sol/ldaps-performance.htm

◆ Netscape Directory Server vs Novell NDS
http://www.mindcraft.com/perfreports/ldap/netscape/dirserver10.html

◆ Sizing up LDAP servers
http://www.nwfusion.com/reviews/2000/0515rev2.html

마치며
지금까지 특화된 데이터베이스 LDAP에 대해 가능한 상세히 살펴보았다. 자체의 내부 알고리즘과 프로토콜에 대한 분석 등 아직 다루지 못한 분야가 많아 아쉽지만 관련 문서가 절대 부족한 시점에서 나름대로 의미있는 정리를 했다고 생각한다. LDAP 관련의 의문점과 토론하고자 하는 주제가 있다면 데이터베이스 사랑넷(http://database. sarang.net)에 방문해 LDAP 게시판을 이용하길 바란다.

다음의 Q&A는 데이터베이스 사랑넷(http://database.sarang. net)의 LDAP 게시판 내용 중 일부를 발췌한 것이다.

LDAP 서버에서 밸류값이 한글로 되어 있다. VC++로 클라이언트 부분을 구현하고 있는데 애트리뷰트의 밸류값을 서치(search)해 오면 한글이 깨진다. 어떤 방법을 사용해야 하나? 유닉스 상에서는 iconv( )함수를 사용하면 된다고 되어 있는데.. vc++에서는 어떻게 해 주어야 하나?
iconv()라는 함수가 바로 문자셋을 변환해주는 범용 함수다. UTF-8, EUC-KR 뿐 아니라 다른 문자셋도 지원한다. VC++라면 libiconv라는 iconv()만 별도로 구현한 라이브러리가 있다. 이 라이브러리를 링크해보면 된다

리눅스에서 Openldap을 세팅했다. 이번에는 PC 두 대로 Referral, Replication 기능을 셋업해 보려고 한다. PC 두 대를 마련했는데 어떻게 접근해야 할지 모르겠다.
OpenLDAP의 소스를 설치하고 tests 디렉토리의 스크립트들을 살펴보면 도움이 될 것이다. 한 대의 서버에 포트를 달리한 마스터 서버와 슬라이브 서버를 테스트한 스크립트와 설정 파일이 고스란히 담겨져 있다.

LDAP의 모든 데이터를 삭제하려면?
간단하게 데이터 디렉토리의 모든 파일을 지우면 모든 데이터가 삭제된다.

LDAP의 데이터를 ldapsearch를 사용하지 않고 간단히 들여다 볼 수 있는 방법이 있는가?
유닉스 시스템의 경우 strings 명령을 이용해 ‘strings id2entry.dbb|less’와 같이 사용하여 내용을 볼 수 있다. 하지만 아스키 문자로 나타낼 수 있는 문자에 한해서만 볼 수 있으며 나머지는 깨져보일 수 있다.

openldap-2.0.6을 컨피규어 과정에서 configure: warning: could not find suitable LDBM backend configure: error: select appropriate LDBM options or disable 에러 메시지가 떴다. db-3.1.17을 설치했는데 무엇이 문제인가?
버클리 DB의 라이브러리와 헤더 파일의 위치를 찾지못해 일어나는 현상이다.
env CPPFLAGS="-I/usr/local/BerkeleyDB.3.1/include" LDFLAGS=”-L/usr/local/BerkeleyDB.3.1/lib” ./configure --prefix=/usr/local/openldap으로 설정 스크립트를 실행하면 에러 없이 설치할 수 있다.

siteserver를 사용하는 환경에서 ldap의 멤버의 총 카운터, 혹은 select한 필터의 카운터를 어떻게 알 수 있나?
C API에서는 ldap_count_entries(ld, res)를 사용하면 가능해진다.

ACL설정에서 access to * by dn=”.+” read 처럼 설정 했을때 “인증된 사용자”만이 읽을 수 있다는데 “인증된 사용자”란 어떤 의미인가?
이는 dn과 패스워드를 제시한 사용자를 말한다. person이나 organizationalPerson 등과 같은 objectclass의 엔트리로 등록된 사용자도 userPassword 속성에 패스워드를 설정해 놓고 이 사용자의 dn과 패스워드를 제시하고 접속한다면 이 또한 인증된 사용자가 된다.
물론 자신이 만든 objectclass의 애트리뷰트에 userPassword가 있다면 이것으로 바인딩해서 쿼리를 날리는 것 또한 인증된 사용자라고 할 수 있다.

defaultaccess none
access to *
by users read
by * none

이렇게 설정해주었을 경우 관리자 이외의 dn과 패스워드로는 서치(search)가 되지 않는다. ‘nsufficient access’때문에 바인드되지 않았다는데 그 이유가 무엇인가?
다음과 같이 설정 하면 목적한대로 관리자와 ‘인증을 거친 사용자’만이 읽을(read) 수 있다

defaultaccess none
access to *
by anonymous auth
by users read
by * none

참고로 위의 설정은 OpenLDAP 2.x 버전에서만 정상 작동한다. 1.2.x 버전의 안정 버전을 사용한다면 위의 설정을 다음과 같이 바꾸면 된다.

defaultaccess none
access to *
by dn=".+" read
by dn="^$$" none
by * none

dn=".+" 는 인증된 사용자를 dn="^$$" 는 anonymous 사용자를 뜻한다.

넷스케이프 디렉토리 서버 4.11에서 DB 임포트가 되지 않는다. 시도한 방법은 디렉토리 서버의 Configuration 탭에서 데이터베이스의 오른쪽 마우스 버튼을 누르면 임포트 메뉴가 보이는데, 파일을 지정하고 ‘OK’를 선택했더니 “0 entries import!ed, 160 entries rejected”라는 메시지가 뜬다. 기본적으로 제공되는 ldif 파일을 선택해도 같은 현상이 발생한다. DB를 임포트하기 전에 하는 설정(configuration)이 따로 있나?
먼저 에러 로그를 확인해 주어야 한다. 에러 로그의 위치는 ${NS_HOME}/slapd-xxxxx/logs고 파일명은 error다. LDIF파일을 임포트할 때 모든 과정이 이 로그 파일에 모두 써지기 때문에 이 파일을 보면 원인을 파악할 수 있다.

정의되지 않은 애트리뷰트를 추가하고 싶다. 리눅스 버전에서는 따로 slapd.at.conf 파일에 추가 해주지 않아도 사용할 수 있었다. 새롭게 HP 머신으로 옮기려 하는데 ‘Undefined attribute type’이라고 나오면서 엔트리를 등록할 수 없다. at.conf 파일을 따로 만들어서 애트리뷰트 정의를 해주어도 같은 결과다. 해결책이 있나?(이번에 나온 openldap 2.0.7 버전)
2.0.7 버전에서는 1.2.11 버전에서 사용한 방식과는 다른 방법으로 애트리뷰트를 정의한다. OpenLDAP 관리자 가이드 문서를 참고하고 etc/openldap/schema 아래 파일들을 살펴보기 바란다.

커맨드 라인 명령으로 ldapmodify은 어떻게 넣어야 하나? 넷스케이프 사이트의 administrator guide에는 ldapmodify 명령을 사용하던데... openldap처럼 slapdadd -f slapd.conf -l test.ldif 같은 명령어는 없나?
OpenLDAP과 마찬가지로 넷스케이프 LDAP도 ldapmodify와 ldapadd가 있으며 그 위치는 ${NS_LDAP_HOME}/shared/ bin에 있다. 넷스케이프 LDAP에 LDIF 데이터를 통째로 넣기 위해서는 보통 ldif2db를 쓴다. 이것은 LDAP 서버 인스턴스(instance)를 생성시키면 자동으로 생성된다. 위치 : ${NS_LDAP_HOME}/ slapd-xxx/

1. 서버 스톱
2. ldif2db [-noconfig] -i 해당 LDIF 파일의 절대 경로
3. 서버 스타트

이때 주의할 점은 ldapmodify와는 달리 기존의 데이터를 모두 덮어쓰게 된다는 것이다. 반대로 db2ldif를 하면 자동으로 LDAP에 있는 내용이 ldif 파일 형태로 익스포트된다.

ldaptest.c 파일을 컴파일하는데 gcc ldaptest.c -o ldaptest -I/usr/local/ldap/include -L/usr/local/lib -lldapssl41 “error in loading shared libraries : libldapssl41.so”와 같은 에러 메시지가 나온다. 어떻게 다르게 컴파일 해야 하나? 컴파일 에러는 없고 warnning만 나오며 실행시키면 에러 메시지가 나온다(netscape sdk 4.1 을 설치)
넷스케이프 LDAP SDK를 사용할 때 가장 많이 하는 실수다. 넷스케이프 LDAP 라이브러리는 쉐어드 오브젝트(Shared Object)로 컴파일되어 있다. 링크할 때는 인터페이스만 체크하고 실제 프로그램 런타임 시에 해당 so 파일을 찾아서 실행된다. 즉, 프로그램을 수행할 때 해당 libldapssl41.so 파일을 찾는다는 것이다. 단, 이 so 파일을 찾는 패스(Path)는 환경 변수에 설정된 값으로 찾는다. 따라서 이런 에러 메시지가 안나타나도록 하려면 libldapssl41.so 파일이 있는 패스를 환경 변수에 등록해 주어야 한다. 해당 환경변수는 운영체제마다 차이점을 갖고 있으므로 man(man cc 나 man ld)을 이용해 확인하기 바란다.

LDAP을 공부하기 시작한 초보다. 막상 운영해보려고 하니 설정을 어떻게 해야 될지 깜깜하다. 특히 suffix, rootdn 이 부분을 이해하기 어렵다. 구체적으로 어떻게 설정을 하면 되는가?
suffix는 DIT(Directory Information Tree) 구조상 최상위 엔트리를 말한다. 즉, c=KR이라는 엔트리를 최상위 엔트리로 만들어 그 아래 엔트리들을 달고 싶다면 suffix는 c=KR이 되는 것이다. 외에도 o=My Company라든지 o=My Company,c=KR 등의 형태도 가능하다. rootdn은 유닉스의 루트 계정과 같이 LDAP 서버에 대해 모든 권한을 갖는 사용자를 말한다. 유닉스나 DB와는 달리 모든 사용자는 DN 형태로 존재해야 한다. slapd.conf에는 원하는 DN을 적어주면 되는데 보통, cn=Directory Manager를 많이 사용한다.

LDAP을 솔라리스에 설치했다. C API를 이용해 프로그램을 작성할 계획이며 현재 사용하는 컴파일러는 gcc다. 어떻게 컴파일을 할 수 있는지 궁금하다..
LDAP SDK를 이용한 프로그래밍 관련 문서로는 http://docs. iplanet.com/docs/manuals/dirsdk/csdk30/contents.htm에서 시작하는 것을 추천한다. LDAP SDK가 설치되어 있다면 링크 옵션에 -lldap -llber를 추가하면 된다.

suffix와 rootdn의 차이점을 잘 모르겠다. DIT상에서 suffix는 최상의 엔트리인것 같은데.. rootdn은 실제적으로 무엇을 의미하는가?
rootd 이란 말그대로 LDAP 서버의 관리자의 ‘distinguished name’이라는 말이다. 이런식으로 LDAP에서는 관리자도 dn 형식으로 저장된다. LDAP 서버의 디렉토리가 방대하고 커서 혼자 관리하기 힘들다면 최상위 관리자 아래에 부서별로 관리자를 두고 액세스 권한을 설정하고 하는 부분이 존재한다. openldap에서 검색을 해보면 원하는 부분을 좀더 자세히 이해할 수 있을 것이다.

LDAP와 PHP로 테스트 프로그램을 만들어보았다. 콘솔에서 ldapsearch를 사용하면 한글이 나오지 않고 ‘not ascii’라고 나온다. 한글을 볼수 있는 방법은 없나?
ldapsearch의 맨페이지를 보면 -B 옵션이 있다.
-B Do not suppress display of non-ascii values....
이 옵션을 사용하면 한글이 문제없이 보일 것이다.

ldap 설치 시 ldbm의 문제에서 버클리DB와 gdbm을 설치했다. 두 DB의 데몬을 띄우는 방법을 모르겠다.
gdbm이나 버클리DB는 흔히 알고 있는 DBMS와는 차이점을 갖는다. Openldap 설정 시 옵션에서 알 수 있듯이 LDAP는 DB의 api를 사용다. 결론적으로 원래 띄우지 않는 것이다.

[출처] LDAP 어떻게 시작됐을까? (★정박사의 정보보안전문가 따라잡기★) |작성자 정박사