test

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

6장 디렉토리 서버 보안

디렉토리 서버는 네트워크를 통해 안전하면서도 신뢰할 수 있는 통신을 제공하는 여러 메커니즘을 지원합니다. LDAPS는 SSL(Secure Sockets Layer)에 추가로 실행되는 표준 LDAP 프로토콜로, 데이터를 암호화하고 선택적으로 인증 시에 인증서를 사용합니다. 이 장에서 사용되는 SSL이라는 용어는 지원되는 프로토콜 SSL2, SSL3 및 TLS 1.0을 의미합니다.

디렉토리 서버는 Start TLS(Start Transport Layer Security) 확장 작업을 지원하므로 기존에 암호화되지 않은 LDAP 연결에서 TLS를 사용할 수 있습니다.

또한 디렉토리 서버에서는 SASL(Simple Authentication and Security Layer)을 통한 GSSAPI(Generic Security Service API)도 지원합니다. GSSAPI를 이용하면 Solaris 운영 체제(Solaris OS)에서 Kerberos 버전 5 보안 프로토콜을 사용할 수 있습니다. 이 경우 아이디 매핑 매커니즘이 Kerberos 사용자(Principal)를 디렉토리 아이디와 연결합니다.

자세한 보안 정보는 http://www.mozilla.org/projects/security/pki/nss/의 NSS 웹 사이트를 참조하십시오.

이 장에서는 SSL을 통해 보안을 구성하는 절차에 대해 설명합니다. ACI에 대한 자세한 내용은 7 장, 디렉토리 서버 액세스 제어를 참조하십시오. 사용자 액세스 및 비밀번호에 대한 자세한 내용은 8 장, 디렉토리 서버 비밀번호 정책을 참조하십시오.

이 장은 다음 내용으로 구성되어 있습니다.

디렉토리 서버에서 SSL 사용

SSL(Secure Sockets Layer)은 디렉토리 서버와 해당 클라이언트 간에 암호화된 통신과 선택적 인증을 제공합니다. SSL은 LDAP 또는 DSML-over-HTTP를 통해 사용할 수 있으며, 기본적으로 LDAP를 통해 활성화되지만 DSML-over-HTTP를 사용하면 SSL을 보다 쉽게 활성화할 수 있습니다. 또한, 복제 시 서버 간의 보안 통신에 SSL을 사용하도록 구성할 수 있습니다.

SSL을 단순 인증(바인드 DN 및 비밀번호)과 함께 사용하면 서버 간에 전송되는 모든 데이터가 암호화되므로 기밀성과 데이터 무결성이 보장됩니다. 선택 사항으로, 클라이언트는 인증서를 사용하여 디렉토리 서버에, 또는 SASL(Simple Authentication and Security Layer)을 통한 타사 보안 메커니즘에 인증할 수 있습니다. 인증서 기반 인증에서는 클라이언트나 서버를 사칭하지 못하도록 공개 키 암호화를 사용합니다.

디렉토리 서버는 별도의 포트에서 SSL 통신과 비SSL 통신을 동시에 지원합니다. 보안상의 이유로 모든 통신을 LDAP 보안 포트로 제한할 수도 있으며 클라이언트 인증을 구성할 수도 있습니다. 클라이언트 인증은 필수 또는 선택 사항으로 설정할 수 있으며 이 설정으로 적용할 보안 수준이 결정됩니다.

SSL을 사용하면 일반 LDAP 연결에 보안을 제공하는 Start TLS 확장 작업도 지원됩니다. 클라이언트는 표준 LDAP 포트에 바인드한 후에 TLS(Transport Layer Security) 프로토콜을 사용하여 연결을 안전하게 설정할 수 있습니다. Start TLS 작업은 클라이언트의 유연성을 높이며 포트 할당을 용이하게 합니다.

SSL에서 제공하는 암호화 메커니즘은 속성 암호화에도 사용됩니다. SSL을 사용할 경우 접미어에 속성 암호화를 구성하여 디렉토리에 저장된 데이터를 보호할 수 있습니다. 자세한 내용은 속성 값 암호화를 참조하십시오.

액세스 제어 지침(ACI)을 통해 디렉토리 내용에 대한 액세스 제어를 설정하여 보안을 강화할 수 있습니다. ACI에는 특정 인증 방법이 필요하며, 데이터가 보안 채널을 통해서만 전송될 수 있도록 합니다. SSL과 인증서의 사용이 상호 보충되도록 ACI를 설정합니다. 자세한 내용은 7 장, 디렉토리 서버 액세스 제어를 참조하십시오.

SSL은 기본적으로 LDAP를 통해 활성화되지만 DSML-over-HTTP를 사용하면 SSL을 보다 쉽게 활성화할 수 있습니다. 또한, 다음 절에 설명된 것처럼 일부 SSL 구성을 수정할 수 있습니다.

인증서 관리

이 절에서는 디렉토리 서버에서 SSL 인증서를 관리하는 방법에 대해 설명합니다.

디렉토리 서버에서 SSL을 실행하려면 자체 서명된 인증서 또는 PKI(Public Key Infrastructure) 솔루션을 사용해야 합니다.

PKI 솔루션에는 외부 인증 기관(CA)이 필요합니다. 즉, PKI 솔루션에는 공개 키와 개인 키가 모두 있는 CA 서명된 서버 인증서가 필요합니다. 이 인증서는 하나의 디렉토리 서버에만 적용됩니다. 또한 공개 키가 포함된 신뢰할 수 있는 CA 인증서도 필요합니다. 신뢰할 수 있는 CA 인증서를 사용하면 CA의 모든 서버 인증서가 신뢰됩니다. 이 인증서를 CA 루트 키 또는 루트 인증서라고도 합니다.

주 –

인증서를 테스트용으로 사용하는 경우에는 자체 서명된 인증서를 사용할 수 있습니다. 그러나, 작업 환경에서 자체 서명된 인증서를 사용하면 보안상 안전하지 않을 수 있습니다. 작업 환경에서는 신뢰할 수 있는 인증 기관(CA) 인증서를 사용합니다.

이 절의 절차에서는 dsadm 및 dsconf 명령을 사용합니다. 이 명령에 대한 자세한 내용은 dsadm(1M) 및 dsconf(1M) 설명서 페이지를 참조하십시오.

이 절에서는 디렉토리 서버에서 인증서를 구성하는 방법과 관련하여 다음 정보에 대해 설명합니다.

Procedure자체 서명된 기본 인증서를 보는 방법

디렉토리 서버 인스턴스를 처음 만들 때 자체 서명된 기본 인증서가 포함됩니다. 자체 서명된 인증서는 공개 키와 개인 키 쌍으로, 여기서 공개 키는 개인 키에 의해 서명됩니다. 자체 서명된 인증서는 3개월 동안 유효합니다.

DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.

  1. 자체 서명된 기본 인증서를 보려면 다음 명령을 사용합니다.


    $ dsadm show-cert instance-path defaultCert

Procedure자체 서명된 인증서를 관리하는 방법

디렉토리 서버 인스턴스를 만들 때 자체 서명된 기본 인증서가 자동으로 제공됩니다.

DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.

  1. 기본값 이외의 설정으로 자체 서명된 인증서를 만들려면 다음 명령을 사용합니다.


    $ dsadm add-selfsign-cert instance-path cert-alias

    여기서 cert-alias는 인증서를 식별하기 위해 입력하는 이름입니다.

    이 명령에 대한 모든 옵션을 보려면 dsadm(1M) 설명서 페이지 또는 명령줄 도움말을 참조하십시오..


    $ dsadm add-selfsign-cert --help

  2. 자체 서명된 인증서가 만료되면 서버 인스턴스를 중지하고 인증서를 갱신합니다.


    $ dsadm stop instance-path
$ dsadm renew-selfsign-cert instance-path cert-alias

  3. 서버 인스턴스를 다시 시작합니다.


    $ dsadm start instance-path

ProcedureCA 서명된 서버 인증서를 요청하는 방법

이 절차에서는 디렉토리 서버에 사용할 CA 서명된 서버 인증서를 요청하고 설치하는 방법에 대해 설명합니다.

DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.

  1. CA 서명된 서버 인증서 요청을 생성합니다.


    $ dsadm request-cert [-W cert-pwd-file] {-S DN | --name name [--org org] \
  [--org-unit org-unit] [--city city] [--state state] [--country country]} \
  [-o output-file] [-F format] instance-path

    예를 들어 Example 회사에 대한 CA 서명된 서버 인증서를 요청하려면 다음 명령을 사용합니다.


    $ dsadm request-cert --name host1 --org Example --org-unit Marketing \
 -o my_cert_request_file /local/ds

    서버를 완벽하게 식별하기 위해 인증 기관(CA)에서는 이 예에 표시된 모든 속성이 필요할 수 있습니다. 각 속성에 대한 설명은 dsadm(1M) 설명서 페이지를 참조하십시오.

    dsadm request-cert를 사용하여 인증서를 요청하는 경우 완성된 인증서 요청은 ASCII를 출력 형식으로 지정하지 않는 한 이진 인증서 요청이 됩니다. ASCII를 지정하면 완성된 인증서 요청은 PEM 형식의 PKCS #10 인증서 요청이 됩니다. PEM은 RFC 1421부터 1424(http://www.ietf.org/rfc/rfc1421.txt)까지 지정된 Privacy Enhanced Mail 형식으로, base64 인코딩된 인증서 요청을 US-ASCII 문자로 나타내는 데 사용됩니다. 요청 내용은 다음 예와 같이 표시됩니다.


    -----BEGIN NEW CERTIFICATE REQUEST-----
MIIBrjCCARcCAQAwbjELMAkGA1UBhMCVXMxEzARBgNVBAgTCkNBElGT1JOSUExLD
AqBgVBAoTI25ldHNjYXBlIGNvb11bmljYXRpb25zIGNvcnBvcmF0aWuMRwwGgYDV
QQDExNtZWxsb24umV0c2NhcGUuY29tMIGfMA0GCSqGSIb3DQEBAUAA4GNADCBiQK
BgCwAbskGh6SKYOgHy+UCSLnm3ok3X3u83Us7u0EfgSLR0f+K41eNqqWRftGR83e
mqPLDOf0ZLTLjVGJaHJn4l1gG+JDf/n/zMyahxtV7+T8GOFFigFfuxJaxMjr2j7I
vELlxQ4IfZgwqCm4qQecv3G+N9YdbjveMVXW0v4XwIDAQABAAwDQYJKoZIhvcNAQ
EEBQADgYEAZyZAm8UmP9PQYwNy4Pmypk79t2nvzKbwKVb97G+MT/gw1pLRsuBoKi
nMfLgKp1Q38K5Py2VGW1E47/rhm3yVQrIiwV+Z8Lcc=
-----END NEW CERTIFICATE REQUEST-----

  2. 해당 절차에 따라 인증서 요청을 인증 기관에 전송합니다.

    인증 기관 인증서를 얻기 위한 프로세스는 사용하는 인증 기관에 따라 다릅니다. 일부 상용 CA에서는 인증서를 자동으로 다운로드할 수 있는 웹 사이트를 제공합니다. 다른 CA에서는 요청한 인증서를 전자 메일로 보냅니다.

    요청을 전송한 후에는 CA에서 이 요청에 대한 응답으로 인증서를 보내줄 때까지 기다려야 합니다. 요청에 대한 응답 시간은 경우에 따라 달라집니다. 예를 들어 회사 내부의 CA인 경우 하루나 이틀이면 요청에 대한 응답을 받을 수 있습니다. 회사 외부의 CA를 선택하면 요청에 대한 응답을 받을 때까지 몇 주가 걸릴 수도 있습니다.

  3. 인증 기관에서 받은 인증서를 저장합니다.

    인증서를 안전한 위치에 백업합니다. 인증서가 손실될 경우 이 백업 파일을 사용하여 인증서를 다시 설치할 수 있습니다. 인증서는 텍스트 파일로 저장할 수 있습니다. PEM 형식의 PKCS #11 인증서는 다음 예와 같이 표시됩니다.


    -----BEGIN CERTIFICATE-----
MIICjCCAZugAwIBAgICCEEwDQYJKoZIhKqvcNAQFBQAwfDELMAkGA1UEBhMCVVMx
IzAhBgNVBAoGlBhbG9a2FWaWxsZGwSBXaWRnZXRzLCBJbmMuMR0wGwYDVQQLExRX
aWRnZXQgTW3FrZXJzICdSJyBVczEpMCcGAx1UEAxgVGVzdCBUXN0IFRlc3QgVGVz
dCBUZXN0IFlc3QgQ0EswHhcNOTgwMzEyMDIzMzUWhcNOTgwMzI2MDIzMpzU3WjBP
MQswCYDDVQQGEwJVUzEoMCYGA1UEChMfTmV0c2NhcGUgRGlyZN0b3J5VIFB1Ymxp
Y2F0aW9uczEWMB4QGA1UEAxMNZHVgh49dq2tLNvbjTBaMA0GCSqGSIb3DQEBAQUA
A0kAMEYkCQCksMR/aLGdfp4m0OiGgijG5KgOsyRNvwGYW7kfW+8mmijDtZaRjYNj
jcgpF3VnlbxbclX9LVjjNLC5737XZdAgEDozYwpNDARBglghkgBhvhCEAQEEBAMC
APAwHkwYDVR0jBBgwFAU67URjwCaGqZHUpSpdLxlzwJKiMwDQYJKoZIhQvcNAQEF
BQADgYEAJ+BfVem3vBOPBveNdLGfjlb9hucgmaMcQa9FA/db8qimKT/ue9UGOJqL
bwbMKBBopsDn56p2yV3PLIsBgrcuSoBCuFFnxBnqSiTS7YiYgCWqWaUA0ExJFmD6
6hBLseqkSWulk+hXHN7L/NrViO+7zNtKcaZLlFPf7d7j2MgX4Bo=
-----END CERTIFICATE-----

