test

Sun Java System Directory Server Enterprise Edition 6.3 관리 설명서

SASL에서 GSSAPI를 사용하는 Kerberos 인증 구성의 예

디렉토리 서버에 대한 Kerberos 구성 작업은 복잡할 수 있습니다. 먼저 Kerberos 설명서를 참조하십시오.

다음의 절차 예를 사용하면 수행할 단계를 고려하는 데 도움이 됩니다. 그러나 이러한 절차는 예로 제시된 것이므로 자신의 구성과 환경에 맞게 수정해야 합니다.

Solaris OS에서 Kerberos를 구성하고 사용하는 방법에 대한 자세한 내용은 System Administration Guide: Security Services를 참조하십시오. 이 설명서는 Solaris 설명서 세트의 일부로, 설명서 페이지를 참조할 수도 있습니다.

    이 예와 해당 단계에 대한 내용은 다음과 같습니다.

  1. 이 예에 대한 가정

  2. 모든 컴퓨터: Kerberos 클라이언트 구성 파일 편집

  3. 모든 컴퓨터: Administration Server ACL 구성 파일 편집

  4. KDC 컴퓨터: KDC 서버 구성 파일 편집

  5. KDC 컴퓨터: KDC 데이터베이스 만들기

  6. KDC 컴퓨터: 관리 사용자(Principal) 및 키 탭 만들기

  7. KDC 컴퓨터: Kerberos 데몬 시작

  8. KDC 시스템: KDC 및 디렉토리 서버 시스템에 호스트 사용자 추가

  9. KDC 컴퓨터: Directory Server에 대한 LDAP 사용자(Principal) 추가

  10. KDC 컴퓨터: KDC에 테스트 사용자 추가

  11. 디렉토리 서버 시스템: 디렉토리 서버 설치

  12. 디렉토리 서버 컴퓨터: GSSAPI를 활성화하도록 디렉토리 서버 구성

  13. 디렉토리 서버 시스템: 디렉토리 서버 키 탭 만들기

  14. 디렉토리 서버 시스템: 디렉토리 서버에 테스트 사용자 추가

  15. 디렉토리 서버 컴퓨터: 테스트 사용자로 Kerberos 티켓 얻기

  16. 클라이언트 컴퓨터: GSSAPI를 통해 디렉토리 서버에 인증

이 예에 대한 가정

이 절차 예에서는 컴퓨터 한 대가 KDC(Key Distribution Center)로 작동하고 보조 컴퓨터가 디렉토리 서버를 실행하도록 구성하는 프로세스를 설명합니다. 이 절차를 사용하면 사용자가 GSSAPI를 통해 Kerberos 인증을 수행할 수 있습니다.

동일한 컴퓨터에서 KDC와 디렉토리 서버를 모두 실행할 수 있습니다. 동일한 컴퓨터에서 모두 실행되도록 선택한 경우, 같은 절차를 사용하지만 이미 디렉토리 서버 컴퓨터에서 KDC 컴퓨터에 대해 수행한 단계는 생략합니다.

이러한 절차는 사용하는 환경에 대한 여러 가지 가정을 전제로 합니다. 절차 예를 사용하는 경우 사용자의 환경에 맞게 값을 적절히 수정합니다. 다음과 같이 가정할 수 있습니다.

모든 컴퓨터: Kerberos 클라이언트 구성 파일 편집

/etc/krb5/krb5.conf 구성 파일은 KDC와 통신하기 위해 Kerberos 클라이언트에서 필요로 하는 정보를 제공합니다.

KDC 컴퓨터, 디렉토리 서버 컴퓨터 및 Kerberos를 사용하여 디렉토리 서버에 인증할 클라이언트 컴퓨터의 /etc/krb5/krb5.conf 구성 파일을 편집합니다.

업데이트된 /etc/krb5/krb5.conf 구성 파일은 다음 예와 같습니다.

예 6–1 편집된 Kerberos 클라이언트 구성 파일 /etc/krb5/krb5.conf 


#pragma ident   "@(#)krb5.conf  1.2     99/07/20 SMI"
# Copyright (c) 1999, by Sun Microsystems, Inc.
# All rights reserved.
#
# krb5.conf template
# In order to complete this configuration file
# you will need to replace the __<name\>__ placeholders
# with appropriate values for your network.
#

[libdefaults]
        default_realm = EXAMPLE.COM
[realms]
        EXAMPLE.COM = {
                kdc = kdc.example.com
                admin_server = kdc.example.com
        }
[domain_realm]
        .example.com = EXAMPLE.COM
