[z/OS][AIX Solaris HP-UX Linux Windows]

LDAP(Lightweight Directory Access Protocol)

이 절에서는 LDAP(Lightweight Directory Access Protocol)의 개념 및 작동 방법에 대한 질문을 다루고 X.500 및 LDAP에 대한 높은 수준의 개요를 제공합니다.

LDAP은 중앙 X.500 또는 LDAP 디렉토리 서버에서 사용자, 그룹 또는 오브젝트에 대한 정보를 저장 및 검색하는 방법을 제공하는 표준 프로토콜입니다. X.500은 다양한 속성을 사용하는 여러 웹 서버에서 LDAP을 사용하여 이러한 정보를 구성 및 조회할 수 있도록 합니다. LDAP 조회는 원하는 개별 엔티티 또는 엔티티 그룹을 식별해야 하므로 단순하거나 복잡할 수 있습니다. LDAP은 원래 X.500 DAP(Directory Access Protocol)의 기능적 서브세트만 포함시킴으로써 필요한 시스템 자원을 줄여줍니다.

그만큼 IBM® HTTP Server LDAP 모듈을 사용하면 X.500 인증 및 권한 부여 목적의 디렉토리 서버입니다. IBM HTTP Server는 이 기능을 사용하여 제어된 사용자 세트로 자원 액세스를 제한할 수 있습니다. 이 기능은 일반적으로 개별 웹 서버에 대한 사용자 및 그룹 정보를 유지보수하는 데 필요한 관리 오버헤드를 줄여줍니다.

IBM HTTP Server LDAP 모듈이 TCP/IP 또는 SSL(Secure Sockets Layer)을 사용하여 X.500 디렉토리 서버에 연결하도록 구성할 수 있습니다. LDAP 모듈이 단일 LDAP 서버 또는 복수 서버를 참조하도록 구성할 수 있습니다.

X.500 개요. X.500은 보다 효율적인 검색을 수행할 수 있는 컴포넌트를 포함하는 디렉토리 서비스를 제공합니다. LDAP은 이러한 컴포넌트 중 다음 두 가지를 사용합니다. 양식과 문자를 판별하는 정보 모델과 정보의 색인화와 참조를 사용 가능하게 하는 네임스페이스.

X.500 디렉토리 구조는 정보 저장 및 검색 측면에서 다른 디렉토리와 다릅니다. 이 디렉토리 서비스는 정보와 속성을 연관시킵니다. 속성에 기초하는 조회가 생성되어 LDAP 서버로 전달되고 서버는 개별 값을 리턴합니다. LDAP은 단순한 문자열 기반 방식을 사용하여 디렉토리 항목을 나타냅니다.

X.500 디렉토리는 ObjectClass 속성에 기초하는 유형이 지정된 항목으로 구성됩니다. 각 항목은 속성으로 구성됩니다. ObjectClass 속성은 개인 또는 조직과 같은 필수 및 선택적 속성을 판별하는 항목 유형을 식별합니다.

지리적 및 조직적 배포의 서버 간에 트리 구조로 배열된 항목을 나눌 수 있습니다. 디렉토리 서비스는 분배 계층 구조에서의 위치에 따라 식별 이름(DN)으로 항목 이름을 지정합니다.

LDAP(Lightweight Directory Access Protocol) 개요. X.500 디렉토리에 액세스하려면 DAP(Directory Access Protocol)가 필요합니다. 그러나 복잡한 프로토콜을 처리하려면 DAP에 많은 시스템 자원과 지원 메커니즘이 필요합니다. 데스크탑 워크스테이션에서 X.500 디렉토리 서비스에 액세스할 수 있도록 하기 위해 LDAP이 도입되었습니다.

클라이언트 및 서버 기반 프로토콜인 LDAP은 DAP 클라이언트에 필요한 많은 자원 중 일부를 처리할 수 있습니다. LDAP 서버는 결과 또는 오류만 클라이언트로 리턴하므로 클라이언트에서 수행해야 할 작업이 적습니다. 클라이언트 요청에 응답할 수 없는 경우 LDAP 서버가 요청을 다른 X.500 서버로 연결해야 합니다. 서버가 요청을 완료하거나 LDAP 서버로 오류를 리턴해야 합니다. 그러면 클라이언트로 정보가 전달됩니다.

IBM HTTP Server는 다음 LDAP 서버를 지원합니다.
  • iPlanet/Netscape Directory Server
  • IBM SecureWay Directory Server
  • Microsoft Active Directory

ldapsearch를 사용하여 LDAP 구성 문제점 디버그

LDAP 구성이 올바로 작업하지 못하게 하는 일부 인스턴스가 있습니다. 예를 들어,
  • 관리자 액세스 제어 목록(ACL, access control list)에 식별 이름(DN, distinguished name)이 없어서 일부 LDAP 조회를 수행할 수 없습니다.
  • 로그인 실패 횟수가 초과되어 DN이 LDAP에 접근할 수 없습니다.
  • DN 비밀번호가 변경되었을 수 있습니다.
  • LDAP 서버에서 익명의 조회를 허용하지 않습니다.
  • 다음에 정의된 기본 필터는 WebSphere® Application Server 설정에 맞지 않을 수 있습니다(예:objectclass=someObjectClass 정의되어 있습니다)
  • 포트에서 방화벽이 통신을 허용하지 않습니다.
  • LDAP가 389가 아닌 비표준 포트를 사용하도록 설정되었습니다.
  • LDAP 관리자 ID를 서버 ID로 사용하고 있으나 관리자 ID가 일반 사용자로 지정되지 않았습니다.
위와 같은 인스턴스 또는 기타 인스턴스로 인해 LDAP 구성이 제대로 작동하지 못하는 경우 ldapsearch를 사용하여 신속하게 문제점을 디버그할 수 있습니다. ldapsearch는 다음과 유사한 명령줄 유틸리티입니다. WebSphere Application Server 관리 콘솔에서 LDAP 서버를 쿼리하는 데 사용됩니다. 예를 들어,
ldapsearch -h <Host> -p <Port> -b "<BaseDN>" -D <BindDN> -w <Bind Password> "<User Filter>"
상황:
호스트
LDAP 서버의 호스트 이름입니다. 호스트 이름으로 짧은 이름, 긴 이름 또는 IP 주소 등을 사용할 수 있습니다.
포트
기본 LDAP 포트 이름은 389입니다.
BaseDN
조회가 LDAP 트리에서 위치 검색을 시작합니다.
BindDN
LDAP 서버에 바인드하고 요청된 조회를 수행할 권한이 있는 완전한 DN입니다. 일부 LDAP 서버에서 익명의 조회를 허용하므로 바인드 DN 또는 바인드 비밀번호가 필요하지 않습니다.
바인드 비밀번호
바인드 DN의 비밀번호입니다.
사용자 필터
LDAP 서버를 조회하는 데 사용되는 문자열입니다.
Idapsearch 조회의 예:
C:\>ldapsearch -h petunia -p 389 -b "o=ibm,c=us" uid=test
cn=test,o=ibm,c=us
sn=test
objectclass=top
objectclass=organizationalPerson
objectclass=ePerson
objectclass=person
objectclass=inetOrgPerson
uid=test
cn=test

C:\>ldapsearch -h petunia -p 389 -b "o=ibm,c=us" "(&(uid=test)(objectclass=ePerson))"
cn=test,o=ibm,c=us
sn=test
objectclass=top
objectclass=organizationalPerson
objectclass=ePerson
objectclass=person
objectclass=inetOrgPerson
uid=test
cn=test