ProcedureCA 서명된 서버 인증서 및 신뢰할 수 있는 CA 인증서를 추가하는 방법

이 절차에서는 디렉토리 서버에 사용할 CA 서명된 서버 인증서 및 신뢰할 수 있는 CA 인증서를 설치하는 방법에 대해 설명합니다.

DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.

  1. CA 서명된 서버 인증서를 추가합니다.


    $ dsadm add-cert --ca instance-path cert-alias cert-file

    여기서 cert-alias는 인증서를 식별하기 위해 입력하는 이름이고 cert-file은 PEM 형식의 PKCS #11 인증서가 저장된 텍스트 파일입니다.

    예를 들어 CA 서명된 서버 인증서를 설치할 경우 다음과 같은 명령을 사용할 수 있습니다.


    $ dsadm add-cert /local/ds server-cert /local/safeplace/serv-cert-file

    이 인증서는 바로 설치되지만 신뢰되지는 않습니다. CA 서명된 서버 인증서를 신뢰하려면 인증 기관 인증서를 설치해야 합니다.

  2. 신뢰할 수 있는 인증 기관 인증서를 추가합니다.


    $ dsadm add-cert --ca instance-path cert-alias cert-file

    --ca 옵션은 해당 인증서가 신뢰할 수 있는 인증 기관 인증서임을 나타냅니다.

    예를 들어 신뢰할 수 있는 인증 기관 인증서를 설치할 경우 다음 명령을 사용할 수 있습니다.


    $ dsadm add-cert --ca /local/ds CA-cert /local/safeplace/ca-cert-file

  3. (옵션) 설치된 인증서를 확인합니다.

    • 모든 서버 인증서를 나열하고 유효 날짜 및 별칭을 표시하려면 다음을 입력합니다.


      $ dsadm list-certs instance-path

      예를 들면 다음과 같습니다.


      $ dsadm list-certs /local/ds1
Enter the certificate database password:
Alias       Valid from Expires on Self-   Issued by          Issued to
                                  signed?                                     
----------- ---------- ---------- ------- -----------------  -----------------
serverCert  2000/11/10 2011/02/10 n       CN=CA-Signed Cert, CN=Test Cert,
            18:13      18:13              OU=CA,O=com        dc=example,dc=com
defaultCert 2006/05/18 2006/08/18 y       CN=host1,CN=DS,    Same as issuer
            16:28      16:28              dc=example,dc=com
2 certificates found

      기본적으로 디렉토리 프록시 서버 인스턴스에는 이름이 defaultCert인 기본 서버 인증서가 포함되어 있습니다. Same as issuer 텍스트는 자체 서명된 서버 인증서가 기본 인증서임을 나타냅니다.

    • 신뢰할 수 있는 CA 인증서를 나열하려면 다음을 입력합니다.


      $ dsadm list-certs -C instance-path

      예를 들면 다음과 같습니다. 


      $ dsadm list-certs -C /local/ds1
Enter the certificate database password:
Alias   Valid from Expires on Self-   Issued by           Issued to
                              signed?                                   
------- ---------- ---------- ------- -----------------   --------------
CA-cert 2000/11/10 2011/02/10 y       CN=Trusted CA Cert, Same as issuer
        18:12      18:12              OU=CA,O=com
1 certificate found

    • 인증서 만료 날짜를 비롯하여 인증서에 대한 자세한 내용을 보려면 다음을 입력합니다.


      $ dsadm show-cert instance-path cert-alias

      예를 들어 서버 인증서를 보려면 다음을 입력합니다.


      $ dsadm show-cert /local/ds1 "Server-Cert"
Enter the certificate database password:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
        Signature Algorithm: PKCS #1 MD5 With RSA Encryption
        Issuer:
            "CN=Server-Cert,O=Sun,C=US"
        Validity:
            Not Before: Fri Nov 10 18:12:20 2000
            Not After : Thu Feb 10 18:12:20 2011
        Subject:
            "CN=CA Server Cert,OU=ICNC,O=Sun,C=FR"
        Subject Public Key Info:
            Public Key Algorithm: PKCS #1 RSA Encryption
            RSA Public Key:
                Modulus:
                    bd:76:fc:29:ca:06:45:df:cd:1b:f1:ce:bb:cc:3a:f7:
                    77:63:5a:82:69:56:5f:3d:3a:1c:02:98:72:44:36:e4:
                    68:8c:22:2b:f0:a2:cb:15:7a:c4:c6:44:0d:97:2d:13:
                    b7:e3:bf:4e:be:b5:6a:df:ce:c4:c3:a4:8a:1d:fa:cf:
                    99:dc:4a:17:61:e0:37:2b:7f:90:cb:31:02:97:e4:30:
                    93:5d:91:f7:ef:b0:5a:c7:d4:de:d8:0e:b8:06:06:23:
                    ed:5f:33:f3:f8:7e:09:c5:de:a5:32:2a:1b:6a:75:c5:
                    0b:e3:a5:f2:7a:df:3e:3d:93:bf:ca:1f:d9:8d:24:ed
                Exponent: 65537 (0x10001)
    Signature Algorithm: PKCS #1 MD5 With RSA Encryption
    Signature:
        85:92:42:1e:e3:04:4d:e5:a8:79:12:7d:72:c0:bf:45:
        ea:c8:f8:af:f5:95:f0:f5:83:23:15:0b:02:73:82:24:
        3d:de:1e:95:04:fb:b5:08:17:04:1c:9d:9c:9b:bd:c7:
        e6:57:6c:64:38:8b:df:a2:67:f0:39:f9:70:e9:07:1f:
        33:48:ea:2c:18:1d:f0:30:d8:ca:e1:29:ec:be:a3:43:
        6f:df:03:d5:43:94:8f:ec:ea:9a:02:82:99:5a:54:c9:
        e4:1f:8c:ae:e2:e8:3d:50:20:46:e2:c8:44:a6:32:4e:
        51:48:15:d6:44:8c:e6:d2:0d:5f:77:9b:62:80:1e:30
    Fingerprint (MD5):
        D9:FB:74:9F:C3:EC:5A:89:8F:2C:37:47:2F:1B:D8:8F
    Fingerprint (SHA1):
        2E:CA:B8:BE:B6:A0:8C:84:0D:62:57:85:C6:73:14:DE:67:4E:09:56

    Certificate Trust Flags:
        SSL Flags:
            Valid CA
            Trusted CA
            User
            Trusted Client CA
        Email Flags:
            User
        Object Signing Flags:
            User

Procedure만료된 CA 서명 서버 인증서를 갱신하는 방법

CA 서명된 서버 인증서(공개 키 및 개인 키)가 만료되면 이 절차를 사용하여 인증서를 갱신합니다.

DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.

  1. 해당 인증 기관에서 업데이트된 CA 서명된 서버 인증서를 얻습니다.

  2. 업데이트된 인증서를 받는 경우 서버 인스턴스를 중지하고 인증서를 설치합니다.


    $ dsadm stop instance-path
$ dsadm renew-cert instance-path cert-alias cert-file

  3. 서버 인스턴스를 다시 시작합니다.


    $ dsadm start instance-path