[logging]
        default = FILE:/var/krb5/kdc.log
        kdc = FILE:/var/krb5/kdc.log
        kdc_rotate = {

# How often to rotate kdc.log. Logs will get rotated no more
# often than the period, and less often if the KDC is not used
# frequently.
                period = 1d

# how many versions of kdc.log to keep around (kdc.log.0, kdc.log.1, ...)
                versions = 10
        }

[appdefaults]
        kinit = {
                renewable = true
                forwardable= true
        }
        gkadmin = {
                help_url =
 http://docs.sun.com:80/ab2/coll.384.1/SEAM/@AB2PageView/1195
        }

모든 컴퓨터: Administration Server ACL 구성 파일 편집

/etc/krb5/kadm5.acl 구성 파일에서 "___default_realm___"을 "EXAMPLE.COM"으로 바꿉니다. 업데이트된 파일은 다음 예와 같습니다.

예 6–2 편집된 Administration Server ACL 구성 파일


#
# Copyright (c) 1998-2000 by Sun Microsystems, Inc.
# All rights reserved.
#
# pragma ident   "@(#)kadm5.acl  1.1     01/03/19 SMI"
*/admin@EXAMPLE.COM *

KDC 컴퓨터: KDC 서버 구성 파일 편집

/etc/krb5/kdc.conf 파일을 편집하여 "___default_realm___"을 "EXAMPLE.COM"으로 바꿉니다. 업데이트된 파일은 다음 예와 같습니다.

예 6–3 편집된 KDC 서버 구성 파일 /etc/krb5/kdc.conf 


# Copyright 1998-2002 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
#ident  "@(#)kdc.conf   1.2     02/02/14 SMI"

[kdcdefaults]
        kdc_ports = 88,750

[realms]
        EXAMPLE.COM = {
                profile = /etc/krb5/krb5.conf
                database_name = /var/krb5/principal
                admin_keytab = /etc/krb5/kadm5.keytab
                acl_file = /etc/krb5/kadm5.acl
                kadmind_port = 749
                max_life = 8h 0m 0s
                max_renewable_life = 7d 0h 0m 0s
                default_principal_flags = +preauth
        }

KDC 컴퓨터: KDC 데이터베이스 만들기


$ /usr/sbin/kdb5_util create -r EXAMPLE.COM -s
Initializing database ’/var/krb5/principal’ for realm ’EXAMPLE.COM’,
master key name ’K/M@EXAMPLE.COM’
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: password
Re-enter KDC database master key to verify: password
$

KDC 컴퓨터: 관리 사용자(Principal) 및 키 탭 만들기

다음 명령을 사용하여 관리 데몬에서 사용할 kws/admin@EXAMPLE.COM 사용자(Principal) 및 서비스 키가 있는 관리 사용자를 만듭니다.


$ /usr/sbin/kadmin.local
kadmin.local:  add_principal kws/admin
Enter password for principal "kws/admin@EXAMPLE.COM": secret
Re-enter password for principal "kws/admin@EXAMPLE.COM": secret
Principal "kws/admin@EXAMPLE.COM" created.
kadmin.local:  ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc.example.com
Entry for principal kadmin/kdc.example.com with kvno 3, encryption type
 DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local:  ktadd -k /etc/krb5/kadm5.keytab changepw/kdc.example.com

Entry for principal changepw/kdc.example.com with kvno 3, encryption type
 DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local:  ktadd -k /etc/krb5/kadm5.keytab kadmin/changepw
Entry for principal kadmin/changepw with kvno 3, encryption type
 DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local:  quit$

KDC 컴퓨터: Kerberos 데몬 시작

다음 명령을 실행하여 KDC 및 관리 데몬을 시작합니다.


$ /etc/init.d/kdc start
$ /etc/init.d/kdc.master start
$

KDC 프로세스는 프로세스 목록에서 /usr/lib/krb5/krb5kdc로 표시되고 관리 데몬은 /usr/lib/krb5/kadmind로 표시됩니다.

Solaris 10 OS의 경우 데몬은 SMF(Service Management Facility) 프레임워크에서 관리합니다. 따라서, Solaris 10 OS에서는 다음 명령을 사용하여 데몬을 시작합니다.


$ svcadm disable network/security/krb5kdc
$ svcadm enable network/security/krb5kdc
$ svcadm disable network/security/kadmin
$ svcadm enable network/security/kadmin
$

KDC 시스템: KDC 및 디렉토리 서버 시스템에 호스트 사용자 추가

다음 명령 시퀀스를 사용하여 KDC 및 디렉토리 서버 컴퓨터의 Kerberos 데이터베이스에 호스트 사용자를 추가합니다. 호스트 사용자는 klist와 같은 특정 Kerberos 유틸리티에서 사용합니다.


