Directory Server 계획 및 설계

Directory Server는 글로벌 디렉터리 서비스를 제공하므로 다양한 애플리케이션에 정보를 제공합니다. Directory Server는 다른 애플리케이션과 함께 번들된 독점 데이터베이스를 통합하려고 하는 대신 동일한 정보를 관리하는 단일 솔루션입니다.

LDAP에서는 클라이언트 애플리케이션 및 서버가 서로 통신하는 데 사용하는 공통 언어를 제공합니다. LDAP는 ISO X.500 표준에서 설명하는 DAP(Directory Access Protocol)의 "Lightweight" 버전입니다.

DAP는 확장 가능하고 강력한 정보 프레임워크를 통해 모든 애플리케이션에 액세스할 수 있지만 관리 비용이 높습니다. DAP는 인터넷 표준 프로토콜이 아니며 복잡한 디렉터리-나밍 규칙이 있는 통신 계층을 사용합니다.

LDAP는 관리 비용을 절감하면서 DAP의 최상의 기능을 유지합니다. LDAP는 TCP/IP 및 간소화된 인코딩 방법을 통해 실행되는 오픈 디렉터리 액세스 프로토콜을 사용합니다. 데이터 모델을 유지하고 하드웨어 및 네트워크 인프라에 대한 모드 투자를 위해 수백만 개의 항목을 지원할 수 있습니다.

Directory Server는 다중 스레드 애플리케이션입니다. 즉, 동일한 네트워크를 통해 여러 클라이언트가 동시에 서버에 바인딩할 수 있습니다. 디렉터리 서비스가 더 많은 수의 항목 또는 지리적으로 분산된 클라이언트를 포함하도록 확장되면 이 서비스에는 네트워크 주변의 전략적 위치에 배치된 여러 디렉터리 서버도 포함됩니다.

Directory Server의 서버 프런트 엔드는 LDAP over TCP/IP 및 LDAP over Unix 소켓 (LDAPI)을 사용하여 디렉터리 클라이언트 애플리케이션과의 통신을 관리합니다.

Directory Server는 클라이언트가 연결에 TLS를 사용하도록 협상하는지에 따라 TLS(Transport Layer Security)를 사용하여 보안(암호화) 연결을 설정할 수 있습니다. 클라이언트가 발급된 인증서인 경우 Directory Server는 TLS를 사용하여 클라이언트가 서버에 액세스할 수 있는 권한이 있는지 확인할 수 있습니다. 또한 TLS는 메시지 무결성 검사, 디지털 서명 및 서버 간 상호 인증과 같은 기타 보안 활동을 수행하는 데 사용됩니다.

디렉터리 트리(DIT)는 대부분의 파일 시스템에서 사용하는 트리 모델을 미러링합니다. 설치하는 동안 Directory Server는 기본 디렉터리 트리를 만듭니다.

그림 1.1. 기본 디렉터리 트리

설치 후 디렉터리에는 다음 루트 접미사 및 하위 트리가 포함됩니다.

디렉터리 설치와 관련된 데이터를 추가하여 기본 디렉터리 트리를 확장할 수 있습니다. 디렉터리 트리에 대한 자세한 내용은 디렉터리 트리 설계를 참조하십시오.

LDAP Data Interchange Format(LDIF) 은 디렉터리 항목을 설명하는 표준 텍스트 기반 형식입니다. 항목은 LDIF 파일의 여러 줄로 구성되며 조직의 사람 또는 네트워크의 프린터와 같은 오브젝트에 대한 정보를 포함합니다.

항목에 대한 정보는 일련의 속성 및 해당 값으로 표시됩니다. 각 항목에는 항목이 설명하는 오브젝트 유형을 지정하고 포함된 추가 특성 집합을 정의하는 오브젝트 클래스 속성이 있습니다. 각 속성은 항목의 특정 특성을 설명합니다.

예를 들어 항목에 조직의 사람을 나타내는 organizationPerson 오브젝트 클래스가 있을 수 있습니다. 이 오브젝트 클래스는 givenName 및 telephoneNumber 특성을 지원합니다. 이러한 속성에 할당된 값은 항목이 제공하는 사람의 이름과 전화 번호를 정의합니다.

Directory Server는 또한 서버에서 계산한 읽기 전용 작동 속성을 사용합니다. 관리자는 액세스 제어 및 기타 서버 기능에 대해 이러한 운영 속성을 수동으로 설정할 수 있습니다.

디렉터리 트리의 일부를 별도의 데이터베이스에 저장하면 디렉터리에서 클라이언트 요청을 병렬로 처리할 수 있습니다. 성능 향상을 위해 데이터베이스를 다른 머신에 저장할 수도 있습니다. 디렉터리의 일부를 연결하기 위해 Directory Server는 데이터베이스 링크 및 체인을 사용합니다. 데이터베이스 링크 및 체인에 대한 자세한 내용은 Directory Server에서 참조 사용을 참조하십시오.

특성으로 개인 또는 자산에 대한 유용한 정보를 항목에 추가할 수 있습니다. 예를 들면 다음과 같습니다.

서버 관리 이외의 용도로 Directory Server를 사용하려면 디렉터리에 저장할 다른 유형의 정보를 계획해야 합니다. 예를 들어 다음 정보 유형을 포함할 수 있습니다.

Red Hat Directory Server는 클라이언트 애플리케이션이 읽기 및 경우에 따라 업데이트되는 대규모 데이터 볼륨을 관리하지만 Directory Server는 이미지 또는 기타 미디어와 같은 구조화되지 않은 큰 개체를 처리하도록 설계되지 않았습니다. 이러한 오브젝트는 파일 시스템에서 유지 관리해야 합니다. 그러나 디렉터리는 FTP, HTTP 및 기타 URL 유형을 사용하여 이러한 유형의 애플리케이션에 대한 포인터를 저장할 수 있습니다.

디렉터리에 액세스하는 애플리케이션 및 이러한 애플리케이션의 데이터 요구 사항은 디렉터리 콘텐츠 계획을 안내합니다. 디렉터리를 사용하는 다양한 일반적인 애플리케이션은 다음과 같습니다.

디렉터리를 사용할 애플리케이션을 평가할 때 각 애플리케이션에서 사용하는 정보 유형을 고려하십시오. 다음 표에서는 애플리케이션의 예와 애플리케이션에서 사용하는 정보를 제공합니다.

표 2.1. 애플리케이션 데이터 요구 예

각 애플리케이션에서 사용하는 애플리케이션 및 정보를 식별하면 둘 이상의 애플리케이션에서 사용하는 데이터 유형을 파악할 수 있습니다. 계획의 이 단계는 디렉터리의 데이터 중복성을 방지하고 데이터 디렉터리 종속 애플리케이션에 필요한 데이터를 명확하게 표시할 수 있습니다.

다음 요인은 디렉터리에서 유지 관리되는 데이터 유형과 정보를 디렉터리로 마이그레이션할 때 최종 결정에 영향을 미칩니다.

디렉터리에 포함할 모든 데이터를 확인하려면 기존 데이터 저장소에 대한 설문 조사를 수행합니다. 설문 조사에는 다음이 포함되어야 합니다.

설문 조사 중에 아래 표와 같이 엔터프라이즈의 모든 정보 소스를 식별하는 매트릭스를 개발하십시오.

표 2.2. 정보 소스 예

디렉터리에 포함할 데이터를 다음과 같은 방식으로 특성화합니다.

디렉터리에 포함할 데이터에서 일반적인 특성을 찾습니다. 이렇게 하면 디렉터리 스키마 설계에 설명된 스키마 설계 단계에서 시간을 절약할 수 있습니다.

디렉터리 데이터를 특징으로 하는 아래 표를 고려하십시오.

표 2.3. 디렉터리 데이터 특성

제공하는 서비스 수준은 디렉터리 지원 애플리케이션에 의존하는 사용자의 기대치에 따라 다릅니다. 각 애플리케이션에 필요한 서비스 수준을 확인하려면 애플리케이션이 사용되는 방법과 시기를 결정합니다.

디렉터리가 진화하면 이 디렉터리는 프로덕션에서 미션 크리티컬 수준에 이르기까지 다양한 서비스 수준을 지원해야 할 수 있습니다. 디렉토리 배포 후 서비스 수준을 올리기 어렵기 때문에 초기 설계가 향후 요구 사항을 충족하는지 확인합니다.

예를 들어 총 실패 위험을 제거하려면 여러 공급업체가 동일한 데이터를 처리하는 다중 공급 업체 구성을 사용합니다.

데이터 공급자는 데이터를 제공하는 서버입니다. 여러 위치에 동일한 정보를 저장하면 데이터 무결성이 저하됩니다. 데이터 공급자는 여러 위치에 저장된 모든 정보가 일관되고 정확한지 확인합니다. 다음 시나리오에는 데이터 공급자가 필요합니다.

다중 제공 복제를 사용하면 Directory Server에 여러 서버의 기본 정보 사본을 포함할 수 있습니다. 여러 공급업체가 변경 로그를 유지하고 충돌을 안전하게 해결합니다. 변경을 수락하고 데이터를 복제본 또는 소비자 서버에 복제할 수 있는 제한된 수의 공급업체 서버를 구성할 수 있습니다. 복제 토폴로지에서 소비자 서버 또는 복제본 서버는 공급자 서버 또는 허브 서버에서 업데이트를 수신합니다. 여러 데이터 공급자 서버는 서버가 오프라인 상태가 되면 안전한 페일오버를 제공합니다. 다중 제공 복제에 대한 자세한 내용은 복제 프로세스 설계를 참조하십시오.

동기화를 사용하면 Directory Server 사용자, 그룹, 속성 및 암호를 Microsoft Active Directory 사용자, 그룹, 속성 및 암호와 통합할 수 있습니다. 두 개의 디렉터리 서비스가 있는 경우 동일한 정보를 관리할지 여부, 공유할 정보의 양 및 데이터를 제공할 서비스를 결정합니다. 데이터를 관리하고 동기화 프로세스에서 다른 서비스에서 항목을 추가, 업데이트 또는 삭제할 수 있도록 하나의 애플리케이션을 선택하는 것이 좋습니다.

디렉터리와 간접적으로 통신하는 애플리케이션을 사용하는 경우 데이터 공급자 소스를 고려하십시오. 데이터 변경 프로세스를 가능한 한 간단하게 유지합니다. 데이터 조각을 관리하기 위한 위치를 결정한 후 동일한 위치를 사용하여 여기에 포함된 다른 모든 데이터를 관리합니다. 단일 위치에서 데이터베이스의 동기화가 손실될 때 문제 해결을 단순화합니다.A single place simplifies troubleshooting when databases lose synchronization across the enterprise.

다음과 같은 방법으로 데이터 공급을 제공할 수 있습니다.

데이터의 주요 복사본을 유지 관리하는 방법은 특정 디렉터리의 필요에 따라 다릅니다. 그러나 항상 유지 관리를 간단하고 일관되게 유지합니다. 예를 들어 여러 위치에서 데이터를 관리한 다음 경쟁하는 애플리케이션 간에 데이터를 자동으로 교환하지 마십시오. 이렇게 하면 업데이트가 손실되고 관리 오버헤드가 증가합니다.

예를 들어 디렉터리는 LDAP 디렉터리와 인사 리소스 데이터베이스 모두에 저장된 직원 홈 전화 번호를 관리합니다. 인적 리소스 애플리케이션은 LDAP를 사용할 수 있으며 LDAP 디렉토리에서 인사 데이터베이스로 데이터를 자동으로 전송할 수 있으며 그 반대의 경우도 마찬가지입니다.

LDAP 디렉토리 및 인적 리소스 데이터베이스 모두에서 해당 직원 전화 번호 변경 사항을 관리하려고 하면 전화 번호가 변경된 마지막 위치가 다른 데이터베이스의 정보를 덮어씁니다. 이는 데이터를 작성한 마지막 애플리케이션에 올바른 정보가 있는 경우에만 허용됩니다.

해당 정보가 오래된 경우(예: 인적 리소스 데이터가 백업에서 복원되었기 때문에) LDAP 디렉터리의 올바른 전화 번호가 삭제됩니다.

데이터 소유권 은 데이터가 최신 상태인지 확인하는 사람 또는 조직을 나타냅니다. 데이터 설계 단계에서 디렉터리에 데이터를 쓸 수 있는 사람을 결정합니다. 다음은 데이터 소유권을 결정하기 위한 몇 가지 일반적인 전략입니다.

여러 개인에서 동일한 정보에 대한 쓰기 권한이 필요할 수 있습니다. 예를 들어 정보 시스템 또는 디렉터리 관리 그룹에는 직원 암호에 대한 쓰기 권한이 필요할 수 있습니다. 또한 직원에게는 자신의 암호에 대한 쓰기 액세스 권한이 필요합니다. 여러 사용자가 동일한 정보에 액세스할 수 있지만 이 그룹을 작게 유지하여 데이터 무결성을 보장하십시오.

데이터 소유권을 확인한 후 각 데이터를 읽을 수 있는 사용자를 결정합니다. 예를 들어, 직원 홈 전화번호를 디렉터리에 저장할 수 있습니다. 이 데이터는 직원 관리자 및 인적 자원 부서를 포함한 여러 사용자에게 유용할 수 있습니다. 직원은 확인 목적으로 이 정보를 읽을 수 있어야 합니다. 그러나 집의 연락처 정보는 민감한 것으로 간주 될 수 있습니다.

디렉터리에 저장된 모든 정보에 대해 다음을 고려하십시오.

디렉터리 데이터의 각 부분에 대해 이러한 결정을 내릴 때 디렉터리에 대한 보안 정책을 정의합니다. 이러한 결정은 사이트의 특성과 사이트에서 이미 사용 가능한 보안에 따라 달라집니다. 예를 들어 방화벽이 있거나 인터넷에 직접 액세스할 수 없으므로 디렉터리가 인터넷에 직접 배치된 것보다 익명 액세스를 지원하는 것이 더 안전합니다. 또한 일부 정보는 액세스를 적절하게 제한하기 위해 액세스 제어 및 인증 조치만 필요할 수 있습니다. 다른 민감한 정보는 저장 시 데이터베이스 내에서 암호화해야 할 수 있습니다.

대부분의 국가의 데이터 보호 법률은 기업이 개인 정보를 유지하고 액세스하는 방법을 관리합니다. 예를 들어, 법률에 따라 정보에 대한 익명 액세스를 금지하거나 사용자가 해당 정보를 나타내는 항목에서 정보를 보고 편집할 수 있도록 요청할 수 있습니다. 조직의 법률 부서에 문의하여 디렉터리 배포가 기업이 운영하는 국가의 데이터 보호법을 준수하는지 확인하십시오.

보안 정책 생성 및 구현 방법은 보안 디렉토리 설계에 자세히 설명되어 있습니다.

복제에서 소비자 서버 또는 복제본 서버는 공급자 서버 또는 허브 서버에서 업데이트를 수신합니다.

