Windows Server 2003 Kerberos 인증의 새로운 기능
|
이 페이지에서
 | 소개 |
| 이점 |
소개
이 페이지에서는 Windows Server 2003의 Kerberos 인증의 새로운 기능을 요약하고 이 새로운 기능을 사용하기 위해 필요한 기본적인 정보를 제공합니다.
이 정보는 Windows Server 2003을 테스트 및 배포하는 관리자에게 도움을 주고자 마련되었습니다. Windows 2000에서 사용할 수 있었던 Kerberos 인증 기능은 그대로 사용 가능하며 다른 제품 라인으로 이동되지 않았습니다.
이점
| 새로운 기능 | 설명 | ||||||||
Windows XP 클라이언트 로그온을 위해 컴퓨터 계정이 필요 없음 | 대개 Kerberos 인증을 위해서는 컴퓨터 계정이 필요합니다. 사용자가 컴퓨터의 리소스에 액세스할 수 있으려면 컴퓨터의 서비스 티켓을 획득해야 합니다. 이러한 사용자와 호스트 간 인증이 없으면, 호스트 컴퓨터가 로컬 계정 데이터베이스에서 유지 관리하는 이름에 대한 사용자 이름 매핑을 기준으로 액세스 제어를 수행해야 합니다. 사용자는 로컬 매핑을 설정하기 위해 KSETUP을 실행해야 합니다. | ||||||||
SPN이 더 이상 정규화되지 않음 | 과거에는 SPN이 보안 계정 관리자(SAM) 계정 이름(예: mycomputer$)에 대해 정규화(canonicalize)되었습니다. 이로 인해 사용자가 비정규적 이름으로 서비스를 요청할 경우 문제가 발생했습니다. 이 경우 시스템이 서비스를 위해 캐시된 티켓을 갖고 있는지 감지할 수 없어서 새 서비스 티켓을 요청할 수 있습니다. 이제 이름 정규화(canonicalization) 없이도 요청된 SPN을 사용하기만 하면 이 문제가 해결됩니다. | ||||||||
서비스 티켓을 발행하기 위한 키 배포 센터(KDC)의 서비스로 동작하는 보안 사용자에 대해 SPN이 설정되어야 합니다. | 이는 KDC가 SPN이 없는 계정(예: 사용자 계정)에 대해서는 서비스 티켓을 발행하지 않음을 의미합니다. 이로 인해, 서비스가 사람에 의해 생성된 암호를 가진 사용자 계정인 경우 그 서비스에 대한 오프라인 사전 공격을 시작하기가 더 쉬워질 수 있습니다. SPN이 없는 계정에 대해 KDC는 사용자 대 사용자(User-2-User)가 필요하다는 오류 메시지를 반환합니다. | ||||||||
클라이언트 주소 확인 강화 | Windows 2000 KDC는 티켓이 존재하는 경우 티켓의 주소를 확인합니다. 하지만 Windows 2000 KDC는 요청된 주소를 티켓에 두지 않습니다. 기본적으로 Windows Server 2003 KDC는 Windows 2000 클라이언트와 호환됩니다. Windows Server 2003 KDC는 새 레지스트리 항목(DWORD 값이 1인 HKLM/System/CCS/Services/Kdc/KdcUseClientAddresses)이 만들어지지 않는 한 AS-REQ의 주소를 티켓으로 전파하지 않습니다. 티켓이 티켓 부여 서비스(TGS)에 제시될 때, 주소가 제공된 경우 주소를 확인합니다. Windows Server 2003에서 이를 비활성화하려면 레지스트리 항목(DWORD 값이 0인 HKLM/System/CCS/Services/Kdc/KdcDontCheckAddresses)을 추가하면 됩니다. 기본값이 Windows 2000과 호환되도록 제시되어 있는 경우 기본적으로 주소를 확인합니다. 관리자는 레지스트리에 다음 항목을 추가하여 두 개의 새로운 Windows Server 2003 KDC 기능을 구성할 수 있습니다. HKLM/System/CCS/Services/Kdc/KdcUseClientAddresses KDC가 클라이언트 주소를 티켓으로 전파할지 여부를 제어합니다.
HKLM/System/CCS/Services/Kdc/KdcDontCheckAddresses KDC가 클라이언트 주소를 확인할지 여부를 제어합니다.
| ||||||||
키 버전 번호 옵션 지원 | 키 버전 번호는 Kerberos 사양의 선택적 부분입니다. 키 버전 번호는 데이터가 유효 기간이 긴 키로 암호화될 경우 Kerberos 암호화 데이터의 일부로 포함될 수 있습니다. Windows Server 2003에는 키 버전 번호의 사용이 도입되었습니다. 키 버전 번호에 대한 자세한 내용은 Windows Server 2003 기술 관련 자료 (영문)를 참조하십시오. | ||||||||
암호화 유형 선택 | Windows 2000에서 KDC는 최초의 암호화 유형을 선택합니다. Windows Server 2003에서 KDC는 클라이언트에서 지원하는 가장 강력한 암호화 유형을 선택합니다. | ||||||||
Windows XP 및 Windows 2000 SP2 이상에서의 TGT 갱신 | TGT는 기본 수명이 10시간이지만 최대 7일(기본값) 동안 갱신될 수 있습니다. 갱신에는 자격 증명이 필요하지 않습니다. 갱신은 TGT가 만료후 5분 내에 사용될 경우에만 발생합니다. 그렇지 않을 경우 TGT가 만료되므로 새로 고쳐져야 합니다(자격 증명 필요). | ||||||||
Windows Server 2003에서의 TGT 갱신 | TGT는 기본 수명이 10시간이지만 최대 7일(기본값) 동안 갱신될 수 있습니다. 갱신에는 자격 증명이 필요하지 않습니다. 갱신은 시스템에서 스캐빈저(scavenger) 스레드의 사용을 통해 발생합니다. 어떤 이유로 인해 TGT가 갱신될 수 없었다면 TGT가 만료되므로 새로 고쳐져야 합니다(자격 증명 필요). Windows XP 및 Windows 2000 SP2 이상에서는 TGT가 만료후 5분 내에 사용될 경우 TGT 갱신이 트리거됩니다. Windows Server 2003에서는 시스템이 만료되는 TGT를 정기적으로 자동으로 갱신합니다. | ||||||||
제약된 위임 | Kerberos는 항상 클라이언트가 중개 서버에 TGT(Ticket-Granting Ticket)를 위임할 수 있도록 하는 메커니즘을 제공해 왔습니다. 따라서 중개자가 클라이언트를 대신하여 다른 서비스에 대한 서비스 티켓을 얻을 수 있습니다. 예를 들어 이러한 위임을 이용하면 트리 계층 시나리오에서 중개자가 최종 응용 프로그램에 대해 클라이언트를 가장할 수 있습니다. 그러나 이 메커니즘은 중개자가 클라이언트로서 모든 서비스에 대한 티켓을 획득할 수 있게 해줍니다. 제약된 위임은 Windows Server 2003의 기능으로서, 중개자가 위임된 티켓을 획득하도록 인증된 서비스에 대해서만(관리 정책의 결정에 따름) 도메인 컨트롤러가 중개자에게 티켓을 발행합니다. 따라서 중개자의 위임 능력은 관리 정책에 의해 제약됩니다. | ||||||||
프로토콜 전환을 이용한 제약된 위임 | 프로토콜 전환은 클라이언트를 처음에 Kerberos 인증을 사용하여 인증할 필요 없이 중개자가 티켓을 요청할 수 있는 기능입니다. 따라서 중개자를 인증하기 위해 SSL(Secure Sockets Layer)을 사용하고 중개자는 최종 응용 프로그램에 대해 Kerberos 인증을 사용할 수 있습니다. 자세한 내용은 Kerberos 프로토콜 전환 및 제약된 위임 (영문)을 참조하십시오. | ||||||||
포리스트 트러스트 | 많은 조직들이 여러 포리스트를 배포하지만 다른 조직의 포리스트 간에 공동 작업이 필요한 경우가 있습니다. 이런 경우가 발생하면 외부 트러스트 관계 확립에 엄청난 양의 관리가 필요한데 여기에 진보된 최신 기술을 이용하지 않습니다. Windows Server 2003에서는 여러 포리스트 배포를 더 쉽게 만드는 포리스트 트러스트 개념을 사용합니다. 이 포리스트 트러스트를 이용하면 관리자가 두 개의 Active Directory 포리스트를 하나의 트러스트 관계로 연합하여 포리스트 전체에 걸쳐 원활한 인증 및 권한 부여 경험을 제공할 수 있습니다. 자세한 내용은 Windows Server 2003에서 연합 포리스트 계획 및 구현 (영문)을 참조하십시오. |