$ /usr/sbin/kadmin -p kws/admin
Enter Password: secret
kadmin:  add_principal -randkey host/kdc.example.com
Principal "host/kdc.example.com@EXAMPLE.COM" created.
kadmin:  ktadd host/kdc.example.com
Entry for principal host/kdc.example.com with kvno 3, encryption type
 DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:  add_principal -randkey host/directory.example.com
Principal "host/directory.example.com@EXAMPLE.COM" created.
kadmin:  ktadd host/directory.example.com
Entry for principal host/directory.example.com with kvno 3, encryption type
 DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:  quit
$

KDC 컴퓨터: Directory Server에 대한 LDAP 사용자(Principal) 추가

디렉토리 서버에서 인증 사용자가 보유한 Kerberos 티켓을 확인할 수 있으려면 디렉토리 서버에 자체 사용자(Principal)가 있어야 합니다. 현재 디렉토리 서버는 하드 코드되어 있으므로 ldap/fqdn@realm의 사용자(Principal)가 필요합니다. 여기서 fqdn은 디렉토리 서버의 정규화된 도메인 이름이며 realm은 Kerberos 영역입니다. fqdn은 디렉토리 서버를 설치할 때 제공된 정규화된 이름과 일치해야 합니다. 이 경우, 디렉토리 서버의 사용자(Principal)는 ldap/directory.example.com@EXAMPLE.COM이 됩니다.

다음 명령 시퀀스를 사용하여 디렉토리 서버에 대한 LDAP 사용자(Principal)를 만듭니다.


$ /usr/sbin/kadmin -p kws/admin 
Enter Password: secret 
kadmin: add_principal -randkey ldap/directory.example.com 
Principal "ldap/directory.example.com@EXAMPLE.COM" created. 
kadmin: quit 
$

KDC 컴퓨터: KDC에 테스트 사용자 추가

Kerberos 인증을 수행하려면 사용자 인증이 Kerberos 데이터베이스에 있어야 합니다. 이 예에서 사용자는 kerberos-test라는 사용자 이름을 갖게 되며, 이는 Kerberos 사용자(Principal)가 kerberos-test@EXAMPLE.COM이라는 의미입니다.

다음 예의 명령 시퀀스를 사용하여 사용자를 만듭니다.


$ /usr/sbin/kadmin -p kws/admin
Enter Password: secret
kadmin:  add_principal kerberos-test
Enter password for principal "kerberos-test@EXAMPLE.COM": secret

Re-enter password for principal "kerberos-test@EXAMPLE.COM": secret

Principal "kerberos-test@EXAMPLE.COM" created.
kadmin:  quit
$

디렉토리 서버 시스템: 디렉토리 서버 설치

Directory Server 6.0과 최신 패치를 설치합니다. 설정 예는 다음과 같습니다.

변수 유형 

예 값 

정규화된 컴퓨터 이름 

directory.example.com

설치 디렉토리 

/opt/SUNWdsee

인스턴스 경로 

/local/ds

서버 사용자 

unixuser

서버 그룹 

unixgroup

서버 포트 

389

접미어 

dc=example,dc=com

디렉토리 서버 컴퓨터: GSSAPI를 활성화하도록 디렉토리 서버 구성

먼저 /data/ds/shared/bin/gssapi.ldif 파일을 만들어 디렉토리 서버에서 사용할 매핑을 정의하고 사용자(Principal)를 기반으로 인증할 Kerberos 사용자를 식별합니다. 다음 예와 동일한 내용으로 파일을 만듭니다.

예 6–4 gssapi.ldif 파일 내용


dn: cn=GSSAPI,cn=identity mapping,cn=config
changetype: add
objectClass: top
objectClass: nsContainer
cn: GSSAPI
dn: cn=default,cn=GSSAPI,cn=identity mapping,cn=config
changetype: add
objectClass: top
objectClass: nsContainer
objectClass: dsIdentityMapping
objectClass: dsPatternMatching
cn: default
dsMatching-pattern: \${Principal}
dsMatching-regexp: (.*)@EXAMPLE.COM
dsMappedDN: uid=\$1,ou=People,dc=example,dc=com

dn: cn=SASL,cn=security,cn=config
changetype: modify
replace: dsSaslPluginsPath
dsSaslPluginsPath: /usr/lib/mps/sasl2/libsasl.so

다음으로, 아래 예와 같이 ldapmodify 명령을 사용하여 적절한 매핑으로 GSSAPI를 활성화하도록 디렉토리 서버를 업데이트합니다.