ProcedureCA 서명된 서버 인증서를 내보내고 가져오는 방법

나중에 인증서를 가져올 수 있도록 인증서의 공개 키와 개인 키를 내보내야 할 수 있습니다. 예를 들어 인증서를 다른 서버에 사용해야 할 수 있습니다.

이 절차에 있는 명령은 "cn=*,o=example"과 같은 와일드카드가 포함된 인증서에 사용할 수 있습니다.

DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.

  1. 인증서를 내보냅니다.


    $ dsadm export-cert [-o output-file] instance-path cert-alias

    예를 들면 다음과 같습니다.


    $ dsadm export-cert -o /tmp/first-certificate /local/ds1 "First Certificate"
$ dsadm export-cert -o /tmp/first-ca-server-certificate /local/ds1/ defaultCert
Choose the PKCS#12 file password:
Confirm the PKCS#12 file password:
$ ls /tmp
first-ca-server-certificate

  2. 인증서를 가져옵니다.


    $ dsadm import-cert instance-path cert-file

    예를 들어 인증서를 서버 인스턴스로 가져오려면 다음을 입력합니다.


    $ dsadm import-cert /local/ds2 /tmp/first-ca-server-certificate
Enter the PKCS#12 file password:

  3. (옵션) 인증서를 서버로 가져온 후 서버에서 가져온 인증서를 사용하도록 구성합니다.


    $ dsconf set-server-prop -e -h host -p port ssl-rsa-cert-name:server-cert

인증서 데이터베이스 비밀번호 구성

기본적으로 디렉토리 서버에서는 저장된 비밀번호를 통해 내부적으로 SSL 인증서 데이터베이스 비밀번호를 관리합니다. 인증서를 관리할 때 사용자가 인증서 비밀번호를 입력하거나 비밀번호 파일을 지정할 필요는 없습니다. 이 옵션은 비밀번호가 숨겨지기만 하고 암호화되지는 않기 때문에 보안상 안전하지 않을 수 있습니다.

그러나, 인증서 사용을 좀 더 엄격하게 제어하려면 명령줄에서 비밀번호를 입력하라는 메시지가 표시되도록 서버를 구성할 수 있습니다. 이 경우 사용자는 autostart, backup, disable-service, enable-service, info, reindex, restore 및 stop을 제외한 모든 dsadm 하위 명령 실행 시에 인증서 데이터베이스 비밀번호를 입력해야 합니다. 인증서 데이터베이스는 instance-path/alias 디렉토리에 있습니다.

Procedure인증서 비밀번호를 입력하라는 메시지가 표시되도록 서버를 구성하는 방법

DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.

  1. 서버를 중지합니다.


    $ dsadm stop instance-path

  2. 비밀번호 프롬프트 플래그를 on으로 설정합니다.


    $ dsadm set-flags instance-path cert-pwd-prompt=on

    새 인증서 비밀번호를 선택하라는 메시지가 표시됩니다.

  3. 서버를 시작합니다.


    $ dsadm start instance-path

디렉토리 서버의 인증서 데이터베이스 백업 및 복원

디렉토리 서버 인스턴스를 백업하는 경우 디렉토리 서버 구성 및 인증서를 백업합니다. 백업된 인증서는 archive-path/alias 디렉토리에 저장됩니다.

디렉토리 서버 백업 및 복원 방법에 대한 자세한 내용은 재해 복구를 위한 백업을 만드는 방법을 참조하십시오.

SSL 통신 구성

이 절은 SSL 활성화 및 비활성화와 관련된 절차로 구성되어 있습니다.

비보안 통신 비활성화

서버 인스턴스를 만들면 기본적으로 LDAP 일반 포트와 보안 LDAP 포트(LDAPS)가 모두 만들어집니다. 그러나, 서버가 SSL을 통해서만 통신하도록 비SSL 통신을 비활성화해야 할 수 있습니다.

자체 서명된 기본 인증서에 SSL 연결을 사용할 수 있습니다. 필요한 경우 사용자 고유의 인증서를 설치할 수 있습니다. 서버 시작 후 인증서를 관리하고 SSL을 비활성화하는 방법에 대한 지침은 6 장, 디렉토리 서버 보안 을 참조하십시오. 인증서, 인증서 데이터베이스 및 CA 서명된 서버 인증서를 얻는 방법에 대한 개요는 Sun Java System Directory Server Enterprise Edition 6.3 Reference를 참조하십시오.

ProcedureLDAP 일반 포트를 비활성화하는 방법

DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.

  1. LDAP 일반 포트를 비활성화합니다.

    비보안 포트를 비활성화하려면 LDAP 보안 포트에 바인드해야 합니다. 다음 예는 호스트 서버 host1에서 기본 LDAP 보안 포트 1636에 바인드하는 명령을 나타냅니다.


    $ dsconf set-server-prop -h host1 -P 1636 ldap-port:disabled

  2. 변경 사항을 적용하려면 서버를 다시 시작합니다.


    $ dsadm restart /local/ds

    이제 비보안 포트 1389에서 더 이상 바인드할 수 없습니다.

암호화 암호 선택

암호는 데이터 암호화 및 암호 해독에 사용되는 알고리즘입니다. 일반적으로 암호화 중에 암호가 사용하는 비트 수가 많을수록 암호화는 더욱 강력해지거나 안전해집니다. SSL 암호는 사용된 메시지 인증 유형으로도 식별할 수 있습니다. 메시지 인증은 데이터 무결성을 보장하는 checksum을 계산하는 별개의 알고리즘입니다.

클라이언트가 서버와의 SSL 연결을 시작하려면 클라이언트 및 서버가 정보 암호화에 사용할 암호에 동의해야 합니다. 양방향 암호화 프로세스의 경우 클라이언트와 서버 모두 동일한 암호를 사용해야 합니다. 사용되는 암호는 서버에서 유지되는 암호 목록의 현재 순서에 따라 달라집니다. 서버는 클라이언트가 표시하는 항목 중 암호 목록 내의 암호와 일치하는 첫 번째 암호를 선택합니다. 디렉토리 서버의 기본 암호 값은 all이며, 이는 기본 SSL 라이브러리에서 지원하는 알려진 모든 보안 암호를 의미합니다. 그러나, 특정 암호만 허용하도록 이 값을 수정할 수 있습니다.

디렉토리 서버에 사용할 수 있는 암호에 대한 자세한 내용은 Sun Java System Directory Server Enterprise Edition 6.3 Reference를 참조하십시오.

Procedure암호화 암호를 선택하는 방법

DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.

  1. SSL이 서버에 대해 활성화되어 있는지 확인합니다.

    SSL 통신 구성을 참조하십시오.

  2. 사용 가능한 SSL 암호를 봅니다.


    $ dsconf get-server-prop -h host -p port ssl-supported-ciphers
