Centralized authentication using OpenLDAP/ko

이 안내서는 LDAP 기초를 소개하고 컴퓨터 그룹을 인증하는데 사용할 OpenLDAP를 어떻게 설정하는지 보여드립니다.

LDAP는 무엇인까요?
LDAP는 경량형 디렉터리 접근 프로토콜을 의미합니다. X.500에 기반하며 주된 기능의 대부분을 아우르고 있지만 X.500이 가진 일부 기능에는 부족함이 있습니다. 자, 그러면 X.500은 무엇이고 왜 LDAP가 있는걸까요?

X.500은 OSI 개념의 디렉터리 서비스 모델입니다. 여기엔 이름 공간의 정의와 디렉터리 요청 및 업데이트용 프로토콜이 들어있습니다. 그러나, X.500은 대부분의 상황을 엉망으로 휘저어놓았습니다. LDAP로 오십시오. X.500처럼 디렉터리의 데이터/이름공간 모델과 프로토콜도 제공합니다. 그러나 LDAP는 TCP/IP 스택을 통해 바로 동작하도록 설계했습니다. X.500에서 군더더기를 뺀 결과물로서 LDAP를 이해하십시오.

잘 모르겠는데요. 디렉터리가 뭔가요?
디렉터리는 빈번한 요청에 드물게 업데이트를 수행하도록 설계하여 특화된 데이터베이스입니다. 일반 데이터베이스와는 달리 트랜잭션 지원 기능이나 롤백 기능이 없습니다. 디렉터리는 가용성과 신뢰성을 개선하기 위해 쉽게 복제할 수 있습니다. 디렉터리를 복제하면, 디렉터리를 동기화 한 만큼 일시적인 비일관성도 허용됩니다.

정보가 어떻게 구성되어 있죠?
모든 디렉터리 내부 정보는 계층 구조로 되어 있습니다. 게다가 디렉터리에 데이터를 입력하면 트리에 데이터를 어떻게 저장하는지 알아야 합니다. 그러면 허구속의 회사와 인터넷과 비슷한 트리를 보도록 하겠습니다:

아스키 아트 유사 방식으로 데이터베이스에 데이터를 넣지 않았기 때문에 각 트리의 모든 노드를 반드시 정의해야 합니다. LDAP에서는 이 노드에 이름을 부여하려 작명 스킴을 사용합니다. 대부분의 LDAP 구성(OpenLDAP 포함)에서는 이미 설정한(그리고 일반적으로 승인하는) inetOrgPerson 같은 스키마와 유닉스/리눅스 머신에서 사용할 수 있도록 사용자를 정의하는 지주 사용하는 posixAccount 스키마가 있습니다. LDAP를 문제 없이 관리할 수 있게 하는 GUI 웹 기반 도구가 있음을 참고하십시오. 대략적인 목록은 Working with OpenLDAP을 보십시오

흥미를 가진 사용자라면 OpenLDAP 관리자 안내서를 보십시오.

그래서... 어디에 사용할 수 있죠?
LDAP는 다양한곳에 사용할 수 있습니다. 이 문서는 사용자 관리를 집중화하고, 단일 LDAP 위치에서 모든 사용자 계정을 관리(단일 서버에 저장한다는 의미가 아니며, LDAP에서는 고가용성과 중복성을 지원합니다)하며, 이와 마찬가지로 그 밖에 LDAP를 활용하는 곳에서 사용 목적을 달성할 수 있습니다.


 * 공개 키 인프라스트럭처


 * 공유 달력


 * 공유 주소록


 * DHCP, DNS등의 저장소


 * 시스템 수준 설정 지시문(몇가지 서버 설정 유지)


 * 집중화된 인증(PosixAccount)



Common notes
이 안내서에서는 genfic.com을 예로 들겠습니다. 물론 이 도메인을 다른 도메인으로 바꿀 수 있습니다. 그러나 공식 상위 도메인(net, com, cc, be, ...)이 상위 노드에 위치했는지 확인하십시오.

먼저 OpenLDAP를 이머지하겠습니다. berkdb, crypt, gnutls, ipv6, sasl, ssl, syslog,-minimal, tcpd USE 플래그를 사용했는지 확인하십시오.