$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -a -f /data/ds/shared/bin/gssapi.ldif
adding new entry cn=GSSAPI,cn=identity mapping,cn=config
adding new entry cn=default,cn=GSSAPI,cn=identity mapping,cn=config
modifying entry cn=SASL,cn=security,cn=config
$

디렉토리 서버 시스템: 디렉토리 서버 키 탭 만들기

앞서 언급한 바와 같이 디렉토리 서버는 GSSAPI를 통해 Kerberos 사용자를 인증하기 위해 KDC에 자체 사용자(Principal)가 있어야 합니다. 인증 작업이 올바로 작동하려면 이 사용자(Principal) 정보는 디렉토리 서버 컴퓨터의 Kerberos 키 탭에 있어야 합니다. 또한, 이 정보는 디렉토리 서버가 작동하는 사용자 계정에서 읽을 수 있는 파일 형식이어야 합니다.

다음 명령 시퀀스를 사용하여 올바른 등록 정보를 가진 키 탭 파일을 만듭니다.


$ /usr/sbin/kadmin -p kws/admin
Enter Password: secret
kadmin:  ktadd -k /local/ds/config/ldap.keytab ldap/directory.example.com
Entry for principal ldap/directory.example.com with kvno 3, encryption type
 DES-CBC-CRC added to keytab
 WRFILE:/local/ds/config/ldap.keytab.
kadmin:  quit
$

이 사용자 정의 키 탭의 사용 권한과 소유권을 변경합니다. 키 탭은 디렉토리 서버를 실행하는 데 사용되는 사용자 계정에서 소유해야 하며 해당 사용자만 읽을 수 있어야 합니다.


$ chown unixuser:unixgroup /local/ds/config /ldap.keytab
$ chmod 600 /local/ds/config/ldap.keytab
$

기본적으로 디렉토리 서버는 /etc/kerb5/krb5.keytab 파일의 표준 Kerberos 키 탭을 사용하려고 합니다. 그러나 이 파일을 디렉토리 서버 사용자가 읽을 수 있도록 만들면 보안상 위험이 따르며, 이러한 이유로 디렉토리 서버에 사용자 정의 키 탭을 만들어야 합니다.

새 사용자 정의 키 탭을 사용하도록 디렉토리 서버를 구성합니다. KRB5_KTNAME 환경 변수를 설정하여 이 작업을 수행합니다.

마지막으로, 이러한 변경 사항이 적용되도록 디렉토리 서버를 다시 시작합니다.


$ KRB5_KTNAME=/etc/krb5/ldap.keytab dsadm restart /local/ds

디렉토리 서버 시스템: 디렉토리 서버에 테스트 사용자 추가

디렉토리 서버에 Kerberos 사용자를 인증하기 위해서는 해당 사용자의 Kerberos 사용자(Principal)에 해당하는 사용자에 대한 디렉토리 항목이 있어야 합니다.

이전 단계에서 kerberos-test@EXAMPLE.COM 사용자(Principal)가 있는 Kerberos 데이터베이스에 테스트 사용자가 추가되었습니다. 아이디 매핑 구성이 디렉토리에 추가되었기 때문에 그 사용자에 해당하는 디렉토리 항목에는 uid=kerberos-test,ou=People,dc=example,dc=com이라는 DN이 있어야 합니다.

사용자를 디렉토리에 추가하려면 다음 내용으로 testuser.ldif 파일을 만들어야 합니다.

예 6–5 새 testuser.ldif 파일


dn: uid=kerberos-test,ou=People,dc=example,dc=com
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: kerberos-test
givenName: Kerberos
sn: Test
cn: Kerberos Test
description: An account for testing Kerberos authentication through GSSAPI

다음으로, ldapmodify를 사용하여 이 항목을 서버에 추가합니다.


$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -f testuser.ldif
adding new entry uid=kerberos-test,ou=People,dc=example,dc=com
$

디렉토리 서버 컴퓨터: 테스트 사용자로 Kerberos 티켓 얻기

테스트 사용자는 Kerberos 데이터베이스와 디렉토리 서버 및 KDC에 있습니다. 따라서, 이제 GSSAPI를 사용하여 Kerberos를 통해 테스트 사용자로 디렉토리 서버에 인증할 수 있습니다.

먼저 아래 예와 같이 kinit 명령을 사용하여 이 사용자에 대한 Kerberos 티켓을 얻습니다.


$ kinit kerberos-test
Password for kerberos-test@EXAMPLE.COM: secret
$

그런 다음 klist 명령을 사용하여 이 티켓에 대한 정보를 확인합니다.


$ klist
Ticket cache: /tmp/krb5cc_0
Default principal: kerberos-test@EXAMPLE.COM