ssl-supported-ciphers  :  TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
ssl-supported-ciphers  :  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
ssl-supported-ciphers  :  TLS_DHE_RSA_WITH_AES_256_CBC_SHA
ssl-supported-ciphers  :  TLS_DHE_DSS_WITH_AES_256_CBC_SHA 
...

  3. (옵션) 암호화되지 않은 데이터의 복사본을 유지하려면 SSL 암호를 설정하기 전에 데이터를 내보냅니다.

    LDIF로 내보내기를 참조하십시오.

  4. SSL 암호를 설정합니다.


    $ dsconf set-server-prop -h host -p port ssl-cipher-family:cipher

    예를 들어 암호 패밀리를 SSL_RSA_WITH_RC4_128_MD5 및 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA로 설정하려면 다음을 입력합니다.


    $ dsconf set-server-prop -h host1 -P 1636 ssl-cipher-family:SSL_RSA_WITH_RC4_128_MD5 \
 ssl-cipher-family:SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
Enter "cn=Directory Manager" password:  
Before setting SSL configuration, export Directory Server data. 
Do you want to continue [y/n] ? y
Directory Server must be restarted for changes to take effect.

  5. (옵션) 기존 목록에 SSL 암호를 추가합니다.

    암호 목록이 이미 지정되어 있고 암호를 추가하려면 이 명령을 사용합니다.


    $ dsconf set-server-prop -h host -p port ssl-cipher-family+:cipher

    예를 들어 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA 암호를 추가하려면 다음을 입력합니다.


    $ dsconf set-server-prop -h host1 -P 1636 \
 ssl-cipher-family+:SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA

  6. 변경 사항을 적용하려면 서버를 다시 시작합니다.


    $ dsadm restart /local/ds

자격 증명 수준 및 인증 방법 구성

클라이언트에 적용되는 보안 모델은 자격 증명 수준과 인증 방법의 조합으로 정의됩니다.

디렉토리 서버는 다음 자격 증명 수준을 지원합니다.

클라이언트 인증은 서버에서 클라이언트의 아이디를 확인하는 메커니즘입니다.

다음 방법 중 하나로 클라이언트 인증을 수행할 수 있습니다.

이 절에서는 이 두 SASL 메커니즘을 디렉토리 서버에 구성하는 방법과 관련하여 다음 정보에 대해 설명합니다.

보안 구성에 대한 자세한 내용은 LDAP 클라이언트에서 보안을 사용하도록 구성을 참조하십시오.

디렉토리 서버의 SASL 암호화 수준 설정

SASL 메커니즘을 구성하기 전에 암호화가 필요한지 여부를 지정해야 합니다. SASL 암호화 필요 여부는 최대 및 최소 SSF(Strength Security Factor)로 설정됩니다.

dsSaslMinSSF(5dsat) 및 dsSaslMaxSSF(5dsat) 속성은 암호화 키 길이를 나타내며 cn=SASL, cn=security, cn=config에 저장됩니다.

이 서버는 암호화 없음을 비롯하여 모든 수준의 암호화를 허용합니다. 이는 디렉토리 서버가 256보다 큰 dsSaslMinSSF 및 dsSaslMaxSSF 값을 허용한다는 의미입니다. 그러나, 현재 SASL 메커니즘은 128보다 큰 SSF를 지원하지 않습니다. 디렉토리 서버에서는 SSF 값을 SASL 메커니즘에서 지원하는 최대 값(128) 이하로 조정합니다. 따라서, 실제 최대 SSF 값은 사용 가능한 기본 메커니즘에 따라 구성된 최대 값보다 작을 수 있습니다.

SASL 보안 요소 인증은 서버 및 클라이언트 응용 프로그램에서 요청되는 최소 및 최대 요소와 기본 보안 구성 요소에서 제공되는 사용 가능한 암호화 메커니즘과 같은 두 가지 주요 항목에 따라 달라집니다. 즉, 서버 및 클라이언트는 둘 모두에 설정된 최대 요소보다 작거나 같은, 하지만 최소 요소보다는 크거나 같은 사용 가능한 최대 보안 요소를 사용하려고 시도합니다.

디렉토리 서버의 기본 최소 SASL 보안 요소인 dsSaslMinSSF는 0으로, 보호되지 않음을 의미합니다. 실제 최소 요소 값은 사용자가 디렉토리 서버의 최소 요소 값을 변경하지 않는 한 클라이언트 설정에 따라 달라집니다. 실제로 최소 요소 값은 서버와 클라이언트가 실제로 사용할 최저 수준으로 설정해야 합니다. 서버와 클라이언트 간에 최소 요소 값이 일치하도록 메커니즘이 조정되지 않으면 연결이 구성되지 않습니다.

ProcedureSASL 암호화를 허용하는 방법

DSCC를 사용하여 이 작업을 수행할 수 없습니다. 이 절차에 설명된 것처럼 명령줄을 사용하십시오.

  1. SASL 암호화를 허용하려면 dsSaslMinSSF 값을 요구되는 최소 암호화로 설정합니다. 


    $ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
dn: cn=SASL, cn=security, cn=config
changetype: modify
replace: dsSaslMinSSF
dsSaslMinSSF: 128
^D

ProcedureSASL 암호화를 허용하지 않는 방법

DSCC를 사용하여 이 작업을 수행할 수 없습니다. 이 절차에 설명된 것처럼 명령줄을 사용하십시오.

  1. SASL 암호화를 허용하지 않으려면 dsSaslMinSSF 및 dsSaslMaxSSF 값을 모두 0으로 설정합니다.


    $ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
dn: cn=SASL, cn=security, cn=config
changetype: modify
replace: dsSaslMinSSF
dsSaslMinSSF: 0

replace: dsSaslMaxSSF
dsSaslMaxSSF: 0

DIGEST-MD5를 통한 SASL 인증

DIGEST-MD5 메커니즘은 클라이언트가 전송한 해시된 값을 사용자 비밀번호의 해시와 비교하여 클라이언트를 인증합니다. 그러나 이 메커니즘은 사용자 비밀번호를 읽어야 하기 때문에 DIGEST-MD5를 통해 인증을 받으려는 사용자는 디렉토리에 {CLEAR} 비밀번호가 있어야 합니다. {CLEAR} 비밀번호를 디렉토리에 저장하는 경우 7 장, 디렉토리 서버 액세스 제어에 설명된 것처럼 비밀번호 값에 대한 액세스가 ACI를 통해 적절하게 제한되도록 해야 합니다. 또한, 속성 값 암호화에 설명된 것처럼 접미어의 속성 암호화도 구성해야 합니다.

ProcedureDIGEST-MD5 메커니즘을 구성하는 방법

다음 절차에서는 디렉토리 서버에서 DIGEST-MD5를 사용하도록 구성하는 방법에 대해 설명합니다.

DSCC를 사용하여 이 작업을 수행할 수 없습니다. 이 절차에 설명된 것처럼 명령줄을 사용하십시오.

  1. ldapsearch 명령을 사용하여 DIGEST-MD5가 루트 항목의 supportedSASLMechanisms 속성 값인지 확인합니다.

    예를 들어 다음 명령을 실행하면 현재 활성화되어 있는 SASL 메커니즘이 표시됩니다.


    $ ldapsearch -h host -p port -D cn=admin,cn=Administrators,cn=config -w - \
 -s base -b "" "(objectclass=*)" supportedSASLMechanisms