Directory Server의 스키마 형식은 LDAP 프로토콜의 버전 3을 기반으로 합니다. 이 프로토콜을 사용하려면 디렉터리 클라이언트 애플리케이션이 프로그래밍 방식으로 스키마를 검색하고 동작을 조정할 수 있도록 LDAP를 통해 스키마를 게시해야 합니다. cn=schema 항목에서 Directory Server의 글로벌 스키마 세트를 찾을 수 있습니다.

디렉터리 서버 스키마는 전용 개체 클래스 및 특성을 사용하므로 LDAPv3 스키마와 다릅니다. 또한 스키마 항목이 원래 정의된 위치를 설명하는 X-ORIGIN 389 Directory Server 라는 스키마 항목의 개인 필드를 사용합니다.

표준 LDAPv3 스키마에 스키마 항목을 정의할 때 X-ORIGIN 389 Directory Server 필드는 RFC 2252를 나타냅니다. Directory Server 사용을 위해 Red Hat에서 항목을 정의한 경우 X-ORIGIN 389 Directory Server 필드에 값 389 Directory Server 가 포함됩니다. 예를 들어 표준 person 오브젝트 클래스는 스키마에 표시됩니다.

# objectclasses: ( 2.5.6.6 NAME 'person' DESC 'Standard Person Object Class' SUP top
MUST (objectclass $ sn $ cn) MAY (description $ seeAlso $ telephoneNumber $ userPassword)
X-ORIGIN 'RFC 2252' )

이 스키마 항목 상태는 다음과 같습니다.

특성에는 이름 또는 고정 번호와 같은 특정 데이터 요소가 포함됩니다. Directory Server는 데이터를 특정 정보와 관련된 설명적인 스키마 속성인 attribute-data 쌍으로 나타냅니다. 이를 attribute-value assertions 또는 AVA 라고도 합니다.

예를 들어 디렉터리는 사용자 이름과 같은 데이터를 표준 속성이 있는 쌍에 저장할 수 있습니다. Babs Jensen 이라는 이름의 항목에는 attribute-data 쌍 cn: Babs Jensen 이 있습니다.

전체 항목은 일련의 특성 데이터 쌍으로 표시됩니다. Babs Jensen의 전체 항목은 다음과 같습니다.

dn: uid=bjensen,ou=people,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Babs Jensen
sn: Jensen
givenName: Babs
givenName: Barbara
mail: bjensen@example.com

스키마의 각 속성 정의에는 다음 정보가 포함되어 있습니다.

cn 속성 정의는 다음과 같이 스키마에 표시됩니다.