OpenLDAP supports two authentication mechanisms:


 * 1) Standard user-password (in LDAP terms user means binddn) named SIMPLE.
 * 2) Proxying authentication requests to SASL (Simple Authentication and Security Layer, see RFC4422 for details).

Although the OpenLDAP default is to use SASL, the initial version of this article used only password-based authentication. With the OLC add-on the article starts to describe the use of the simplest SASL mechanism called EXTERNAL, which relies on the system authentication.

OpenLDAP의 주 사용자는 프로그램에 하드코딩한 rootdn(루트 식별 이름) 입니다. 기존의 유닉스 루트 사용자와는 달리, rootdn 사용자는 적당한 권한 할당이 필요합니다. rootdn 사용자는 설정 환경에서만 활용할 수 있지만 디렉터리 정의 범위에서도 사용할 수 있습니다. 이 경우 해당 사용자는 환경 설정에 넣은 암호과 트리(디렉터리 기반) 암호를 사용하여 rootdn으로 자신을 인증 할 수 있습니다.

검증 목적의(rootdn 사용자 여부와는 상관 없는) 사용자 암호는 평문 또는 해시 문자열로 저장할 수 있습니다. 다양한 해시 알고리즘을 사용할 수 있지만, 취약한 알고리즘의 사용(MD5 까지)은 권장하지 않습니다. SHA는 현재 암호화 보안 수단으로 활용하기에 충분합니다.

아래 명령을 통해, 주어진 암호에 대한 해시값을 만듭니다. 이 명령의 결과는 설정 파일에서 사용하거나 사용자 내부 디렉터리 정의 용도로 사용할 수 있습니다:

Legacy configuration (flat config slapd.conf)
에 있는 LDAP 서버 설정을 편집하십시오. 제공된 는 원본 OpenLDAP 소스 코드에 들어있는 파일입니다. 아래 예제 설정 파일은 처음 시작할 때 대체할 내용으로 사용할 수 있습니다.

더 자세하게 설정 파일을 분석하려면, OpenLDAP 관리자 안내서를 보며 진행하시는게 좋습니다.

파일을 사용자의 취향대로 이리저리 설정하고 난 후, 다음 명령으로 확인할 수 있습니다.

더 많은 내용을 확인하려면 디버그 레벨("-d 1" 이상)을 바꿔보십시오. 모든 동작이 잘 된다면 "config file testing succeedded"가 보입니다. 오류가 있다면, 에서 ( 파일에서) 오류가 난 부분의 줄 번호를 표시합니다

By default writes the log events to the local4 syslog facility.

참고로 2.4.23부터는, OpenLDAP의 기본 설정 방식이 기존 플랫 설정 파일에서 OLC(OnLineConfiguration,   구조로 알려짐) 방식으로 바뀌었습니다. OLC를 사용하면 설정을 업데이트한 후 동적 백엔드(cn=config)에서 서버를 재시작할 필요가 없는 장점이 있습니다. 기존의 사용자는  명령 실행시 -f 와 -F 옵션 설정을 사용하는 새 설정 방식으로 옮겨갈 수 있습니다. 기존의 OLC는 디렉터리의 ldif 백엔드(사용자가 알아볼 수 있는 장점이 있음) 에 저장했습니다. 젠투에서는 아직 설정을 변환할 필요가 없지만 현재 문서로 정리한 방법은 나중에 제거합니다.

Migration from slapd.conf to OLC
OpenLDAP 서버 설정을 바꿀 수 있게 하려면 최소한 에 쓰기(또는 일반 관리) 접근 권한을 정의해야 합니다.

아래 예시에서는 파일 마지막에 적당한 줄을 추가하여 시스템 관리자(루트 사용자)에게 OLC(cn=config 데이터베이스) 접근 권한을 부여하는 방법을 보여줍니다:

Then, invoke the utility with the   and   options to convert the  file into a configuration directory.

이 명령을 실행하면 설정을 보내고 변환합니다. 이 과정이 끝나면 각각 마련된 ldif 파일을 사용하여 설정을 업데이트함니다. 그리고 이 방식에 충분히 익숙하지 않다면, 우선 를 편집하고, 그 다음에 파일을  형식에 맞춰 재작성할 수 있습니다. 디렉터리 권한 확인을 잊지 마십시오.

