|
| Sun ONE Directory Server 관리 설명서 |
Sun ONE Directory Server에서는 네트워크를 통해 안전하면서도 트러스트할 수 있는 통신을 제공할 수 있도록 여러 메커니즘을 지원합니다. LDAPS는 SSL(Secure Sockets Layer)에 추가로 실행되는 표준 LDAP 프로토콜로, 데이터를 암호화하고 인증서를 사용하여 인증합니다(선택 사항).
Sun ONE Directory Server는 Start TLS(Start Transport Layer Security) 확장 작업을 지원하므로 기존에 암호화되지 않은 LDAP 연결에서 TLS를 사용할 수 있습니다. Directory Server 5.2에서는 Unix 플랫폼은 물론 Windows 플랫폼에서도 StartTLS를 지원합니다.
Directory Server 5.2에서는 SASL(Simple Authentication and Security Layer)을 통한 GSSAPI
(Generic Security Services API)도 지원하므로 Solaris 운영 환경에서 커버로스 버전 5 보안 프로토콜을 사용할 수 있습니다. 이 경우 ID 매핑 메커니즘이 커버로스 사용자를 디렉토리 ID와 연결합니다.이 장은 다음 내용으로 구성되어 있습니다.
- Directory Server에 SSL 사용
- SSL 활성화 단계 요약
- 서버 인증서 얻기 및 설치
- SSL 활성화
- 클라이언트 인증 구성
- ID 매핑
- LDAP 클라이언트에서 보안을 사용하도록 구성
Directory Server에 SSL 사용
SSL(Secure Sockets Layer)은 Directory Server와 클라이언트 간에 암호화된 통신과 인증(선택 사항)을 제공합니다. LDAP와 DSML-over-HTTP 프로토콜 모두에 대해 SSL을 활성화하여 모든 서버 연결에 보안을 제공할 수 있습니다. 또한 복제 및 연결 접미사 메커니즘을 구성하여 서버 간의 보안 통신에 SSL을 사용할 수도 있습니다.
SSL을 단순 인증(바인드 DN과 암호)과 함께 사용하면 서버 간에 전송되는 모든 데이터가 암호화되므로 기밀성과 데이터 무결성이 보장됩니다. 선택 사항으로, 클라이언트는 인증서를 사용하여 Directory Server 또는 SASL(Simple Authentication and Security Layer)을 통한 타사 보안 메커니즘에 인증할 수 있습니다. 인증서 기반 인증에서는 클라이언트나 서버를 사칭하지 못하도록 공개 키 암호화를 사용합니다.
Directory Server는 별도의 포트에서 SSL 통신과 비SSL 통신을 동시에 지원합니다. 또는 보안상의 이유로 모든 통신을 보안 포트로 제한할 수도 있습니다. 클라이언트 인증은 구성이 가능하며, 필수 또는 선택 사항으로 구성되어 실행할 보안 수준을 결정할 수 있습니다.
SSL을 사용하면 일반 LDAP 연결에 보안을 제공하는 Start TLS 확장 작업도 지원됩니다. 클라이언트는 비SSL 포트에 바인드한 후에 TLS(Transport Layer Security) 프로토콜을 사용하여 SSL 연결을 시작할 수 있습니다. Start TLS 작업은 클라이언트의 유연성을 높이며 포트 할당을 용이하게 합니다.
SSL에서 제공하는 암호화 메커니즘은 속성 암호화에도 사용됩니다. SSL을 사용할 경우 접미사에 속성 암호화를 구성하여 디렉토리에 저장된 데이터를 보호할 수 있습니다. 자세한 내용은 "속성 값 암호화"를 참조하십시오.
클라이언트의 SSL 및 인증서 사용에 따라 디렉토리 내용에 대한 액세스 제어를 구성하여 보안을 강화할 수 있습니다. 특정 인증 방법이 필요한 액세스 제어 명령(ACI)을 정의할 수 있으며, 이 경우 보안 채널을 통해서만 데이터가 전송됩니다. 자세한 내용은 "바인드 규칙"을 참조하십시오.
관리 서버에서 SSL을 구성하는 방법 등 SSL, 인터넷 보안 및 인증서에 대한 자세한 내용은 Sun ONE Server Console Server Management Guide의 Chapter 10, "Using SSL and TLS with Sun ONE Servers"를 참조하십시오.
SSL 활성화 단계 요약
각각의 단계에 대해서는 이 장의 후속 절에서 설명합니다.
- 인증서를 얻어 Directory Server에 설치하고 Directory Server에서 인증 기관의 인증서를 트러스트하도록 구성합니다. 이 절차에는 다음과 같은 작업이 포함됩니다.
- 필요한 경우 인증서 데이터 베이스 작성
- 서버에서 인증서 요청을 생성하여 서버 인증서를 제공할 인증 기관으로 전송
- 서버에 새 인증서 설치
- 인증 기관과 인증 기관이 발급한 모든 인증서 트러스트
- LDAP 및 DSML 작업을 위한 보안 포트를 포함하여 디렉토리에서 SSL을 활성화하고 구성합니다. Directory Server 콘솔에서 SSL을 사용하여 서버에 액세스하도록 구성할 수도 있습니다.
- 선택 사항으로, 다음 클라이언트 인증 메커니즘 중에서 하나 이상을 서버에 구성합니다.
- 인증서 기반의 기본 인증 메커니즘
- SASL을 통한 DIGEST_MD5 인증 메커니즘
- 커버로스 V5 보안 메커니즘의 사용을 허용하는 SASL을 통한 GSSAPI 인증
- 선택 사항으로 사용할 인증 메커니즘을 포함하여 클라이언트에서 디렉토리 서버와의 통신에 SSL을 사용하도록 구성합니다.
명령줄을 통해 인증서를 관리하려면 certutil 도구를 사용하여 위의 단계 중 일부를 수행할 수도 있습니다. 이 도구는 Sun ONE Directory Server Resource Kit에 포함되어 있습니다. 자세한 내용은 Sun ONE Directory Server Resource Kit Tools Reference의 Chapter 30, "Security Tools"를 참조하십시오.
서버 인증서 얻기 및 설치
이 절에서는 인증서 데이터베이스를 작성하고, Directory Server에서 사용할 인증서를 얻어서 설치하며, Directory Server에서 인증 기관(CA)의 인증서를 트러스트하도록 구성하는 절차에 대해 설명합니다.
인증서 데이터베이스 작성
서버에 처음 SSL을 구성할 때 보안 장치 암호를 설정해야 합니다. 외부 하드웨어 보안 장치를 사용하지 않는 경우 아래 파일에 저장된 인증서 및 키 데이터베이스가 내부 보안 장치가 됩니다.
serverRoot/alias/slapd-serverID-cert7.db
serverRoot/alias/slapd-serverID-key3.dbserverID에 대문자가 포함되어 있으면 아래의 명령줄 절차를 사용하여 인증서 데이터베이스를 작성해야 합니다.
콘솔 사용
콘솔에서 인증서 관리자 대화 상자를 처음 실행하면 인증서 데이터베이스 파일이 자동으로 작성됩니다.
- Directory Server 콘솔의 최상위 "태스크" 탭에서 "인증서 관리" 버튼을 누릅니다. 또는 "태스크" 탭을 표시하고 "콘솔 > 보안" 메뉴에서 "인증서 관리" 항목을 선택합니다.
- 서버에서 인증서 및 키 데이터베이스를 자동으로 작성하며, 보안 장치 암호를 설정하라는 메시지가 표시됩니다. 이 암호는 서버에 저장된 인증서의 개인 키를 보호합니다. 암호를 두 번 입력하여 확인한 다음 "확인"을 누릅니다.
명령줄 사용
명령줄에서 인증서 데이터베이스 파일을 작성하는 경우 서버가 이 파일을 찾을 수 있도록
아래 절차에 제공된 경로 및 파일 이름 접두어를 사용해야 합니다.
- 서버 호스트 시스템에서 아래 명령을 실행하여 인증서 데이터베이스를 작성합니다.
certutil -N -d serverRoot/alias -P slapd-LCserverID-
여기서 LCserverID는 모두 소문자로 지정된 서버 이름입니다.
인증서 키를 보호할 암호를 입력하라는 메시지가 표시됩니다.
인증서 요청 생성
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-----콘솔 사용
- Directory Server 콘솔의 최상위 "태스크" 탭에서 "인증서 관리" 버튼을 누릅니다. 또는 "태스크" 탭을 표시하고 "콘솔 > 보안" 메뉴에서 "인증서 관리" 항목을 선택합니다.
"인증서 관리" 대화 상자가 표시됩니다.
- "서버 인증서" 탭을 선택하고 "요청" 버튼을 누릅니다.
"인증서 요청 마법사"가 표시됩니다.
- 서버에서 CA와 직접 통신할 수 있도록 지원하는 플러그 인을 설치한 경우 지금 선택할 수 있습니다. 그렇지 않으면 생성된 요청을 전자 우편이나 웹 사이트를 통해 전송하여 수동으로 인증서를 요청해야 합니다. "다음"을 눌러 계속합니다.
- 빈 텍스트 필드에 다음과 같은 "요청자 정보"를 입력합니다.
서버 이름. DNS 조회 시 사용되는 Directory Server의 전체 호스트 이름을 입력합니다
(예: east.example.com).조직. 회사나 기관의 공식 이름을 입력합니다. 대부분의 CA는 사업자 등록증 사본과 같은 공식 문서를 사용하여 이 정보를 확인하도록 요청합니다.
조직 구성 단위. (선택 사항) 회사 부서 또는 사업부를 잘 나타내는 이름을 입력합니다.
구/군/시. (선택 사항) 회사가 있는 도시 이름을 입력합니다.
시/도. 약어를 사용하지 말고 회사가 있는 시/도의 전체 이름을 입력합니다.
국가. 두 자로 된 ISO 형식의 국가 이름 약어를 선택합니다. 미국의 국가 코드는 US입니다. ISO 국가 코드 목록은 Sun ONE Directory Server Reference Manual의 Appendix C, "Directory Internationalization"을 참조하십시오.
"다음"을 눌러 계속합니다.
- 보안 장치 암호를 입력하고 "다음"을 누릅니다. 이 암호는 "인증서 데이터베이스 작성"에서 설정한 암호입니다.
- "클립보드로 복사" 또는 "파일에 저장"을 선택하여 인증 기관에 보내야 하는 인증서 요청 정보를 저장합니다.
- "완료"를 눌러 "인증서 요청 마법사"를 닫습니다.
명령줄 사용
- 아래 명령을 실행하여 서버 인증서 요청을 작성합니다.
certutil -R \
-s "cn=serverName,ou=division,o=company,l=city,st=state,c=country" \
-a -d serverRoot/alias -P slapd-serverID-
-s 옵션은 요청된 서버 인증서의 DN을 지정합니다. 대체로 인증 기관은 서버를 정확하게 식별하기 위해 이 예제에 사용된 속성을 모두 필요로 합니다. 각 속성에 대한 자세한 내용은 위의 단계 4를 참조하십시오.
- certutil 도구로부터 서버의 키 데이터베이스 암호를 입력하라는 메시지가 표시됩니다. 이 암호는 "인증서 데이터베이스 작성"에서 설정한 암호입니다. 그런 후에 이 도구는 PEM 인코딩된 텍스트 형식으로 PKCS #10 인증서 요청을 생성합니다.
서버 인증서 설치
인증 기관의 절차에 따라 이전 절에서 생성한 인증서 요청을 인증 기관으로 전송합니다. 예를 들어, 전자 우편으로 인증서 요청을 보내야 하는 경우도 있고 CA 웹 사이트에서 요청을 입력할 수 있는 경우도 있습니다.
요청을 보낸 후에는 CA에서 이 요청에 대한 응답으로 인증서를 보내줄 때까지 기다려야 합니다. 요청에 대한 응답 시간은 경우에 따라 달라집니다. 예를 들어, 회사 내부의 CA인 경우 하루나 이틀이면 요청에 대한 응답을 받을 수 있습니다. 회사 외부의 CA를 선택하면 요청에 대한 응답을 받을 때까지 몇 주가 걸릴 수도 있습니다.
CA로부터 받은 응답 정보는 반드시 텍스트 파일에 저장해야 합니다. PEM 형식의 PKCS #11 인증서는 아래 예제와 같이 표시됩니다. PEM은 RFC 1421부터 1424
(http://www.ietf.org/rfc/rfc1421.txt)까지에 지정된 Privacy Enhanced Mail 형식으로, base64 인코딩된 인증서를 US-ASCII 문자로 나타내는 데 사용됩니다.
-----BEGIN CERTIFICATE-----
MIICjCCAZugAwIBAgICCEEwDQYJKoZIhKqvcNAQFBQAwfDELMAkGA1UEBhMCVVMx
IzAhBgNVBAoGlBhbG9a2FWaWxsZGwSBXaWRnZXRzLCBJbmMuMR0wGwYDVQQLExRX
aWRnZXQgTW3FrZXJzICdSJyBVczEpMCcGAx1UEAxgVGVzdCBUXN0IFRlc3QgVGVz
dCBUZXN0IFlc3QgQ0EswHhcNOTgwMzEyMDIzMzUWhcNOTgwMzI2MDIzMpzU3WjBP
MQswCYDDVQQGEwJVUzEoMCYGA1UEChMfTmV0c2NhcGUgRGlyZN0b3J5VIFB1Ymxp
Y2F0aW9uczEWMB4QGA1UEAxMNZHVgh49dq2tLNvbjTBaMA0GCSqGSIb3DQEBAQUA
A0kAMEYkCQCksMR/aLGdfp4m0OiGgijG5KgOsyRNvwGYW7kfW+8mmijDtZaRjYNj
jcgpF3VnlbxbclX9LVjjNLC5737XZdAgEDozYwpNDARBglghkgBhvhCEAQEEBAMC
APAwHkwYDVR0jBBgwFAU67URjwCaGqZHUpSpdLxlzwJKiMwDQYJKoZIhQvcNAQEF
BQADgYEAJ+BfVem3vBOPBveNdLGfjlb9hucgmaMcQa9FA/db8qimKT/ue9UGOJqL
bwbMKBBopsDn56p2yV3PLIsBgrcuSoBCuFFnxBnqSiTS7YiYgCWqWaUA0ExJFmD6
6hBLseqkSWulk+hXHN7L/NrViO+7zNtKcaZLlFPf7d7j2MgX4Bo=
-----END CERTIFICATE-----인증서 데이터도 안전한 장소에 백업해 두어야 합니다. 시스템에 저장된 인증서 데이터가 손실될 경우 백업 파일을 사용하여 인증서를 다시 설치할 수 있습니다.
서버 인증서가 있으면 즉시 서버의 인증서 데이터베이스에 설치할 수 있습니다.
콘솔 사용
- Directory Server 콘솔의 최상위 "태스크" 탭에서 "인증서 관리" 버튼을 누릅니다. 또는 "태스크" 탭을 표시하고 "콘솔 > 보안" 메뉴에서 "인증서 관리" 항목을 선택합니다.
"인증서 관리" 창이 표시됩니다.
- "서버 인증서" 탭을 선택하고 "설치"를 누릅니다.
"인증서 설치 마법사"가 표시됩니다.
- 다음 인증서 위치 옵션 중에서 하나를 선택합니다.
인증서가 있는 파일. 이 필드에는 인증서의 절대 경로를 입력합니다.
다음 인코딩된 텍스트 블록. 사용자가 작성한 텍스트 파일 또는 인증 기관의 텍스트를 복사하여 이 필드에 붙여넣습니다.
"다음"을 눌러 계속합니다.
- 표시된 인증서 정보가 올바른지 확인하고 "다음"을 누릅니다.
- 인증서 이름을 지정하고 "다음"을 누릅니다. 이 이름이 인증서 테이블에 표시됩니다.
- 개인 키를 보호하는 암호를 입력하여 인증서를 확인합니다. 이 암호는 "인증서 데이터베이스 작성"의 단계 2에서 입력한 암호와 같아야 합니다. 작업이 끝나면 "완료"를 누릅니다.
"서버 인증서" 탭의 목록에 새 인증서가 표시됩니다. 이제 서버에서 SSL을 사용할 수 있습니다.
명령줄 사용
- 아래 명령을 실행하여 인증서 데이터베이스에 새 서버 인증서를 설치합니다.
certutil -A -n "certificateName" -t "u,," -a -i certFile \
-d serverRoot/alias -P slapd-serverID-
여기서 certificateName은 인증서를 식별하기 위해 사용자가 지정한 이름이며, certFile은 PEM 형식의 PKCS #11 인증서가 포함된 텍스트 파일입니다. -t "u,," 옵션은 이 인증서가 SSL 통신용 서버 인증서임을 나타냅니다.
- 선택 사항으로, 아래의 certutil 명령을 실행하여 설치된 인증서를 확인할 수도 있습니다.
certutil -L -d serverRoot/alias -P slapd-serverID-
u,, 트러스트 속성을 사용하면 서버 인증서가 열거됩니다.
인증 기관 트러스트
Directory Server에서 인증 기관을 트러스트하도록 구성하려면 인증서를 얻어 서버의 인증서 데이터베이스에 설치해야 합니다. 이 프로세스는 사용하는 인증 기관에 따라 달라집니다. 인증서를 자동으로 다운로드할 수 있는 웹 사이트를 제공하는 민간 CA도 있고, 요청 시 전자 우편으로 인증서를 보내주는 CA도 있습니다.
콘솔 사용
CA 인증서가 있으면 "인증서 설치 마법사"를 사용하여 Directory Server에서 인증 기관을 트러스트하도록 구성할 수 있습니다.
- Directory Server 콘솔의 최상위 "태스크" 탭에서 "인증서 관리" 버튼을 누릅니다. 또는 "태스크" 탭을 표시하고 "콘솔 > 보안" 메뉴에서 "인증서 관리" 항목을 선택합니다.
"인증서 관리" 창이 표시됩니다.
- "CA 인증서" 탭을 선택하고 "설치"를 누릅니다.
"인증서 설치 마법사"가 표시됩니다.
- CA 인증서를 파일에 저장한 경우 제공된 필드에 파일 경로를 입력합니다. 전자 우편을 통해 CA 인증서를 받은 경우 헤더를 포함한 인증서 전체를 복사하여 제공된 텍스트 필드에 붙여넣습니다. "다음"을 누릅니다.
- 표시된 인증서 정보가 인증 기관에 맞는지 확인하고 "다음"을 누릅니다.
- 인증서 이름을 지정하고 "다음"을 누릅니다.
- 이 CA를 트러스트하는 목적을 선택합니다. 다음 중 하나 또는 둘 모두를 선택할 수 있습니다.
클라이언트의 연결 허용(클라이언트 인증). LDAP 클라이언트가 이 CA에서 발급한 인증서를 제공하여 인증서 기반의 클라이언트 인증을 수행하는 경우 이 확인란을 선택합니다.
다른 서버에 연결(서버 인증). 서버가 이 CA에서 발급한 인증서가 있는 다른 서버에 대해 SSL을 통한 복제 공급자 또는 연결 멀티플렉서 역할을 할 경우 이 확인란을 선택합니다.
- "완료"를 눌러 마법사를 닫습니다.
명령줄 사용
- 아래 명령을 실행하여 트러스트할 수 있는 CA 인증서를 설치할 수도 있습니다.
certutil -A -n "CAcertificateName" -t "trust,," -a -i certFile \
-d serverRoot/alias -P slapd-serverID-
여기서 CAcertificateName은 트러스트할 수 있는 CA를 식별하기 위해 사용자가 지정한 이름이고 certFile 은 PEM 인코딩된 텍스트 형식의 PKCS #11 CA 인증서가 포함된 텍스트 파일이며, trust는 다음 코드 중 하나입니다.
- T - 이 CA는 클라이언트 인증서를 발급하도록 트러스트되었습니다. LDAP 클라이언트가 이 CA에서 발급한 인증서를 제공하여 인증서 기반의 클라이언트 인증을 수행하는 경우 이 코드를 사용합니다.
- C - 이 CA는 서버 인증서를 발급하도록 트러스트되었습니다. 서버가 이 CA에서 발급한 인증서가 있는 다른 서버에 대해 SSL을 통한 복제 공급자 또는 연결 멀티플렉서 역할을 할 경우 이 코드를 사용합니다.
- CT - 이 CA는 클라이언트 인증서와 서버 인증서를 모두 발급하도록 트러스트되었습니다. 위의 두 경우가 모두 적용되면 이 코드를 사용합니다.
- 선택 사항으로, 아래의 certutil 명령을 실행하여 설치된 인증서를 확인할 수도 있습니다.
certutil -L -d serverRoot/alias -P slapd-serverID-
u,, 트러스트 속성을 사용하면 서버 인증서가 열거되고 CT,, 속성을 사용하면 트러스트할 수 있는 CA 인증서가 열거됩니다.
SSL 활성화
서버 인증서 설치와 CA 인증서 트러스트가 끝나면 SSL을 활성화할 수 있습니다. 대체로 SSL을 사용하여 서버를 실행하는 것이 좋습니다. 일시적으로 SSL을 비활성화한 경우 기밀성, 인증 또는 데이터 무결성이 필요한 작업을 처리하기 전에 SSL을 다시 활성화해야 합니다.
SSL을 활성화하려면 먼저 "서버 인증서 얻기 및 설치"에 설명된 것처럼 인증서 데이터베이스를 작성하고 서버 인증서를 얻어서 설치한 후에 CA 인증서를 트러스트해야 합니다.
그런 다음, 아래 절차에 따라 디렉토리 서버에서 SSL 통신을 활성화하고 암호화 메커니즘을 사용합니다.
- Directory Server 콘솔의 최상위 "구성" 탭에서 이 서버 이름이 포함된 루트 노드를 선택한 다음 오른쪽 창에서 "암호화" 탭을 선택합니다.
현재의 서버 암호화 설정이 탭에 표시됩니다.
- "이 서버에 SSL 사용" 확인란을 선택하여 암호화를 사용하도록 지정합니다.
- "사용할 암호 패밀리" 확인란을 선택합니다.
- 드롭다운 메뉴에서 사용할 인증서를 선택합니다.
- "암호 설정"을 눌러 "암호 기본 설정" 대화 상자에서 사용할 암호를 선택합니다. 특정 암호에 대한 자세한 내용은 "암호화 암호 선택"을 참조하십시오.
- 클라이언트 인증에 대한 기본 설정을 설정합니다.
클라이언트 인증 허용 안 함. 이 옵션을 사용하면 서버가 클라이언트의 인증서나 SASL 보안 메커니즘을 무시하고 바인드 DN과 암호를 요구합니다.
클라이언트 인증 허용. 이 옵션이 기본 설정입니다. 이 옵션을 사용하면 클라이언트 요청에 대한 인증이 수행됩니다. 인증서 기반의 인증에 대한 자세한 내용은 "클라이언트 인증 구성"을 참조하십시오.
주 복제 시 인증서 기반의 인증을 사용하는 경우 소비자 서버에서 클라이언트 인증을 허용하거나 필요로 하도록 구성해야 합니다.
클라이언트 인증 필요. 이 옵션을 사용하면 클라이언트가 서버의 인증 요청에 응답하지 않을 경우 클라이언트 연결이 거부됩니다.
주 Sun ONE 서버 콘솔이 SSL을 통해 Directory Server에 연결하는 경우 "클라이언트 인증 필요"를 선택하면 클라이언트 인증에 사용할 인증서가 Sun ONE 서버 콘솔에 없기 때문에 통신이 비활성화됩니다. 명령줄에서 이 속성을 수정하려면 "클라이언트 인증 허용"을 참조하십시오.
- 선택 사항으로, 콘솔이 SSL을 통해 Directory Server와 통신하도록 설정하려면 "Sun ONE 서버 콘솔에 SSL 사용"을 선택합니다.
- 작업이 끝나면 "저장"을 누릅니다.
- 선택 사항으로, 서버에서 LDAP 및 DSML-over-HTTP 프로토콜 모두의 SSL 통신에 사용할 보안 포트를 설정합니다. 자세한 내용은 "Directory Server의 포트 번호 변경"을 참조하십시오.
보안 포트에 대한 모든 연결은 SSL을 사용해야 합니다. SSL을 활성화하면 보안 포트 구성 여부에 관계 없이 클라이언트에서 Start TLS 작업을 사용하여 비보안 포트를 통한 SSL 암호화를 수행할 수 있습니다.
- Directory Server를 다시 시작합니다.
자세한 내용은 "SSL을 활성화하여 서버 시작"을 참조하십시오.
암호화 암호 선택
암호는 데이터를 암호화하고 암호를 해독하는 데 사용하는 알고리즘입니다. 일반적으로 암호는 암호화 중에 사용하는 비트 수가 많을수록 더 강력하거나 안전합니다. SSL 암호는 사용된 메시지 인증 유형으로도 식별할 수 있습니다. 메시지 인증은 데이터 무결성을 보장하는 체크섬을 계산하는 별개의 알고리즘입니다. 암호 알고리즘 및 각 장점에 대한 자세한 내용은Sun ONE Server Console Server Management Guide의 Appendix B, "Ciphers Used With SSL"을 참조하십시오.
클라이언트가 서버와의 SSL 연결을 시작하려면 클라이언트 및 서버가 정보 암호화에 사용할 암호에 동의해야 합니다. 양방향 암호화 프로세스의 경우 클라이언트와 서버 모두, 지원되는 가장 강력한 암호를 동일하게 사용해야 합니다.
Sun ONE Directory Server는 다음과 같은 SSL 3.0 및 TLS용 암호를 제공합니다.
Sun ONE 서버 콘솔에서 계속 SSL을 사용하려면 최소한 다음 암호 중 하나를 선택해야 합니다.
- 40비트 암호화 및 MD5 메시지 인증을 사용하는 RC4 암호
- 암호화 없음, MD5 메시지 인증만 사용(권장되지 않음)
- 56비트 암호화 및 SHA 메시지 인증을 사용하는 DES
- 128비트 암호화 및 MD5 메시지 인증을 사용하는 RC4 암호
- 168비트 암호화 및 SHA 메시지 인증을 사용하는 Triple DES
서버에서 사용할 암호를 선택하려면 아래 절차에 따라 수행합니다.
- Directory Server 콘솔의 최상위 "구성" 탭에서 이 서버 이름이 포함된 루트 노드를 선택한 다음 오른쪽 창에서 "암호화" 탭을 선택합니다.
현재의 서버 암호화 설정이 탭에 표시됩니다. "SSL 활성화"에 설명된 것처럼 서버에서 SSL을 활성화해야 합니다.
- "암호 설정"을 누릅니다.
"암호 기본 설정" 대화 상자가 표시됩니다.
- "암호 기본 설정" 대화 상자에서 이름 옆에 있는 확인란을 선택하거나 선택 취소하여 서버에서 사용할 암호를 지정합니다.
보안상 특정 암호를 사용하지 않는 경우가 아니면 없음, MD5를 제외한 모든 암호를 선택해야 합니다.
주의
"암호화 없음, MD5 메시지 인증만 사용" 암호 옵션은 선택하지 마십시오. 서버는 클라이언트에서 다른 암호를 사용할 수 없을 때 이 옵션을 사용합니다. 이 경우 암호화가 사용되지 않으므로 연결이 안전하지 않습니다.
- "암호 기본 설정" 대화 상자에서 "확인"을 누른 다음 "암호화" 탭에서 "저장"을 누릅니다.
클라이언트 인증 허용
Directory Server에 클라이언트 인증이 필요하고 Sun ONE 서버 콘솔이 SSL을 사용하여 연결하도록 구성한 경우에는 더 이상 Sun ONE 서버 콘솔을 사용하여 Sun ONE 서버를 관리할 수 없습니다. 이 경우 해당 명령줄 유틸리티를 사용해야 합니다.
Sun ONE 서버 콘솔을 사용할 수 있도록 디렉토리 구성을 변경하려면 다음 단계에 따라 클라이언트 인증을 필수가 아닌 선택 사항으로 설정해야 합니다.
- 아래 명령을 실행하여 cn=encryption,cn=config 항목을 수정합니다.
ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn: cn=encryption,cn=config
changetype: modify
replace: nsSSLClientAuth
nsSSLClientAuth: allowed
- "명령줄에서 서버 시작 및 중지(Unix)"에 설명된 것처럼 Directory Server를 다시 시작합니다.
이제 Sun ONE 서버 콘솔을 시작할 수 있습니다.
클라이언트 인증 구성
클라이언트 인증은 서버에서 클라이언트 ID를 확인하는 메커니즘입니다. 클라이언트가 제공한 인증서를 사용하거나 DIGEST-MD5 같은 SASL 기반의 메커니즘을 통해 클라이언트 인증을 수행할 수 있습니다. Solaris 운영 체제의 경우 Directory Server에서 SASL을 통한 GSSAPI 메커니즘을 지원하므로 커버로스 V5를 통해 클라이언트 인증을 허용할 수 있습니다.
인증서 기반의 인증 시에는 SSL 프로토콜을 통해 얻은 클라이언트 인증서를 사용하여 식별할 사용자 항목을 찾습니다. 이 항목에는 인증할 사용자에 대한 동일한 인증서가 있어야 합니다. 이 메커니즘은 SASL 외부 메커니즘이기 때문에 EXTERNAL이라고도 합니다. 인증서 기반의 인증에 대해서는 Sun ONE Server Console Server Management Guide의 Chapter 10, "Using Client Authentication"에서 자세히 설명합니다.
다음 절에서는 디렉토리 서버에 두 개의 SASL 메커니즘을 구성하는 방법에 대해 설명합니다. "LDAP 클라이언트에서 보안을 사용하도록 구성"을 참조하십시오.
DIGEST-MD5를 통한 SASL 인증
DIGEST-MD5 메커니즘은 클라이언트에서 보낸 해시 값을 사용자 암호의 해시와 비교하여
클라이언트를 인증합니다. 하지만 이 메커니즘은 사용자 암호를 읽어야 하기 때문에 DIGEST-MD5를 통해 인증을 받으려는 사용자는 디렉토리에 {CLEAR} 암호가 있어야 합니다.DIGEST-MD5 메커니즘 구성
아래 절차에서는 Directory Server에서 DIGEST-MD5를 사용하도록 구성하는 방법에 대해 설명합니다.
- 콘솔이나 ldapsearch 명령을 사용하여 DIGEST-MD5가 루트 항목의 supportedSASLMechanisms 속성 값인지 확인합니다. 예를 들어 아래 명령은 현재 활성화되어 있는 SASL 메커니즘을 보여줍니다.
ldapsearch -h host -p port -D "cn=Directory Manager" -w password \
-s base -b "" "(objectclass=*)" supportedSASLMechanismsdn:
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: GSSAPI
- DIGEST-MD5가 활성화되어 있지 않으면 아래의 ldapmodify 명령을 사용하여 활성화합니다.
ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn: cn=SASL, cn=security, cn=config
changetype: modify
add: dsSaslPluginsEnable
dsSaslPluginsEnable: DIGEST-MD5
-
replace: dsSaslPluginsPath
dsSaslPluginsPath: serverRoot/lib/sasl
- "DIGEST-MD5 ID 매핑"에 설명된 것처럼 DIGEST-MD5에 기본 ID 매핑을 사용하거나 새로운 ID 매핑을 작성합니다.
- DIGEST-MD5를 사용하여 SSL을 통해 서버에 액세스하는 모든 사용자의 암호가 {CLEAR}에 저장되어 있는지 확인합니다. 암호 저장 체계를 구성하는 방법은 7장 "사용자 계정 관리를 참조하십시오.
주의
디렉토리에 {CLEAR} 암호를 저장하는 경우 6장 "액세스 제어 관리에 설명된 것처럼 ACI를 통해 암호 값에 대한 액세스를 적절하게 제한해야 합니다.
"속성 값 암호화"에 설명된 것처럼 해당 접미사에 속성 암호화를 구성하여 {CLEAR} 암호의 보안을 강화할 수도 있습니다.
- SASL 구성 항목이나 DIGEST-MD5 ID 매핑 항목 중 하나를 수정한 경우 디렉토리 서버를 다시 시작합니다.
DIGEST-MD5 ID 매핑
SASL 메커니즘의 ID 매핑은 SASL ID의 자격 증명을 디렉토리에 있는 사용자 항목과 일치시킵니다. 이 메커니즘에 대한 자세한 내용은 "ID 매핑"을 참조하십시오. 매핑 중에 SASL ID에 해당하는 DN을 찾을 수 없으면 인증은 실패합니다.
SASL ID는 각 메커니즘의 고유 형식으로 사용자를 나타내는 Principal 문자열입니다. DIGEST-MD5의 경우 클라이언트가 dn: 접두어와 LDAP DN이 포함된 사용자나 클라이언트에서 지정한 텍스트가 u: 접두어 뒤에 오는 Principal을 작성하는 것이 좋습니다. 클라이언트가 보낸 Principal은 매핑 중에 ${Principal} 자리 표시자에서 사용할 수 있습니다.
DIGEST-MD5의 기본 ID 매핑은 서버 구성의 아래 항목에서 지정합니다.
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이 ID 매핑에서는 Principal dn 필드에 기존 디렉토리 사용자의 DN이 포함되어 있다고 가정합니다.
DIGEST-MD5에 대한 사용자 정의 ID 매핑을 정의하려면 다음을 수행합니다.
- 기본 매핑 항목을 편집하거나 cn=DIGEST-MD5,cn=identity mapping,cn=config에 새 매핑 항목을 작성합니다. ID 매핑 항목의 속성 정의에 대해서는 "ID 매핑"을 참조하십시오. DIGEST-MD5 매핑 예제는 아래 파일에 포함되어 있습니다.
serverRoot/slapd-serverID/ldif/identityMapping_Examples.ldif
이 예제에서는 정식 이름이 아닌 Principal 텍스트 필드에 원하는 ID의 사용자 이름이 포함되어 있다고 가정합니다. 아래 명령은 이 매핑이 어떻게 정의되는지 보여줍니다.
ldapmodify -a -h host -p port -D "cn=Directory Manager" -w 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)
- Directory Server를 다시 시작하여 새로운 매핑을 적용합니다.
GSSAPI를 통한 SASL 인증(Solaris에만 해당)
SASL을 통한 GSSAPI(Generic Security Services API)를 사용하면 커버로스 V5와 같은 타사 보안 시스템을 통해 클라이언트를 인증할 수 있습니다. GSSAPI 라이브러리는 Solaris 플랫폼에서만 사용할 수 있습니다. SEAM(Sun Enterprise Authentication Mechanism) 1.0.1 서버에 커버로스 V5 구현을 설치하는 것이 좋습니다.
서버는 이 API를 사용하여 사용자 ID를 검증합니다. 그런 후에 SASL 메커니즘에서 GSSAPI 매핑 규칙을 적용하여 이 연결이 유지되는 동안 모든 작업의 바인드 DN으로 지정될 DN을 얻습니다.
커버로스 시스템 구성
제조업체의 지침에 따라 커버로스 소프트웨어를 구성합니다. SEAM 1.0.1 서버를 사용하는 경우 아래 단계도 수행해야 합니다.
- /etc/krb5에 있는 파일을 구성합니다.
- 사용자와 서비스를 저장할 커버로스 데이터베이스를 작성한 다음, 여기에 LDAP 서비스 사용자를 작성합니다. LDAP 서비스 사용자는 다음과 같습니다.
ldap/serverFQDN@REALM
여기서 serverFQDN은 서버의 전체 도메인 이름입니다.
- LDAP 서비스 키 등의 서비스 키를 저장할 키 탭을 작성합니다.
- 커버로스 데몬 프로세스를 시작합니다.
자세한 단계별 지침은 소프트웨어 설명서를 참조하십시오.
GSSAPI 메커니즘 구성
아래 절차에서는 Solaris 플랫폼의 Directory Server에서 GSSAPI를 사용하도록 구성하는 방법에 대해 설명합니다.
- 콘솔이나 ldapsearch 명령을 사용하여 GSSAPI가 루트 항목의 supportedSASLMechanisms 속성 값인지 확인합니다. 예를 들어 아래 명령은 현재 활성화되어 있는 SASL 메커니즘을 보여줍니다.
ldapsearch -h host -p port -D "cn=Directory Manager" -w password \
-s base -b "" "(objectclass=*)" supportedSASLMechanismsdn:
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: DIGEST-MD5
- 기본적으로 GSSAPI는 사용되지 않으므로 아래의 ldapmodify 명령을 사용하여 활성화할 수 있습니다.
ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn: cn=SASL, cn=security, cn=config
changetype: modify
add: dsSaslPluginsEnable
dsSaslPluginsEnable: GSSAPI
-
replace: dsSaslPluginsPath
dsSaslPluginsPath: serverRoot/lib/sasl
- "GSSAPI ID 매핑"에 설명된 것처럼 GSSAPI에 대한 기본 ID 매핑과 사용자 정의 매핑을 작성합니다.
- 호스트 시스템에서 서버 커버로스를 구성합니다.
- 세션 키를 사용하여 커버로스에 LDAP 서비스 사용자 ldap/serverHostname@Realm을 작성합니다. 여기서,
- serverHostname은 서버 호스트 시스템의 전체 도메인 이름입니다. 이 값은 반드시 소문자여야 한다는 점만 제외하고 cn=config의 nsslapd-localhost 속성 값과
반드시 동일해야 합니다.
- Realm은 서버의 커버로스 영역입니다.
- LDAP 서비스에는 /etc/krbs/krb5.keytab 파일의 키 데이터베이스에 대한 읽기 액세스 권한이 있어야 합니다.
- DNS는 호스트 시스템에 구성해야 합니다.
- SASL 구성 항목이나 GSSAPI ID 매핑 항목 중 하나를 수정한 경우 디렉토리 서버를 다시 시작합니다.
GSSAPI ID 매핑
SASL 메커니즘의 ID 매핑은 SASL ID의 자격 증명을 디렉토리에 있는 사용자 항목과 일치시킵니다. 이 메커니즘에 대한 자세한 내용은 "ID 매핑"을 참조하십시오. 매핑 중에 SASL ID에 해당하는 DN을 찾을 수 없으면 인증은 실패합니다.
SASL ID는 각 메커니즘의 고유 형식으로 사용자를 나타내는 Principal 문자열입니다. GSSAPI를 사용하는 커버로스에서 Principal은 uid[/instance][@realm] 형식의 ID로 지정됩니다. 여기서 uid에는 instance 식별자가 선택 사항으로 포함될 수 있으며 이 식별자 뒤에 선택 사항인 realm이 옵니다. realm에는 일반적으로 도메인 이름이 포함됩니다. 예를 들어, 다음은 모두 유효한 사용자 Principal입니다.
bjensen
bjensen/Sales
bjensen@EXAMPLE.COM
bjensen/Sales@EXAMPLE.COM처음에는 디렉토리에 GSSAPI 매핑이 정의되어 있지 않습니다. 클라이언트에서 Principal을 정의하는 방법에 따라 기본 매핑 및 필요한 사용자 정의 매핑을 모두 정의해야 합니다.
GSSAPI에 대한 ID 매핑을 정의하려면 다음을 수행합니다.
- cn=GSSAPI,cn=identity mapping, cn=config에 새 매핑 항목을 작성합니다. ID 매핑 항목의 속성 정의에 대해서는 "ID 매핑"을 참조하십시오.
GSSAPI 매핑 예제는 아래 파일에 포함되어 있습니다.
serverRoot/slapd-serverID/ldif/identityMapping_Examples.ldif
이 파일에 제공된 기본 GSSAPI 매핑에서는 Principal에 사용자 ID만 포함되어 있으며, 이 ID로 디렉토리의 고정 분기에 있는 사용자를 결정한다고 가정합니다.
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에 포함할 사용자 ID를 결정하는 방법을 보여줍니다.
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
- Directory Server를 다시 시작하여 새로운 매핑을 적용합니다.
ID 매핑
Directory Server에는 다른 프로토콜의 자격 증명을 디렉토리 DN으로 매핑해야 하는 여러 가지 인증 매커니즘이 있습니다. DSML-over-HTTP 프로토콜과 DIGEST-MD5 및 GSSAPI SASL 메커니즘도 이러한 경우에 해당합니다. 각 메커니즘에서는 ID 매핑을 사용하여 클라이언트가 제공한 프로토콜별 자격 증명에 따라 바인드 DN을 결정합니다.
ID 매핑 중에는 cn=identity mapping, cn=config 구성 분기의 항목이 사용됩니다.
이 분기에는 ID 매핑을 수행해야 하는 각 프로토콜의 컨테이너가 포함되어 있습니다.
- cn=HTTP-BASIC, cn=identity mapping, cn=config - DSML-over-HTTP 연결에 대한 매핑이 포함되어 있습니다.
- cn=DIGEST-MD5, cn=identity mapping, cn=config - DIGEST-MD5 SASL 메커니즘을 사용하는 클라이언트 인증에 대한 매핑이 포함되어 있습니다.
- cn=GSSAPI, cn=identity mapping, cn=config - GSSAPI SASL 메커니즘을 사용하는 클라이언트 인증에 대한 매핑이 포함되도록 작성해야 합니다.
매핑 항목은 디렉토리 검색에서 사용하기 위해 프로토콜별 자격 인증 요소를 추출하는 방법을 정의합니다. 검색 결과 한 개의 사용자 항목이 반환되면 매핑이 성공한 것이며, 연결이 유지되는 동안 이 항목을 모든 작업의 바인드 DN으로 사용합니다. 검색 결과 0 또는 두 개 이상의 항목이 반환되면 매핑이 실패하고 다른 매핑이 적용됩니다.
각 분기마다 해당 프로토콜의 기본 매핑과 사용자 정의 매핑이 포함되어야 합니다. 기본 매핑에는 cn=default RDN이 있고, 사용자 정의 매핑에는 이름 지정 속성으로 cn을 사용하는 다른 RDN이 있을 수 있습니다. 사용자 정의 매핑 중 하나가 성공할 때까지 모든 사용자 정의 매핑이 비결정적 순서로 먼저 평가됩니다. 모든 사용자 정의 매핑이 실패하면 마지막으로 기본 매핑이 적용됩니다. 기본 매핑도 실패하면 클라이언트 인증은 실패합니다.
매핑 항목에는 top, Container 및 dsIdentityMapping 개체 클래스가 있어야 하며, 이 경우 항목에는 다음과 같은 속성이 포함될 수 있습니다.
- dsMappedDN: DN - 디렉토리 DN을 정의하는 리터럴 문자열. 매핑을 수행할 때 이 DN이 있으면 해당 DN이 바인드에 사용됩니다. 해당 DN이 없을 때 검색을 수행할 다른 속성을 정의할 수도 있습니다.
- dsSearchBaseDN: DN - 검색할 기본 DN. 이 속성을 지정하지 않으면 매핑은 전체 디렉토리 트리에서 모든 루트 접미사를 검색합니다.
- dsSearchScope: base|one|sub - 검색 기본 항목 , 기본 항목보다 한 수준 아래의 자식, 기본 항목 아래의 전체 하위 트리 중 하나인 검색 범위. 이 속성을 지정하지 않으면 매핑 검색의 기본 범위는 전체 하위 트리입니다.
- dsSearchFilter: filterString - 매핑 검색을 수행할 필터 문자열. LDAP 검색 필터에 대해서는 RFC 2254(http://www.ietf.org/rfc/rfc2254.txt)에 정의되어 있습니다.
또한 매핑 항목에는 dsPatternMatching 개체 클래스가 포함되어 다음과 같은 속성의 사용을 허용할 수도 있습니다.
- dsMatching-pattern: patternString - 패턴 일치를 수행할 문자열을 지정합니다.
- dsMatching-regexp: regularExpression - 패턴 문자열에 적용할 정규 표현식을 지정합니다.
dsSearchScope를 제외한 위의 모든 속성 값에는 ${keyword} 형식의 자리 표시자가 포함될 수 있습니다. 여기서 keyword 는 프로토콜별 자격 증명에 있는 요소 이름입니다. 매핑 중에 자리 표시자는 클라이언트가 제공한 요소의 실제 값으로 대체됩니다.
모든 자리 표시자가 대체된 후에 정의된 패턴 일치가 수행됩니다. 일치하는 패턴은 정규 표현식과 비교됩니다. 정규 표현식이 패턴 문자열과 일치하지 않으면 이 매핑은 실패합니다. 일치하면 괄호 안에 있는 정규 표현식 조건에 일치하는 값을 번호가 매겨진 다른 속성 값의 자리 표시자로 사용할 수 있습니다. 예를 들어, SASL에 아래 매핑을 정의할 수 있습니다.
dsMatching-pattern: ${Principal}
dsMatching-regexp: (.*)@(.*)\.(.*)
dsMappedDN: uid=$1,ou=people,dc=$2,dc=$3클라이언트가 bjensen@example.com Principal로 인증하면 이 매핑은 uid=bjensen,
ou=people,dc=example,dc=com 바인드 DN을 정의합니다. 디렉토리에 이 DN이 있으면 매핑이 성공하여 클라이언트 인증이 이루어지고, 연결이 유지되는 동안 수행된 모든 작업은 이 바인드 DN을 사용합니다.dsMatching-pattern은 Posix regexec(3C) 및 regcomp(3C) 함수 호출을 사용하여 dsMatching-regexp와 비교됩니다. Directory Server는 확장 정규 표현식을 사용하며, 비교 시 대소문자는 구분하지 않습니다. 자세한 내용은 이러한 함수에 대한 설명서 페이지를 참조하십시오.
자리 표시자를 포함할 수 있는 속성 값에서 자리 표시자로 사용되지 않은 $, { 및 } 문자는 다른 자리 표시자를 사용하지 않아도 반드시 인코딩해야 합니다. 즉, $ 는 \24, { 는 \7B, }는 \7D로 인코딩해야 합니다.
자리 표시자와 대체를 사용하면 프로토콜별 자격 증명에서 사용자 이름과 다른 값을 추출하는 매핑을 작성하고 이 값을 사용하여 매핑된 DN을 정의하거나 디렉토리에서 해당 DN을 검색할 수 있습니다. 디렉토리 클라이언트가 제공한 예상 자격 증명을 추출하는 매핑을 정의하고 특정 디렉토리 구조에 이를 매핑해야 합니다.
LDAP 클라이언트에서 보안을 사용하도록 구성
다음 절에서는 디렉토리 서버와 보안 연결을 구성하려는 LDAP 클라이언트에서 SSL을 구성 및 사용하는 방법에 대해 설명합니다. SSL 연결에서 서버는 해당 인증서를 클라이언트로 보냅니다. 클라이언트는 먼저 인증서를 트러스트하여 서버를 인증해야 합니다. 그런 후에 클라이언트는 두 SASL 메커니즘(DIGEST-MD5 또는 커버로스 V5를 사용하는 GSSAPI) 중 하나에 대한 정보나 자신의 인증서를 보내 클라이언트 인증 메커니즘 중 하나를 선택적으로 시작할 수 있습니다.
다음 절에서는 SSL을 사용하는 LDAP 클라이언트의 예로 ldapsearch 도구를 사용합니다. 디렉토리 서버와 함께 제공된 ldapmodify, ldapdelete 및 ldapcompare 도구는 모두 동일한 방법으로 구성됩니다. 이러한 디렉토리 액세스 도구는 Sun ONE LDAP SDK for C에 기반을 두고 있으며, Sun ONE Directory Server Resource Kit Tools Reference에서 자세히 설명합니다.
다른 LDAP 클라이언트에서 SSL 연결을 구성하려면 응용 프로그램과 함께 제공된 설명서를 참조하십시오.
주 일부 클라이언트 응용 프로그램은 SSL만 구현하고 서버에 트러스트할 수 있는 인증서가 있는지 확인하지 않으므로 SSL 프로토콜을 사용하여 데이터 암호화는 제공하지만 기밀성이나 사칭에 대한 보호는 보장할 수 없습니다.
클라이언트에 서버 인증 구성
클라이언트는 서버와 SSL 연결을 구성할 때 서버에서 제공한 인증서를 트러스트해야 합니다. 이렇게 하려면 클라이언트는 다음과 같은 작업을 수행해야 합니다.
- 인증서 데이터베이스를 작성합니다.
- 서버 인증서를 발급하는 인증 기관(CA)을 트러스트합니다.
- LDAP 클라이언트의 SSL 옵션을 지정합니다.
Netscape Communicator는 SSL을 사용하여 HTTP 프로토콜을 통해 웹 서버와 통신하는 클라이언트 응용 프로그램입니다. Communicator를 사용하여 LDAP 클라이언트에서도 사용할 인증서를 관리할 수 있습니다. 또는 certutil 명령줄 도구를 사용하여 인증서 데이터베이스를 관리할 수 있습니다.
Communicator를 통한 클라이언트 인증서 관리
아래 절차에서는 Netscape Communicator를 사용하여 클라이언트 시스템에서 인증서 데이터베이스를 관리하는 방법에 대해 설명합니다.
- Netscape Communicator는 시작과 동시에 인증서 데이터베이스가 있는지 확인하며, 필요한 경우 새 인증서 데이터베이스를 작성합니다. 인증서 데이터베이스는 Communicator의 다른 기본 설정과 함께 파일에 저장됩니다. 예를 들어, UNIX 시스템에서는 /home/username/.netscape/cert7.db 파일에 저장됩니다.
이 절차를 사용할 경우 Communicator에서 작성된 인증서 데이터베이스를 찾아 클라이언트 응용 프로그램에 사용할 경로를 기억해 둡니다.
- Communicator를 사용하여 액세스할 디렉토리 서버 인증서를 발급한 인증 기관의 웹 사이트를 탐색합니다. Communicator에서 인증 기관의 인증서를 자동으로 검색하며, 트러스트 여부를 묻는 메시지를 표시합니다.
예를 들어, 내부용으로 배포된 Sun ONE Certificate Server를 사용하는 경우 https://hostname:444 형식의 URL을 방문합니다.
- 인증서를 트러스트하라는 메시지가 Communicator에 표시되면 인증 기관의 인증서를 트러스트합니다. 서버 인증을 위해 CA 인증서를 트러스트해야 합니다.
CA 웹 사이트에 따라 이 단계를 수행할 수 없는 경우도 있습니다. CA 인증서를 트러스트하라는 메시지가 Communicator에 자동으로 표시되지 않으면 아래 절차를 수행하여 인증서를 수동으로 트러스트합니다.
명령줄을 통한 클라이언트 인증서 관리
명령줄을 통해 인증서를 관리하려면 certutil 도구를 사용합니다. 이 도구는 Sun ONE Directory Server Resource Kit에 포함되어 있습니다. 자세한 내용은 Sun ONE Directory Server Resource Kit Tools Reference의 Chapter 30, "Security Tools"를 참조하십시오.
- 아래 명령을 실행하여 클라이언트 호스트 시스템에 인증서 데이터베이스를 작성합니다.
certutil -N -d path -P prefix
이 도구는 인증서를 보호하는 암호를 입력하라는 메시지를 사용자에게 표시한 다음 path/prefixcert7.db 및 path/prefixkey3.db 파일을 작성합니다.
LDAP 클라이언트 응용 프로그램 사용자는 자신들만 액세스할 수 있는 위치(예: 홈 디렉토리의 보호된 하위 디렉토리)에 개별적으로 인증서 데이터베이스를 작성해야 합니다.
- 액세스하려는 디렉토리 서버의 인증서를 발급한 인증 기관에 연락하여 CA 인증서를 요청합니다. 전자 우편을 보내거나 해당 웹 사이트에 액세스하여 PEM 인코딩된 텍스트 버전 형식의 PKCS #11 인증서를 얻을 수 있습니다. 이 인증서를 파일에 저장합니다.
예를 들어, 내부용으로 배포된 Sun ONE Certificate Server를 사용하는 경우 https://hostname:444 형식의 URL을 방문합니다. 최상위 "검색" 탭에서 "CA 인증서 체인 가져오기"를 선택하고 인코딩된 인증서를 복사합니다.
또는, 동일한 CA에서 클라이언트 인증서와 서버 인증서를 얻는 경우 "인증 기관 트러스트" 절차를 통해 얻은 CA 인증서를 다시 사용할 수도 있습니다.
- SSL 연결에 사용할 서버 인증서를 발급하기 위해 CA 인증서를 트러스트할 수 있는 CA로 가져옵니다. 아래 명령을 실행합니다.
certutil -A -n "certificateName" -t "C,," -a -i certFile -d path -P prefix
여기서 certificateName은 이 인증서를 식별하기 위해 사용자가 지정한 이름이고 certFile은 PEM 인코딩된 텍스트 형식의 PKCS #11 CA 인증서가 있는 텍스트 파일이며, path와 prefix는 단계 1과 같습니다.
LDAP 클라이언트 응용 프로그램의 모든 사용자는 CA 인증서를 자신의 인증서 데이터베이스로 가져와야 하며 모든 사용자가 certFile에 있는 동일한 인증서를 가져올 수 있습니다.
서버 인증에 대한 SSL 옵션 지정
ldapsearch 도구를 사용하여 SSL에서 서버 인증을 수행하려면 사용자는 인증서 데이터베이스 경로만 지정하면 됩니다. 서버는 보안 포트를 통해 SSL 연결을 구성할 때 자체 인증서를 보냅니다. 그런 후에 ldapsearch 도구는 사용자의 인증서 데이터베이스에서 서버 인증서를 발급한 CA의 트러스트할 수 있는 CA 인증서를 찾습니다.
아래 명령은 Netscape Communicator에서 인증서 데이터베이스를 작성한 경우 사용자가 자신의 인증서 데이터베이스를 지정하는 방법을 보여줍니다.
ldapsearch -h host -p securePort \
-D "uid=bjensen,dc=example,dc=com" -w bindPassword \
-Z -P /home/bjensen/.netscape/cert7.db \
-b "dc=example,dc=com" "(givenname=Richard)"클라이언트에 인증서 기반의 인증 구성
클라이언트 인증의 기본 메커니즘은 인증서를 사용하여 디렉토리 서버에서 사용자를 안전하게 식별하는 것입니다. 인증서 기반의 클라이언트 인증을 수행하려면 다음과 같은 작업을 해야 합니다.
- 모든 디렉토리 사용자에 대한 인증서를 얻어 클라이언트 응용 프로그램이 액세스할 수 있는 위치에 설치합니다.
- 동일한 인증서의 이진 복사본을 사용하여 사용자 디렉토리 항목을 구성합니다. 인증을 수행하는 동안 서버는 클라이언트 응용 프로그램이 제공한 인증서를 이 복사본과 비교하여 사용자를 정확하게 식별합니다.
- Sun ONE Server Console Server Management Guide의 Chapter 10, "Using Client Authentication"에 설명된 것처럼 서버에 인증서 기반의 인증을 구성합니다.
- 인증서 기반의 인증에 대한 LDAP 클라이언트의 SSL 옵션을 지정합니다.
이 절차에서는 certutil 도구를 사용하여 명령줄을 통해 인증서를 관리해야 합니다. 이 도구는 Sun ONE Directory Server Resource Kit에 포함되어 있습니다. 자세한 내용은 Sun ONE Directory Server Resource Kit Tools Reference의 Chapter 30, "Security Tools"를 참조하십시오.
사용자 인증서 얻기 및 설치
인증서 기반의 인증을 사용하여 디렉토리에 액세스하려는 각 사용자는 클라이언트 인증서를 요청하여 설치해야 합니다. 이 절차에서는 "클라이언트에 서버 인증 구성"에 설명된 것처럼 사용자가 이미 인증서 데이터베이스를 구성했다고 가정합니다.
- 아래 명령을 실행하여 사용자 인증서 요청을 작성합니다.
certutil -R \
-s "cn=Babs Jensen,ou=Sales,o=example.com,l=city,st=state,c=country"\
-a -d path -P prefix
-s 옵션은 요청한 인증서의 DN을 지정합니다. 대체로 인증 기관은 인증서 소유자를 정확하게 식별하기 위해 이 예제에 사용된 속성을 모두 필요로 합니다. 단계 9의 인증서 매핑 메커니즘을 통해 인증서 DN이 사용자 디렉토리 DN에 매핑됩니다.
path 및 prefix가 사용자의 인증서와 키 데이터베이스를 찾습니다. certutil 도구는 사용자에게 키 데이터베이스 암호를 입력하라는 메시지를 표시한 다음 PEM 인코딩된 텍스트 형식으로 PKCS #10 인증서 요청을 생성합니다.
- 해당 절차에 따라 인코딩된 인증서 요청을 파일에 저장하여 인증 기관으로 보냅니다. 예를 들어, 전자 우편으로 인증서 요청을 보내야 하는 경우도 있고 CA 웹 사이트에서 요청을 입력할 수 있는 경우도 있습니다.
- 요청을 보낸 후에는 CA에서 이 요청에 대한 응답으로 인증서를 보내줄 때까지 기다려야 합니다. 요청에 대한 응답 시간은 경우에 따라 달라집니다. 예를 들어, 회사 내부의 CA인 경우 하루나 이틀이면 요청에 대한 응답을 받을 수 있습니다. 회사 외부의 CA를 선택하면 요청에 대한 응답을 받을 때까지 몇 주가 걸릴 수도 있습니다.
- CA에서 응답을 보내면 새 인증서의 PEM 인코딩된 텍스트를 다운로드하거나 텍스트 파일에 복사합니다. 또한 인코딩된 인증서를 안전한 장소에 백업해 두어야 합니다. 시스템에 저장된 인증서 데이터가 손실될 경우 백업 파일을 사용하여 인증서를 다시 설치할 수 있습니다.
- 아래 명령을 실행하여 인증서 데이터베이스에 새 사용자 인증서를 설치합니다.
certutil -A -n "certificateName" -t "u,," -a -i certFile -d path -P prefix
여기서 certificateName은 이 인증서를 식별하기 위해 사용자가 지정한 이름이고 certFile은 PEM 형식의 PKCS #11 CA 인증서가 있는 텍스트 파일이며, path와 prefix는 단계 1과 같습니다.
또는 Netscape Communication를 통해 인증서 데이터베이스를 관리하는 경우 CA 웹 사이트에 있는 링크를 사용하여 인증서를 직접 설치할 수도 있습니다. 이 링크를 누른 다음 Communicator에서 제공하는 대화 상자에 따라 단계별로 수행합니다.
- 아래 명령을 실행하여 인증서 이진 복사본을 작성합니다.
certutil -L -n "certificateName" -d path -r > userCert.bin
여기서 certificateName 은 설치할 때 인증서에 지정한 이름이고 path 는 인증서 데이터베이스의 위치이며, userCert.bin은 이진 형식의 인증서가 포함될 출력 파일의 이름입니다.
- Directory Server에서 클라이언트 인증서를 소유한 사용자의 디렉토리 항목에 userCertificate 속성을 추가합니다.
- 콘솔을 통해 인증서를 추가하려면 다음을 수행합니다.
- Directory Server 콘솔의 최상위 "디렉토리" 탭의 디렉토리 트리에서 사용자 항목을 찾아 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 "일반 편집기로 편집"을 선택합니다.
- 일반 편집기에서 "속성 추가"를 누르고 팝업 대화 상자에서 userCertificate 속성을 선택합니다.
- 일반 편집기에서 새 userCertificate 필드를 찾습니다. 해당 "값 설정" 버튼을 눌러 이 속성에 이진 값을 설정합니다.
- "값 설정" 대화 상자에 단계 6에서 작성한 userCert.bin 파일의 이름을 입력하거나 "찾아보기"를 눌러 해당 찾습니다.
- "값 설정" 대화 상자에서 "확인"을 누른 다음 일반 편집기에서 "저장"을 누릅니다.
- 명령줄에서 인증서를 추가하려면 아래 예제와 같이 ldapmodify 명령을 사용합니다. 이 명령은 SSL을 사용하여 보안 연결을 통해 인증서를 보냅니다.
ldapmodify -h host -p securePort \
-D "uid=bjensen,dc=example,dc=com" -w bindPassword \
-Z -P /home/bjensen/.netscape/cert7.db
version: 1
dn: uid=bjensen,dc=example,dc=com
changetype: modify
add: userCertificate
userCertificate: < file:///path/userCert.bin
< 앞뒤의 공백은 중요하므로 표시된 대로 정확하게 사용해야 합니다. < 구문을 사용하여 파일 이름을 지정하려면 version: 1 줄에서 LDIF 명령문을 시작해야 합니다. ldapmodify 명령은 이 명령문을 처리할 때 속성 값을 지정된 파일의 전체 내용에서 읽은 값으로 설정합니다.
- 필요한 경우 사용자 인증서를 발급한 CA 인증서를 디렉토리 서버에 설치하여 트러스트합니다. 클라이언트 연결을 허용하려면 이 CA를 트러스트해야 합니다. "인증 기관 트러스트"를 참조하십시오.
- Sun ONE Server Console Server Management Guide의 Chapter 10, "Using Client Authentication"에 설명된 것처럼 디렉토리 서버에서 인증서 기반의 인증을 구성합니다. 이 절차에서는 서버가 LDAP 클라이언트를 통해 제공된 사용자 인증서를 해당 사용자 DN에 매핑할 수 있도록 certmap.conf 파일을 편집합니다.
certmap.conf 파일의 verifyCert 매개 변수가 on으로 설정되어 있는지 확인합니다. 이렇게 하면 서버가 사용자 항목에 동일한 인증서가 있는지 확인하여 사용자를 증명합니다.
인증서 기반의 클라이언트 인증에 대한 SSL 옵션 지정
ldapsearch 도구를 사용하여 SSL에서 인증서 기반의 클라이언트 인증을 수행하려는 경우 사용자는 자신의 인증서를 사용하는 여러 가지 명령줄 옵션을 지정해야 합니다. 보안 포트를 통해 SSL 연결을 구성하면 이 도구는 서버 인증서를 인증한 다음 사용자 인증서를 서버로 보냅니다.
아래 명령은 사용자가 Netscape Communicator에서 작성된 자신의 인증서 데이터베이스에 액세스하는 옵션을 지정하는 방법을 보여줍니다.
ldapsearch -h host -p securePort \
-Z -P /home/bjensen/.netscape/cert7.db \
-N "certificateName" \
-K /home/bjensen/.netscape/key3.db -W keyPassword \
-b "dc=example,dc=com" "(givenname=Richard)"-Z 옵션은 인증서 기반의 인증을 나타내고 certificateName은 보낼 인증서를 지정하며, -K 및 -W 옵션은 클라이언트 응용 프로그램이 인증서에 액세스하여 보낼 수 있도록 합니다. -D 및 -w 옵션을 지정하지 않으면 인증서 매핑을 통해 바인드 DN이 결정됩니다.
클라이언트에 SASL DIGEST-MD5 사용
클라이언트에 DIGEST-MD5 메커니즘을 사용하는 경우에는 사용자 인증서를 설치할 필요가 없습니다. 하지만 암호화된 SSL 연결을 사용하려면 "클라이언트에 서버 인증 구성"에 설명된 것처럼 서버 인증서를 트러스트해야 합니다.
영역 지정
영역은 선택한 인증 ID가 속하는 이름 공간을 정의합니다. DIGEST-MD5 인증에서는 특정 영역에 인증해야 합니다.
Directory Server는 시스템의 전체 호스트 이름을 DIGEST-MD5의 기본 영역으로 사용하며, nsslapd-localhost 구성 속성에 있는 호스트 이름의 소문자 값을 사용합니다.
영역을 지정하지 않으면 서버에서 제공하는 기본 영역이 사용됩니다.
환경 변수 지정
UNIX 환경에서 LDAP 도구가 DIGEST-MD5 라이브러리를 찾으려면 SASL_PATH 환경 변수를 설정해야 합니다. DIGEST-MD5 라이브러리는 SASL 플러그 인에 의해 동적으로 로드되는 공유 라이브러리이므로 Korn 셸의 경우처럼 SASL_PATH 변수를 다음과 같이 설정해야 합니다.
export SASL_PATH=serverRoot/lib/sasl
이 경로에서는 Directory Server가 LDAP 도구를 실행할 호스트에 설치되어 있다고 가정합니다.
Windows에서는 레지스트리 키 [HKEY_LOCAL_MACHINE\SOFTWARE\Carnegie Mellon\Project Cyrus\SASL Library\Available Plugins]에 SASL 라이브러리 경로가 지정됩니다. Directory Server를 동일한 호스트에 설치하면 이 키는 자동으로 serverRoot/lib/sasl로 설정되므로 수정할 필요가 없습니다.
ldapsearch 명령 예제
SSL을 사용하지 않고 DIGEST-MD5 클라이언트 인증을 수행할 수 있습니다. 아래 예제에서는 기본 DIGEST-MD5 ID 매핑을 사용하여 바인드 DN을 결정합니다.
ldapsearch -h host -p nonSecurePort -D "" -w bindPassword \
-o mech=DIGEST-MD5 [-o realm="hostFQDN"] \
-o authid="dn:uid=bjensen,dc=example,dc=com" \
-o authzid="dn:uid=bjensen,dc=example,dc=com" \
-b "dc=example,dc=com" "(givenname=Richard)"위 예제에서는 -o(소문자 o) 옵션을 사용하여 SASL 옵션을 지정합니다. Realm은 선택 사항이지만 지정할 경우 서버 호스트 시스템의 전체 도메인 이름을 제공해야 합니다. 프록시 작업용 authzid를 사용하지 않는 경우에도 authid와 authzid는 둘 다 있어야 하며 동일한 값을 가져야 합니다.
authid 값은 ID 매핑에 사용되는 Principal입니다. authid는 dn: 접두어가 사용되고 뒤에 디렉토리의 유효한 사용자 DN이 오거나 u: 접두어가 사용되고 뒤에 클라이언트에서 결정되는 문자열이 오는 것이 좋습니다. 이렇게 하면 "DIGEST-MD5 ID 매핑"에 설명된 매핑을 사용할 수 있습니다.
일반적으로 SSL 연결을 사용하여 보안 포트를 통해 암호화를 제공하고 DIGEST-MD5를 사용하여 클라이언트 인증을 제공합니다. 아래 예제에서는 SSL을 통해 동일한 작업을 수행합니다.
ldapsearch -h host -p securePort \
-Z -P /home/bjensen/.netscape/cert7.db \
-N "certificateName" -W keyPassword \
-o mech=DIGEST-MD5 [-o realm="hostFQDN"] \
-o authid="dn:uid=bjensen,dc=example,dc=com" \
-o authzid="dn:uid=bjensen,dc=example,dc=com" \
-b "dc=example,dc=com" "(givenname=Richard)"이 예제에서 -N 및 -W 옵션은 ldapsearch 명령에 필요하며 클라이언트 인증에는 사용되지 않습니다. 대신, 서버는 authid 값의 Principal에 대해 다시 DIGEST-MD5 ID 매핑을 수행합니다.
클라이언트에 커버로스 SASL GSSAPI 사용
클라이언트에 GSSAPI 메커니즘을 사용하는 경우 사용자 인증서를 설치할 필요는 없지만 커버로스 V5 보안 시스템은 구성해야 합니다. 또한 암호화된 SSL 연결을 사용하려면 "클라이언트에 서버 인증 구성"에 설명된 것처럼 서버 인증서를 트러스트해야 합니다.
클라이언트 호스트에 커버로스 V5 구성
LDAP 클라이언트를 실행할 호스트 시스템에 커버로스 V5를 구성해야 합니다.
- 설치 지침에 따라 커버로스 V5를 설치합니다. SEAM(Sun Enterprise Authentication Mechanism) 1.0.1 클라이언트 소프트웨어를 설치하는 것이 좋습니다.
- 커버로스 소프트웨어를 구성합니다. SEAM을 사용하면/etc/krb5에 있는 파일을 구성하여 kdc 서버를 설정하고, 기본 영역 및 커버로스 시스템에 필요한 기타 구성을 정의할 수 있습니다.
- 필요한 경우 /etc/gss/mech 파일을 수정하여 kerberos_v5를 첫 번째 값으로 표시합니다.
커버로스 인증에 대한 SASL 옵션 지정
- GSSAPI를 사용하는 클라이언트 응용 프로그램을 사용하기 전에 먼저 아래 명령을 실행하여 커버로스 보안 시스템을 사용자 Principal로 초기화해야 합니다.
kinit userPrincipal
userPrincipal은 사용자의 SASL ID입니다(예: bjensen@example.com).
- 아래의 ldapsearch 도구 예제에서는 -o(소문자 o) 옵션을 사용하여 커버로스 사용에 대한 SASL 옵션을 지정하는 방법을 보여줍니다.
ldapsearch -h host -p securePort \
-Z -P /home/bjensen/.netscape/cert7.db \
-N "certificateName" -W keyPassword \
-o mech=GSSAPI [-o realm="example.com" \
-o authid="bjensen@example.com" \
-o authzid="bjensen@example.com"] \
-b "dc=example,dc=com" "(givenname=Richard)"
이 예제에서 -N 및 -W 옵션은 ldapsearch 명령에 필요하며 클라이언트 인증에는 사용되지 않습니다. realm, authid 및 authzid는 kinit 명령으로 초기화된 커버로스 캐시에 있기 때문에 생략할 수 있습니다. 프록시 작업용 authzid를 사용하지 않는 경우에도 authid와 authzid 값은 둘 다 있어야 하며 동일한 값을 가져야 합니다. authid 값은 ID 매핑에 사용되는 Principal입니다. 자세한 내용은 "GSSAPI ID 매핑"을 참조하십시오.