티켓의 유형

티켓에는 티켓의 사용 방식을 제어하는 등록 정보가 있습니다. 이러한 등록 정보는 티켓을 만들 때 지정되지만, 나중에 사용자가 티켓의 등록 정보를 수정할 수도 있습니다. 예를 들어 티켓은 forwardable에서 forwarded로 변경될 수 있습니다. 티켓 등록 정보는 klist 명령으로 확인할 수 있습니다. Kerberos 티켓 확인을 참조하십시오.

티켓은 다음 용어 중 하나 이상으로 설명할 수 있습니다.

Forwardable/forwarded

전달 가능 티켓은 한 호스트에서 다른 호스트로 전송될 수 있으므로, 클라이언트 재인증이 필요하지 않습니다. 예를 들어 사용자 david가 사용자 jennifer의 시스템에서 전달 가능 티켓을 얻은 경우, david는 새 티켓 없이도 자신의 시스템에 로그인할 수 있으므로 다시 인증할 필요가 없습니다. 전달 가능 티켓에 대한 예는 Example 6–1을 참조하십시오.

초기

초기 티켓이란 TGT(티켓 부여 티켓)를 기반으로 하지 않고 직접 발행되는 티켓입니다. 암호가 달라지는 응용 프로그램과 같은 일부 서비스의 경우 티켓을 "초기"로 표시해야 클라이언트에 보안 키가 있음을 입증할 수 있습니다. 초기 티켓은 클라이언트가 더 오래되었을 수 있는 TGT(티켓 부여 티켓)에 의존하지 않고 최근에 인증되었음을 나타냅니다.

잘못됨

잘못된 티켓은 아직 사용 가능하지 않은 후일자 티켓으로, 검증될 때까지 애플리케이션 서버에서 거부됩니다. 티켓을 검증하려면 티켓 시작 시간이 경과한 후 클라이언트가 TGS(티켓 부여 서비스) 요청에서 –VALIDATE 플래그를 설정하여 티켓을 KDC에 제공해야 합니다.

후일자 가능/후일자

후일자 티켓이란 생성 후 지정된 시간이 경과해야 유효해지는 티켓입니다. 예를 들어 티켓이 도난 당하더라도 일괄 처리 작업이 실행될 때까지는 사용할 수 없으므로, 이러한 티켓은 나중에 야간에 실행하려는 일괄 처리 작업에 유용합니다. 후일자 티켓은 발행된 후 시작 시간이 경과할 때까지 유효하지 않은 상태로 유지되며, 클라이언트에서는 KDC의 검증을 요청합니다. 후일자 티켓은 보통 TGT(티켓 부여 티켓)의 만료 시간까지 유효합니다. 그러나 티켓이 갱신 가능한 것으로 표시된 경우 티켓의 수명은 TGT(티켓 부여 티켓)의 전체 수명 지속 기간과 동일하게 설정됩니다.

프록시 가능/프록시

때때로 서비스가 주체를 대신해 작업을 수행해야 하는 경우가 있습니다. 티켓을 만들 때 프록시의 주체 이름을 지정해야 합니다. Oracle Solaris에서는 프록시 가능 또는 프록시 티켓을 지원하지 않습니다.

프록시 가능 티켓은 전달 가능 티켓과 비슷하지만, 단일 서비스에 대해서만 유효한 반면 전달 가능 티켓은 클라이언트 ID의 완전한 사용 권한을 부여합니다. 따라서 전달 가능 티켓은 일종의 수퍼 프록시로 간주될 수 있습니다.

갱신 가능

티켓을 매우 오랫동안 사용하는 것은 보안상 위험하므로 티켓을 갱신 가능하도록 지정할 수 있습니다. 갱신 가능 티켓에는 두 개의 만료 시기가 있습니다. 즉, 티켓의 현재 인스턴스가 만료되는 시기와 티켓의 최대 수명(1주)입니다. 클라이언트에서 계속 티켓을 사용하려는 경우 첫번째 만료가 발생하기 전에 티켓을 갱신합니다. 예를 들어 모든 티켓의 최대 수명이 10시간일 경우 한 티켓은 한 시간 동안 유효할 수 있다고 가정해 보십시오. 티켓을 보유하고 있는 클라이언트가 티켓을 한 시간 이상 보존하려는 경우에는 해당 시간 내에 티켓을 갱신해야 합니다. 티켓이 최대 티켓 수명(10시간)에 도달하면 자동으로 만료되므로 갱신할 수 없습니다.

티켓 속성을 확인하는 방법에 대한 자세한 내용은 Kerberos 티켓 확인을 참조하십시오.

티켓 수명

주체가 TGT(티켓 부여 티켓)를 포함한 티켓을 얻으면 티켓의 수명은 다음 수명 값 중 가장 작은 값으로 설정됩니다.