더 많은 내용은 만들어진 파일의 자체 주석을 참고하십시오.

아래 줄은 설정 방식을 활성화합니다.

마지막으로, 구조를 만드십시오:

Initial setup with OLC
An initial configuration is shipped as a standard LDAP database dump, available as or.

This initial configuration can be loaded (and only loaded, unlike ordinary LDAP databases) by the utility:

When using a root account, be sure to correct ownership of the files created by root, as described below in migrate section.

For the right to change the configuration database, proper permissions must be provided. The next example shows how these privileges are granted to the system user:

See for more details.

When using OLC, never manually edit the configuration files. The directory files can be used to check the consistency of the configuration through:

디렉터리 관리
slapd를 시작하십시오:

Most users will also want the OpenLDAP daemon to start automatically:

아파치/proftpd/qmail/삼바에서 사용자를 인증할 때 디렉터리를 사용하여 시작할 수 있습니다. 쉬운 관리 인터페이스를 제공하는 LAM (LDAP 계정 관리자) phpldapadmin,diradm, jxplorer, lat으로 관리할 수 있습니다.

The directory server can be managed with tools such as, and  from the Gentoo ebuild repository, or  from the poly-c overlay available through Layman or eselect repository.

Server management with OLC
OLC 방식 설정 업데이트 예제를 아래에 보여드리겠습니다.

예를 들자면, OLC 설정 디렉터리 위치를 바꾸려면:

OpenLDAP 인스턴스에서 사용할 로그 레벨을 바꾸려면:

바뀐 내용을 적용하려면, 다음 명령을 실행하십시오:

OpenLDAP logging
OpenLDAP produces numerous log events, which might not be obvious to interpret, but are necessary for debugging purposes.

As OpenLDAP by default writes the log events into the system log, it is advisable to reconfigure the system logger to direct OpenLDAP log events into a dedicated log file.

It is advisable to use the  log level in OpenLDAP standalone server and   in OpenLDAP cluster. In such case query results logs session-related information such as the following:

Most common errors in server log are :

Which means «invalid credentials» (i.e. wrong password).

And :

Which means «No such object». Usually this error appears when binddn (user) has no permissions on requested object. So either try to do something wrong, or there is a mistake in the set ACLs.

Access management (ACLs)
The authorizations and access control mechanism used in OpenLDAP is described in the manual page. Its base syntax is as follows:

The following table shows the access levels available in OpenLDAP:

For details about the exact privilege settings, see the manual pages and official OpenLDAP documentation.

Config file
ACLs are parsed in the order they are set in the configuration, and are applied based on the specificity (meaning that, when an ACL rule is considered, the remainder of ACL rules is no longer checked). As such, more specific definitions should go first, before more generic ones are listed. For more information, see Access Control Evaluation.

For example:

Config directory
ACLs are parsed in the order they are set in the configuration, and are applied based on the specificity (meaning that, when an ACL rule is considered, the remainder of ACL rules is no longer checked). As such, more specific definitions should go first, before more generic ones are listed. This order, when using OLC, is handled through the  directives.

For example:

The following example inserts a new ACL on top, making the existing  entries to shift by one:

To delete an ACL:

고가용성
바뀌는 상황의 복제는 여러대의 LDAP 시스템에서 일어납니다. 이 안내서에서 OpenLDAP에서의 복제 동작은, 첫번째 LDAP 서버에서 권한을 읽어들이고 첫번째 LDAP 서버에서 두번째로 바뀐 내용을 끌어들이도록 하는 특정 복제 계정을 활용하여 설정합니다.

Replication within OpenLDAP is, in this guide, set up using a specific replication account which has read rights on the primary LDAP server and which pulls in changes from the primary LDAP server to the secondary.

두번째 LDAP 서버가 첫번째 서버의 동작과 유사한 동작을 허용한 상태에서 이 설정을 복제합니다. OpenLDAP의 내부 구조에 감사해야 할 일은 LDAP 구조상 바뀐 내용이 또 있다 할지라도 중복 적용하지 않습니다.

복제 설정
복제를 설정하려면, 우선, 먼저 위에서 진행한 바와 같이 두번째 OpenLDAP 서버를 설정해야 합니다. 그러나 설정 파일에 대해서는 다음을 주의하십시오.


 * 동기화 복제 제공자는 다른 시스템을 가리킵니다


 * 각각의 OpenLDAP의 서버 ID는 다릅니다

