11.5. Cross-Realm Kerberos 트러스트 설정
Kerberos V5 영역은 연결된 모든 마스터 및 슬레이브의 Kerberos 데이터베이스에 정의된 Kerberos 사용자 집합입니다. 서로 통신하기 위해 다양한 영역의 주체가 서로 통신하려면 교차 영역 Kerberos 트러스트를 구성해야 합니다.
많은 Linux 환경과 혼합 환경은 이미 SSO(Single Sign-On), 애플리케이션 인증 및 사용자 관리를 위해 Kerberos 영역이 배포되어 있습니다. 이는 특히 Linux 환경이 ID 관리와 같은 구조화된 도메인 구성을 사용하지 않는 경우 Kerberos가 서로 다른 도메인 및 혼합 시스템(예: Windows 및 Linux) 환경에 대한 일반적인 통합 경로입니다.
11.5.1. 신뢰 관계
신뢰 는 한 영역 내의 사용자가 해당 영역에 속해 있는 것처럼 다른 도메인의 리소스에 액세스하도록 신뢰할 수 있음을 의미합니다. 이 작업은 두 도메인에서 공통으로 보유하는 단일 주체에 대해 공유 키를 만들어 수행됩니다.
그림 11.2. 기본 신뢰
그림 11.2. “기본 신뢰” 에서 공유 주체는 도메인 B(krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM)에 속합니다. 해당 주체도 도메인 A에 추가되면 도메인 A의 클라이언트는 도메인 B의 리소스에 액세스할 수 있습니다. 구성된 주체는 두 영역에 모두 있습니다. 공유 주체는 다음 세 가지 특성을 갖습니다.
- 두 영역에 모두 존재합니다.
- 키가 생성되면 두 영역에서 동일한 암호가 사용됩니다.
- 키의 키 버전 번호(
kvno)가 같습니다.
교차 영역 신뢰는 기본적으로 단방향입니다. 이 신뢰는 자동으로 복구되지 않으므로
B.EXAMPLE.COM 영역이 A.EXAMPLE.COM 영역의 서비스에 인증할 수 있습니다. 다른 방향으로 신뢰를 설정하려면 두 영역 모두 krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM 서비스의 키를 공유해야 합니다. - 이전 예제의 역방향 매핑이 있는 항목입니다.
영역에는 여러 개의 신뢰가 있을 수 있으며, 두 영역 모두 신뢰하는 영역과 신뢰할 수 있는 영역입니다. Kerberos를 신뢰하면 체인으로 신뢰가 쌓을 수 있습니다. Realm A가 Realm B와 Realm B가 Realm C를 신뢰한다면 Realm A도 Realm C를 신뢰합니다. 신뢰는 영역을 따라가며, 이는 전이적인 신뢰입니다.
그림 11.3. 전향적인 신뢰
전향적인 신뢰의 방향은 신뢰 흐름 입니다. 신뢰 흐름을 정의해야 합니다. 먼저 서비스가 속한 영역을 인식한 다음 클라이언트에서 해당 서비스에 액세스하기 위해 연결해야 하는 영역을 식별하여 정의해야 합니다.
Kerberos 주체 이름은 service/hostname@REALM 형식으로 구성됩니다. 서비스는 일반적으로 LDAP, IMAP, HTTP 또는 호스트와 같은 프로토콜입니다. 호스트 이름은 호스트 시스템의 정규화된 도메인 이름이며 REALM 은 속해 있는 Kerberos 영역입니다. Kerberos 클라이언트는 일반적으로 Kerberos 영역 매핑에 호스트 이름 또는 DNS 도메인 이름을 사용합니다. 이 매핑은 명시적이거나 암시적일 수 있습니다. 명시적 매핑은
/etc/krb5.conf 파일의 [domain_realm] 섹션을 사용합니다. 암시적 매핑을 사용하면 도메인 이름이 대문자로 변환됩니다. 그런 다음 변환된 이름은 검색할 Kerberos 영역으로 간주됩니다.
신뢰를 전달하는 경우 Kerberos는 각 영역이 루트 도메인 및 하위 도메인을 사용하는 계층형 DNS 도메인과 같이 구성되어 있다고 가정합니다. 즉, 신뢰는 공유 루트로 이동합니다. 각 단계 또는 홉 에는 공유 키가 있습니다. 그림 11.4. “동일한 도메인에서의 신뢰” 에서 SALES.EXAMPLE.COM은 EXAMPLE.COM과 키를 공유하며 EXAMPLE.COM은 EVERYWHERE.EXAMPLE.COM과 키를 공유합니다.
그림 11.4. 동일한 도메인에서의 신뢰
클라이언트는 영역 이름을 DNS 이름으로 처리하고, 루트 이름에 도달할 때까지 자체 영역 이름의 요소를 제거하여 신뢰 경로를 결정합니다. 그런 다음 이름 앞에 붙은 이름이 서비스 영역에 도달할 때까지 시작됩니다.
그림 11.5. 동일한 도메인의 자식/기존 신뢰
이는 전향적인 신뢰의 속성입니다. SITE.SALES.EXAMPLE.COM에는 SALES.EXAMPLE.COM이 포함된 하나의 공유 키만 있습니다. 하지만 일련의 신뢰감으로 인해 SITE.SALES.EXAMPLE.COM에서 EVERYWHERE.EXAMPLE.COM으로 신뢰가 가능합니다.
이 신뢰 흐름은 사이트에서 공통 접미사를 공유하지 않는 도메인 수준에서 공유 키를 만들어 완전히 다른 도메인 간에도 이동할 수 있습니다.
그림 11.6. 다른 도메인의 신뢰
[capaths] 섹션
또한 흐름을 명시적으로 정의하여 홉 수를 줄이고 매우 복잡한 신뢰 흐름을 나타낼 수 있습니다.
/etc/krb5.conf 파일의 [capaths] 섹션은 서로 다른 영역 간의 신뢰 흐름을 정의합니다.
[capaths] 섹션 형식은 비교적 간단합니다. 클라이언트에 주체가 있는 각 영역의 주요 항목이 있으며, 각 realm 섹션 내에는 클라이언트가 자격 증명을 받아야 하는 중간 영역 목록이 있습니다.
예를 들어
[capaths] 를 사용하여 인증 정보를 가져오기 위한 다음 프로세스를 지정할 수 있습니다.
- 클라이언트는 A의 인증 정보를 사용하여 클라이언트는 KDC A에서
krbtgt/A@A티켓을 받습니다. 이 티켓을 사용하면 클라이언트는krbtgt/B@A티켓을 요청합니다.krbtgt/B@A티켓은 KDC A 에서 발행한 티켓입니다. 이를 통해 고객은 Realm B의 서비스 주체에게 티켓을 요청하도록 Realm B의 KDC에 요청할 수 있습니다. krbtgt/B@A티켓을 사용하면 클라이언트에서krbtgt/C@Bcross-realm 티켓을 요청합니다.krbtgt/C@B티켓에서 krbtgt/C@B 티켓에서 발급한 상태에서 클라이언트는krbtgt/D@Ccross-realm 티켓을 요청합니다.krbtgt/D@C티켓에서 발행한 krbtgt/D@C 티켓에서 client는 Cryostat D의 서비스 주체에 대한 티켓을 요청합니다.
이 후 인증 정보 캐시에는
krbtgt/A@A,krbtgt/B@A,krbtgt/C@B,krbtgt/D@C, service/hostname@D 에 대한 티켓이 포함되어 있습니다. 서비스/hostname@D 티켓을 얻으려면 3개의 중간 교차 실제 티켓을 받아야 했습니다.
[capaths] 구성 예제를 포함하여 [capaths] 섹션에 대한 자세한 내용은 krb5.conf(5) 도움말 페이지를 참조하십시오.
11.5.2. Realm Trust 설정
이 예제에서 Kerberos 영역은 A.EXAMPLE.COM 및 B.EXAMPLE.COM 입니다.
kadmin 을 사용하여 A 영역의 B 영역에 대한 공유 주체의 항목을 만듭니다.
[root@server ~]# kadmin -r A.EXAMPLE.COM kadmin: add_principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM Enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM": Re-enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM": Principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" created. quit
즉, A 영역이 B 주체를 신뢰함을 의미합니다.
중요
교차 영역 주체에 대해 매우 강력한 암호를 선택하는 것이 좋습니다. 사용자가 하루에 여러 번 표시되는 다른 암호와 달리 시스템은 자주 교차 영역 주체에 대한 암호를 요청하지 않습니다. 따라서 기억하기 쉬운 것은 아닙니다.
양방향 신뢰성을 만든 후 그 반대 방향으로 원칙을 만드십시오. kadmin 을 사용하여 B 영역에서 A 영역에 대한 주체를 생성합니다.
[root@server ~]# kadmin -r B.EXAMPLE.COM kadmin: add_principal krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM Enter password for principal "krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM": Re-enter password for principal "krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM": Principal "krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM" created. quit
get_principal 명령을 사용하여 두 항목이 모두 일치하는 키 버전 번호(
kvno 값) 및 암호화 유형이 있는지 확인합니다.
중요
일반적이지만 잘못된 상황은 관리자가 add_principal 명령의
-randkey 옵션을 사용하여 암호 대신 임의의 키를 할당하고 첫 번째 영역의 데이터베이스에서 새 항목을 덤프한 다음 두 번째 항목으로 가져오는 것입니다. 데이터베이스 덤프에 포함된 키가 master 키를 사용하여 암호화되므로 영역 데이터베이스의 마스터 키가 동일하지 않는 한 이 작업은 작동하지 않습니다.
