LDAP 알아보기

LDAP란?

LDAP란?
LDAP(Lightweight Directory Access Protocol)는 디렉토리 서비스를 제공하기 위한 프로토콜
네트워크상에서 조직이나 개인, 파일, 디바이스 등을 쉽게 조회할 수 있도록 해줍니다.
출처 : 삼성 SDS 블로그

 

우선 LDAP를 이해하기 위해서는 "디렉터리 서비스"에 대한 이해가 필요합니다.

디렉터리 서비스는 사람, 그룹, 장비, 계정 같은 개체의 속성 정보를 계층적으로 저장하고,
조회와 인증에 최적화된 특수 목적의 데이터 저장소입니다.

쉽게 말하면, 디렉터리 서비스란 일종의 조직도와 같습니다.
읽기(조회, 인증)가 압도적으로 많고, 쓰기(사용자 추가, 수정)는 드물다는 가정 위에서 만들어졌습니다.

여기서, 일반적으로 사용되는 RDB와의 차이가 있습니다.

흔히 사용되는 MySQL 같은 RDB와 디렉터리 서비스는 목적 자체가 다릅니다.

 

 

• 데이터 구조
  • RDB : 정규화된 테이블과 조인으로 관계 표현
  • DS : 하나의 계층 트리에 데이터를 배치
• 워크로드
  • RDB : 복잡한 트랜잭션이나 조인, 즉시 정합성 등을 이뤄냄
  • DS : 읽기 중심으로, 복제를 이용해 읽기 부하 분산
• 스키마
  • RDB : 애플리케이션들마다 제각각
  • DS : objectClass와 속성이 표준화되어 서로 다른 시스템이 같은 cn, mail, uid 공유

LDAP는 디렉터리 서비스라고 하지만, 실제로는 프로토콜입니다.

 

디렉터리 서비스의 표준 모델로 자리 잡은 X.500에 대해,
X.500 디렉터리에 접근하기 위한 프로토콜이 DAP(Directory Access Protocol)였습니다.

DAP는 무거운 OSI 프로토콜 스택 전체를 요구하며, 사용에 있어 부담이 생길 수밖에 없었습니다.

이를 극복하기 위해 나온 것이 LDAP로, Lightweight가 붙은 것입니다.

다만, 이름에 Lightweight가 붙어 데이터도 가벼운? 줄 알지만,
데이터가 가볍거나 작다는 것이 아니라,
OSI 스택 전체를 요구하던 DAP 대비 프로토콜과 구현이 가볍다는 의미입니다.

 

또한 TCP 389번 포트 하나로 접속한다는 점에 차이가 있습니다.
(평문으로 관리하기엔 어려움이 있어, TLS로 감싸는 636(LDAPS)또는 StartTLS로 암호화합니다.)

 

LDAP의 데이터 모델

 

트리

 

앞서 LDAP는 트리를 이용해 데이터를 담는다고 하였습니다.

이 트리는 DIT (Directory Information Tree)라 부릅니다.

 

DIT 내 최소 단위는 Entry로,
엔트리 하나가 사람 한 명, 그룹 하나, 조직 하나에 대응합니다.

 

그리고 이러한 엔트리는 DN(Distinguished Name)으로 트리 내에서 유일하게 식별됩니다.

DN을 이해하는 가장 좋은 비유는 파일 시스템의 절대 경로입니다.

uid=hong,ou=people,dc=lab,dc=example,dc=com

 

DN을 분해하면 이렇게 됩니다.

• uid=hong : 같은 부모 밑 형제들 사이에서만 유일하면 되는 이름.
• ou=people : 부모 컨테이너(organizationalUnit, 부서/그룹 같은 계층).
• dc=lab,dc=example,dc=com : 트리의 뿌리(base DN).

DN에 자주 등장하는 약어들은 각각 계층과 용도가 다릅니다.