Enter bind password:
dn:
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: GSSAPI

  2. DIGEST-MD5가 활성화되어 있지 않으면 다음 명령을 사용하여 활성화합니다.


    $ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w - 
Enter bind password:
dn: cn=SASL, cn=security, cn=config
changetype: modify
add: dsSaslPluginsEnable
dsSaslPluginsEnable: DIGEST-MD5
-
replace: dsSaslPluginsPath
dsSaslPluginsPath: SASL-library

    여기서 SASL-library는 다음 값 중 하나입니다.

    JES 설치

    /usr/lib/mps/sasl2

    Zip 설치

    install-path/dsee6/private/lib

  3. DIGEST-MD5에 기본 아이디 매핑을 사용하거나 새 아이디 매핑을 만듭니다.

    자세한 내용은 DIGEST-MD5 아이디 매핑을 참조하십시오.

  4. DIGEST-MD5를 사용하여 SSL을 통해 서버에 액세스하는 모든 사용자의 비밀번호가 {CLEAR}에 저장되어 있는지 확인합니다.

    비밀번호 저장소 체계에 대해서는 8 장, 디렉토리 서버 비밀번호 정책을 참조하십시오.

  5. SASL 구성 항목 또는 DIGEST-MD5 아이디 매핑 항목 중 하나를 수정했다면 디렉토리 서버를 다시 시작합니다.

DIGEST-MD5 아이디 매핑

SASL 메커니즘에 아이디를 매핑하면 디렉토리의 사용자 항목이 SASL 아이디의 자격 증명과 일치하는지 확인합니다. 매핑 중에 SASL 아이디에 해당하는 DN을 찾을 수 없으면 인증은 실패합니다. 이 메커니즘에 대한 자세한 내용은 Sun Java System Directory Server Enterprise Edition 6.3 Reference를 참조하십시오.

SASL 아이디는 각 메커니즘의 고유 형식으로 사용자를 나타내는 사용자(Principal)라고 불리는 문자열입니다. DIGEST-MD5의 경우, 클라이언트에서는 dn: 접두어와 LDAP DN 또는 u: 접두어 뒤에 클라이언트가 지정한 텍스트가 있는 사용자(Principal)를 만들어야 합니다. 클라이언트가 보낸 사용자(Principal)는 매핑 중에 ${Principal} 자리 표시자에서 사용할 수 있습니다.

DIGEST-MD5에 대한 기본 아이디 매핑은 서버 구성의 다음 항목에서 지정합니다.


dn: cn=default,cn=DIGEST-MD5,cn=identity mapping,cn=config
objectClass: top
objectClass: nsContainer
objectClass: dsIdentityMapping
objectClass: dsPatternMatching
cn: default
dsMatching-pattern: \${Principal}
dsMatching-regexp: dn:(.*)
dsMappedDN: \$1

이 아이디 매핑에서는 사용자(Principal) dn 필드에 기존 디렉토리 사용자의 DN이 포함되어 있다고 가정합니다.

ProcedureDIGEST-MD5에 대한 사용자 고유의 아이디 매핑을 정의하는 방법

DSCC를 사용하여 이 작업을 수행할 수 없습니다. 이 절차에 설명된 것처럼 명령줄을 사용하십시오.

  1. 기본 매핑 항목을 편집하거나 cn=DIGEST-MD5,cn=identity mapping,cn=config에 새 매핑 항목을 만듭니다.

    다음 명령은 이 매핑이 어떻게 정의되는지 보여줍니다.


    $ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
dn: cn=unqualified-username,cn=DIGEST-MD5,cn=identity mapping
cn=config
objectclass: dsIdentityMapping
objectclass: dsPatternMatching
objectclass: nsContainer
objectclass: top
cn: unqualified-username
dsMatching-pattern: \${Principal}
dsMatching-regexp: u:(.*)@(.*)\\.com
dsSearchBaseDN: dc=\$2
dsSearchFilter: (uid=\$1)

  2. 새 매핑을 적용하려면 디렉토리 서버를 다시 시작합니다.

GSSAPI를 통한 SASL 인증(Solaris OS에만 해당)

SASL에서 GSSAPI(Generic Security Service API)를 통해 Kerberos V5와 같은 타사 보안 시스템을 사용함으로써 클라이언트를 인증할 수 있습니다. GSSAPI 라이브러리는 Solaris OS SPARC® 플랫폼에서만 사용할 수 있습니다. Sun Enterprise Authentication MechanismTM 1.0.1 서버에 Kerberos V5 구현을 설치하는 것이 좋습니다.

서버는 GSSAPI를 사용하여 사용자 아이디를 확인합니다. 그런 다음 SASL 메커니즘에서 GSSAPI 매핑 규칙을 적용하여 이 연결이 유지되는 동안 모든 작업의 바인드 DN으로 지정될 DN을 얻습니다.

ProcedureKerberos 시스템을 구성하는 방법

제조업체의 지침에 따라 Kerberos 소프트웨어를 구성합니다. Sun Enterprise Authentication Mechanism 1.0.1 서버를 사용하는 경우 이 절차를 사용합니다.

DSCC를 사용하여 이 작업을 수행할 수 없습니다. 이 절차에 설명된 것처럼 명령줄을 사용하십시오.

  1. /etc/krb5에 있는 파일을 구성합니다.

  2. 사용자와 서비스를 저장할 Kerberos 데이터베이스를 만듭니다.

  3. 데이터베이스에서 LDAP 서비스에 대한 사용자(Principal)를 만듭니다.


    $ ldap/server-FQDN@realm

    여기서 server-FQDN은 디렉토리 서버의 정규화된 도메인 이름입니다.

  4. Kerberos 데몬 프로세스를 시작합니다.

    주 –

    DNS는 호스트 시스템에 구성해야 합니다.

    자세한 단계별 지침은 소프트웨어 설명서 및 SASL에서 GSSAPI를 사용하는 Kerberos 인증 구성의 예를 참조하십시오.

ProcedureGSSAPI 메커니즘을 구성하는 방법

다음 절차에서는 Solaris OS에서 디렉토리 서버가 GSSAPI를 사용하도록 구성하는 방법에 대해 설명합니다.

DSCC를 사용하여 이 작업을 수행할 수 없습니다. 이 절차에 설명된 것처럼 명령줄을 사용하십시오.

  1. GSSAPI 아이디 매핑에 설명된 것처럼 GSSAPI에 대한 기본 아이디 매핑 및 사용자 정의 매핑을 만듭니다.

  2. 서비스 키를 저장할 키 탭을 만듭니다.

    LDAP 서비스 키는 키 탭에 저장됩니다.

    1. 디렉토리 서버 사용자가 키 탭에 대한 읽기만 가능한지 확인합니다.

    2. 파일 이름을 기본 /etc/krb5/krb5.keytab과 다르게 변경합니다.

    3. 스크립트에서 환경 변수 KRB5_KTNAME을 설정하여 기본 키 탭 대신 새 키 탭을 사용하도록 합니다.

  3. SASL 구성 항목 또는 GSSAPI 아이디 매핑 항목 중 하나를 수정했다면 디렉토리 서버를 다시 시작합니다.

    DNS는 호스트 시스템에 구성해야 합니다.