Synchronisation account
다음, 동기화 계정을 만드십시오. LDIF 파일(LDAP서버 에서 데이터 입력할때 사용하는 형식)을 만들고 LDAP 서버 각각에 이를 추가하겠습니다.

Enabling syncprov overlay
Overlay can be linked statically and dynamically. When it is built dynamically, you'll need to load module. For now in Gentoo it's usually built statically. To ensure type:

Load syncprov module (optional)
To load syncprov module, use the following ldif file:

Setting up replication for database
Next step, mandatory for everybody, is to setup replication for database (must be done on both nodes):

Final configuration
Finally, add replication's definition.

On node 1:

traditionally means the password string.

On node 2:

The only difference is in server's ident (rid) and provider uri.

If LDAP master (mirror node with initially loaded database) is unavailable (slapd daemon not started, or 389/tcp port is blocked by a packet filter) slapd daemon on secondary node fails to start with the following error message:

Almost certainly the database will not fit into default limits. So, you will need to increase 's limits. For example:

Performance tuning
Default daemon settings significantly limits LDAP server performance.

Symptoms
When server load fits system limit client applications fails with different kind of timeout errors.

In server log this produces error messages like following:

Increasing OS limits
First, read system user limits:

The first parameter, you need to increase, is the open files limit.

Maximum available value is described in Documentation/sysctl/fs.txt file of kernel documentation:

PAM system limits are stored in /etc/security/limits.conf file or, optionally, in /etc/security/limits.d/ directory. Daemons, started with init system use these parameters (see  for details), so you need just to put in the file:

And restart daemon.

The next limitation is 's  parameter.

During run time, this value can be updated via:

After verifying new value do not forget to fix it:

And, possibly, some other application-specific parameters.

OpenLDAP 클라이언트 도구 설정
LDAP 클라이언트 설정 파일을 편집하십시오. 이 파일은 ldapsearch 및 다른 ldap 명령행 도구에서 읽어들입니다.

다음 명령으로 서버 동작을 시험해볼 수 있습니다:

오류가 나타났다면, 자세한 수준을 늘리기 위해 를 추가하고, 처한 문제를 해결해보십시오.

중앙 인증용 클라이언트 설정
원격 인증에 사용할 수 있는 방식과 도구는 많이 있습니다. 어떤 배포판에서는 사용하기 쉬운 자체 도구도 있습니다. 아래에는 특별한 순서는 없습니다. 로컬 사용자와 중앙 인증 계정을 통시에 합칠 수 있습니다. LDAP 서버가 루트 계정으로 여전히 로그인할 수 있는 위치에 접근할 수 없는 경우 등의 이유로 이러한 점은 중요합니다.


 * SSSD (Single Sign-on Services Daemon). 시스템에 캐싱, 오프라인 지원 기능을 제공할 수 있는 일반 프레임워크를 통해 원격 자원을 식별하고 인증하여 접근하는 기능을 제공하는 근본 기능을 수행합니다. PAM과 NSS 모듈을 제공하며, 나중에는 확장 사용자 정보에 대해 D-Bus 인터페이스를 지원할 예정입니다. 확장 사용자 데이터로 로컬 사용자를 저장하기 위해 더 나은 데이터베이스를 제공하기도 합니다.


 * LDAP 서버에 로그인하고 인증하기 위해 를 사용합니다. 암호는 네트워크 상에 분명한 텍스트로 전송하지 않습니다.


 * NSLCD (Name Service Look up Daemon). SSSD와 유사하지만 오래됐습니다.


 * 기존  모듈을 사용하는 NSS(Name Service Switch)로 네트워크로 암호 해시를 가져옵니다. 사용자가 암호를 새로 바꿀 수 있게 하려면,   방식과 결합합니다.

아랫 부분에 시연한 처음 두 부분은, 동작하게 하는 최소한의 필요 설정 옵션입니다.

SSSD 방식의 클라이언트 PAM 설정
더 직접적인 방식이 있습니다. 아래에 필요한 세가지 파일을 편집한 상태로 보여드리겠습니다.