• dc : domainComponent. 도메인을 조각낸 것, 보통 트리 뿌리를 짓는 데 씁니다.
• ou : organizationalUnit. 부서나 그룹 같은 컨테이너 계층.
• cn : commonName. 표시 이름(사람, 그룹 모두 사용).
• uid : userID. 로그인 아이디.

 

objectClass

 

 

objectClass란?
objectClass는 엔트리의 종류를 규정하고, 어떤 속성이 필수/선택인지 정하는 스키마 요소입니다.
출처 : RFC 4512

 

objectClass는 엔트리가 사람인지 그룹인지 결정합니다.

objectClass는 일종의 폼 템플릿으로,
엔트리에 inetOrgPerson 폼을 붙이면 이름칸(cn, sn)은 필수가 되고 메일칸은 선택이 됩니다.

 

이러한 objectClass는 STRUCTURAL, AUXILIARY, ABSTRACT(top)로 나뉩니다.

이 중 실무에서는 주로 STRUCTURAL과 AUXILIARY을 사용합니다.

• STRUCTURAL
  • 엔트리의 본질적 종류를 정하는 것
• AUXILIARY
  • 기존 엔트리에 속성을 덧붙이는 보조 클래스
  • posixAccount가 대표적인 예시

이렇게 구성된 엔트리들을 텍스트로 표현하는 표준 포맷이 LDIF입니다.

LDIF는 서버 간 데이터를 가져오고 내보내거나 변경을 기술할 때 사용됩니다.
dn:으로 시작해 '속성: 값' 줄이 이어지고, 빈 줄로 레코드를 구분합니다.

dn: uid=hong,ou=people,dc=lab,dc=example,dc=com
objectClass: top
objectClass: inetOrgPerson
cn: Gildong Hong
sn: Hong
uid: hong
mail: hong@lab.example.com

 

ldapsearch 를 사용할 경우, 스크립트를 활용해 ldap 내 조회를 더 쉽게 가져갈 수도 있습니다.

LDAP_URI="ldapIP"
DN="$1"

if ldapsearch -x -H "$LDAP_URI" -b "$DN" -s base dn &> /dev/null; then
    echo "[OK] 존재하는 DN: $DN"
else
    echo "[NO] 없는 DN: $DN"
fi

 

LDAP 활용

 

이러한 LDAP는 특정 회사의 제품이 아니라, IETF의 RFC로 정의된 개방형 프로토콜입니다.

사용자는 LDAP라는 프로그램을 설치하는 것이 아니라,
LDAP라는 프로토콜(규칙)을 구현한 구현체를 설치해 사용하는 것입니다.

 

LDAP의 구현체에는 다음과 같은 프로그램이 있습니다.

• OpenLDAP
• Microsoft Active Directory
• 389 Directory Server
• Apache DS
• Red Hat Directory Server

이들은 모두 LDAP 프로토콜을 구현한 서로 다른 제품으로,
LDAP 자체는 표준 문서로서 벤더에 종속되지 않고 ldapsearch 같은 클라이언트로 접근이 가능합니다.

 

389DS

 

389DS

 

사내에서는 389를 이용해 LDAP를 관리하고 있습니다.

 

사실 그동안 써 온 AD도 내부적으로는 LDAP(과 Kerberos)로 동작하는 디렉터리 서버입니다.
다만 스키마와 관리 방식이 Windows에 강하게 묶여 있을 뿐이죠.

같은 LDAP 구현체임에도, 사내에서 389 DS를 택한 데에는 Linux라는 장벽이 있었습니다.

 

Linux는 user를 모두 숫자(uidNumber, gidNumber)로 알아보는데,
Windows AD는 사람을 SID로 알아보는 문제가 있었습니다.

같은 사용자를 두 OS가 서로 다른 방식으로 식별하고 있던 것입니다.

Linux가 사용자를 로그인시키려면 다음 값들이 필요합니다.

• uidNumber : 숫자 사용자 ID
• gidNumber : 기본 그룹 ID
• homeDirectory : 홈 디렉터리 경로
• loginShell : 로그인 셸