GSSAPI 아이디 매핑

SASL 메커니즘에 아이디를 매핑하면 디렉토리의 사용자 항목이 SASL 아이디의 자격 증명과 일치하는지 확인합니다. 매핑 중에 SASL 아이디에 해당하는 DN을 찾을 수 없으면 인증은 실패합니다.

SASL 아이디는 각 메커니즘의 고유 형식으로 사용자를 나타내는 사용자(Principal)라고 불리는 문자열입니다. GSSAPI를 사용하는 Kerberos에서 사용자(Principal)는 형식이 uid [/instance][@realm]인 아이디로 나타납니다. 여기서 uid에는 instance 식별자가 선택적으로 포함될 수 있으며 이 식별자 뒤에 일반적으로 도메인 이름인 realm이 선택적으로 붙습니다. 예를 들어 다음 문자열은 모두 유효한 사용자입니다.


bjensen
bjensen/Sales
bjensen@EXAMPLE.COM
bjensen/Sales@EXAMPLE.COM

처음에는 디렉토리에 GSSAPI 매핑이 정의되어 있지 않습니다. 클라이언트에서 자신이 사용하는 사용자(Principal)를 정의하는 방법에 따라 기본 매핑 및 필요한 사용자 정의 매핑을 모두 정의해야 합니다.

ProcedureGSSAPI에 대한 아이디 매핑을 정의하는 방법

DSCC를 사용하여 이 작업을 수행할 수 없습니다. 이 절차에 설명된 것처럼 명령줄을 사용하십시오.

  1. cn=GSSAPI,cn=identity mapping, cn=config에 새 매핑 항목을 만듭니다.

    아이디 매핑 항목의 속성 정의에 대한 내용은 Sun Java System Directory Server Enterprise Edition 6.3 Reference를 참조하십시오. GSSAPI 매핑에 대한 예는 instance-path/ldif/identityMapping_Examples.ldif에 있습니다.

    이 파일의 기본 GSSAPI 매핑에서는 사용자(Principal)에 사용자 아이디만 포함되어 있다고 가정합니다. 이 매핑에서는 디렉토리의 고정 분기에 있는 사용자를 결정합니다. 


    dn: cn=default,cn=GSSAPI,cn=identity mapping,cn=config
objectclass: dsIdentityMapping
objectclass: nsContainer
objectclass: top
cn: default
dsMappedDN: uid=\${Principal},ou=people,dc=example,dc=com

    이 파일의 다른 예에서는 알려진 영역이 지정된 사용자(Principal)에 포함할 사용자 아이디를 결정하는 방법을 보여줍니다.


    dn: cn=same_realm,cn=GSSAPI,cn=identity mapping,cn=config
objectclass: dsIdentityMapping
objectclass: dsPatternMatching
objectclass: nsContainer
objectclass: top
cn: same_realm
dsMatching-pattern: \${Principal}
dsMatching-regexp: (.*)@EXAMPLE.COM
dsMappedDN: uid=\$1,ou=people,dc=EXAMPLE,dc=COM

  2. 새 매핑을 적용하려면 디렉토리 서버를 다시 시작합니다.

LDAP 클라이언트에서 보안을 사용하도록 구성

다음 절에서는 디렉토리 서버와 보안 연결을 구성하려는 LDAP 클라이언트에서 SSL을 구성 및 사용하는 방법에 대해 설명합니다. SSL 연결에서 서버는 해당 인증서를 클라이언트로 보냅니다. 클라이언트는 먼저 인증서를 신뢰하여 서버를 인증해야 합니다. 그런 다음, 클라이언트는 두 SASL 메커니즘 중 하나에 대한 정보 또는 자신의 인증서를 보내서 클라이언트 인증 메커니즘 중 하나를 선택적으로 시작할 수 있습니다. SASL 메커니즘은 DIGEST-MD5 및 Kerberos V5를 사용하는 GSSAPI입니다.

다음 절에서는 SSL을 사용하는 LDAP 클라이언트의 예로 ldapsearch 도구를 사용합니다.

다른 LDAP 클라이언트에서 SSL 연결을 구성하려면 응용 프로그램과 함께 제공된 설명서를 참조하십시오.

주 –

일부 클라이언트 응용 프로그램은 SSL만 구현하고 서버에 신뢰할 수 있는 인증서가 있는지 확인하지 않으므로 SSL 프로토콜을 사용하여 데이터 암호화는 제공하지만 기밀성이나 사칭에 대한 보호는 보장할 수 없습니다.

다음 절에서는 LDAP 클라이언트에서 보안을 사용하도록 구성하는 방법에 대해 설명합니다.

클라이언트에 SASL DIGEST-MD5 사용

클라이언트에 DIGEST-MD5 메커니즘을 사용하는 경우에는 사용자 인증서를 설치할 필요가 없습니다. 하지만 암호화된 SSL 연결을 사용하려면 인증서 관리에 설명된 것처럼 서버 인증서를 신뢰해야 합니다.

영역 지정

영역은 선택한 인증 아이디가 속하는 이름 공간을 정의합니다. DIGEST-MD5 인증에서는 특정 영역에 인증해야 합니다.

디렉토리 서버는 시스템의 정규화된 호스트 이름을 DIGEST-MD5의 기본 영역으로 사용하며, nsslapd-localhost 구성 속성에 있는 호스트 이름의 소문자 값을 사용합니다.

영역을 지정하지 않으면 서버에서 제공하는 기본 영역이 사용됩니다.

환경 변수 지정

UNIX 환경에서 LDAP 도구가 DIGEST-MD5 라이브러리를 찾을 수 있도록 SASL-PATH 환경 변수를 설정해야 합니다. DIGEST-MD5 라이브러리는 SASL 플러그인에 의해 동적으로 로드되는 공유 라이브러리입니다. SASL_PATH 환경 변수를 다음과 같이 설정합니다.


export SASL_PATH=SASL-library

이 경로에서는 디렉토리 서버가 LDAP 도구를 호출하는 호스트와 동일한 호스트에 설치되어 있다고 가정합니다.

ldapsearch 명령 예

SSL을 사용하지 않고 DIGEST-MD5 클라이언트 인증을 수행할 수 있습니다. 다음 예에서는 기본 DIGEST-MD5 아이디 매핑을 사용하여 바인드 DN을 결정합니다.


$ ldapsearch -h host1 -p 1389 \
 -o mech=DIGEST-MD5 [ \
 -o realm="example.com"] \
 -o authid="dn:uid=bjensen,dc=example,dc=com" \
 -w - \
 -o authzid="dn:uid=bjensen,dc=example,dc=com" \
 -o secProp="minssf=56,maxssf=256,noplain" \
 -b "dc=example,dc=com" "(givenname=Richard)"

