6.3. 기술 자료 참조 정보
데이터를 여러 데이터베이스에 배포한 후 기술 참조를 사용하여 분산 데이터 간의 관계를 정의하며 서로 다른 데이터베이스에 보관된 디렉터리 정보에 대한 포인터입니다. Directory Server는 분산 데이터를 단일 디렉터리 트리에 연결하는 데 도움이 되는 다음과 같은 유형의 지식 참조를 제공합니다.
- 추천 - 서버는 클라이언트 애플리케이션이 요청을 충족하기 위해 다른 서버에 연결해야 함을 나타내는 정보를 클라이언트 애플리케이션에 반환합니다.
- 연결 - 서버 연결 - 클라이언트 애플리케이션을 대신하여 다른 서버에 연결하고 작업이 완료되면 결합된 결과를 클라이언트 애플리케이션에 반환합니다.
다음 섹션에서는 이러한 두 가지 유형의 지식 참조에 대해 자세히 설명하고 비교합니다.
6.3.1. Referrals 사용
추천 은 서버에서 반환한 정보의 한 부분으로, 작업 요청을 진행하기 위해 연결할 서버를 클라이언트 애플리케이션에 알립니다. 이 리디렉션 메커니즘은 클라이언트 애플리케이션이 로컬 서버에 없는 디렉터리 항목을 요청할 때 발생합니다.
Directory Server는 다음 두 가지 유형의 추천을 지원합니다.
- 기본 추천 - 클라이언트 애플리케이션이 서버에 일치하는 접미사가 없는 DN을 제공할 때 디렉터리에 기본 추천을 반환합니다. 기본 추천은 서버의 구성 파일에 저장됩니다. Directory Server에 대해 하나의 기본 추천을 설정하고 각 데이터베이스에 대해 별도의 기본 추천을 설정할 수 있습니다.각 데이터베이스의 기본 추천은 접미사 구성 정보를 통해 수행됩니다. 데이터베이스 접미사가 비활성화되면 해당 접미사에 대한 클라이언트 요청에 대한 기본 추천을 반환하도록 디렉터리 서비스를 구성합니다.접미사에 대한 자세한 내용은 6.2.2절. “Suffixes 정보” 을 참조하십시오. 접미사 구성에 대한 자세한 내용은 Red Hat Directory Server 관리 가이드를 참조하십시오 .
- 스마트 추천 - 스마트 추천은 디렉터리 서비스 자체의 항목에 저장됩니다. 스마트 추천은 스마트 추천이 포함된 항목의 DN과 일치하는 하위 트리에 대한 지식이 있는 디렉터리 서버를 가리킵니다.
모든 추천은 LDAP 균일한 리소스 Cryostat 또는 LDAP URL 형식으로 반환됩니다. 다음 섹션에서는 LDAP 추천 구조에 대해 설명하고 Directory Server에서 지원하는 두 가지 추천 유형에 대해 설명합니다.
6.3.1.1. LDAP Referral의 구조
LDAP 추천에는 LDAP URL 형식의 정보가 포함되어 있습니다. LDAP URL에는 다음 정보가 포함되어 있습니다.
- 연결할 서버의 호스트 이름입니다.
- LDAP 요청을 수신 대기하도록 구성된 서버의 포트 번호입니다.
- 기본 DN(검색 작업용) 또는 대상 DN(추가, 삭제 및 수정용)입니다.
예를 들어 클라이언트 애플리케이션은 dc=example,dc=com 에서 surname 값이 Jensen 인 항목을 검색합니다. 추천은 클라이언트 애플리케이션에 다음 LDAP URL을 반환합니다.
ldap://europe.example.com:389/ou=people, l=europe,dc=example,dc=com
이 추천은 클라이언트 애플리케이션이 포트 389에서 호스트 europe.example.com 에 연락하고 루트 접미사 ou=people, l=europe,dc=example,dc=com 을 사용하여 검색을 제출하도록 지시합니다.
LDAP 클라이언트 애플리케이션은 추천 처리 방법을 결정합니다. 일부 클라이언트 애플리케이션은 참조된 서버에서 작업을 자동으로 재시도합니다. 다른 클라이언트 애플리케이션은 추천 정보를 사용자에게 반환합니다. Red Hat Directory Server에서 제공하는 대부분의 LDAP 클라이언트 애플리케이션(예: 명령줄 유틸리티)은 자동으로 추천을 따릅니다. 초기 디렉터리 요청에 제공된 동일한 바인딩 자격 증명은 서버에 액세스하는 데 사용됩니다.
대부분의 클라이언트 애플리케이션은 제한된 수의 추천 또는 홉 을 따릅니다. 이후의 추천 수에 대한 제한은 클라이언트 애플리케이션이 디렉터리 조회 요청을 완료하는 데 걸리는 시간을 줄이고 순환 참조 패턴으로 인한 중단 프로세스를 제거하는 데 도움이 됩니다.
6.3.1.2. 기본 참조 정보
연결된 서버 또는 데이터베이스에 요청된 데이터가 포함되어 있지 않으면 기본 추천이 클라이언트에 반환됩니다.
Directory Server는 요청된 디렉터리 오브젝트의 DN을 로컬 서버에서 지원하는 디렉터리 접미사와 비교하여 기본 추천을 반환해야 하는지 여부를 결정합니다. DN이 지원되는 접미사와 일치하지 않으면 디렉터리 서버는 기본 추천을 반환합니다.
예를 들어 디렉터리 클라이언트는 다음 디렉터리 항목을 요청합니다.
uid=bjensen,ou=people,dc=example,dc=com
그러나 서버는 dc=europe,dc=example,dc=com 접미사 아래에 저장된 항목만 관리합니다. 디렉터리는 dc=example,dc=com 접미사 아래에 저장된 항목에 대해 연결할 서버를 나타내는 클라이언트에 대한 추천을 반환합니다. 그런 다음 클라이언트는 적절한 서버에 연결하여 원래 요청을 다시 제출합니다.
디렉터리 서비스의 배포에 대한 자세한 정보가 있는 디렉터리 서버를 가리키도록 기본 추천을 구성합니다. 서버에 대한 기본 추천은
nsslapd-referral 특성으로 설정됩니다. 디렉터리 설치의 각 데이터베이스에 대한 기본 추천은 구성의 데이터베이스 항목의 nsslapd-referral 속성에 의해 설정됩니다. 이러한 속성 값은 dse.ldif 파일에 저장됩니다.
기본 추천 구성에 대한 자세한 내용은 Red Hat Directory Server 관리 가이드를 참조하십시오.
6.3.1.3. Smart Referrals
Directory Server는 또한 스마트 추천을 사용할 수 있습니다. 스마트 추천은 디렉터리 항목 또는 디렉터리 트리를 특정 LDAP URL과 연결합니다. 즉, 요청을 다음 중 하나로 전달할 수 있습니다.
- 다른 서버에 포함된 동일한 네임스페이스입니다.
- 로컬 서버의 다른 네임스페이스입니다.
- 동일한 서버의 다른 네임스페이스입니다.
기본 추천과 달리 스마트 추천은 디렉터리 서비스 자체에 저장됩니다. 스마트 추천 구성 및 관리에 대한 자세한 내용은 Red Hat Directory Server 관리 가이드를 참조하십시오.
예를 들어 Example Corp.의 미국 사무실에 대한 디렉터리 서비스에는 ou=people,dc=example,dc=com 디렉토리 분기 포인트가 포함되어 있습니다.
ou=people 항목 자체에 스마트 추천을 지정하여 이 분기의 모든 요청을 Example Corp.의 ou=people 분기로 리디렉션합니다. 스마트 추천은 ldap://europe.example.com:389/ou=people,dc=example,dc=com 입니다.
미국 디렉터리 서비스의 people 분기에 대한 요청은 유럽 디렉터리로 리디렉션됩니다. 이는 아래에 설명되어 있습니다.
그림 6.7. 스마트 조회를 사용하여 요청 리디렉션
동일한 메커니즘을 사용하여 다른 네임스페이스를 사용하는 다른 서버로 쿼리를 리디렉션할 수 있습니다. 예를 들어, Example Corp.의 이탈리아 사무실에서 근무하는 직원은 미국 Example Corp. 직원의 전화 번호에 대한 유럽 디렉터리 서비스에 요청합니다. 디렉터리 서비스는 참조 ldap://europe.example.com:389/ou=US 직원,dc=example,dc=com 을 반환합니다.
그림 6.8. 쿼리를 다른 서버 및 네임스페이스에 리디렉션
마지막으로 동일한 서버에서 여러 접미사가 제공되는 경우 한 네임스페이스에서 동일한 시스템에서 제공된 다른 네임스페이스로 쿼리를 리디렉션할 수 있습니다. 예를 들어 로컬 머신의 o=example,c=us 의 모든 쿼리를 dc=example,dc=com 으로 리디렉션하려면 스마트 추천 ldap:///dc=example,dc=com 을 o=example,c=us 항목에 배치합니다.
그림 6.9. 하나의 네임스페이스에서 동일한 서버의 다른 네임스페이스로 쿼리 리디렉션
참고
이 LDAP URL의 세 번째 슬래시는 URL이 동일한 디렉터리 서버를 가리키는 것을 나타냅니다.
한 네임스페이스에서 다른 네임스페이스로 추천을 생성하면 검색이 해당 고유 이름을 기반으로 하는 클라이언트에 대해서만 작동합니다. ou=people,o=example,c=US 아래의 검색과 같은 기타 종류의 작업은 올바르게 수행되지 않습니다.
LDAP URLS에 대한 자세한 내용 및 Directory Server 항목에 스마트 URL을 포함하는 방법에 대한 자세한 내용은 Red Hat Directory Server 관리 가이드를 참조하십시오.
6.3.1.4. Smart Referrals 설계 팁
스마트 추천을 구현하기는 쉽지만 사용하기 전에 다음 사항을 고려하십시오.
- 설계를 간단하게 유지합니다.복잡한 추천 웹을 사용하여 디렉터리 서비스를 배포하면 관리가 어렵습니다. 스마트 추천을 과도하게 사용하면 원형 추천 패턴이 발생할 수 있습니다. 예를 들어, 추천은 다른 LDAP URL을 가리키는 LDAP URL을 가리키므로 체인의 어느 곳에서는 다시 원래 서버를 가리킬 때까지 마찬가지입니다. 이는 아래에 설명되어 있습니다.
그림 6.10. Circular Referral Pattern
- 주요 분기에서 리디렉션합니다.디렉터리 트리의 접미사 수준에서 리디렉션을 처리하기 위해 참조 사용을 제한합니다. 스마트 추천은 다른 서버 및 DN으로 리프(branch 이외의) 항목에 대한 조회 요청을 리디렉션합니다. 결과적으로 스마트 추천을 별칭 메커니즘으로 사용하여 디렉터리 구조를 보호하기 위한 복잡하고 어려운 방법으로 이끌고 있습니다.As a result, it is tempting to use smart referrals as an alias mechanism, leading to a complex and difficult method to secure directory structure. 디렉터리 트리의 접미사 또는 주요 분기 지점으로 추천을 제한하면 관리해야 하는 추천 수가 제한되므로 디렉터리의 관리 오버헤드가 줄어듭니다.
- 보안에 미치는 영향을 고려하십시오.액세스 제어는 추천 경계를 교차하지 않습니다. 요청이 시작된 서버가 항목에 대한 액세스를 허용하는 경우에도 스마트 추천이 다른 서버로 클라이언트 요청을 보내면 클라이언트 애플리케이션이 액세스를 허용하지 않을 수 있습니다.또한 클라이언트의 인증 정보는 클라이언트가 클라이언트 인증을 수행해야 하는 서버에서 사용할 수 있어야 합니다.
6.3.2. 체인 사용
체인은 다른 서버로 요청을 릴레이하는 방법입니다. 이 방법은 데이터베이스 링크를 통해 구현됩니다. 6.2절. “디렉터리 데이터 배포” 에 설명된 데이터베이스 링크에는 데이터가 없습니다. 대신 데이터를 포함하는 원격 서버로 클라이언트 애플리케이션 요청을 리디렉션합니다.
연결 프로세스 중에 서버는 서버가 포함하지 않는 데이터에 대한 클라이언트 애플리케이션에서 요청을 수신합니다. 데이터베이스 링크를 사용하여 서버는 클라이언트 애플리케이션을 대신하여 다른 서버에 연결하여 클라이언트 애플리케이션에 결과를 반환합니다.
각 데이터베이스 링크는 데이터를 보유하는 원격 서버와 연결됩니다. 오류가 발생할 경우 데이터베이스 링크가 사용할 데이터의 복제본을 포함하는 대체 원격 서버를 구성합니다. 데이터베이스 링크 구성에 대한 자세한 내용은 Red Hat Directory Server 관리 가이드를 참조하십시오.
데이터베이스 링크는 다음과 같은 기능을 제공합니다.
- 원격 데이터에 대한 보이지 않는 액세스.데이터베이스 링크가 클라이언트 요청을 해결하므로 데이터 배포는 클라이언트에서 완전히 숨겨집니다.
- 동적 관리.디렉터리 서비스의 일부는 시스템에서 추가 또는 제거할 수 있지만 전체 시스템은 클라이언트 애플리케이션에서 계속 사용할 수 있습니다. 데이터베이스 링크는 디렉터리 서비스에서 항목이 재배포될 때까지 애플리케이션에 대한 추천을 일시적으로 반환할 수 있습니다.이는 클라이언트 애플리케이션을 데이터베이스로 전달하는 대신 추천을 반환할 수 있는 접미사 자체를 통해 구현할 수도 있습니다.
- 액세스 제어.데이터베이스 링크는 클라이언트 애플리케이션을 가장하여 원격 서버에 적절한 권한 부여 ID를 제공합니다. 액세스 제어 평가가 필요하지 않은 경우 원격 서버에서 사용자 가장을 비활성화할 수 있습니다. 데이터베이스 링크 구성에 대한 자세한 내용은 Red Hat Directory Server 관리 가이드를 참조하십시오.
6.3.3. 추천 및 체인 간 결정
디렉터리 파티션을 연결하는 두 방법에는 장단점이 있습니다. 사용할 방법 또는 방법은 디렉터리 서비스의 특정 요구 사항에 따라 다릅니다.
두 지식 참조의 주요 차이점은 분산 정보를 찾는 방법을 알고 있는 인텔리전스의 위치입니다. 연결된 시스템에서는 인텔리전스가 서버에 구현됩니다. 추천을 사용하는 시스템에서는 인텔리전스가 클라이언트 애플리케이션에서 구현됩니다.
연결로 인해 클라이언트의 복잡성이 줄어들지만 서버 복잡성이 증가할 경우 서버 복잡성이 증가합니다. 연결된 서버는 원격 서버에서 작동해야 하며 결과를 디렉터리 클라이언트로 보내야 합니다.
추천을 통해 클라이언트는 추천을 찾고 검색 결과를 배치하는 작업을 처리해야 합니다. 그러나 추천은 클라이언트 애플리케이션 작성자에게 더 많은 유연성을 제공하고 개발자가 분산 디렉터리 작업의 진행 상황에 대해 사용자에게 더 나은 피드백을 제공할 수 있도록 합니다.
다음 섹션에서는 추천과 연결 간의 보다 구체적인 차이점을 자세히 설명합니다.
6.3.3.1. 사용 차이점
일부 클라이언트 애플리케이션은 추천을 지원하지 않습니다. 연결 기능을 사용하면 클라이언트 애플리케이션이 단일 서버와 통신하고 여러 서버에 저장된 데이터에 계속 액세스할 수 있습니다. 회사의 네트워크가 프록시를 사용하는 경우 추천이 작동하지 않는 경우가 있습니다. 예를 들어 클라이언트 애플리케이션에는 방화벽 내의 하나의 서버와만 통신할 수 있는 권한이 있을 수 있습니다. 해당 애플리케이션을 다른 서버를 참조하면 성공적으로 연결할 수 없습니다.
추천을 사용할 때 클라이언트가 올바르게 인증할 수 있어야 합니다. 즉, 클라이언트를 참조하는 서버에 클라이언트의 자격 증명을 포함해야 합니다. 연결에서는 클라이언트 인증이 한 번만 수행됩니다. 클라이언트는 요청이 연결되는 서버에서 다시 인증할 필요가 없습니다.
6.3.3.2. 액세스 제어 평가
체인은 추천과 다르게 액세스 제어를 평가합니다. 추천 기능을 사용하면 클라이언트의 항목이 모든 대상 서버에 있어야 합니다. 연결에서 클라이언트 항목이 모든 대상 서버에 있을 필요는 없습니다.
Referrals를 사용하여 검색 요청 수행
다음 다이어그램은 추천을 사용하여 서버에 대한 클라이언트 요청을 보여줍니다.
그림 6.11. Referrals를 사용하여 클라이언트 요청을 서버로 전송
위의 그림에서 클라이언트 애플리케이션은 다음 단계를 수행합니다.
- 클라이언트 애플리케이션은 먼저 서버 A와 바인딩합니다.
- 서버 A에는 사용자 이름과 암호를 제공하는 클라이언트에 대한 항목이 포함되어 있어 바인딩 수락 메시지를 반환합니다. 추천이 작동하려면 클라이언트 항목이 서버 A에 있어야 합니다.
- 클라이언트 애플리케이션은 작업 요청을 서버 A로 보냅니다.
- 그러나 서버 A에는 요청된 정보가 포함되어 있지 않습니다. 대신 Server A는 서버 B에 연결하도록 지시하는 클라이언트 애플리케이션에 대한 참조를 반환합니다.
- 그러면 클라이언트 애플리케이션이 서버 B로 바인드 요청을 보냅니다. 성공적으로 바인딩하려면 서버 B에도 클라이언트 애플리케이션에 대한 항목이 포함되어야 합니다.
- 바인딩에 성공하고 클라이언트 애플리케이션에서 검색 작업을 Server B로 다시 제출할 수 있습니다.
이 방법을 사용하려면 서버 B가 서버 A에서 클라이언트 항목의 복제 복사본을 보유해야 합니다.
체인을 사용하여 검색 요청 수행
서버 간에 클라이언트 항목을 복제하는 문제는 체인을 사용하여 해결됩니다. 체인 시스템에서 검색 요청은 응답이 있을 때까지 여러 번 전달됩니다.
그림 6.12. 체인 작업을 사용하여 클라이언트 요청을 서버로 전송
위의 그림에서는 다음 단계가 수행됩니다.
- 클라이언트 애플리케이션이 서버 A에 바인딩되고 서버 A는 사용자 이름과 암호가 올바른지 확인합니다.
- 서버 A에는 클라이언트 애플리케이션에 해당하는 항목이 포함되어 있지 않습니다. 대신 클라이언트의 실제 항목이 포함된 서버 B에 대한 데이터베이스 링크가 포함되어 있습니다. 서버 A는 서버 B에 바인딩 요청을 보냅니다.
- 서버 B는 서버 A에 수락 응답을 보냅니다.
- 서버 A는 데이터베이스 링크를 사용하여 클라이언트 애플리케이션의 요청을 처리합니다. 데이터베이스 링크는 서버 B에 있는 원격 데이터 저장소에 연결하여 검색 작업을 처리합니다.
연결된 시스템에서 클라이언트 애플리케이션에 해당하는 항목을 클라이언트가 요청하는 데이터와 동일한 서버에 배치할 필요가 없습니다.
그림 6.13. 다른 서버를 사용하여 클라이언트 인증 및 데이터 검색
이 그림에서는 다음 단계가 수행됩니다.In this illustration, the following steps are performed:
- 클라이언트 애플리케이션이 서버 A에 바인딩되고 서버 A는 사용자 이름과 암호가 올바른지 확인합니다.
- 서버 A에는 클라이언트 애플리케이션에 해당하는 항목이 포함되어 있지 않습니다. 대신 클라이언트의 실제 항목이 포함된 서버 B에 대한 데이터베이스 링크가 포함되어 있습니다. 서버 A는 서버 B에 바인딩 요청을 보냅니다.
- 서버 B는 서버 A에 수락 응답을 보냅니다.
- 그러면 서버 A가 다른 데이터베이스 링크를 사용하여 클라이언트 애플리케이션의 요청을 처리합니다. 데이터베이스 링크는 검색 작업을 처리하기 위해 서버 C에 있는 원격 데이터 저장소에 연결합니다.
지원되지 않는 액세스 제어
데이터베이스 링크는 다음 액세스 제어를 지원하지 않습니다.
- 사용자 항목이 다른 서버에 있는 경우 사용자 항목의 콘텐츠에 액세스해야 하는 제어는 지원되지 않습니다. 여기에는 그룹, 필터 및 역할을 기반으로 하는 액세스 제어가 포함됩니다.
- 클라이언트 IP 주소 또는 DNS 도메인을 기반으로 하는 제어는 거부될 수 있습니다. 이는 데이터베이스 링크가 원격 서버에 연결할 때 클라이언트를 가장하기 때문입니다. 원격 데이터베이스에 IP 기반 액세스 제어가 포함된 경우 원래 클라이언트 도메인이 아닌 데이터베이스 링크의 도메인을 사용하여 평가합니다.