Windows AD는 사용자에게 SID, samAccountName은 주지만, POSIX를 쓰지 않습니다.

이를 극복하고자 사용하던 것이 SFU였습니다.

SFU는 AD 사용자에 uidNum, gidNum 같은 POSIX 속성을 붙여주고,
이를 NIS처럼 배포해 UNIX가 AD 계정을 인식하도록 해줍니다.

 

이러한 SFU를 MS에서 deprecate하며, 내부적으로 Linux 환경 유저들에 한해 AD에서 분리하게 된 것입니다.

 

운영환경

다만, 389 DS를 세웠다고 해서 리눅스가 알아서 계정을 봐주지는 않습니다.

실제로 계정을 읽어오는 주체는 서버가 아니라 각 클라이언트의 연동 데몬입니다.
서버가 조직도를 들고 있어도, 이를 열람해 로그인에 반영하는 것은 클라이언트의 몫인 것이죠.

 

연동을 담당하는 클라이언트 패키지도 하나가 아니라, 세대별로 나뉘어 있습니다.

• nslcd : LDAP 조회와 인증만 담당하는 가볍고 단순한 데몬 (nss-pam-ldapd 패키지)
• nscd : 엄밀히는 LDAP 클라이언트가 아니라, 조회 결과를 캐시해주는 보조 데몬
• sssd : 조회에 캐싱, 오프라인 로그인, 접근 제어까지 묶은 현대적 기본값

이름이 다 비슷하게 생겨서 헷갈려요..

 

무엇을 고르느냐에 따라 권한 관리의 위치도 달라집니다.

 

nslcd를 쓸 경우 PAM 계층의 pam_access로 관리자와 그룹의 접근 권한을 제어하지만,
sssd를 쓸 경우 LDAP 연결, TLS, 캐시, 접근 제어까지 sssd.conf 한 파일로 수정점이 집약됩니다.

 

이처럼 같은 프로토콜을 쓰더라도,
어떤 클라이언트 구성을 고르고 보안과 접근 제어를 어떻게 챙기느냐에 따라 운영의 결이 크게 달라집니다.

 

 

 

마무리

 

 

입사 후 LDAP를 맡아 열심히 적응하는 중이지만,
팀은 기존에 사용하던 389 DS에서 FreeIPA로의 전환을 검토 중입니다.

 

순수 LDAP은 '디렉터리', 즉 신원을 저장하고 조회하는 계층까지만 주기에,
Kerberos 기반 SSO, HBAC, 중앙 sudo 규칙 같은 것들을 관리자가 직접 관리해야합니다.

 

하지만, FreeIPA는 이를 미리 묶어, ipa라는 단일 인터페이스로 관리하게 해줍니다.
(FreeIPA 야호 ..!)

 

다만 이런 FreeIPA도 결국은 LDAP을 활용합니다.
FreeIPA의 디렉터리 백엔드가 바로 389 DS이기 때문입니다.

즉 FreeIPA로 넘어가는 것은 LDAP을 버리는 것이 아니라, LDAP 위에 관리 계층을 얹는 것에 가깝습니다.
앞서 'AD도 결국은 LDAP'라고 했는데, FreeIPA도 열어보면 심장은 389 DS인 셈이죠.

 

정리하면 LDAP은 특정 제품이 아니라,
X.500에 뿌리를 둔 디렉터리 서비스에 TCP/IP로 접근하기 위한 경량 프로토콜입니다.

 

디렉터리는 트리(DIT)에 엔트리를 담아 DN으로 식별하고, objectClass로 종류와 속성을 규정합니다.

그리고 그 위에서 389 DS 같은 구현체, SSSD 같은 클라이언트, TLS 같은 보안 장치가 실제 운영을 만듭니다.

AD든 FreeIPA든, 속을 열어보면 결국 LDAP이 있습니다.

 

팀은 FreeIPA로 넘어가지만, LDAP에 대한 공부가 헛수고가 아닐 것이라 믿습니다.