sssd 시스템 서비스의 역할로서의 검색을 활성화 하려면 하부에 보이는대로 마지막 부분에 sss를 추가하십시오. 편집을 끝내고 나면 sssd 데몬을 시작하십시오.

마지막 파일은 상당히 중요합니다. 편집하기 전에 추가 루트 터미널을 대체 수단으로 여십시오. 으로 끝나는 줄은 원격 인증을 활성화하려 추가했습니다. 참고로 사용자 디렉터리 만들기를 지원하는 파일을 사용합니다.

이제 다른 머신에서 로그인하십시오.

pam_ldap 모듈 방식으로 클라이언트 PAM 설정
먼저 LDAP 인증을 할 수 있게 PAM을 설정하겠습니다. PAM이 LDAP 인증을 지원하게 를 설치하고, (가 활용하는) 추가 정보에 대해 여러분의 시스템이 LDAP 서버에 대응할 수 있도록 를 설치하십시오.

마지막 파일은 상당히 중요합니다. 이 파일을 편집하기 전의 백업본으로 몇가지 추가 루트 터미널 창을 여십시오. 으로 끝나는 줄은 원격 인증을 활성화하려 추가했습니다.

이제 읽어들이도록 를 바꾸십시오:

다음, 서버에서 (OpenLDAP) 파일을 복사하여 클라이언트에 넣고, 클라이언트가 LDAP 환경을 인식하도록 하십시오:

마지막으로 클라이언트를 설정하여 시스템 계정에 대해 LDAP를 검사하도록 하십시오:

에 붙여넣은 줄 중 하나를( 줄) 주석처리했음을 알아챘다면: 슈퍼유저 권한으로 사용자의 암호를 바꾸려 하지 않는 한 이럴 필요가 없습니다. 이 경우 에 있는 그대로의 텍스트로 루트 암호를 적어넣어야 합니다. 이는 위험한 조치이며 파일 접근 권한을 chmod 명령을 통해 600 값으로 설정해야 합니다. 여러분이 할 일은 파일을 빈채로 두는 것이며, LDAP와 에서 누군가의 암호를 바꾸려 할 경우, 사용자의 암호를 10초 이내로 넣어두었다가 과정 처리가 끝나면 제거하십시오.

기존 데이터를 LDAP로 이전하기
집중화 관리 및 일반 Linux/Unix 요소 관리를 위한 OpenLDAP 설정은 쉽지 않지만, 단일 시스템 관리 관점의 시스템을 OpenLDAP 기반 집중화 관리 시스템을 덜 까다롭게 하는 몇가지 도구와 스크립트가 인터넷에 둥둥 떠다닌다는 점은 감사해야 할 일입니다. :-P

http://www.padl.com/OSS/MigrationTools.html를 방문하셔서 스크립트를 가져오십시오. 이전 도구와 스크립트가 필요합니다.

다음 도구의 압축을 해제하고  스크립트를 압축을 푼 위치에 복사하십시오:

다음 단계에서는 시스템 정보를 OpenLDAP로 옮깁니다. LDAP 구조와 환경에 대한 정보를 제공한 후 스크립트로 이 과정을 진행하십시오.

작성하는 도중에, 도구에서 다음 입력사항을 요구합니다:

또한 도구에서 옮길 계정과 설정이 어떤건지 물어봅니다.

Emerge errors after conversion to LDAP
If for any reasons local user accounts (i.e. /etc/passwd /etc/shadow) or groups (i.e. /etc/group) are deleted after converting the file userbase to LDAP, errors may be encountered relating to missing user (or group) while emerging certain packages.

Example of error while emerging due to missing "apache" local user account: Installing build system files make[1]: Leaving directory '/var/tmp/portage/www-servers/apache-2.4.41/work/httpd-2.4.41'              [ ok ] chown: invalid user: ?apache:apache? * ERROR: www-servers/apache-2.4.41::gentoo failed (install phase): *  fowners failed In such cases, a workaround involves emerging the package using FEATURES=-network-sandbox. Doing so has potential security consequences so system users should remain in local files.

감사문
이 안내서의 목적을 달성하기 위해 머신을 빌려준 Matt Heler에게 감사를 표합니다. 또한 #ldap @ irc.freenode.net의 대단한 분들께도 감사를 드립니다.