Valid starting            Expires                   Service principal
Sat Jul 24 00:24:15 2004  Sat Jul 24 08:24:15 2004  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until Sat Jul 31 00:24:15 2004
$

클라이언트 컴퓨터: GSSAPI를 통해 디렉토리 서버에 인증

마지막 단계로 GSSAPI를 사용하여 디렉토리 서버에 인증합니다. 디렉토리 서버에 제공된 ldapsearch 유틸리티는 GSSAPI, DIGEST-MD5 및 EXTERNAL 메커니즘을 비롯하여 SASL 인증에 대한 지원을 제공합니다. 그러나, GSSAPI를 사용하여 바인드하려면 클라이언트에 SASL 라이브러리에 대한 경로를 제공해야 합니다. 이 경로를 제공하려면 SASL_PATH 환경 변수를 lib/sasl 디렉토리로 설정합니다.


$ SASL_PATH=SASL-library
$ export SASL_PATH
$

ldapsearch를 사용하여 디렉토리 서버에 대한 Kerberos 기반의 인증을 올바르게 수행하려면 -o mech=GSSAPI 및 -o authzid=principal 인수를 포함해야 합니다.

또한, 여기에 표시된 -h directory.example.com과 같이 정규화된 호스트 이름도 지정해야 합니다. 여기서 이 값은 서버의 cn=config에 대한 nsslapd-localhost 속성 값과 일치해야 합니다. GSSAPI 인증 프로세스 중 클라이언트가 제공한 호스트 이름이 서버에서 제공한 호스트 이름과 일치해야 하기 때문에 위와 같이 -h 옵션을 사용해야 합니다.

다음 예는 이전에 만든 Kerberos 테스트 사용자 계정으로 인증되는 동안 dc=example,dc=com 항목을 검색합니다.


$ ldapsearch -h directory.example.com -p 389 -o mech=GSSAPI \
 -o authzid="kerberos-test@EXAMPLE.COM" -b "dc=example,dc=com" -s base "(objectClass=*)"
version: 1
dn: dc=example,dc=com
dc: example
objectClass: top
objectClass: domain
$

디렉토리 서버 액세스 로그를 검사하여 인증이 예상대로 처리되었는지 확인합니다.


$ tail -12 /local/ds/logs/access

[24/Jul/2004:00:30:47 -0500] conn=0 op=-1 msgId=-1 - fd=23 slot=23 LDAP 
		connection from 1.1.1.8 to 1.1.1.8
[24/Jul/2004:00:30:47 -0500] conn=0 op=0 msgId=1 - BIND dn="" method=sasl 
     version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=0 msgId=1 - RESULT err=14 tag=97 
     nentries=0 etime=0, SASL bind in progress
[24/Jul/2004:00:30:47 -0500] conn=0 op=1 msgId=2 - BIND dn="" method=sasl 
     version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=1 msgId=2 - RESULT err=14 tag=97 
     nentries=0 etime=0, SASL bind in progress
[24/Jul/2004:00:30:47 -0500] conn=0 op=2 msgId=3 - BIND dn="" method=sasl 
     version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=2 msgId=3 - RESULT err=0 tag=97 
     nentries=0 etime=0 dn="uid=kerberos-test,ou=people,dc=example,dc=com"
[24/Jul/2004:00:30:47 -0500] conn=0 op=3 msgId=4 - SRCH base="dc=example,dc=com"
     scope=0 filter="(objectClass=*)" attrs=ALL
[24/Jul/2004:00:30:47 -0500] conn=0 op=3 msgId=4 - RESULT err=0 tag=101 nentries=1 
     etime=0
[24/Jul/2004:00:30:47 -0500] conn=0 op=4 msgId=5 - UNBIND
[24/Jul/2004:00:30:47 -0500] conn=0 op=4 msgId=-1 - closing - U1
[24/Jul/2004:00:30:48 -0500] conn=0 op=-1 msgId=-1 - closed.
$

이 예에서 바인드는 3단계 프로세스로서, 처음 두 단계에서는 LDAP 결과 14(처리 중인 SASL 바인드)가 반환되었으며 세 번째 단계에서는 해당 바인드가 성공적으로 처리되었음을 보여줍니다. method=sasl 및 mech=GSSAPI 태그는 이 바인드에서 GSSAPI SASL 메커니즘을 사용했음을 나타내며, 성공적으로 처리된 바인드 응답의 끝 부분에 있는 dn="uid=kerberos-test,ou=people,dc=example,dc=com"은 바인드가 적합한 사용자로 수행되었음을 나타냅니다.