attributetypes: ( 2.5.4.3 NAME 'cn' DESC 'commonName Standard Attribute'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

특성의 구문을 사용하여 속성에 저장할 수 있는 값의 형식을 정의할 수 있습니다. Directory Server는 모든 표준 특성 구문을 지원합니다.

개체 클래스는 사람 또는 성정기 시스템과 같은 실제 개체를 나타냅니다. 관련 정보를 그룹화하는 데 사용됩니다. 오브젝트 클래스를 사용하기 전에 스키마에서 오브젝트 클래스 및 해당 속성을 식별해야 합니다. 디렉터리는 기본적으로 표준 오브젝트 클래스 목록을 인식합니다.

각 디렉터리 항목은 하나 이상의 오브젝트 클래스에 속합니다. 항목의 스키마에 식별된 오브젝트 클래스를 배치하면 해당 항목에 특정 특성 값 세트가 있을 수 있으며 다른 더 작은 필수 특성 값 세트가 있어야 함을 디렉터리 서버에 알립니다.

오브젝트 클래스 정의에서 다음 정보를 사용할 수 있습니다.

스키마의 표준 person 개체 클래스입니다.

objectclasses: ( 2.5.6.6 NAME 'person' DESC 'Standard Person Object Class' SUP top
     MUST (objectclass $ sn $ cn) MAY (description $ seeAlso $ telephoneNumber $ userPassword)
     X-ORIGIN 'RFC 2252' )

사이트 설문 조사에서 식별된 데이터를 기존 디렉터리 스키마에 매핑할 수 있습니다. 이 프로세스에는 다음 단계가 포함됩니다.

경우에 따라 데이터 조각이 여러 오브젝트를 설명할 수 있습니다. 디렉터리 스키마에 차이점을 기록해야 하는지 확인합니다. 예를 들어, 전화 번호는 직원의 전화 번호와 회의실의 전화 번호를 설명할 수 있습니다. 이러한 종류의 데이터가 디렉터리 스키마의 다른 개체로 간주되어야 하는지 여부를 결정합니다.

각 LDAP 오브젝트 클래스 또는 속성에 대해 고유 이름 및 OID(오브젝트 ID)를 할당해야 합니다. 스키마를 정의할 때 요소에는 조직에 고유한 기본 OID가 필요합니다. 다른 계층 구조를 추가하여 특성 및 개체 클래스에 대한 새 분기를 만듭니다. 스키마에서 OID를 가져오고 할당하려면 다음 단계를 수행해야 합니다.

다음과 같은 두 가지 방법으로 새 오브젝트 클래스를 생성할 수 있습니다.

두 가지 방법을 혼합할 수 있습니다. 예를 들어 예제 DateOfBirth ,example PreferredOS,exampleBuildingFloor 및 exampleVicePresident 속성을 생성하려고 합니다. 간단한 솔루션은 이러한 속성의 일부 하위 집합을 허용하는 여러 개체 클래스를 만드는 것입니다.

새 오브젝트 클래스는 다음과 같이 LDAPv3 스키마 형식으로 표시됩니다.

objectclasses: ( 2.16.840.1.117370.999.1.2.3 NAME 'examplePerson' DESC 'Example Person Object Class'
     SUP inetorgPerson MAY (exampleDateOfBirth $ examplePreferredOS) )

objectclasses: ( 2.16.840.1.117370.999.1.2.4 NAME 'exampleOrganization' DESC 'Organization Object Class'
     SUP organization MAY (exampleBuildingFloor $ exampleVicePresident) )

또는 이러한 모든 특성을 허용하는 단일 오브젝트 클래스를 만들고 이를 필요한 모든 항목과 함께 사용할 수 있습니다. 단일 오브젝트 클래스는 다음과 같습니다.

objectclasses: (2.16.840.1.117370.999.1.2.5 NAME 'exampleEntry' DESC 'Standard Entry Object Class' SUP top
     AUXILIARY MAY (exampleDateOfBirth $ examplePreferredOS $ exampleBuildingFloor $ exampleVicePresident) )

새로운 exampleEntry 오브젝트 클래스는 A Cryostat ILIARY 로 표시됩니다. 즉, 구조적인 오브젝트 클래스에 관계없이 모든 항목에 사용할 수 있습니다.

조직 환경에 따라 새 오브젝트 클래스를 구성할 수 있습니다. 새 개체 클래스의 구현을 결정할 때는 다음을 고려하십시오.

애플리케이션 호환성과 장기 유지 관리 모두에 표준 특성을 사용해야 합니다. 기본 디렉터리 스키마에 이미 존재하는 특성을 검색하고 새 개체 클래스와 함께 사용하거나 Directory Server 스키마 가이드를 확인해야 합니다. 그러나 표준 스키마에 필요한 모든 정보가 포함되어 있지 않은 경우 새 특성과 새 개체 클래스를 추가합니다.

예를 들어 사람 항목에는 기본적으로 사람, organizationalPerson 또는 inetOrgPerson 개체 클래스보다 많은 속성이 필요할 수 있습니다. 생년월일을 저장하기 위한 표준 Directory Server 스키마 내에는 특성이 없습니다. 새 특성을 생성하고 설정할 수 있습니다. dateOfBirth 는 새 보조 개체 클래스 내에서 허용되는 속성인 examplePerson:

attributetypes: ( dateofbirth-oid NAME 'dateofbirth' DESC 'For employee birthdays'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Example defined')

objectclasses: ( 2.16.840.1.117370.999.1.2.3 NAME 'examplePerson' DESC 'Example Person Object Class'
     SUP inetorgPerson MAY (exampleDateOfBirth $ cn) X-ORIGIN 'Example defined')

Directory Server에 기본적으로 포함된 스키마 요소는 삭제할 수 없습니다. 사용되지 않는 스키마 요소는 운영 또는 관리 오버헤드를 나타내지 않습니다. 표준 LDAP 스키마의 일부를 삭제하면 나중에 Directory Server 및 기타 디렉터리 지원 애플리케이션의 호환성 문제가 발생할 수 있습니다.

그러나 사용되지 않는 사용자 지정 스키마 요소를 삭제할 수 있습니다. 스키마에서 오브젝트 클래스 정의를 제거하기 전에 오브젝트 클래스를 사용하여 각 항목을 수정합니다. 먼저 정의를 제거하면 오브젝트 클래스를 사용하는 항목이 나중에 수정되지 않을 수 있습니다. 알 수 없는 개체 클래스 값이 항목에서 제거되지 않으면 스키마가 수정된 항목도 실패합니다.

Directory Server에 대한 사용자 지정 스키마 파일을 생성하여 Directory Server와 함께 제공된 99user.ldif 파일 외에도 사용할 수 있습니다. 이러한 스키마 파일에는 조직과 관련된 새로운 사용자 지정 속성 및 개체 클래스가 있습니다. 새 스키마 파일은 스키마 디렉터리 /etc/dirsrv/slapd-instance_name/schema/ 에 있습니다. 모든 표준 특성 및 개체 클래스는 사용자 지정 스키마 요소가 로드된 후에만 로드됩니다.

사용자 지정 스키마 파일을 만든 후 다음과 같은 방식으로 모든 서버에 스키마 변경 사항을 배포할 수 있습니다.

이러한 사용자 지정 스키마 파일을 모든 서버에 복사하지 않으면 공급자 서버의 스키마를 변경하는 경우에만 스키마 정보가 소비자 서버에 복제됩니다. 스키마 정의가 아직 없는 소비자 서버에 복제되면 99user.ldif 파일에 저장됩니다.

다음 제안 사항은 호환 가능하고 관리하기 쉬운 사용자 정의 스키마를 정의하는 데 도움이 됩니다.

스키마 파일 이름 지정

사용자 지정 스키마 파일의 이름을 99user.ldif 보다 숫자 및 알파벳순으로 낮게 지정합니다. 99user.ldif 파일에 는 'user defined'의 X-ORIGIN 값이 있는 속성이 포함되어 있습니다. Directory Server는 모든 '사용자 정의' 스키마 요소를 가장 높은 이름이 지정된 파일에 쓰고 숫자 및 알파벳순으로 작성합니다. 스키마 파일 이름이 99zzz.ldif 이고 스키마가 업데이트되면 'user defined'의 X-ORIGIN 값이 있는 모든 속성이 99zzz.ldif 파일에 기록됩니다. 결과적으로 중복 정보가 포함된 LDIF 파일 두 개 모두 삭제되고 99zzz.ldif 파일 의 일부 정보는 삭제될 수 있습니다.

사용자 지정 스키마 파일 이름을 지정할 때 다음 이름 지정 형식을 사용합니다 .yourName.ldif.

'user defined'를 원본으로 사용

LDAP를 통해 스키마를 추가할 때 '사용자 정의' 가 디렉터리 서버에서 내부적으로 사용되므로 사용자 지정 스키마 파일의 X-ORIGIN 필드에 'user defined'를 사용하지 마십시오.

사용자 지정 스키마 요소가 수동으로 99user.ldif 에 직접 추가되는 경우 X-ORIGIN 값으로 'user defined'를 사용합니다. 다른 X-ORIGIN 값이 설정된 경우 서버는 간단히 이를 덮어쓸 수 있습니다.

'사용자 정의' 값의 X-ORIGIN 을 사용하면 Directory Server에서 99user.ldif 파일에서 스키마 정의를 제거할 수 없습니다.

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

attributetypes: ( exampleContact-oid NAME 'exampleContact'
DESC 'Example Corporate contact'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
X-ORIGIN 'Example defined')

Directory Server가 스키마 항목을 로드하면 다음과 같이 표시됩니다.

attributetypes: ( exampleContact-oid NAME 'exampleContact'
DESC 'Example Corporate contact'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
X-ORIGIN ('Example defined' 'user defined') )

오브젝트 클래스 이전의 속성 정의

새 스키마 요소를 추가하면 개체 클래스에서 사용하기 전에 모든 특성을 정의합니다. 특성 및 개체 클래스는 동일한 스키마 파일에 정의할 수 있습니다.

단일 파일에서 스키마 정의

가장 최근에 생성된 스키마를 로드할 때 서버가 이전 정의를 덮어쓰지 않도록 각 사용자 지정 특성 또는 개체 클래스를 스키마 파일에 정의합니다. 서버는 먼저 스키마를 숫자순으로 로드한 다음 알파벳순으로 로드합니다. 중복 파일에 스키마를 사용하지 않도록 하는 방법을 결정합니다.

스키마 검사는 모든 신규 또는 수정된 디렉터리 항목이 스키마 규칙을 준수하는지 확인합니다. 기본적으로 디렉터리는 스키마 검사를 활성화합니다. 규칙이 위반되면 디렉터리는 요청된 변경을 거부합니다.

스키마 확인이 활성화된 경우 오브젝트 클래스에 정의된 필수 및 허용되는 속성에 주의해야 합니다. 항목의 개체 클래스 정의에 따라 필요하지 않거나 허용되지 않은 항목에 특성을 추가할 때 Directory Server에서 개체 클래스 위반 메시지를 반환할 수 있습니다.

예를 들어 organizationalPerson 오브젝트 클래스를 사용하도록 항목이 정의된 경우 항목에 공통 이름(cn) 및 surname(sn) 속성이 필요합니다. 이러한 속성의 값은 항목을 만들 때 설정해야 합니다. 또한 전화 번호,uid,StreetAddress 및 userPassword 와 같은 설명적 특성을 포함하여 항목에서 선택적으로 사용할 수 있는 속성의 긴 목록이 있습니다.

구문 검증은 Directory Server에서 특성 값이 해당 속성에 필요한 구문과 일치하는지 확인합니다. 예를 들어 구문 검증에서는 새 telephoneNumber 속성에 해당 값에 유효한 전화 번호가 있는지 확인할 수 있습니다. 기본적으로 활성화되어 있습니다.

선택적으로 구문 위반에 대한 경고 메시지를 기록하도록 구문 검증에 대한 추가 설정을 구성한 다음 수정을 거부하거나 수정 프로세스가 성공하도록 허용할 수 있습니다.

새 속성 값이 추가되면 구문 검증에서 LDAP 작업을 확인합니다. 복제와 같은 데이터베이스 작업을 통해 추가된 기존 특성 또는 특성을 처리하지 않습니다. 기존 속성은 dsconf schema validate-syntax 명령을 사용하여 검증할 수 있습니다.

이 기능은 필수 형식이 없는 바이너리 구문 및 비표준 구문을 제외한 모든 특성 구문의 유효성을 검사합니다. 구문은 덜 엄격한 RFC 1779 또는 RFC 2253 에 대해 검증되는 DN을 제외하고 RFC 4514 에 대해 검증됩니다.

LDAP 스키마를 사용하여 속성 값으로 데이터를 배치할 수 있습니다. 그러나 LDAP 클라이언트 애플리케이션 및 디렉터리 사용자에게 적합한 형식을 선택하여 디렉터리 트리에 일관되게 데이터를 저장하는 것이 중요합니다.

LDAP 프로토콜 및 디렉터리 서버를 사용하여 RFC 2252 에 지정된 데이터 형식으로 데이터를 나타낼 수 있습니다. 예를 들어 전화 번호에 대한 올바른 LDAP 형식은 다음 두 ITU-T 권장 사항 문서에 정의되어 있습니다.

또 다른 예로, postalAddress 속성에는 달러 기호($)를 줄 구분 기호로 사용하는 다중 줄 문자열 형식의 속성 값이 있습니다. 올바르게 포맷된 디렉터리 항목이 다음과 같이 표시됩니다.

postalAddress: 1206 Directory Drive$Pleasant View, MN$34200

변경 사항은 디렉터리 스키마를 편집할 때 변경 로그에 기록됩니다. 복제 중에 변경 사항이 복제되고 변경 사항이 복제되는 경우 변경 로그를 스캔합니다. 복제 스키마에서 일관성을 유지 관리하면 오류 없이 복제를 계속할 수 있습니다.

복제된 환경에서 일관된 스키마를 유지 관리하려면 다음 사항을 고려하십시오.

접미사는 디렉터리 트리의 루트에 있는 항목의 이름이며 디렉터리 데이터는 그 아래에 저장됩니다. 디렉터리에는 접미사가 두 개 이상 포함될 수 있습니다. 공통 루트가 없는 두 개 이상의 정보 트리가 있는 경우 여러 접미사를 사용할 수 있습니다. 기본적으로 표준 Directory Server 배포에는 여러 접미사가 포함되어 있으며, 하나는 구성 정보 및 디렉터리 스키마와 같은 내부 디렉터리 작업에 필요한 데이터에 대해 데이터를 저장하는 데 사용됩니다.

4.2.1.2. 여러 접미사 이름

링크 복사

디렉터리의 각 접미사는 고유한 디렉터리 트리입니다. 별도의 데이터베이스 Directory Server에 저장된 여러 디렉터리 트리를 만들 수 있습니다.

예를 들어 example_a 및 example_b 에 대한 별도의 접미사를 생성하여 별도의 데이터베이스에 저장할 수 있습니다.

리소스 제한에 따라 단일 서버 또는 여러 서버에 데이터베이스를 저장할 수 있습니다.

플랫 또는 계층 트리 구조를 사용할지 여부를 결정합니다. 디렉터리 트리를 최대한 플랫으로 만듭니다. 그러나 복제를 준비할 때 또는 액세스 제어를 설정할 때 정보가 여러 데이터베이스에 분할되는 경우 일정 양의 계층 구조가 중요할 수 있습니다.

트리 구조에는 다음 단계와 고려 사항이 포함됩니다.

디렉터리 트리의 계층을 설계한 후 구조 내의 항목의 이름을 지정할 때 사용할 속성을 결정해야 합니다. 하나 또는 여러 특성 값을 선택할 때 상대 고유 이름 (RDN)을 형성합니다. RDN은 DN의 왼쪽 부분이며, 해당 부분에 대해 선택한 속성은 이름 지정 속성입니다. naming 속성은 항목의 고유한 이름을 설정합니다. 예를 들어 DN uid=bjensen,ou=people,dc=example,dc=com 에는 RDN uid=bjensen.

선택한 속성은 이름 지정에 따라 다릅니다.

항목의 이름을 지정할 때는 다음을 고려하십시오.

항목을 생성할 때 항목 내에 RDN을 정의합니다. 항목 내에 정의된 RDN을 사용하면 항목을 보다 쉽게 배치할 수 있습니다. 이는 검색에서 실제 DN을 기반으로 하지 않고 항목 자체에 저장된 속성 값을 기반으로 하는 항목을 찾기 때문입니다.

특성 이름에는 의미가 있으므로 나타내는 항목 유형과 일치하는 속성 이름을 사용하십시오. 예를 들어 조직을 나타내는 데 l (로케이션)을 사용하거나 조직 단위를 나타내는 c (국가)를 사용하지 마십시오.

항목 이름은 디렉터리 트리 구조를 정의합니다. 각 분기 지점은 계층에 새 링크를 생성합니다.

                                                                  dc=example,dc=com  =>  root suffix
                                                        ou=People,dc=example,dc=com  =>  org unit
                                          st=California,ou=People,dc=example,dc=com  =>  state/province
                          l=Mountain View,st=California,ou=People,dc=example,dc=com  =>  city
           ou=Engineering,l=Mountain View,st=California,ou=People,dc=example,dc=com  =>  org unit
uid=jsmith,ou=Engineering,l=Mountain View,st=California,ou=People,dc=example,dc=com  =>  leaf entry

항목의 이름 지정 특성, 항목 RDN을 변경하면 modrdn 작업을 수행합니다. 이 수정 작업은 디렉터리 트리 내에서 항목을 이동합니다. 리프 항목( 자식이 없는 항목)의 경우 modrdn 작업만 RDN 부분만 변경하므로 상위 항목은 동일하게 유지됩니다.

하위 트리 항목의 경우 modrdn 작업에서는 하위 트리 항목 자체의 이름을 바꾸고 하위 트리 아래의 모든 하위 항목의 DN 구성 요소를 변경합니다.

하위 트리의 이름을 바꾸는 것과 유사한 작업이 한 하위 트리에서 다른 하위 트리로 항목을 이동하는 것입니다. 확장된 이러한 유형의 modrdn 작업은 동일한 이름인 경우에도 항목의 이름을 동시에 바꾸고 항목을 부모 간에 이동하는 newsuperior 특성을 설정합니다.

Directory Server는 entryrdn.db 인덱스를 사용하여 새로운 정상 및 하위 트리 이름 변경 작업을 수행합니다. Directory Server는 각 항목을 자체 링크, 상위 링크 및 하위 링크로 식별합니다. entryrdn.db 인덱스는 부모와 하위 항목을 항목의 속성으로 제공하고 모든 항목을 전체 DN이 아닌 고유 ID와 RDN으로 설명합니다.

entryrdn.db 인덱스의 형식은 다음과 같습니다.

numeric_id:RDN => self link
     ID: ; RDN: "rdn"; NRDN: normalized_rdn P:RDN => parent link
     ID: ; RDN: "rdn"; NRDN: normalized_rdn C:RDN => child link
     ID: #; RDN: "rdn"; NRDN: normalized_rdn

예를 들어 ou=people 하위 트리에는 dc=example,dc=com 상위 및 uid=jsmith 하위 항목이 있습니다. entryrdn.db 인덱스에는 다음과 같은 내용이 있습니다.

4:ou=people
   ID: 4; RDN: "ou=people"; NRDN: "ou=people"
P4:ou=people
   ID: 1; RDN: "dc=example,dc=com"; NRDN: "dc=example,dc=com"
C4:ou=people
   ID: 10; RDN: "uid=jsmith"; NRDN: "uid=jsmith"

이름 변경 작업을 수행할 때는 다음을 고려하십시오.

그룹은 사용자 컬렉션입니다. Directory Server에는 고유한 멤버만 있는 인증서 그룹, URL 그룹 및 고유 그룹과 같이 허용되는 멤버십 유형을 반영하는 여러 그룹 유형이 있습니다. 각 유형의 그룹(예: groupOfUniqueNames )과 같은 해당 멤버 특성(예: uniqueMember )을 정의합니다.

그룹 유형은 멤버 유형을 식별합니다. 그룹 구성은 Directory Server가 그룹에 멤버를 추가하는 방법에 따라 달라집니다. Directory Server에는 다음 두 가지 그룹 유형이 있습니다.

그룹은 항목에 대한 작업을 수행하지 않지만 LDAP 클라이언트는 작업을 수행하기 위해 그룹을 관리할 수 있습니다.

4.3.1.2. 그룹에 자동으로 새 항목 추가

링크 복사

그룹 멤버십에 따라 암호 정책, 액세스 제어 목록 및 기타 규칙을 적용할 수 있습니다. 그룹을 사용하면 디렉터리에 정책을 일관되고 안정적으로 적용할 수 있습니다.

새 항목이 생성될 때 새 항목을 자동으로 할당하면 Directory Server가 관리자 작업 없이 해당 항목에 즉시 적절한 정책과 기능을 적용할 수 있습니다.

Automembership 플러그인을 사용하면 정적 그룹이 동적 그룹처럼 작동할 수 있습니다. Automembership 플러그인은 항목 특성, 디렉터리 위치 및 정규식에 따라 일련의 규칙을 사용하여 사용자를 지정된 그룹에 자동으로 할당합니다.

LDAP 검색 필터와 일치하는 항목을 다른 속성의 값에 따라 다른 그룹에 추가해야 하는 인스턴스가 있을 수 있습니다. 예를 들어 IP 주소 또는 물리적 위치에 따라 시스템을 다른 그룹에 추가해야 합니다. 또는 직원 ID 번호에 따라 사용자를 다른 그룹에 배치해야 합니다.

automember 정의는 중첩된 항목 세트로, Auto membership 플러그인 컨테이너, automember 정의, 해당 정의에 대한 정규식 조건입니다.

참고

Directory Server는 항목이 Directory Server에 새로 추가된 경우에만 그룹에 항목을 자동으로 할당합니다. automember 규칙을 충족하도록 수정한 기존 항목 또는 항목의 경우 수정 작업을 실행하여 적절한 그룹 멤버십을 할당합니다.

역할은 정적 그룹 및 동적 그룹으로 작동합니다. 그룹을 사용하면 Directory Server에서 그룹 항목에 항목을 멤버로 추가합니다. 역할로 Directory Server는 역할 속성을 항목에 추가한 다음 해당 속성을 사용하여 역할 항목의 멤버를 자동으로 식별합니다.

역할을 사용하면 다음과 같은 방법으로 사용자를 구성할 수 있습니다.

관리 역할은 정적 그룹으로 수행할 수 있는 모든 작업을 수행할 수 있습니다. 동적 그룹으로 필터링하는 것과 유사하게 필터링된 역할을 사용하여 역할 멤버를 필터링할 수 있습니다. 역할은 구현에 더 유연하고 클라이언트의 복잡성을 줄이기 때문에 그룹보다 쉽게 사용할 수 있습니다.

역할 유형을 사용하여 명시적으로 또는 동적으로 멤버를 지정할 수 있습니다. Directory Server는 다음 유형의 역할을 지원합니다.

하나의 작업에서 전체 항목 그룹을 활성화하거나 비활성화할 수 있습니다. 해당 역할이 속한 역할을 비활성화하여 역할 멤버를 일시적으로 비활성화할 수 있습니다.

역할을 비활성화하면 사용자는 역할 항목을 사용하여 서버에 계속 바인딩할 수 있습니다. 그러나 사용자는 이 역할에 속하는 항목을 사용하여 서버에 바인딩할 수 없습니다. 비활성화된 역할에 속하는 항목에는 nsAccountLock 속성이 true 로 설정되어 있습니다.

중첩된 역할을 비활성화하면 중첩된 역할 내의 모든 역할의 멤버인 경우 사용자가 서버에 바인딩할 수 없습니다. 중첩된 역할의 직접 또는 간접 멤버인 역할에 속하는 모든 항목은 nsAccountLock 을 true 로 설정합니다. 중첩의 어느 시점에서나 중첩 역할을 비활성화하면 해당 아래의 모든 역할과 사용자가 비활성화됩니다.

역할과 그룹은 동일한 목표를 달성할 수 있습니다. 관리되는 역할은 정적 그룹이 수행할 수 있는 모든 작업을 수행할 수 있지만 필터링된 역할은 동적 그룹과 동일한 방식으로 멤버를 필터링하고 식별할 수 있습니다. 역할과 그룹 모두 장단점이 있습니다. 역할 또는 그룹 또는 혼합 사용 여부를 결정하는 것은 요구 사항과 서버 리소스의 균형을 조정하는 데 따라 달라집니다.

역할은 클라이언트 측의 복잡성을 줄입니다. 역할을 사용하면 클라이언트 애플리케이션에서 항목에서 nsRole 작동 속성을 검색하여 역할 멤버십을 확인할 수 있습니다. 이 다중 값 속성은 항목이 속한 모든 역할을 식별합니다. 클라이언트 애플리케이션 관점에서 멤버십을 확인하는 방법은 균일하며 서버 측에서 수행됩니다.

그러나 역할에는 서버 복잡성이 증가해야 합니다. 역할을 평가하는 것은 서버가 클라이언트 애플리케이션에 대해 작업을 수행하기 때문에 그룹을 평가하는 것보다 리소스 집약적입니다.

그룹은 효과적으로 사용하기 위해 더 스마트하고 복잡한 클라이언트가 필요합니다. 예를 들어 애플리케이션 관점에서 동적 그룹은 그룹 멤버 목록을 제공하기 위해 서버에서 지원하지 않습니다. 대신 애플리케이션은 그룹 정의를 검색한 다음 필터를 실행합니다. 사용자 항목에는 적절한 플러그인을 구성하는 경우에만 그룹 멤버십 정보가 포함됩니다.

아래의 LDIF 항목은 위치를 기반으로 하는 가상 뷰 계층 구조를 보여줍니다. dc=example,dc=com 아래에 있고 view 설명에 맞는 모든 항목이 위치별로 구성된 이 보기에 표시됩니다.

dn: ou=Location Views,dc=example,dc=com
objectclass: top
objectclass: organizationalUnit
objectclass: nsView
ou: Location Views
description: views categorized by location


dn: ou=Sunnyvale,ou=Location Views,dc=example,dc=com
objectclass: top
objectclass: organizationalUnit
objectclass: nsView
ou: Sunnyvale
nsViewFilter: (l=Sunnyvale)
description: views categorized by location


dn: ou=Santa Clara,ou=Location Views,dc=example,dc=com
objectclass: top
objectclass: organizationalUnit
objectclass: nsView
ou: Santa Clara
nsViewFilter: (l=Santa Clara)
description: views categorized by location


dn: ou=Cupertino,ou=Location Views,dc=example,dc=com
objectclass: top
objectclass: organizationalUnit
objectclass: nsView
ou: Cupertino
nsViewFilter: (l=Cupertino)
description: views categorized by location

ou=Location Views,dc=example,dc=com 에 기반한 하위 트리 검색은 필터 (l=Sunnyvale), (l= Santa Cextensiona) 또는 (l=Cupertino) 와 일치하는 dc= example,dc=com 아래의 모든 항목을 반환합니다. 그러나 한 수준 검색에서는 모든 적격 항목이 세 하위 뷰에 있기 때문에 하위 뷰 항목이 아닌 항목을 반환하지 않습니다.

ou=Location Views,dc=example,dc=com view 항목 자체에는 필터가 포함되어 있지 않습니다. 이 기능은 보기에 포함된 항목을 추가로 제한해야 하는 요구 없이 계층적 조직을 용이하게 합니다. 모든 보기에서 필터를 생략할 수 있습니다.

예제 필터는 매우 간단하지만 사용하는 필터는 필요에 따라 복잡할 수 있습니다. 뷰에 포함되어야 하는 항목 유형을 제한할 수 있습니다. 예를 들어 이 계층 구조에 사람 항목만 포함하도록 제한하려면 필터 값 (objectclass=organizationalperson) 을 사용하여 ou=Location Views,dc=example,dc=com 에 nsfilter 특성을 추가합니다.

필터가 있는 각 뷰는 모든 하위 뷰의 콘텐츠를 제한하지만 필터가 있는 하위 뷰도 상위 콘텐츠를 제한합니다. 예를 들어 위에서 언급한 새 필터와 먼저 상위 뷰 ou=Location Views 를 생성하면 조직 오브젝트 클래스가 포함된 모든 항목이 있는 뷰가 생성됩니다. 하위 뷰가 추가되어 항목을 추가로 제한할 때 하위 보기에 이제 하위 보기가 표시되는 항목이 상위 보기에서 제거됩니다. 이는 가상 DIT 뷰가 기존 DIT의 동작을 에뮬레이션하는 방법을 보여줍니다.

가상 DIT 보기는 기존 DIT의 동작을 에뮬레이션하지만 기존 DIT는 할 수 없는 작업을 수행할 수 있습니다: 항목이 두 개 이상의 위치에 표시될 수 있습니다. 예를 들어 Entry B 를 192.0.2. View 및 Sunnyvale 모두와 연결하려면 Sunnyvale 값을 location 속성에 추가하고 항목이 두 보기 모두에 표시됩니다.

인터넷 도메인 이름을 디렉터리 트리의 루트 항목으로 사용합니다. 그런 다음 엔터프라이즈가 작업을 수행하는 각 국가의 루트 항목 아래에 트리를 분기합니다.

다른 국가를 표현하려면 l (location) 특성을 사용합니다.

그러나 c (country) 속성은 각 국가 분기를 나타낼 수도 있습니다.

LDAP에서는 DN의 속성 순서에 제한이 없습니다.

인터넷 서비스 공급자(ISP)는 해당 디렉토리를 통해 여러 엔터프라이즈를 지원할 수 있습니다. Cryostat는 각 고객을 고유한 엔터프라이즈로 간주하고 그에 따라 디렉터리 트리를 설계해야 합니다. 보안상의 이유로 각 고객에 대한 고유한 접미사와 독립적인 보안 정책을 포함하는 고유한 디렉터리 트리를 제공합니다.

각 고객에게 별도의 데이터베이스를 할당하고 이러한 데이터베이스를 별도의 서버에 저장합니다. 각 디렉터리 트리를 자체 데이터베이스에 배치하면 다른 고객에 영향을 주지 않고 각 디렉터리 트리의 데이터를 백업하고 복원할 수 있습니다.

또한 파티션은 디스크 경합으로 인한 성능 문제와 디스크 중단이 잠재적으로 영향을 미칠 수 있는 고객 수를 줄입니다.

Directory Server는 LDAP Database Manager(LDBM)에 데이터를 저장합니다. 각 데이터베이스는 할당된 모든 데이터를 포함하는 큰 파일 세트로 구성됩니다.

디렉터리 트리의 다른 부분을 다른 데이터베이스에 저장할 수 있습니다. 예를 들어 디렉터리 트리는 다음과 같은 방식으로 표시될 수 있습니다.

그림 5.1. 디렉터리 트리 예

예제의 디렉터리는 다음 세 개의 하위 요소로 구성됩니다.

다음과 같은 방식으로 3개의 하위 데이터베이스로 데이터를 저장할 수 있습니다.

그림 5.2. 별도의 데이터베이스에 접미사 데이터 저장

디렉터리 트리를 여러 데이터베이스로 나눌 때 이러한 데이터베이스를 여러 서버에 배포하여 각 서버의 워크로드를 줄일 수 있습니다. 예를 들어 두 서버(서버A 및 서버 B)에 세 개의 데이터베이스(DB1,DB2 및 DB3)를 저장할 수 있습니다.

그림 5.3. 별도의 서버 간에 접미사 데이터베이스 분할

서버 A 에는 DB1 및 DB2 가 포함되어 있으며 서버 B 에는 DB3 가 포함되어 있습니다.

Directory Server는 전체 디렉터리 서비스를 중지하지 않고 동적으로 데이터베이스 추가를 지원합니다.

데이터베이스에는 특정 접미사(디렉터리 트리의 일부)에 대한 데이터가 포함되어 있습니다. Directory Server에서는 루트 접미사 또는 sub-suffix를 만들 수 있습니다.

예를 들어 ExampleCom은 접미사를 생성하여 다음과 같은 방식으로 디렉터리 데이터의 배포를 나타냅니다.

그림 5.4. ExampleCom의 디렉터리 트리

ExampleCom은 다음과 같은 방식으로 네 가지 데이터베이스에 디렉터리 트리를 분배합니다.

그림 5.5. 여러 데이터베이스에 디렉터리 트리 분산

4개의 데이터베이스에는 다음 접미사에 대한 데이터가 포함되어 있습니다.

5.2.2.1. 여러 루트 접미사 사용

링크 복사

디렉터리 서비스에는 루트 접미사가 두 개 이상 포함될 수 있습니다. 예를 들어, Rackspace라는 이름은 example_a.com 과 example_b.com 과 같은 여러 웹 사이트를 호스팅합니다. ExampleISP에는 다음과 같은 디렉터리 구조가 있습니다.

그림 5.6. 여러 루트 접미사가 있는 디렉터리 트리

Cryostat는 다음 루트 접미사를 생성합니다.

• DC=exampleISP,dc=com 과 다음 항목에 대한 데이터가 있습니다.

  • dc=exampleISP,dc=com
  • o=ISP,dc=exampleISP,dc=com
  • o=internet,dc=exampleISP,dc=com
  • ou=groups,dc=exampleISP,dc=com

• O =example_a.com 과 다음 항목에 대한 데이터가 있습니다.

  • o=example_a.com,o=ISP,dc=exampleISP,dc=com
  • ou=people,o=example_a.com,o=ISP,dc=exampleISP,dc=com
  • ou=groups,o=example_a.com,o=ISP,dc=exampleISP,dc=com

• O =example_b.com 과 다음 항목에 대한 데이터가 있습니다.

  • o=example_b.com,o=ISP,dc=exampleISP,dc=com
  • ou=people,o=example_b.com,o=ISP,dc=exampleISP,dc=com
  • ou=groups,o=example_b.com,o=ISP,dc=exampleISP,dc=com

Directory Server는 LDAP URL 형식의 모든 추천을 반환합니다. LDAP URL에는 다음 정보가 포함되어 있습니다.

예를 들어 클라이언트 애플리케이션은 dc=example,dc=com 분기에서 이름이 Jensen 인 항목을 검색합니다. 그러나 디렉터리 트리의 일부는 유럽 서버에 저장됩니다. 추천은 클라이언트 애플리케이션에 다음 LDAP URL을 반환합니다.

ldap://europe.example.com:389/ou=people,l=europe,dc=example,dc=com

이 추천은 클라이언트 애플리케이션이 포트 389에서 host europe.example.com 에 연락하고 European branch ou=people,l=europe,dc=example,dc=com 을 통해 새 검색을 제출하도록 지시합니다.

사용하는 LDAP 클라이언트 애플리케이션에 따라 추천 처리 방법이 결정됩니다. 일부 클라이언트 애플리케이션은 참조된 서버에서 작업을 자동으로 재시도합니다. 다른 클라이언트 애플리케이션은 추천 정보를 사용자에게 반환합니다. Red Hat Directory Server에서 제공하는 대부분의 LDAP 클라이언트 애플리케이션(예: 명령줄 유틸리티)은 자동으로 추천을 따릅니다. Directory Server는 초기 디렉터리 요청에 제공된 동일한 바인딩 자격 증명을 사용하여 서버에 액세스합니다.

대부분의 클라이언트 애플리케이션은 제한된 수의 추천 또는 홉 을 따릅니다. 추천 횟수에 대한 제한은 클라이언트 애플리케이션이 디렉터리 조회 요청을 완료하는 데 걸리는 시간을 줄이고 순환 참조 패턴으로 인한 중단 프로세스를 제거하는 데 도움이 됩니다.

연결된 서버 또는 데이터베이스에 요청된 데이터가 포함되지 않은 경우 Directory Server는 클라이언트에 대한 기본 추천을 반환합니다.

예를 들어 클라이언트는 uid=bjensen,ou=people,dc=example,dc=com 디렉터리 항목을 요청합니다.

그러나 서버는 dc=europe,dc=example,dc=com 접미사 아래에 저장된 항목만 관리합니다. 디렉터리는 dc=example,dc=com 접미사 아래에 저장된 항목에 대해 연결할 수 있는 정보를 사용하여 클라이언트에 대한 참조를 반환합니다. 그런 다음 클라이언트는 적절한 서버에 연결하여 원래 요청을 다시 제출합니다.

서버 및 접미사 수준에서 기본 추천을 구성할 수 있습니다.

디렉터리 서버는 기본 참조 외에도 디렉터리 항목 또는 디렉터리 트리를 특정 LDAP URL과 연결하는 스마트 추천을 지원합니다. 따라서 Directory Server는 다음 중 하나로 클라이언트 요청을 전달할 수 있습니다.

기본 참조와 달리 Directory Server는 구성 파일이 아닌 디렉터리에 스마트 참조를 저장합니다.

예를 들어, ExampleCom의 미국 사무실용 디렉터리에는 ou=people,dc=example,dc=com 디렉토리 분기 포인트가 포함되어 있습니다.

이 분기의 요청을 ExampleCom의 유럽 사무실의 ou=people 분기로 리디렉션하려면 ou=people 항목 자체에서 스마트 추천을 지정할 수 있습니다. 스마트 추천에는 다음과 같은 값이 있습니다.

ldap://europe.example.com:389/ou=people,dc=example,dc=com

미국 디렉터리의 ou=people 분기에 대한 요청은 다음과 같은 방식으로 유럽 디렉터리로 리디렉션됩니다.

그림 5.7. 스마트 추천을 사용하여 요청 리디렉션

동일한 메커니즘을 사용하여 다른 네임스페이스를 사용하는 다른 서버로 쿼리를 리디렉션할 수 있습니다. 예를 들어, ExampleCom의 이탈리아 사무실에서 근무하는 직원은 미국에서 ExampleCom 직원의 전화 번호에 대한 유럽 디렉터리 서비스에 요청합니다. Directory Server는 다음과 같은 추천을 반환합니다.

ldap://america.example.com:389/ou=people,dc=example,dc=com

다음 다이어그램은 다른 네임스페이스에 대한 참조가 작동하는 방법을 보여줍니다.

그림 5.8. 쿼리를 다른 서버 및 네임스페이스로 리디렉션

마지막으로 동일한 서버에서 여러 접미사를 제공할 때 한 네임스페이스의 쿼리를 동일한 서버에서 제공된 다른 네임스페이스로 리디렉션할 수 있습니다. 예를 들어 로컬 서버의 o=example,c=us 에 대한 모든 쿼리를 dc=example,dc=com 으로 리디렉션하려면 o=example,c=us 항목에서 스마트 추천 ldap:///dc=example,dc=com 을 설정합니다. LDAP URL의 세 번째 슬래시는 URL이 동일한 서버를 가리키는 것을 나타냅니다.

스마트 추천을 사용하기 전에 다음 사항을 고려하십시오.

그림 5.9. 순환 추천 패턴

체인은 추천과 다르게 액세스 제어를 평가합니다. 추천을 사용하면 클라이언트 항목(바인드 DN)이 모든 대상 서버에 있어야 합니다. 연결에서 클라이언트 항목이 모든 대상 서버에 있을 필요는 없습니다.

5.6.1.1. 추천을 사용하여 검색 요청 수행

링크 복사

다음 다이어그램에서는 추천을 사용하여 서버에 대한 클라이언트 요청을 보여줍니다.

그림 5.11. 추천을 사용하여 클라이언트 요청을 서버로 전송

검색 요청이 다음과 같은 방식으로 수행됩니다.

1. 클라이언트 애플리케이션은 먼저 서버 A 와 바인딩합니다.
2. 서버 A 에는 사용자 이름과 암호를 제공하는 클라이언트에 대한 항목이 포함되어 있어 바인딩 수락 메시지를 반환합니다. 추천이 작동하려면 클라이언트 항목이 서버 A 에 있어야 합니다.
3. 클라이언트 애플리케이션에서 서버 A 로 작업 요청을 보냅니다.
4. 그러나 서버 A 에는 요청된 정보가 포함되어 있지 않습니다. 대신 Server A 는 서버 B에 연결하도록 지시하는 클라이언트 애플리케이션에 대한 참조를 반환합니다.
5. 그러면 클라이언트 애플리케이션이 서버 B 로 bind 요청을 보냅니다. 성공적으로 바인딩하려면 서버 B 에도 클라이언트 애플리케이션에 대한 항목도 포함되어야 합니다.
6. 바인딩에 성공하고 클라이언트 애플리케이션에서 검색 작업을 Server B 로 다시 제출할 수 있습니다.

이 방법을 사용하려면 서버 B 에 서버 A 에서 클라이언트 항목의 복제 사본이 있어야 합니다.

5.6.1.2. 체인을 사용하여 검색 요청 수행

링크 복사

연결을 통해 서버 간에 클라이언트 항목을 복제하는 문제를 해결할 수 있습니다.

그림 5.12. 연결 을 사용하여 클라이언트 요청을 서버로 전송

검색 요청이 다음과 같은 방식으로 수행됩니다.

1. 클라이언트 애플리케이션이 서버 A 와 바인딩되고 서버 A 는 사용자 이름과 암호가 올바른지 확인합니다.
2. 서버 A 에는 클라이언트 애플리케이션에 해당하는 항목이 포함되어 있지 않습니다. 대신 클라이언트의 실제 항목이 포함된 서버 B 에 대한 데이터베이스 링크가 포함되어 있습니다. 서버 A 는 서버 B 에 바인딩 요청을 보냅니다.
3. 서버 B 는 서버 A 에 수락 응답을 보냅니다.
4. 서버 A 는 데이터베이스 링크를 사용하여 클라이언트 애플리케이션 요청을 처리합니다. 데이터베이스 링크는 서버 B 에 있는 원격 데이터 저장소에 연결하여 검색 작업을 처리합니다.

연결된 시스템에서 클라이언트 애플리케이션에 해당하는 항목을 클라이언트가 요청하는 데이터와 동일한 서버에 배치할 필요가 없습니다. 다음 다이어그램은 클라이언트 검색 요청을 완료하는 데 두 개의 체인 서버를 사용하는 방법에 대해 설명합니다.

그림 5.13. 두 개의 다른 서버를 사용하여 클라이언트 인증 및 데이터 검색

검색 요청이 다음과 같은 방식으로 수행됩니다.

1. 클라이언트 애플리케이션이 서버 A 에 바인딩되고 서버 A 는 사용자 이름과 암호가 올바른지 확인합니다.
2. 서버 A 에는 클라이언트 애플리케이션에 해당하는 항목이 포함되어 있지 않습니다. 대신 클라이언트의 실제 항목이 포함된 서버 B 에 대한 데이터베이스 링크가 포함되어 있습니다. 서버 A 는 서버 B 에 바인딩 요청을 보냅니다.
3. 서버 B 는 서버 A 에 수락 응답을 보냅니다.
4. 그러면 서버 A 가 다른 데이터베이스 링크를 사용하여 클라이언트 요청을 처리합니다. 데이터베이스 링크는 검색 작업을 처리하기 위해 서버 C 에 있는 원격 데이터 저장소에 연결합니다.

Directory Server는 다음 인덱스 유형을 지원합니다.

인덱스를 사용하여 검색 성능을 향상시킬 때 다음 사항을 고려하십시오.

복제 구현을 고려할 때 다음과 같은 기본 질문에 대답하십시오.

Directory Server가 복제를 구현하는 방법에 대한 이해를 제공하는 개념에 대해 알아봅니다.

데이터 일관성은 복제된 데이터베이스 내용이 지정된 시간에 서로 얼마나 밀접하게 일치하는지 나타냅니다. 공급자는 소비자를 업데이트해야 하는 시기를 결정하고 복제를 시작합니다. 소비자를 초기화한 후에만 복제를 시작할 수 있습니다.

Directory Server는 항상 특정 요일 또는 요일에 대한 복제본을 동기화된 상태로 유지하거나 업데이트를 예약할 수 있습니다.

지속적으로 동기화된 복제본

지속적으로 동기화된 복제본은 데이터 일관성을 개선하지만 자주 업데이트되므로 네트워크 트래픽을 늘립니다.

다음과 같은 경우 지속적으로 동기화된 복제본을 사용합니다.

소비자 업데이트 예약

디렉터리에 낮은 수준의 데이터 일관성이 있을 수 있고 네트워크 트래픽에 미치는 영향을 낮추려는 경우 업데이트를 예약하도록 선택합니다.

다음의 경우 예약된 업데이트를 사용합니다.

다중 제공 복제의 데이터 일관성

다중 제공 복제가 있는 경우, 각 공급 업체마다 복제본이 지속적으로 동기화되어도 저장된 데이터에 차이가 있을 수 있으므로 각 공급 업체마다 일관적인 복제본이 있습니다.

느슨한 일관성의 주요 이유는 다음과 같습니다.

단일 제공 복제 시나리오에서는 공급자 서버가 디렉토리 데이터(읽기-쓰기 복제본)의 주요 복사본을 유지 관리하고 이 데이터의 업데이트를 하나 이상의 소비자 서버로 보냅니다. 모든 디렉터리 수정은 공급자 서버의 읽기-쓰기 복제본에서 수행되며 소비자 서버에는 데이터의 읽기 전용 복제본이 포함됩니다.

공급자 서버는 공급자 복제본의 모든 변경 사항을 기록하는 변경 로그를 유지합니다.

다음 다이어그램은 단일 공급 업체 복제 시나리오를 보여줍니다.

그림 6.1. 단일 공급 업체 복제

단일 공급자 서버가 관리할 수 있는 총 소비자 서버 수는 네트워크의 속도와 매일 수정된 총 항목 수에 따라 달라집니다.

다중 제공 복제 환경에서는 동일한 정보의 주요 사본이 여러 서버에 존재할 수 있으며 디렉터리 데이터를 다른 위치에서 동시에 업데이트할 수 있습니다. 각 서버에서 발생하는 변경 사항은 다른 서버에 복제되므로 각 서버가 공급업체와 소비자 역할을 합니다.

여러 서버에서 동일한 데이터를 수정하면 복제 충돌이 발생합니다. 충돌 해결 절차를 사용하여 Directory Server는 최근 변경 사항을 유효한 작업으로 사용합니다.

멀티 공급 업체 환경에서 각 공급 업체는 소비자와 다른 공급 업체를 가리키는 복제 계약이 있어야합니다. 예를 들어 두 공급업체, provider A 및 provider B 와 소비자 C 및 소비자 D 두 개로 복제를 구성합니다. 또한 하나의 공급업체가 하나의 소비자만 업데이트한다고 결정합니다. 공급업체 A에서 공급업체 B 및 소비자 C 를 가리키는 복제 계약을 생성합니다. 공급업체 B에서 공급업체 A 및 소비자 D 를 가리키는 복제 계약을 생성합니다. 다음 다이어그램에서는 복제 계약을 보여줍니다.

그림 6.2. 두 공급업체를 통한 멀티 공급 업체 복제

많은 공급업체를 사용하려면 다양한 복제 계약을 생성해야 합니다. 또한 각 공급업체는 서로 다른 토폴로지로 구성할 수 있으므로 디렉터리 서버 환경에 20개의 디렉토리 트리와 스키마 차이가 있을 수 있습니다. 다른 많은 변수는 토폴로지 선택에 직접적인 영향을 미칠 수 있습니다.

공급업체는 다른 모든 공급 업체 또는 일부 공급 업체에 업데이트를 보낼 수 있습니다. 업데이트가 모든 공급업체에 전송되면 변경 사항이 더 빨라지고 전체 시나리오가 장애 허용성이 향상됩니다. 그러나 공급업체 구성의 복잡성이 증가하고 높은 네트워크 및 높은 서버 수요를 도입합니다. 공급업체의 하위 집합에 업데이트를 보내는 것은 네트워크 및 서버 로드를 구성하고 줄이는 것이 훨씬 쉽지만 여러 서버 오류가 발생하면 데이터 손실 위험이 증가합니다.

6.2.2.1. 완전히 연결된 메시 토폴로지

링크 복사

다음 다이어그램은 4개의 공급업체 서버가 다른 모든 공급자 서버에 데이터를 복제하는 완전히 연결된 메시 토폴로지를 보여줍니다. 하나의 복제 계약에는 하나의 공급업체와 하나의 소비자 간의 관계를 설명하기 때문에 총 4개의 공급자 서버 간에 복제 계약이 존재합니다.

20개의 공급업체가 있는 경우 총 20개의 공급업체(각각 19개의 공급업체)에 380개의 복제 계약을 생성해야 합니다.

두 개 이상의 서버가 동시에 실패할 가능성이 적거나 특정 공급 업체 간의 연결이 작으면 부분적으로 연결된 토폴로지를 사용하는 것이 좋습니다.

6.2.2.2. 부분적으로 연결된 토폴로지

링크 복사

다음 다이어그램은 각 공급자 서버가 두 공급자 서버에 데이터를 복제하는 토폴로지를 보여줍니다. 이전 예제 토폴로지에 비해 4개의 공급업체 서버 간에는 8개의 복제 계약만 존재합니다.

계단식 복제 시나리오에서는 허브 서버가 공급자 서버에서 업데이트를 수신하고 이러한 업데이트를 소비자 서버로 보냅니다. 허브 서버는 일반적인 소비자 서버와 같은 읽기 전용 복제본을 보유하고 있으며 일반적인 공급자 서버와 같은 변경 로그를 유지 관리하기 때문에 하이브리드입니다.

Hub 서버는 공급자 데이터를 소비자에게 전달하고 디렉터리 클라이언트의 업데이트 요청을 공급자에게 참조합니다.

다음 다이어그램에서는 계단식 복제 시나리오를 보여줍니다.

그림 6.3. 계단식 복제 시나리오

다음 다이어그램은 각 서버에 복제본을 구성하는 방법과 변경 로그를 유지 관리하는 서버(읽기-쓰기 또는 읽기 전용)를 보여줍니다.

그림 6.4. cascading 복제의 복제 트래픽 및 변경 로그

계단식 복제는 다음과 같은 경우에 유용합니다.

복제 시나리오를 네트워크 및 디렉터리 환경의 요구 사항에 맞게 결합할 수 있습니다. 일반적인 조합 중 하나는 계단식 구성과 함께 다중 제공 구성을 사용하는 것입니다.

다음 다이어그램은 혼합 시나리오에 대한 예제 토폴로지를 보여줍니다.

그림 6.5. Multi-supplier 및 cascading 복제

복제 전략을 정의하는 데 도움이 되는 네트워크 품질 및 사용법에 대한 정보를 수집합니다.

복제에는 리소스가 필요합니다. 복제 전략을 정의할 때 다음 리소스 요구 사항을 고려하십시오.

다중 제공 토폴로지에서 공급업체는 디렉터리 편집의 변경 로그, 업데이트된 항목에 대한 상태 정보, 삭제된 항목에 대한 tombstone 항목을 포함하여 복제에 필요한 추가 로그를 유지 관리합니다. 이러한 로그 파일은 매우 커질 수 있으므로 디스크 공간을 불필요하게 사용하지 않도록 이러한 파일을 정기적으로 정리해야 합니다.

각 서버에서 다음 특성을 사용하여 복제 환경에서 복제 로그 유지 관리를 구성할 수 있습니다.

단일 서버가 실패할 때 디렉터리를 사용할 수 없는 경우 복제를 사용하여 디렉터리를 사용할 수 없습니다. 최소한 로컬 디렉터리 트리를 하나 이상의 백업 서버에 복제합니다. 내결함성을 위해 복제하는 빈도는 요구 사항에 따라 다릅니다. 그러나 이 결정은 디렉터리에서 사용하는 하드웨어 및 네트워크의 품질에 따라 결정됩니다. 신뢰할 수 없는 하드웨어에는 더 많은 백업 서버가 필요합니다.

다음 전략을 선택하여 디렉터리를 사용할 수 없도록 할 수 있습니다.

LDAP 클라이언트 애플리케이션은 일반적으로 하나의 LDAP 서버만 검색하도록 구성됩니다. 다른 DNS 호스트 이름에 있는 LDAP 서버를 통해 회전할 사용자 지정 클라이언트 애플리케이션이 없는 경우 Directory Server의 단일 DNS 호스트 이름을 확인하도록 LDAP 클라이언트 애플리케이션만 구성할 수 있습니다. 따라서 DNS 라운드 로빈 또는 네트워크 정렬을 사용하여 백업 디렉터리 서버에 대한 장애 조치를 제공해야 할 수 있습니다.

네트워크의 품질 및 데이터가 미션 크리티컬한지 여부에 따라 로컬 가용성에 복제를 사용해야 할 수도 있습니다.

다음과 같은 이유로 로컬 가용성에 복제를 사용하십시오.

디렉터리 데이터를 복제하는 주요 이유 중 하나는 네트워크의 워크로드 균형을 유지하고 디렉터리 성능을 개선하는 것입니다.

디렉터리 항목은 일반적으로 1KB 크기이므로 모든 디렉터리 검색은 네트워크 로드에 약 1KB를 추가합니다. 디렉터리 사용자가 하루에 10개의 디렉토리 검색을 수행하는 경우 모든 디렉터리에 대한 증가된 네트워크 로드는 매일 약 10KB입니다. 느리거나 많이 로드되거나 신뢰할 수 없는 WAN이 있는 경우 디렉터리 트리를 로컬 서버로 복제해야 할 수 있습니다.

그러나 로컬에서 사용 가능한 데이터가 복제로 인한 증가된 네트워크 로드 비용의 가치가 있는지 확인합니다. 전체 디렉터리 트리를 원격 사이트에 복제하는 경우 사용자의 검색으로 인한 트래픽과 비교하여 네트워크에 더 큰 로드를 추가할 수 있습니다. 특히 디렉터리가 자주 변경되지만 원격 사이트에서 하루에 몇 개의 디렉토리 검색을 수행하는 사용자는 몇 명뿐입니다.

다음 표에서는 디렉터리 복제의 부하 영향을 1 만 개의 항목으로, 여기서 100,000 개의 항목이 매일 변경되고, 매일 10개의 검색을 수행하는 100명의 직원 중 작은 원격 사이트를 갖는 부하 영향을 비교하고, 매일 10개의 검색을 수행하는 100명의 직원 중 부하 영향을 비교합니다.

네트워크를 과부하하지 않고 로컬 사이트에 데이터를 사용할 수 있도록 하는 것 사이의 중단은 예약된 복제를 사용하는 것입니다. 데이터 일관성 및 복제 스케줄에 대한 자세한 내용은 데이터 일관성을 참조하십시오.

6.3.6.1. 네트워크 로드 밸런싱의 예

링크 복사

이 예에서는 뉴질랜드 (NY) 및 로스 앤젤레스 (LA)에 사무실이 있고 각 사무실이 별도의 하위 트리를 관리하는 기업에 대해 설명합니다.

다음 다이어그램에서는 기업이 하위 트리를 관리하는 방법을 보여줍니다.

그림 6.6. enterprise Cryostat 및 LA 하위 트리

각 사무실에는 고속 네트워크가 포함되어 있지만 두 도시 간의 연결은 신뢰할 수 없습니다. 네트워크 로드의 균형을 조정하려면 다음 전략을 사용합니다.

• 각 사무실에서 로컬 관리 데이터의 공급자 서버로 전환하려면 하나의 서버를 선택합니다.

  해당 공급 업체에서 원격 사무실의 해당 공급자 서버로 로컬 관리 데이터를 복제합니다. 각 위치에 데이터의 주요 사본이 있는 경우 사용자는 신뢰할 수 없는 연결을 통해 업데이트 및 검색 작업을 수행하지 않습니다. 결과적으로 성능이 최적화됩니다.

• 디렉터리 데이터의 가용성을 보장하기 위해 각 공급자 서버(원격 사무실에서 제공된 데이터 포함)의 디렉터리 트리를 하나 이상의 로컬 디렉터리 서버로 복제합니다.

• 추가 로드 밸런싱을 제공하기 위해 로컬 데이터를 검색하는 데 전용 소비자 수가 증가하여 각 위치에서 계단식 복제를 구성합니다.

  Cryostat 사무실은 LA 특정 검색보다 더 많은 특정 검색을 생성합니다. 이 예제에서는 3 명의 데이터 소비자와 1 LA 소비자가있는 사무실을 보여줍니다. LA 사무실에는 3개의 LA 데이터 소비자와 1개의 data consumer가 있습니다.

그림 6.7. 엔터프라이즈 로드 밸런싱 예

부분 복제를 사용하면 Directory Server가 공급 업체에서 소비자 또는 다른 공급자로 복제하지 않는 속성 집합을 선택할 수 있습니다. 따라서 데이터베이스에 포함된 모든 정보를 복제하지 않고 데이터베이스를 복제할 수 있습니다.

부분 복제는 복제 계약에 따라 활성화 및 구성됩니다. Directory Server는 특성을 모든 항목에 동일하게 제외합니다. 제외된 속성은 항상 소비자에 대한 값이 없습니다. 따라서 소비자 서버에 대해 검색을 수행하는 클라이언트는 검색 필터가 이러한 특성을 명시적으로 지정하는 경우에도 제외된 속성을 볼 수 없습니다.

다음과 같은 경우 소수 복제를 사용합니다.

자세한 내용은 소수 복제 내에서 속성 관리를 참조하십시오.

광역 네트워크(wide area networks)는 일반적으로 더 높은 대기 시간, 대역폭 지연 제품, 로컬 영역 네트워크보다 빠른 속도를 갖습니다. Directory Server는 공급 업체와 소비자가 광역 네트워크를 사용하여 연결할 때 효율적인 복제를 지원합니다.

이전에는 공급자가 하나의 업데이트 작업만 보낸 다음 소비자의 응답을 기다리기 때문에 Directory Server에서 사용하는 복제 프로토콜이 대기 시간에 민감했습니다. 이로 인해 대기 시간이 길어진 처리량이 줄어들었습니다.

현재 공급자는 응답을 기다리지 않고 많은 업데이트 및 항목을 소비자에게 전송하고 복제 처리량은 로컬 영역 네트워크의 처리량과 유사합니다.

WAN을 사용할 때 다음과 같은 성능 및 보안 문제를 고려하십시오.

디렉터리는ACI(Access Control instructions)를 항목의 속성으로 저장하고 디렉터리 서버는 다른 디렉터리 콘텐츠와 함께 이러한 ACI를 복제합니다. 예를 들어 특정 호스트의 디렉터리에 대한 액세스를 제한하려면 ACI의 호스트별 설정만 사용합니다. 그렇지 않으면 ACI가 다른 서버에 복제되면 Directory Server가 ACI를 로컬로 평가하므로 모든 서버에서 디렉터리에 대한 액세스가 거부됩니다.

디렉터리에 대한 액세스 제어 설계에 대한 자세한 내용은 액세스 제어 설계를 참조하십시오.

복제는 Directory Server와 함께 제공되는 대부분의 플러그인에서 작동합니다. 그러나 다음 플러그인에는 다중 제공 환경에서 제한 사항 및 예외가 있습니다.

체인을 사용하여 디렉터리에 항목을 배포할 때 데이터베이스 링크가 포함된 서버는 실제 데이터가 포함된 원격 서버를 나타냅니다. 이 환경에서는 데이터베이스 링크를 복제할 수 없습니다. 그러나 원격 서버의 실제 데이터가 포함된 데이터베이스를 복제할 수 있습니다.

연결 및 항목 배포에 대한 자세한 내용은 Directory Server에서 연결 사용을 참조하십시오.

복제된 환경에서는 복제에 참여하는 모든 서버에서 스키마를 일관되게 유지해야 합니다. 스키마 일관성을 보장하기 위해 단일 공급자 서버에서만 스키마를 수정합니다.

서버 간 복제를 구성한 경우 기본적으로 스키마 복제가 수행됩니다.

무단 액세스로부터 디렉토리를 보호하는 것은 쉽지 않은 것처럼 보일 수 있지만 보안 솔루션을 구현하는 것이 처음 나타나는 것보다 더 복잡할 수 있습니다. 디렉터리 정보 전달 경로에는 권한이 없는 클라이언트가 데이터에 액세스할 수 있는 여러 잠재적인 액세스 지점이 있습니다.

다음 시나리오에서는 권한이 없는 클라이언트가 디렉터리 데이터에 액세스하는 방법에 대한 몇 가지 예를 설명합니다.

Directory Server에서 제공하는 인증 방법, 암호 정책 및 액세스 제어 메커니즘은 무단 액세스를 방지하는 효율적인 방법을 제공합니다.

침입자가 디렉터리에 액세스하거나 Directory Server와 클라이언트 애플리케이션 간의 통신을 가로채는 경우 디렉터리 데이터를 수정하거나 변조할 가능성이 있습니다. 클라이언트가 데이터를 신뢰하지 않거나 디렉터리 자체에서 수정 사항을 신뢰할 수 없는 경우 디렉터리 서비스는 쓸모 없습니다.

예를 들어 디렉터리가 변조를 감지할 수 없는 경우 공격자는 클라이언트 요청을 서버로 변경하거나 이를 전달하지 않고 클라이언트에 서버 응답을 변경할 수 있습니다. TLS 및 유사한 기술은 연결 종료 시 정보에 서명하여 이 문제를 해결할 수 있습니다.

서비스 거부 공격에서 공격자는 디렉터리가 클라이언트에 서비스를 제공하지 못하도록 하는 것입니다. 예를 들어 공격자는 모든 시스템 리소스를 사용할 수 있으므로 다른 사용자가 이러한 리소스를 사용하지 못하도록 할 수 있습니다. Directory Server는 특정 바인딩 DN에 할당된 리소스에 대한 제한을 설정하여 서비스 거부 공격을 방지할 수 있습니다. 사용자 바인딩 DN을 기반으로 리소스 제한 설정에 대한 자세한 내용은 사용자 관리 및 인증 가이드를 참조하십시오.

데이터 분석은 사용자, 그룹, 파트너, 고객 및 애플리케이션이 디렉터리 서비스에 액세스해야 하는 정보를 식별합니다. 액세스 권한은 다음 두 가지 방법 중 하나로 부여할 수 있습니다.

액세스 권한을 결정하는 데 사용되는 방법과 관계없이 조직의 사용자 범주와 각각에 부여된 액세스 권한을 나열하는 간단한 테이블을 만듭니다. 디렉터리에 보관된 중요한 데이터를 나열하고 각 데이터 조각에 대해 해당 데이터를 보호하는 단계를 나열하는 테이블을 만드는 것이 좋습니다.

이 디렉토리를 사용하여 엑스트라넷을 통해 비즈니스 파트너와의 교환을 지원하거나 인터넷상의 고객과 함께 전자 상거래 애플리케이션을 지원하는 경우, 교환된 데이터의 개인 정보 보호 및 무결성을 확인하십시오.

데이터 개인 정보 및 무결성을 보장하기 위해 다음 방법을 사용하십시오.

추가 보안 조치로 로그 파일 및 SNMP 에이전트가 기록하는 정보를 검사하여 전체 보안 정책의 효율성을 확인하기 위해 정기적인 감사를 수행합니다.

예에서는 imaginary Cryostat 회사 example.com 이 보안 요구 사항을 분석하는 방법을 보여줍니다. example.com 은 웹 호스팅 및 인터넷 액세스를 제공합니다. example.com 활동 중 일부는 클라이언트 회사의 디렉터리를 호스팅하는 것입니다. 또한 여러 개별 구독자에게 인터넷 액세스를 제공합니다. 따라서 example.com 의 디렉터리에는 다음 세 가지 주요 카테고리가 있습니다.

example.com 에는 다음과 같은 액세스 제어가 필요합니다.

익명 액세스를 통해 디렉터리에 대한 가장 쉬운 형태의 액세스 권한을 제공합니다. 익명 액세스를 사용하면 디렉터리에 연결하는 모든 사용자가 데이터에 액세스할 수 있습니다.

익명 액세스를 구성하면 사용자가 검색을 수행하는 경우에만 어떤 종류의 검색을 수행하는지 추적할 수 없습니다. 특정 사용자 또는 사용자 그룹이 일부 종류의 디렉토리 데이터에 액세스하지 못하도록 차단할 수 있지만, 익명 액세스가 해당 데이터에 대해 허용되는 경우 해당 사용자는 디렉터리에 직접 바인딩하여 해당 데이터에 계속 액세스할 수 있습니다.

익명 액세스를 제한할 수 있습니다. 일반적으로 디렉터리 관리자는 쓰기, 추가, 삭제 또는 자체 쓰기 권한이 아닌 읽기, 검색 및 비교 권한에 대한 익명 액세스만 허용합니다. 관리자는 이름, 전화 번호 및 이메일 주소와 같은 일반 정보가 포함된 속성 하위 집합에 대한 액세스를 제한하는 경우가 많습니다. 정부 식별 번호와 같은 보다 민감한 데이터에 대한 익명 액세스를 허용해서는 안 됩니다 (예: 미국 사회 보안 번호, 가정 전화 번호 및 주소, 급여 정보).

디렉터리 데이터에 액세스하는 사용자에 대한 규칙을 강화해야 하는 경우 익명 액세스를 완전히 비활성화할 수 있습니다.

인증되지 않은 바인딩 은 사용자가 사용자 이름으로 바인딩하려고 하지만 사용자 암호 속성이 없는 경우입니다. 예를 들면 다음과 같습니다.

ldapsearch -x -D "cn=jsmith,ou=people,dc=example,dc=com" -b "dc=example,dc=com" "(cn=joe)"

사용자가 암호를 제공하지 않는 경우 Directory Server는 익명 액세스 권한을 부여합니다. 인증되지 않은 바인딩에서는 바인딩 DN이 기존 항목일 필요가 없습니다.

익명 바인딩과 마찬가지로 인증되지 않은 바인딩을 비활성화하여 데이터베이스에 대한 액세스를 제한하여 보안을 강화할 수 있습니다. 또한 인증되지 않은 바인딩을 비활성화하여 클라이언트에 대한 자동 바인딩 실패를 방지할 수 있습니다. 일부 애플리케이션은 실제로 암호가 전달되지 않고 인증되지 않은 바인딩과 연결할 때 바인딩 성공 메시지를 수신했기 때문에 디렉터리에 성공적으로 인증되었다고 생각할 수 있습니다.

익명 액세스가 허용되지 않는 경우 사용자는 디렉터리 콘텐츠에 액세스하기 전에 디렉터리에 대한 인증을 받아야 합니다. 간단한 암호 인증을 사용하여 클라이언트는 재사용 가능한 암호를 전송하여 서버에 인증합니다.

예를 들어 클라이언트는 고유 이름과 인증 정보 집합을 제공하는 bind 작업을 사용하여 디렉터리에 인증합니다. 서버는 디렉터리에서 클라이언트 DN에 해당하는 항목을 찾고 클라이언트에서 제공한 암호가 해당 항목과 저장된 값과 일치하는지 확인합니다. 이 경우 서버는 클라이언트를 인증합니다. 그렇지 않으면 인증 작업이 실패하고 클라이언트에 오류 메시지가 표시됩니다.

바인딩 DN은 종종 사람의 입력에 해당합니다. 그러나 일부 디렉터리 관리자는 사람이 아닌 조직 항목으로 바인딩하는 것을 선호합니다. 디렉터리에는 userPassword 특성을 허용하는 오브젝트 클래스를 바인딩하는 데 사용하는 항목이 필요합니다. 이렇게 하면 디렉터리가 바인딩 DN 및 암호를 인식합니다.

대부분의 LDAP 클라이언트는 사용자가 이해하기 어려운 DN 문자의 긴 문자열을 찾을 수 있기 때문에 사용자의 바인딩 DN을 숨깁니다. 클라이언트에서 사용자의 바인딩 DN을 숨기려고 하면 다음 바인딩 알고리즘을 사용합니다.

간단한 암호 인증은 사용자를 인증하는 쉬운 방법을 제공하지만 추가 보안 방법이 필요합니다. 조직 인트라넷에 대한 사용을 제한하는 것이 좋습니다. 엑스트라넷을 통해 비즈니스 파트너 간 연결 또는 인터넷 상의 고객과의 전송을 위해서는 안전한(암호화) 연결이 필요한 것이 가장 좋습니다.

nsslapd-require-secure-binds 구성 속성을 사용하여 TLS 또는 Start TLS를 사용하여 보안 연결을 설정합니다. SASL 인증 또는 인증서 기반 인증도 가능합니다. Directory Server 및 클라이언트 애플리케이션이 서로 보안 연결을 설정하는 경우 클라이언트는 일반 텍스트로 암호를 전송하지 않고 추가 수준의 보호로 간단한 바인딩을 수행합니다.

다른 형식의 디렉터리 인증에는 디지털 인증서를 사용하여 디렉터리에 바인딩해야 합니다. 디렉터리에 처음 액세스할 때 사용자에게 암호를 입력하라는 메시지가 표시됩니다. 그러나 디렉터리에 저장된 암호와 일치하지 않고 암호는 사용자 인증서 데이터베이스를 엽니다.

사용자가 올바른 암호를 제공하는 경우 디렉터리 클라이언트 애플리케이션은 인증서 데이터베이스에서 인증 정보를 가져옵니다. 그런 다음 클라이언트 애플리케이션 및 디렉터리는 이 정보를 사용하여 사용자 인증서를 디렉터리 DN에 매핑하여 사용자를 식별합니다. 디렉터리는 이 인증 프로세스 중에 식별된 디렉터리 DN을 기반으로 액세스를 허용하거나 거부합니다.

디렉터리에 대한 액세스를 요청하는 사용자가 자체 DN과 바인딩되지 않지만 프록시 DN과 바인딩되므로 프록시 인증은 특별한 형식의 인증입니다.

프록시 DN은 사용자가 요청하는 작업을 수행할 수 있는 적절한 권한이 있는 엔티티입니다. 사용자 또는 애플리케이션에서 프록시 권한을 수신하는 경우 Directory Manager DN을 제외하고 모든 DN을 프록시 DN으로 지정할 수 있습니다.

프록시 권한의 주요 이점 중 하나는 LDAP 애플리케이션에서 디렉터리 서버에 대한 요청을 수행하는 여러 사용자를 서비스하는 단일 스레드를 사용할 수 있다는 것입니다. 각 사용자에 대해 바인딩하고 인증하는 대신 클라이언트 애플리케이션은 프록시 DN을 사용하여 Directory Server에 바인딩합니다.

프록시 DN은 클라이언트 애플리케이션이 제출하는 LDAP 작업에 지정됩니다. 예를 들면 다음과 같습니다.

ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -X "dn:cn=joe,dc=example,dc=com" -f mods.ldif

이 명령을 사용하면 관리자 항목 cn=Directory Manager 에서 cn=joe 사용자 권한을 수신하여 mods.ldif 파일에 수정 사항을 적용합니다. 관리자는 이러한 변경을 위해 사용자 암호를 제공할 필요가 없습니다.

PTA(Pass-through Authentication) 는 Directory Server가 한 서버에서 다른 서버로 인증 요청을 전달하는 경우입니다.

예를 들어 Directory Server가 다른 디렉터리 인스턴스에 대한 모든 구성 정보를 저장할 때 Directory Server는 사용자 디렉터리 서버에 대한 패스스루 인증을 사용하여 구성 디렉터리 서버에 연결합니다. PTA 플러그인은 Directory Server-to-Directory Server pass-through 인증을 처리합니다.

많은 시스템에는 이미 PAM(Pluggable Authentication Modules)과 같은 Unix 및 Linux 사용자를 위한 인증 메커니즘이 있습니다. LDAP 클라이언트에 기존 인증 저장소를 사용하도록 Directory Server에 지시하도록 PAM 모듈을 구성할 수 있습니다. 디렉터리 서버는 PAM 서비스와 상호 작용하여 PAM 통과 인증 플러그인을 사용하여 LDAP 클라이언트를 인증합니다.

PAM 통과 인증을 사용하여 사용자가 Directory Server에 바인딩하려고 하면 디렉터리 서버는 자격 증명을 PAM 서비스에 전달합니다. 인증 정보가 PAM 서비스의 정보와 일치하는 경우 사용자는 모든 Directory Server 액세스 제어 제한 및 계정 설정을 사용하여 디렉터리 서버에 성공적으로 바인딩할 수 있습니다.

SSSD(System Security Services Daemon)를 사용하여 PAM 서비스를 구성할 수 있습니다. PAM 패스스루 인증 플러그인은 기본적으로 /etc/pam.d/system-auth 와 같이 SSSD에서 사용하는 PAM 파일을 가리키기만 하면 됩니다. SSSD는 Active Directory, Red Hat Directory Server 또는 OpenLDAP와 같은 기타 디렉토리 또는 로컬 시스템 설정을 포함하여 다양한 ID 공급자를 사용할 수 있습니다.

인증 시도는 먼저 사용자 계정을 인증할 수 있는지 평가합니다. 계정은 다음 기준에 속해야 합니다.

경우에 따라 사용자가 Active Directory Server에 바인딩하거나 바인딩할 수 없을 때 사용자 계정 인증을 수행해야 하는 경우가 있습니다. 예를 들어 시스템은 PAM을 사용하여 시스템 계정을 관리하고, LDAP 디렉터리를 ID 저장소로 사용하도록 PAM을 구성할 수 있습니다. 그러나 시스템은 SSH 키 또는 RSA 토큰과 같은 암호 없는 자격 증명을 사용하며 해당 인증 정보를 전달하여 Directory Server에 인증할 수 없습니다.

Red Hat Directory Server는 LDAP 검색에 대한 계정 지원 확장 제어 확장을 지원합니다. 이 확장은 계정 상태를 제공하는 반환된 각 항목에 대한 추가 행과 해당 계정의 암호 정책에 대한 몇 가지 정보를 반환합니다. 그러면 클라이언트 또는 애플리케이션에서 해당 사용자 계정에 대한 디렉터리 서버 외부의 인증 시도를 평가하는 데 해당 상태를 사용할 수 있습니다. 기본적으로 이 제어는 인증 작업을 수행할 필요 없이 사용자가 인증할 수 있는지 여부를 나타냅니다.

또한 PAM과 같은 시스템 수준 서비스와 함께 이 확장을 사용하여 Directory Server를 사용하여 ID를 저장하고 계정 상태를 제어하는 암호 없는 로그인을 허용할 수 있습니다.

Directory Server는 세분화된 암호 정책을 지원합니다. 즉 디렉터리 서버는 디렉터리 트리의 모든 지점에서 암호 정책을 정의합니다. Directory Server는 다음 수준에서 암호 정책을 정의합니다.

기본적으로 Directory Server에는 글로벌 암호 정책과 관련된 항목 및 속성이 포함되어 있습니다. 즉, 모든 사용자에게 동일한 정책이 적용됩니다. 하위 트리 또는 사용자에 대한 암호 정책을 설정하려면 하위 트리 또는 사용자 수준에서 추가 항목을 추가하고 cn=config 항목의 nsslapd-pwpolicy-local 속성을 활성화합니다. 이 속성은 스위치 역할을 하며, / off의 암호 정책을 세밀하게 설정합니다.

명령줄 또는 웹 콘솔을 사용하여 암호 정책을 변경할 수 있습니다. 명령줄에서 dsconf pwpolicy 명령은 글로벌 정책을 변경하고 dsconf localpwp 명령은 로컬 정책을 변경합니다. 암호 정책 구성 섹션에서 암호 정책을 설정하는 절차를 확인할 수 있습니다.

암호 정책 확인 프로세스

디렉터리에 추가하는 암호 정책 항목은 Directory Server에서 적용해야 하는 암호 정책의 유형(글로벌 또는 로컬)을 결정합니다.

사용자가 디렉터리에 바인딩하려고 하면 Directory Server에서 사용자 항목에 대해 로컬 정책이 정의되고 활성화되어 있는지 여부를 결정합니다. Directory Server는 다음 순서로 정책 설정을 확인합니다.

요청을 바인딩하는 것 외에도 userPassword 속성이 요청에 있는 경우 추가 및 수정 작업 중에 암호 정책 확인이 수행됩니다.

userPassword 값을 수정하면 다음 두 가지 암호 정책 설정이 있는지 확인합니다.

userPassword 값을 추가하고 수정하면 모두 암호 구문에 대해 설정된 암호 정책을 확인합니다.

서버의 암호 정책을 생성하는 데 사용할 수 있는 특성에 대해 알아봅니다. Directory Server는 cn=config 항목에 암호 정책 속성을 저장하고 dsconf 유틸리티를 사용하여 이러한 설정을 변경할 수 있습니다.

최대 실패 수

이 설정은 암호 정책에서 암호 기반 계정 잠금을 활성화합니다. 사용자가 특정 횟수에 로그인하여 실패하는 경우 관리자가 잠금을 해제할 때까지 Directory Server는 해당 계정을 잠급니다. passwordMaxFailure 구성 매개변수를 사용하여 최대 실패 수를 설정합니다.

Directory Server에는 로그인 시도를 계산하고 로그인 시도가 제한에 도달할 때 계정을 잠그는 두 가지 방법이 있습니다.

예를 들어 실패 제한이 세 번 시도한 경우 세 번째 실패 시도 (n ) 또는 네 번째 실패 시도 (n+1)에서 계정을 잠글 수 있습니다. n+1 동작은 LDAP 서버의 이전 동작이므로 기존 동작으로 간주됩니다. 최신 LDAP 클라이언트는 더 엄격한 하드 제한을 기대합니다. 기본적으로 Directory Server는 strict 제한(n)을 사용하지만 passwordLegacyPolicy 구성 매개변수에서 레거시 동작을 변경할 수 있습니다.

재설정 후 암호 변경

Directory Server 암호 정책은 사용자가 처음 로그인 후 또는 관리자가 암호를 재설정한 후 암호를 변경해야 하는지 여부를 지정할 수 있습니다. 관리자가 설정한 기본 암호는 일반적으로 사용자 initials, 사용자 ID 또는 회사 이름과 같은 회사 규칙을 따릅니다. 이 규칙이 발견되면 일반적으로 악의적인 행위자가 시스템에 침입하려는 시도에서 사용하는 첫 번째 값입니다. 따라서 관리자가 암호를 재설정한 후 사용자가 암호를 변경해야 합니다.

암호 정책에 대해 이 설정을 구성하는 경우 사용자 정의 암호가 비활성화된 경우에도 암호를 변경해야 합니다. 암호 정책에 필요하지 않거나 사용자가 암호 변경을 허용하지 않는 경우 관리자가 할당한 암호는 명확한 규칙을 따르지 않아야 하며 검색하기 어려울 수 있습니다.

기본 설정에서는 사용자가 암호를 재설정한 후 변경할 필요가 없습니다.

사용자 정의 암호

사용자가 자신의 암호를 변경할 수 있도록 허용하거나 허용하지 않도록 암호 정책을 설정할 수 있습니다. 좋은 암호는 강력한 암호 정책의 키입니다. 좋은 암호는 사전 단어, 가사나 자식의 이름, 달란, 사용자 ID 또는 쉽게 찾을 수 있는 사용자에 대한 기타 정보와 같은 간단한 단어를 사용해서는 안 됩니다(또는 디렉토리 자체에 저장). 좋은 암호에는 문자, 숫자 및 특수 문자의 조합이 포함되어야 합니다. 그러나 편의를 위해 사용자가 쉽게 기억할 수 있는 암호를 사용하는 경우가 많습니다. 결과적으로 일부 기업은 강력한 암호 기준을 충족하고 사용자가 암호를 변경할 수 없는 사용자의 암호를 설정하도록 선택합니다.

사용자에 대한 관리자의 암호 설정에는 다음과 같은 단점이 있습니다.

기본적으로 사용자 정의 암호는 허용됩니다.

암호 만료

암호 정책을 사용하면 사용자가 동일한 암호를 무기한 사용하거나 지정된 시간 후에 암호가 만료되도록 지정할 수 있습니다. 일반적으로 암호가 더 오래 사용할수록 검색될 가능성이 높아집니다. 그러나 암호가 너무 자주 만료되는 경우 사용자가 암호를 기억하는 데 어려움이 있을 수 있으며 암호를 적어 둘 수 있습니다. 일반적인 정책은 30일에서 90일마다 암호가 만료되는 것입니다. 암호 만료가 비활성화된 경우에도 서버는 암호 만료 사양을 기억합니다. 암호 만료가 다시 활성화된 경우 암호가 마지막으로 비활성화되기 전에 설정된 기간 동안만 유효합니다. 예를 들어 90일마다 만료되도록 암호를 구성한 다음 암호 만료를 비활성화하고 다시 활성화하면 기본 암호 만료 기간은 90일로 유지됩니다.

기본적으로 사용자 암호는 만료되지 않습니다.

만료 경고

암호 만료 기간을 설정하는 경우 암호가 만료되기 전에 사용자에게 경고를 보내는 것이 좋습니다.

사용자가 서버에 바인딩되면 Directory Server가 경고를 표시합니다. 암호 만료가 활성화된 경우 기본적으로 디렉터리 서버는 사용자 암호가 만료되기 직전에 LDAP 메시지를 사용하여 사용자에게 경고를 보냅니다. 사용자 클라이언트 애플리케이션에서 이 기능을 지원해야 합니다.

암호 만료 경고에 대한 유효한 범위는 1일에서 2455일 사이입니다.

유예 로그인 제한

만료된 암호의 유예 기간은 사용자가 암호가 만료된 경우에도 계속 시스템에 로그인할 수 있음을 의미합니다. 일부 사용자가 만료된 암호를 사용하여 로그인할 수 있도록 하려면 암호가 만료된 후 사용자에게 허용되는 유예 로그인 시도 횟수를 지정합니다.

기본적으로 Directory Server는 유예 로그인을 허용하지 않습니다.

암호 구문 확인

암호 구문 검사에서는 암호를 사용하여 특정 기준을 충족하거나 초과하도록 암호 문자열 규칙을 적용합니다. 모든 암호 구문 검사는 하위 트리 또는 사용자별로 전역적으로 적용할 수 있습니다. passwordCheckSyntax 속성은 암호 구문 검사를 관리합니다.

기본 암호 구문에는 최소 8자의 암호 길이가 필요하며 암호에는 간단한 단어가 사용되지 않습니다. 간단한 단어는 사용자 항목의 uid,cn,sn,givenName,ou 또는 mailattributes 에 저장된 모든 값입니다.

또한 다른 암호 구문 적용 양식을 사용하여 암호 구문에 대한 다양한 선택적 카테고리를 제공할 수 있습니다.

구문 카테고리가 많을수록 암호가 강화됩니다.

기본적으로 암호 구문 검사는 비활성화되어 있습니다.

암호 길이

암호 정책에는 사용자 암호에 대한 최소 길이가 필요할 수 있습니다. 일반적으로 더 짧은 암호는 해독하기가 더 쉽습니다. 권장되는 최소 암호 길이는 8자입니다. 크래킹하기가 어려울 만큼 길지만 사용자가 암호를 적어 두지 않고도 암호를 기억할 수 있을 만큼 짧습니다. 이 속성에 유효한 값 범위는 2에서 512자 사이입니다.

기본적으로 서버에는 최소 암호 길이가 없습니다.

암호 최소 기간: 암호 정책은 사용자가 지정된 시간에 대한 암호를 변경하지 못하도록 할 수 있습니다. passwordHistory 속성과 함께 passwordMinAge 속성을 설정하면 사용자가 이전 암호를 재사용할 수 없습니다. 예를 들어 암호 최소 사용 기간(passwordMinAge) 속성이 2일이면 사용자는 단일 세션 중에 암호를 반복적으로 변경할 수 없습니다. 이렇게 하면 이전 암호를 재사용할 수 있도록 암호 기록을 순환하지 못합니다.

passwordMinAge 속성에 유효한 값 범위는 0에서 24855일 사이입니다. 값0(0)은 사용자가 암호를 즉시 변경할 수 있음을 나타냅니다.

암호 내역

Directory Server는 암호 기록에 2~24개의 암호를 저장할 수 있습니다. 암호가 기록에 있는 경우 사용자는 이전 암호로 암호를 재설정할 수 없습니다. 이렇게 하면 사용자가 쉽게 기억할 수 있는 몇 개의 암호를 재사용할 수 없습니다. 또는 암호 기록을 비활성화하여 사용자가 암호를 재사용할 수 있습니다.

암호 기록이 꺼져 있어도 암호는 기록에 남아 있습니다. 암호 기록이 다시 켜지면 암호 기록을 비활성화하기 전에 사용자가 기록에 있는 암호를 재사용할 수 없습니다.

서버는 기본적으로 암호 기록을 유지하지 않습니다.

암호 스토리지 체계

암호 스토리지 스키마는 디렉터리 내에서 Directory Server 암호를 저장하는 데 사용되는 암호화 유형을 지정합니다. Directory Server는 다양한 암호 스토리지 체계를 지원합니다.

암호 마지막 변경 시간 passwordTrackUpdateTime 구성 속성은 서버에 마지막으로 Directory Server가 항목의 암호를 업데이트한 시점의 타임스탬프를 기록하도록 지시합니다. Directory Server는 암호 변경 시간을 사용자 항목에 pwdUpdateTime 으로 저장합니다. 이는 modifyTimestamp 또는 last Cryostat 운영 속성과 다릅니다.

기본적으로 서버는 암호를 마지막으로 변경한 시간을 저장하지 않습니다.

Directory Server는 다음과 같이 복제된 환경에서 암호 및 계정 잠금 정책을 적용합니다.

Directory Server는 암호 사용, 계정 잠금 카운터 및 만료 경고 카운터와 같은 디렉터리에 암호 정책 정보를 복제합니다. 그러나 Directory Server는 암호 구문 및 암호 변경 기록과 같은 구성 정보를 복제하지 않습니다. Directory Server는 이 정보를 로컬에 저장합니다.

복제된 환경에서 암호 정책을 구성할 때 다음 사항을 고려하십시오.

보안 정책을 설계할 때 디렉터리에 ACI가 표시되는 방법과 설정할 수 있는 권한을 이해해야 합니다.

Directory ACI는 다음과 같은 일반적인 형식을 사용합니다.

target permission bind_rule

ACI 변수에는 다음과 같은 설명이 있습니다.

따라서 디렉터리 오브젝트 대상의 경우 ACI는 바인딩 규칙이 true인 경우 권한을 허용하거나 거부합니다.

권한 및 바인딩 규칙은 쌍으로 설정되며 모든 대상에 여러 권한 바인딩 규칙 쌍이 있을 수 있습니다. 지정된 대상에 대해 여러 액세스 제어를 효과적으로 설정할 수 있습니다. 예를 들면 다음과 같습니다.

target (permission bind_rule)(permission bind_rule) ...

기본적으로 Directory Server는 Directory Manager를 제외하고 모든 사용자에 대한 액세스를 거부합니다. 결과적으로 사용자가 디렉터리에 액세스하려면 ACI를 설정해야 합니다.

GER( Get effective rights )는 항목 내의 각 속성에 설정된 액세스 제어 권한을 반환하는 확장된 ldapsearch 명령입니다. 이 검색을 통해 LDAP 클라이언트는 서버 액세스 제어 구성으로 사용자가 수행할 수 있는 작업을 결정할 수 있습니다.

액세스 제어 정보는 두 개의 액세스 그룹, 즉 항목 권한 및 속성 권한으로 나뉩니다. 항목 권한은 해당 특정 항목으로 제한되는 수정 또는 삭제와 같은 권한입니다. 속성 권한은 디렉터리 전체의 해당 속성의 모든 인스턴스에 대한 액세스 권한입니다.

이러한 자세한 액세스 제어는 다음과 같은 상황에서 필요할 수 있습니다.

다음 팁은 디렉터리 보안 모델을 관리하고 디렉터리 성능 특성을 개선하는 데 도움이 될 수 있습니다.

일반적으로 액세스 제어 규칙은 Directory Manager 사용자에게 적용되지 않습니다. 디렉터리 관리자는 일반 사용자 데이터베이스가 아닌 dse.ldif 파일에 정의되어 있으며 ACI 대상에는 해당 사용자가 포함되지 않습니다.

디렉터리 관리자는 유지 관리 작업을 수행하고 사고에 응답하기 위해 높은 수준의 액세스 권한이 필요합니다. 그러나 디렉터리 관리자에 특정 수준의 액세스 제어 권한을 부여하여 권한이 없는 액세스 또는 공격이 root 사용자로 수행되지 않도록 할 수 있습니다.

RootDN 액세스 제어 플러그인을 사용하여 Directory Manager 사용자와 관련된 특정 액세스 제어 규칙을 설정합니다.

Directory Manager에 대해 하나의 액세스 제어 규칙만 설정할 수 있습니다. 플러그인 항목에 있으며 전체 디렉터리에 적용됩니다.

디렉터리가 저장할 데이터 유형을 결정하기 위해 ExampleCom은 사이트 설문 조사를 수행하는 배포 팀을 만듭니다. 배포 팀은 다음 주요 포인트를 결정합니다.

ExampleCom 디렉터리에서 지원하는 애플리케이션에는 userCertificate 및 uid (userID) 속성이 필요합니다. 따라서 ExampleCom 배포 팀은 inetOrgPerson 오브젝트 클래스를 사용하여 두 특성을 모두 허용하므로 디렉터리의 항목을 나타냅니다.

또한 ExampleCom은 예제Person 오브젝트 클래스를 생성하여 직원을 나타내는 기본 디렉터리 스키마를 사용자 지정하려고 합니다. 이 개체 클래스는 inetOrgPerson 개체 클래스에서 파생됩니다. examplePerson 은 하나의 exampleID 속성을 허용합니다. 이 속성에는 각 직원에 할당된 특수 직원 번호가 포함됩니다. 나중에 ExampleCom은 examplePerson 오브젝트 클래스에 새 속성을 추가할 수 있습니다.

준비된 데이터 및 스키마 설계에 따라 ExampleCom은 다음 디렉터리 트리를 생성합니다.

그림 8.1. 예제Com의 디렉터리 트리

ExampleCom 배포 팀은 디렉터리 데이터베이스 및 서버 토폴로지를 설계하기 시작합니다.

ExamleCom은 다음과 같은 데이터베이스 토폴로지를 설계합니다.

그림 8.2. 로컬 엔터프라이즈 데이터베이스 토폴로지

ExamleCom은 다음 서버 토폴로지를 설계합니다.

그림 8.3. 로컬 엔터프라이즈 서버 토폴로지

ExampleCom은 두 개의 공급자 서버와 세 개의 소비자 서버가 있는 서버 토폴로지를 사용하기로 결정했습니다. 두 공급자 각각은 Directory Server 배포에서 세 명의 소비자를 모두 업데이트합니다.

소비자는 하나의 메시징 서버 및 다른 서버에 데이터를 제공합니다. 호환되는 서버의 요청 수정은 적절한 소비자 서버로 라우팅됩니다. 소비자 서버는 스마트 추천을 사용하여 요청이 수정되는 데이터의 주요 사본에 대한 책임이 있는 공급자 서버로 라우팅합니다.

ExampleCom은 디렉터리 데이터의 고가용성을 보장하기 위해 다중 제공 복제 설계를 사용하기로 결정했습니다. 다중 제공 복제에 대한 자세한 내용은 Multi-supplier 복제 를 참조하십시오.

8.1.5.1. Multi-supplier 아키텍처

링크 복사

ExampleCom은 다중 제공 복제 아키텍처에서 두 개의 공급자 서버를 사용합니다. 공급업체는 디렉터리 데이터가 일관되게 유지되도록 서로를 업데이트합니다. 다음 다이어그램은 ExampleCom의 공급업체 제공 아키텍처를 보여줍니다.

그림 8.4. ExampleCom 다중 공급 아키텍처

8.1.5.2. vendor-consumer 아키텍처

링크 복사

다음 다이어그램에서는 디렉터리의 ExampleCom 배포에서 공급업체 서버가 각 소비자에게 복제하는 방법을 설명합니다.

그림 8.5. 예Com 공급자 소비자 아키텍처

두 공급자 서버 모두 세 개의 소비자 서버를 업데이트합니다. 이렇게 하면 공급자 서버 중 하나가 실패하면 소비자가 영향을 받지 않습니다.

디렉터리 데이터를 보호하기 위해 ExampleCom은 다음 액세스 제어 명령(ACI)을 생성합니다.

또한 ExampleCom은 다음과 같은 보안 조치를 결정합니다.

회사는 디렉터리의 일상적인 운영에 대해 다음과 같은 결정을 내립니다.

ExampleCom International은 설문 조사를 수행하기 위한 배포 팀을 생성합니다. 배포 팀은 사이트 설문 조사에서 다음 주요 포인트를 결정합니다.

또한 엑스트라넷의 데이터 설계는 다음 조건이 충족되어야 합니다.

ExampleCom International은 원래 스키마 설계를 사용하고 엑스트라넷을 지원하기 위해 두 가지 새로운 오브젝트 클래스를 추가합니다.

기본 디렉터리 스키마 사용자 지정에 대한 자세한 내용은 스키마 사용자 지정을 참조하십시오.

ExampleCom International은 다음 디렉터리 트리를 생성합니다.

그림 8.6. ExampleCom International의 기본 디렉터리 트리

dc=com 접미사는 디렉터리 트리의 루트입니다. 이 접미사 아래에 회사는 다음 분기를 생성합니다.

dc=exampleCom,dc=com 에서 인트라넷의 디렉터리 트리에는 세 가지 주요 분기가 있습니다. 각 분기는 ExampleCom International에 사무실이 있는 지역 중 하나에 해당합니다. 이러한 분기는 l (로컬) 속성을 사용하여 식별됩니다.

dc=exampleNet,dc=com 브랜치 아래에 ExampleCom International은 다음과 같은 분기를 생성합니다.

8.2.3.1. ExampleCom International의 인트라넷 설계

링크 복사

dc=exampleCom,dc=com 아래의 각 분기는 로컬 엔터프라이즈 예제의 디렉터리 트리 설계에서 ExampleCom의 원래 디렉터리 트리 설계를 반복합니다.

그림 8.7. 인트라넷의 디렉터리 트리 예

각 지역에 따라 ExampleCom International은 다음 분기 지점을 생성합니다.

• ou=people
• ou=groups
• ou=roles
• ou=resources

l=Asia locality의 항목은 다음과 같이 LDIF에 나타납니다.

dn: l=Asia,dc=exampleCom,dc=com
objectclass: top
objectclass: locality
l: Asia
description: includes all sites in Asia

8.2.3.2. ExampleCom International의 엑스트라넷 설계

링크 복사

다음 다이어그램은 ExampleCom extranet의 디렉터리 트리를 보여줍니다.

그림 8.8. 엑스트라넷의 디렉터리 트리 예

ExampleCom International 배포 팀은 디렉터리 데이터베이스 및 서버 토폴로지를 설계하기 시작합니다.

8.2.4.1. ExampleCom International의 데이터베이스 토폴로지

링크 복사

ExampleCom International은 모든 지역에 대해 동일한 토폴로지 설계를 사용합니다. 그러나 유럽 지역성은 다음 분기에 대한 데이터의 주요 사본을 저장합니다.

• dc=com root 항목
• dc=exampleCom,dc=com아래의 인트라넷
• dc=exampleNet,dc=com아래의 extranet

다음 다이어그램에서는 지역별 유럽의 데이터베이스 토폴로지를 보여줍니다.

그림 8.9. ExampleCom 유럽의 데이터베이스 토폴로지

l=Europe 데이터베이스는 dc=exampleCom,dc=com 및 dc=com 항목의 주요 사본을 저장합니다.

데이터베이스 링크 1 과 데이터베이스 링크 2 는 각 국가에 로컬로 저장된 데이터베이스를 가리킵니다. 예를 들어, 작업 요청에서는 l=USA 분기 아래에 있는 데이터를 수신하도록 작업 요청이 미국 내의 서버의 데이터베이스에 대한 데이터베이스 링크에 의해 연결됩니다. 데이터베이스 링크 및 체인에 대한 자세한 내용은 체인 사용을 참조하십시오.

유럽 서버에는 엑스트라넷에 대한 데이터의 주요 사본이 포함되어 있습니다. 엑스트라넷 데이터는 다음과 같은 세 가지 데이터베이스에 저장됩니다.

• 데이터베이스 1 은 o=suppliers 분기의 주요 사본을 저장합니다.
• 데이터베이스 2 는 o=partners 분기의 주요 사본을 저장합니다.
• 데이터베이스 3 은 ou=groups 분기의 주요 사본을 저장합니다.

다음 다이어그램은 extranet의 데이터베이스 토폴로지를 보여줍니다.

그림 8.10. ExampleCom International Extranet의 데이터베이스 토폴로지

8.2.4.2. ExampleCom International의 서버 토폴로지

링크 복사

ExampleCom International은 다음과 같은 유형의 서버 토폴로지를 개발합니다.

• 기업 인트라넷의 토폴로지입니다. ExampleCom은 각 주요 지역에 대해 하나씩 세 개의 데이터 센터 즉 유럽, 미국 및 아시아를 사용하기로 결정했습니다. 각 데이터 센터에는 다음 서버가 포함되어 있습니다.

  • 두 개의 공급자 서버.
  • 두 개의 허브 서버.
  • 소비자 서버 세 개.
• 파트너 엑스트라넷의 토폴로지입니다.

다음 다이어그램에서는 ExampleCom 유럽 데이터 센터의 아키텍처를 보여줍니다.

그림 8.11. ExampleCom Europe의 서버 토폴로지

유럽 데이터 센터에는 ExampleCom 엑스트라넷의 주요 사본이 포함되어 있습니다. 이 데이터는 미국 데이터 센터의 두 개의 소비자 서버와 아시아 데이터 센터의 소비자 서버로 복제됩니다. 전반적으로 ExampleCom은 엑스트라넷을 지원하기 위해 10 대의 서버가 필요합니다.

다음 다이어그램은 유럽 데이터 센터에 있는 ExampleCom 엑스트라넷의 서버 아키텍처를 보여줍니다.

그림 8.12. ExampleCom International extranet의 서버 토폴로지

허브 서버는 데이터를 각 데이터 센터의 두 소비자 서버(유럽, 미국 및 아시아)에 복제합니다.

ExampleCom International에서는 디렉터리에 대한 복제를 설계할 때 다음 사항을 고려합니다.

허브 서버는 메일 서버 또는 웹 서버와 같은 중요한 디렉터리 지원 애플리케이션 근처에 있습니다.

공급자 서버가 쓰기 작업에 집중하도록 하려면 허브 서버만 복제를 수행합니다.

나중에 ExampleCom이 확장되고 더 많은 소비자 서버를 추가해야 하는 경우 추가 소비자는 공급 업체 서버의 성능에 영향을 미치지 않습니다.

허브 서버에 대한 자세한 내용은 캐스케이딩 복제 섹션을 참조하십시오.

Multi-supplier 아키텍처

ExampleCom 인트라넷의 경우 각 지역성은 데이터의 주요 사본을 저장하고 데이터베이스 링크를 사용하여 다른 지역의 데이터에 체인합니다.

데이터의 주요 사본에 대해 각 지역성은 다중 제공 복제 아키텍처를 사용합니다.

다음 다이어그램은 dc=exampleCom,dc=com 및 dc=com 분기를 포함하는 지역 유럽의 다중 공급 업체 아키텍처를 보여줍니다.

그림 8.13. ExampleCom 유럽의 다중 공급 아키텍처

각 지역에는 해당 사이트에 대한 데이터의 주요 사본을 공유하는 두 개의 공급자가 포함되어 있습니다. 각 지역성은 데이터의 주요 복사본에 대한 책임이 있습니다.

다중 공급 아키텍처를 사용하면 데이터 가용성을 보장하고 각 공급업체 서버에서 관리하는 워크로드의 균형을 유지하는 데 도움이 됩니다.

전체 실패 위험을 줄이기 위해 ExampleCom은 각 사이트에서 여러 읽기-쓰기 공급자 디렉터리 서버를 사용합니다.

다음 다이어그램은 유럽의 두 공급자 서버와 미국에서 두 공급자 서버 간의 상호 작용을 보여줍니다.

그림 8.14. ExampleCom 유럽 및 ExampleCom USA의 멀티 공급 업체 아키텍처

ExampleCom USA와 ExampleCom Asia와 ExampleCom Europe과 ExampleCom Asia와 동일한 관계가 있습니다.

ExampleCom International은 새로운 다국적 인트라넷을 지원하기 위해 다음과 같은 액세스 제어를 추가하는 이전 보안 설계를 사용합니다.

매크로 ACI에 대한 자세한 내용은 매크로 액세스 제어 지침 사용을 참조하십시오.

ExampleCom은 다음 액세스 제어를 추가하여 엑스트라넷을 지원합니다.