• kinit의 –l 옵션에 지정된 수명 값(kinit를 사용하여 티켓을 얻은 경우). 기본적으로 kinit는 최대 수명 값을 사용합니다.

• kdc.conf 파일에 지정된 최대 수명 값(max_life)

• 티켓을 제공하는 서비스 주체의 Kerberos 데이터베이스에 지정된 최대 수명 값. kinit의 경우 서비스 주체는 krbtgt/realm입니다.

• 티켓을 요청하는 사용자 주체의 Kerberos 데이터베이스에 지정된 최대 수명 값

다음 그림은 TGT의 수명이 결정되는 방식과 네 가지 수명 값이 비롯되는 위치를 보여 줍니다. 주체가 티켓을 얻으면 비슷한 방식으로 티켓의 수명이 결정됩니다. 단, kinit가 수명 값을 제공하지 않고, 티켓을 제공하는 서비스 주체가 krbtgt/realm 주체 대신 최대 수명 값을 제공한다는 두 가지 점만 다릅니다.

그림 7-1  TGT의 수명이 결정되는 방식

갱신 가능 티켓의 수명도 다음과 같이 네 갱신 가능 값 중 가장 작은 값에서 결정됩니다.

• kinit의 –r 옵션으로 지정된 갱신 가능한 수명 값(kinit를 사용하여 티켓을 얻었거나 갱신한 경우)

• kdc.conf 파일에 지정된 최대 갱신 가능한 수명 값(max_renewable_life )

• 티켓을 제공하는 서비스 주체의 Kerberos 데이터베이스에 지정된 최대 갱신 가능한 수명 값. kinit의 경우 서비스 주체는 krbtgt/realm입니다.

• 티켓을 요청하는 사용자 주체의 Kerberos 데이터베이스에 지정된 갱신 가능한 최대 수명 값

Kerberos 주체 이름

각 티켓은 주체 이름으로 식별됩니다. 주체 이름으로 사용자나 서비스를 식별할 수 있습니다. 다음 예에서는 일반 주체 이름을 보여 줍니다.

changepw/kdc1.example.com @EXAMPLE.COM

암호를 변경할 때 KDC에 액세스할 수 있도록 해주는 마스터 KDC 서버에 대한 주체입니다.

clntconfig/admin@EXAMPLE.COM

kclient 설치 유틸리티에서 사용하는 주체입니다.

ftp/boston.example.com @EXAMPLE.COM

ftp 서비스에서 사용하는 주체입니다. 이 주체는 host 주체 대신 사용할 수 있습니다.

host/boston.example.com @EXAMPLE.COM

Kerberos화된 응용 프로그램(예: klist 및 kprop) 및 서비스(예: ftp 및 telnet)에서 사용하는 주체입니다. 이 주체를 host 또는 서비스 주체라고 합니다. 이 주체는 NFS 마운트를 인증하는 데 사용되며, 클라이언트에 발행된 TGT가 올바른 KDC에서 제공되는지 클라이언트에서 확인하는 데도 사용됩니다.

K/M@EXAMPLE.COM

마스터 키 이름 주체입니다. 마스터 KDC별로 하나의 마스터 키 이름이 연관됩니다.

kadmin/history@EXAMPLE.COM

다른 주체에 대한 암호 사용 기록을 보존하는 데 사용되는 키를 포함하는 주체입니다. 하나의 마스터 KDC에는 이러한 주체 중 하나가 포함되어 있습니다.

kadmin/kdc1.example.com @EXAMPLE.COM

kadmind 명령을 사용하여 KDC에 액세스할 수 있도록 해주는 마스터 KDC 서버에 대한 주체입니다.

kadmin/changepw.exam ple.com@EXAMPLE.COM

Oracle Solaris 릴리스에서 실행 중이지 않은 클라이언트의 암호 변경 요청을 수락하는 데 사용되는 주체입니다.

krbtgt/EXAMPLE.COM @EXAMPLE.COM

이 주체는 TGT(티켓 부여 티켓)를 생성할 때 사용됩니다.

krbtgt/EAST.EXAMPLE.COM @WEST.EXAMPLE.COM

이 주체는 영역 간 TGT(티켓 부여 티켓)의 한 예입니다.

nfs/boston.example.com @EXAMPLE.COM

NFS 서비스에서 사용하는 주체입니다. 이 주체는 host 주체 대신 사용할 수 있습니다.

root/boston.example.com @EXAMPLE.COM

클라이언트의 root 계정과 연관된 주체입니다. 이 주체는 root 주체라고 하며 NFS 마운트 파일 시스템에 대한 root 액세스 권한을 제공합니다.

username @EXAMPLE.COM

사용자 주체입니다.

username/admin@EXAMPLE.COM

KDC 데이터베이스를 관리하는 데 사용할 수 있는 admin 주체입니다.