위 예에서는 -o(소문자 o) 옵션을 사용하여 SASL 옵션을 지정합니다. realm은 선택 사항이지만 지정할 경우 서버 호스트 시스템의 정규화된 도메인 이름이어야 합니다. 프록시 작업용 authzid를 사용하지 않는 경우에도 authid와 authzid는 둘 다 있어야 하며 동일한 값을 가져야 합니다. -w 비밀번호 옵션은 authid에 적용됩니다.

authid 값은 아이디 매핑에 사용되는 사용자(Principal)입니다. authid는 dn: 접두어가 사용되고 뒤에 디렉토리의 유효한 사용자 DN이 오거나 u: 접두어가 사용되고 뒤에 클라이언트에서 결정되는 문자열이 와야 합니다. 이렇게 authid를 사용하면 DIGEST-MD5 아이디 매핑에 표시된 매핑을 사용할 수 있습니다.

일반적으로 SSL 연결을 사용하여 LDAPS 보안 포트를 통해 암호화를 제공하고 DIGEST-MD5를 사용하여 클라이언트 인증을 제공하도록 구성합니다. 다음 예에서는 SSL을 통해 동일한 작업을 수행합니다.


$ ldapsearch -h host1 -P 1636 \
 -Z -P .mozilla/bjensen/BJE6001.slt/cert8.db \
 -N "cert-example" -w - \
 -o mech=DIGEST-MD5 [-o realm="example.com"] \
 -o authid="dn:uid=bjensen,dc=example,dc=com" \
 -o authzid="dn:uid=bjensen,dc=example,dc=com" \
 -o secProp="minssf=0,maxssf=0,noplain" \
 -b "dc=example,dc=com" "(givenname=Richard)"

이 예에서는 작업이 SSL을 통해 수행되므로 ldapsearch 명령에 -N 및 -w 옵션이 필요합니다. 그러나 클라이언트 인증에는 이 옵션이 사용되지 않습니다. 대신, 서버는 authid 값의 사용자(Principal)에 대해 다른 DIGEST-MD5 아이디 매핑을 수행합니다.

클라이언트에 Kerberos SASL GSSAPI 사용

클라이언트에 GSSAPI 메커니즘을 사용하는 경우 사용자 인증서를 설치할 필요는 없지만, Kerberos V5 보안 시스템을 구성해야 합니다. 또한, 암호화된 SSL 연결을 사용하려면 인증서 관리에 설명된 것처럼 서버 인증서를 신뢰해야 합니다.

Procedure호스트에 Kerberos V5를 구성하는 방법

LDAP 클라이언트를 실행할 호스트 시스템에 Kerberos V5를 구성해야 합니다.

DSCC를 사용하여 이 작업을 수행할 수 없습니다. 이 절차에 설명된 것처럼 명령줄을 사용하십시오.

  1. 설치 지침에 따라 Kerberos V5를 설치합니다.

    Sun Enterprise Authentication Mechanism 1.0.1 클라이언트 소프트웨어를 설치하는 것이 좋습니다.

  2. Kerberos 소프트웨어를 구성합니다.

    Sun Enterprise Authentication Mechanism 소프트웨어를 사용하여 /etc/krb5에 파일을 구성합니다. 이 구성 작업에서 kdc 서버를 설정하고 기본 영역 및 Kerberos 시스템에 필요한 다른 구성을 정의합니다.

  3. 필요한 경우 /etc/gss/mech 파일을 수정하여 kerberos_v5를 첫 번째 값으로 표시합니다.

ProcedureKerberos 인증에 대한 SASL 옵션을 지정하는 방법

DSCC를 사용하여 이 작업을 수행할 수 없습니다. 이 절차에 설명된 것처럼 명령줄을 사용하십시오.

  1. GSSAPI 메커니즘을 사용하는 클라이언트 응용 프로그램을 사용하기 전에 먼저 Kerberos 보안 시스템을 사용자(Principal)로 초기화합니다.


    $ kinit user-principal

    여기서 user-principal은 사용자의 SASL 아이디입니다(예: bjensen@example.com).

  2. Kerberos를 사용하도록 SASL 옵션을 지정합니다.

    UNIX 환경에서 SASL_PATH 환경 변수를 SASL 라이브러리에 대한 올바른 경로로 설정해야 합니다. Korn 쉘의 예는 다음과 같습니다.


    $ export SASL_PATH=SASL-library

    이 경로에서는 디렉토리 서버가 LDAP 도구를 호출하는 호스트와 동일한 호스트에 설치되어 있다고 가정합니다.

    아래의 ldapsearch 도구 예에서는 -o(소문자 o) 옵션을 사용하여 Kerberos 사용에 대한 SASL 옵션을 지정하는 방법을 보여줍니다.


    $ ldapsearch -h www.host1.com -p 1389 -o mech=GSSAPI -o authid="bjensen@EXAMPLE.COM" \
 -o authzid="bjensen@EXAMPLE.COM" -b "dc=example,dc=com" "(givenname=Richard)"

    authid는 kinit 명령으로 초기화된 Kerberos 캐시에 있기 때문에 생략할 수 있습니다. authid가 있는 경우, 프록시 작업에 대한 authzid를 사용하지 않는 경우에도 authid와 authzid 값은 동일한 값을 가져야 합니다. authid 값은 아이디 매핑에 사용되는 사용자(Principal)입니다. 사용자(Principal)는 영역을 포함하는 완전한 사용자여야 합니다. GSSAPI 아이디 매핑을 참조하십시오.

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"은 바인드가 적합한 사용자로 수행되었음을 나타냅니다.

PTA(Pass-Through Authentication)

PTA(Pass-through authentication)는 바인드 요청이 바인드 DN으로 필터링되는 메커니즘입니다. 한 디렉토리 서버(위임자)가 바인드 요청을 수신하고 필터를 기반으로 다른 디렉토리 서버(대리자)가 바인드 요청을 인증합니다. 이 기능의 일부로, PTA 플러그인을 사용하면 위임자 디렉토리 서버가 해당 로컬 데이터베이스에 반드시 저장할 필요가 없는 항목에 대해 비밀번호 기반의 단순 바인드 작업을 허용할 수 있습니다.

PTA 플러그인은 서버와의 개인 통신을 위해 DSCC에서도 사용됩니다. 서버 인스턴스가 DSCC에 등록될 때 PTA 플러그인이 활성화되며 DSCC URL이 인수로 추가됩니다.


$ dsconf get-plugin-prop -h host -p port "Pass Through Authentication" enabled argument
argument  :  ldap://DSCC_URL:DSCC_PORT/cn=dscc
enabled   :  on
주 –

가능한 경우 사용자 고유 용도로 PTA 플러그인을 수정하지 마십시오. PTA 플러그인을 수정하면 DSCC에 대한 액세스 문제가 발생할 수 있습니다.

PTA 플러그인을 수정해야 하는 경우에는 다음 작업을 수행해야 합니다.

PTA 플러그인이 비활성화되거나 DSCC URL이 인수에서 제거되면 서버 인스턴스는 DSCC에서 inaccessible로 표시됩니다. 이 경우, DSCC에서 PTA 플러그인을 재설정하라는 옵션이 자동으로 표시됩니다.