Microsoft SharePoint 2010 제품용 Kerberos 인증 개요

아티클
03/03/2017

적용 대상: SharePoint Server 2010

마지막으로 수정된 항목: 2016-11-30

Microsoft SharePoint 2010 제품에서는 플랫폼에서 ID가 관리되는 방법이 크게 개선되었습니다. 이러한 변경 내용이 솔루션 디자인과 플랫폼 구성에 어떤 영향을 주어 사용자 ID를 통합 시스템에 위임해야 하는 시나리오를 수행할 수 있도록 하는지를 이해해야 합니다. Kerberos 버전 5 프로토콜은 위임을 사용하는 데 있어서 중요한 역할을 하며, 이러한 시나리오에서 반드시 Kerberos 프로토콜을 사용해야 하는 경우도 있습니다.

이 문서 집합에서는 다음을 수행하는 데 도움이 되는 정보를 제공합니다.

SharePoint 2010 제품에서 ID의 개념 이해
인증 및 위임 시나리오에서 Kerberos 인증이 어떤 중요한 역할을 하는지 확인
솔루션 디자인에서 Kerberos 인증을 사용해야 하거나 Kerberos 인증이 필요할 수 있는 상황 파악
환경 내에서 전체 Kerberos 인증 구성(SharePoint Server에서 다양한 서비스 응용 프로그램을 사용하는 시나리오 포함)
Kerberos 인증이 올바르게 구성되었으며 정상적으로 작동하는지 테스트 및 유효성 검사
작업 환경에서 Kerberos 인증을 구성하는 데 사용할 수 있는 추가 도구 및 리소스 찾기

이 문서 집합은 다음과 같은 두 가지 주요 섹션으로 구분됩니다.

SharePoint 2010 제품의 Kerberos 인증 개요

이 문서에서는 SharePoint 2010 제품에서 ID를 관리하는 방법과 Kerberos 프로토콜에 대한 개념 정보를 제공하고, SharePoint 2010 솔루션에서 Kerberos 인증이 어떤 중요한 역할을 하는지 소개합니다.
단계별 구성

이 문서 그룹에서는 다양한 SharePoint 솔루션 시나리오에서 Kerberos 인증 및 위임을 구성하기 위해 수행해야 하는 단계를 설명합니다.

Kerberos 인증과 관련한 이 문서의 대상 독자

SharePoint 2010 제품의 ID 및 위임은 광범위한 주제이며 이해의 측면과 수준도 달라질 수 있습니다. 이 문서 집합에서는 해당 주제를 개념적 수준과 기술적 수준에서 모두 다루며, 다양한 독자의 요구를 충족할 수 있도록 작성되었습니다.

초보 사용자에서 고급 사용자까지

이 문서에서는 SharePoint 2010 제품의 ID 및 Kerberos에 대한 모든 측면을 설명합니다.

SharePoint 2010 제품, Kerberos 인증 및 클레임 인증을 처음 사용하며 아직 익숙치 않은 경우에는 이 문서의 첫 번째 섹션을 확인하십시오. 이 섹션에서는 ID 및 위임의 기본 개념을 소개하고 클레임 인증 및 Kerberos 인증의 주요 사항에 대해 설명합니다. 단계별 구성 문서로 계속 진행하기 전에, 반드시 외부 문서 및 추가 정보 링크를 따라 이동하여 이 문서에서 제공하는 정보를 더욱 명확하게 이해할 수 있도록 하십시오.

Office SharePoint Server 2007에서 업그레이드

이 문서에서는 2007 버전에서 달라진 점과 2010 버전으로 업그레이드하기 위해 준비해야 할 사항을 설명합니다.

기존 Microsoft Office SharePoint Server 2007 환경에서 이미 Kerberos 인증 및 Kerberos 위임을 사용하도록 구성한 경우에는 다음 문서의 내용을 확인해야 합니다.

SharePoint 2010 제품의 시나리오 파악
클레임 주요 사항
Windows 2008 R2 및 Windows 7의 Kerberos 인증 변경 내용
SharePoint 2010 제품의 Kerberos 구성 변경 내용
SharePoint Server 2007에서 업그레이드할 때의 고려 사항

특정 기능이나 시나리오에 대해 위임을 구성하는 방법에 대한 추가 문의 사항이 있는 경우 단계별 구성 문서, 특히 구성 검사 목록을 확인하십시오. 그러면 업그레이드 후에 환경을 올바르게 구성하는 데 도움이 됩니다.

단계별 연습

이 문서에서는 SharePoint Server의 Kerberos 위임 및 해당하는 SharePoint Server 서비스 응용 프로그램을 구성하는 방법에 대한 단계별 지침을 제공합니다.

단계별 구성 문서에서는 Kerberos 위임을 사용하여 구성할 수 있는 여러 SharePoint 2010 제품 시나리오에 대해 다룹니다. 각 시나리오에는 자세한 설명이 포함되어 있으며, 실제 환경에서 Kerberos 인증을 구성하는 데 사용할 수 있는 구성 검사 목록 및 단계별 지침도 포함되어 있습니다. 이 문서에서 다루는 시나리오는 다음과 같습니다.

시나리오 1: 핵심 구성
시나리오 2: SQL OLTP용 Kerberos 인증
시나리오 3: SQL Analysis Services용 Kerberos 인증
시나리오 4: SQL Reporting Services용 ID 위임
시나리오 5: Excel Services용 ID 위임
시나리오 6: PowerPivot for SharePoint 2010용 ID 위임
시나리오 7: Visio Services용 ID 위임
시나리오 8: PerformancePoint Services용 ID 위임
시나리오 9: Business Connectivity Services용 ID 위임

첫 번째 핵심 구성 시나리오는 그 이후의 모든 시나리오에 대한 전제 조건이므로 철저하게 검토하십시오.

참고

위의 시나리오에는 "SetSPN" 명령이 포함되어 있는데, 이 문서에서 해당 명령을 복사하여 명령 프롬프트 창에 붙여 넣을 수 있습니다. 이러한 명령에는 하이픈 문자가 포함되어 있습니다. Microsoft Word에는 하이픈을 대시 문자로 변환하는 자동 서식 기능이 있습니다. Word에서 이 기능을 설정한 상태로 복사하여 붙여넣기 작업을 수행하면 명령이 올바르게 작동하지 않습니다. 이 오류를 해결하려면 대시를 하이픈으로 변경하십시오. Word에서 이 자동 서식 기능을 해제하려면 파일 메뉴에서 옵션을 선택하고 언어 교정 탭을 클릭한 후에 자동 고침 대화 상자를 엽니다.

기존 SharePoint 2010 제품 환경

기존에 SharePoint 2010 제품 환경을 사용하고 있는데 Kerberos 인증의 작동 방법을 모르는 경우, 이 문서에서는 구성을 확인하고 디버그하는 데 필요한 정보를 제공합니다.

단계별 구성 문서에는 다양한 시나리오에서 환경을 분류하는 데 사용할 수 있는 여러 검사 목록이 들어 있습니다. 특히 Kerberos 구성을 분류하기 위한 기본 도구 및 기술에 대해 다루는 시나리오 1 핵심 구성의 내용을 꼼꼼하게 확인하십시오.

SharePoint 2010 제품의 시나리오 파악

SharePoint 2010 제품의 인증 컨텍스트에서 ID에 대해 파악할 때는 들어오는 인증, 팜 간/팜 내부 인증 및 나가는 인증의 세 가지 주요 시나리오에서 플랫폼이 ID를 처리하는 방법을 개념적으로 확인할 수 있습니다.

팜 인증 다이어그램

들어오는 ID

들어오는 인증 시나리오는 클라이언트가 플랫폼에 해당 ID를 제공하는 방법, 즉 웹 응용 프로그램이나 웹 서비스에 인증하는 방법을 나타냅니다. SharePoint Server에서는 클라이언트 ID를 사용하여 클라이언트가 웹 페이지, 문서 등의 보안된 SharePoint Server 리소스에 액세스할 수 있는 권한을 부여합니다.

SharePoint 2010 제품에서는 클라이언트가 플랫폼에 인증할 수 있는 두 가지 모드, 즉 클래식 모드와 클레임 모드를 지원합니다.

클래식 모드

클래식 모드에서는 이전 버전 SharePoint Server에서 이미 사용해 보았을 수 있는 일반적인 IIS(인터넷 정보 서비스) 인증 방법을 사용할 수 있습니다. SharePoint Server 2010 웹 응용 프로그램이 클래식 모드를 사용하도록 구성된 경우 다음 IIS 인증 방법을 사용할 수 있습니다.

통합 Windows 인증

통합 Windows 인증을 사용하는 경우 Windows 클라이언트가 자격 증명(사용자 이름/암호)을 수동으로 제공하지 않고도 SharePoint Server에 원활하게 인증할 수 있습니다. Internet Explorer에서 SharePoint Server에 액세스하는 사용자는 Internet Explorer 프로세스를 실행하는 데 사용하는 자격 증명(기본적으로 사용자가 데스크톱에 로그온하는 데 사용한 자격 증명)을 사용하여 인증합니다. Windows 통합 모드에서 SharePoint Server에 액세스하는 서비스 또는 응용 프로그램은 실행 중인 스레드의 자격 증명(기본적으로 프로세스 ID)을 사용하여 인증합니다.

NTLM

NTLM(NT LAN Manager)은 통합 Windows 인증을 선택하는 경우 기본적으로 사용되는 프로토콜 유형입니다. 이 프로토콜은 세 부분으로 구성된 챌린지-응답 시퀀스를 사용하여 클라이언트를 인증합니다. NTLM에 대한 자세한 내용은 Microsoft NTLM(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=196643&clcid=0x412)(영문일 수 있음)을 참조하십시오.

장점

NTLM은 쉽게 구성할 수 있으며 일반적으로 인프라/환경을 추가로 구성하지 않아도 작동합니다.
클라이언트가 도메인에 포함되어 있지 않거나 SharePoint Server가 있는 도메인에서 신뢰하는 도메인에 있지 않은 경우에도 작동합니다.

단점

NTLM을 사용하려면 클라이언트 인증 응답의 유효성을 확인해야 할 때마다 SharePoint Server에서 도메인 컨트롤러에 연결해야 하므로 도메인 컨트롤러에 대한 트래픽이 증가합니다.
클라이언트 자격 증명을 백 엔드 시스템에 위임할 수 없습니다(이중 홉 규칙).
NTLM은 소유 프로토콜입니다.
서버 인증이 지원되지 않습니다.
Kerberos 인증보다 안전성이 떨어집니다.

Kerberos 프로토콜

Kerberos는 티켓 인증을 지원하는 보다 안전한 프로토콜입니다. Kerberos 인증 서버는 유효한 사용자 자격 증명과 유효한 SPN(서비스 사용자 이름)이 포함된 클라이언트 컴퓨터 인증 요청에 대한 응답으로 티켓을 부여합니다. 그러면 클라이언트 컴퓨터에서는 해당 티켓을 사용하여 네트워크 리소스에 액세스합니다. Kerberos 인증을 사용하도록 설정하려면 클라이언트 컴퓨터와 서버 컴퓨터에 도메인 KDC(키 배포 센터)에 대한 트러스트된 연결이 있어야 합니다. KDC는 암호화를 사용할 수 있도록 공유 비밀 키를 배포합니다. 또한 클라이언트 컴퓨터와 서버 컴퓨터가 AD DS(Active Directory 디렉터리 서비스)에 액세스할 수 있어야 합니다. Active Directory의 경우 포리스트 루트 도메인이 Kerberos 인증 조회의 중심입니다. Kerberos 프로토콜에 대한 자세한 내용은 Kerberos 버전 5 인증 프로토콜의 작동 방식(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=196644&clcid=0x412)(영문일 수 있음) 및 Microsoft Kerberos(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=196645&clcid=0x412)(영문일 수 있음)를 참조하십시오.

장점

가장 안전한 Windows 통합 인증 프로토콜입니다.
클라이언트 자격 증명을 위임할 수 있습니다.
클라이언트 및 서버 상호 인증이 지원됩니다.
도메인 컨트롤러에 대해 생성되는 트래픽이 NTLM에 비해 적습니다.
대부분의 플랫폼 및 공급업체에서 지원하는 개방형 프로토콜입니다.

단점

인프라와 환경을 추가로 구성해야 올바르게 작동합니다.
클라이언트가 TCP/UDP 포트 88(Kerberos) 및 TCP/UDP 포트 464(Kerberos 암호 변경 - Windows)를 통해 KDC(Windows 환경의 Active Directory 도메인 컨트롤러)에 연결해야 합니다.

기타 방법

SharePoint Server에서는 NTLM 및 Kerberos 인증 외에도 기본 인증, 다이제스트 인증, 인증서 기반 인증 등 다른 종류의 IIS 인증도 지원합니다. 그러나 이러한 인증에 대해서는 이 문서에서 다루지 않습니다. 이러한 프로토콜의 작동 방법에 대한 자세한 내용은 IIS 6.0에서 지원되는 인증 방법(IIS 6.0)(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=196646&clcid=0x412)(영문일 수 있음)을 참조하십시오.

클레임 기반 인증

SharePoint 2010 제품에서는 클레임 인증이 새롭게 지원되며, Windows Identity Foundation(WIF)에서는 클레임 인증이 기본적으로 지원됩니다. 클레임 모델에서 SharePoint Server는 클라이언트 인증에 대한 클레임을 하나 이상 허용하여 클라이언트를 식별하고 권한을 부여합니다. 클레임은 SAML 토큰 형식이며, 신뢰할 수 있는 기관에서 제공하는 클라이언트에 대한 정보입니다. 예를 들어 클레임에 "Bob은 Contoso.com 도메인의 Enterprise Admins 그룹 구성원입니다."라는 설명이 포함될 수 있습니다. 이 클레임을 SharePoint Server에서 신뢰하는 공급자에서 제공한 경우에는 플랫폼에서 이 정보를 사용하여 Bob을 인증하고 Bob이 SharePoint Server 리소스에 액세스하도록 권한을 부여할 수 있습니다. 클레임 인증에 대한 자세한 내용은 클레임 기반 ID 및 액세스 제어 가이드(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=187911&clcid=0x412)(영문일 수 있음)를 참조하십시오.

SharePoint 2010 제품에서 들어오는 인증에 대해 지원하는 클레임 종류는 Windows 클레임, 양식 기반 인증 클레임 및 SAML 클레임입니다.

Windows 클레임

Windows 클레임 모드 로그인에서는 SharePoint Server가 표준 Windows 통합 인증(NTLM/Kerberos)을 사용하여 클라이언트를 인증한 다음 인증 후에 생성되는 Windows ID를 클레임 ID로 변환합니다.

양식 기반 인증 클레임

양식 기반 인증 클레임 모드에서는 SharePoint Server가 클라이언트를 표준 ASP.NET 로그온 컨트롤이 호스팅되는 로그온 페이지로 리디렉션합니다. 이 페이지에서는 Office SharePoint Server 2007에서 양식 기반 인증이 작동하는 방식과 비슷하게 ASP.NET 구성원 자격 및 역할 공급자를 사용하여 클라이언트를 인증합니다. 사용자를 나타내는 ID 개체가 만들어지면 SharePoint Server에서 해당 ID를 클레임 ID 개체로 변환합니다.

SAML 클레임

SAML 클레임 모드에서는 SharePoint Server가 신뢰할 수 있는 외부 STS(보안 토큰 공급자)의 SAML 토큰을 허용합니다. 사용자가 로그온할 때 주석이 외부 클레임 공급자(예: Windows Live ID 클레임 공급자)에게 전달됩니다. 이 공급자는 사용자를 인증하고 SAML 토큰을 생성합니다. SharePoint Server에서는 이 토큰을 수락하여 처리하고, 사용자에 대해 클레임을 확장하고 클레임 ID 개체를 만듭니다.

SharePoint 2010 제품의 클레임 기반 인증에 대한 자세한 내용은 SharePoint 클레임 기반 인증(영문일 수 있음)을 참조하십시오.

들어오는 클레임 인증 및 C2WTS(Windows 토큰 서비스에 대한 클레임)에 대한 참고 사항

일부 응용 프로그램에서는 Windows Identity Foundation(WIF) C2WTS(Windows 토큰 서비스에 대한 클레임)를 사용하여 팜 내의 클레임을 아웃바운드 인증용 Windows 자격 증명으로 변환해야 합니다. C2WTS는 들어오는 인증 방법이 클래식 모드 또는 Windows 클레임이어야 작동합니다. 클레임이 구성된 경우 C2WTS에는 Windows 클레임만 필요합니다. 웹 응용 프로그램은 여러 클레임 형식을 사용할 수 없으며, 여러 형식을 사용하는 경우에는 C2WTS가 작동하지 않습니다.

SharePoint 2010 제품 환경 내의 ID

SharePoint 2010 제품 환경에서는 어떤 들어오는 인증 메커니즘을 사용하는지에 관계없이, 대부분의 SharePoint 서비스 응용 프로그램 및 SharePoint 통합 제품에 대해 팜 간 통신과 팜 내부 통신에 클레임 인증을 사용합니다. 따라서 클래식 인증을 사용하여 특정 웹 응용 프로그램을 인증하는 경우에도 SharePoint Products는 들어오는 ID를 클레임 ID로 변환하여 클레임을 인식하는 SharePoint 서비스 응용 프로그램 및 제품을 인증합니다. 팜 간/팜 내부 통신을 위한 클레임 모델을 표준화하면 플랫폼에서 사용되는 들어오는 프로토콜을 파악할 수 있습니다.

참고

SQL Server Reporting Services와 같이 SharePoint Server에 통합된 일부 제품은 클레임을 인식하지 못하므로 팜 내 클레임 인증 아키텍처를 사용하지 않습니다. SharePoint Server 역시 RSS 뷰어 웹 파트가 인증된 피드를 사용하도록 구성된 것과 같은 기타 시나리오에서 클래식 Kerberos 위임 및 클레임을 사용할 수 있습니다. 각 제품 또는 서비스 응용 프로그램 설명서를 참조하여 클레임 기반 인증 및 ID 위임이 지원되는지를 확인하십시오.

아웃바운드 ID

SharePoint 2010 제품의 아웃바운드 ID는 팜 내의 서비스가 외부 LOB(기간 업무) 시스템 및 서비스에 인증해야 하는 시나리오를 나타냅니다. 시나리오에 따라 두 가지 기본 개념 모델 중 하나에서 인증을 수행할 수 있습니다.

신뢰할 수 있는 하위 시스템

신뢰할 수 있는 하위 시스템에서는 프런트 엔드 서비스가 클라이언트를 인증하고 권한을 부여한 다음, 클라이언트 ID를 백 엔드 시스템으로 전달하지 않고 추가 백 엔드 서비스를 인증합니다. 백 엔드 시스템은 프런트 엔드 서비스가 자신을 대신하여 인증 및 권한 부여를 수행하도록 신뢰합니다. 이 모델을 구현하는 가장 일반적인 방법은 공유 서비스 계정을 사용하여 외부 시스템에 인증하는 것입니다.

신뢰할 수 있는 하위 시스템 다이어그램

SharePoint Server에서 이 모델은 다양한 방식으로 구현될 수 있습니다.

IIS 응용 프로그램 풀 ID 사용 - 일반적으로 웹 응용 프로그램에서 외부 시스템을 호출하는 중에 권한을 높이는 코드를 실행하는 방식으로 수행합니다. RevertToSelf를 사용하는 등의 다른 방법에서도 응용 프로그램 풀 ID를 사용하여 외부 시스템에 인증할 수 있습니다.
서비스 계정 사용 - 일반적으로 보안 저장소에 응용 프로그램 자격 증명을 저장한 다음 해당 자격 증명을 사용하여 외부 시스템에 인증하는 방식으로 수행합니다. 서비스 계정 자격 증명을 포함된 연결 문자열 등의 다른 방식으로 저장하는 방법도 있습니다.
익명 인증 - 외부 시스템에 인증하지 않아도 되는 방식입니다. 따라서 프런트 엔드 SharePoint Server 서비스에서 백 엔드 시스템으로 ID를 전달할 필요가 없습니다.

위임

위임 모델에서는 프런트 엔드 서비스가 먼저 클라이언트를 인증한 다음 클라이언트의 ID를 사용하여 자체 인증과 권한 부여를 수행하는 다른 백 엔드 시스템을 인증합니다.

위임 프로세스 다이어그램

SharePoint 2010 제품에서 이 모델은 다양한 방식으로 구현될 수 있습니다.

Kerberos 위임 - 클라이언트가 Kerberos 인증을 사용하여 프런트 엔드 서비스에 인증하는 경우에는 Kerberos 위임을 사용하여 클라이언트의 ID를 백 엔드 시스템에 전달할 수 있습니다.
클레임 - 클레임 인증을 사용하는 경우 두 서비스가 모두 클레임을 인식하며 서로를 신뢰하면 클라이언트의 클레임을 서비스 간에 전달할 수 있습니다.

참고

현재는 SharePoint Server에 포함된 대부분의 서비스 응용 프로그램이 아웃바운드 클레임 인증을 허용하지 않지만, 향후 플랫폼 기능으로 아웃바운드 클레임을 사용할 수 있을 것입니다. 또한, 오늘날 일반적으로 사용되고 있는 대부분의 LOB(기간 업무) 시스템에서는 들어오는 클레임 인증을 지원하지 않습니다. 따라서 아웃바운드 클레임 인증을 사용할 수 없거나, 해당 인증이 정상적으로 작동하려면 추가 개발을 수행해야 합니다.

여러 도메인 및 포리스트에 걸친 위임

Kerberos 인증과 관련된 이 문서 집합의 시나리오를 수행하려면 SharePoint Server 서비스 및 외부 데이터 원본이 동일한 Windows 도메인에 있어야 합니다(Kerberos 제한 위임을 사용하려는 경우 필수 요구 사항). Kerberos 프로토콜은 기본(제한되지 않은) 위임과 제한 위임의 두 가지 위임 종류를 지원합니다. 기본 Kerberos 위임의 경우 단일 포리스트에서 여러 도메인에 적용할 수 있지만, 트러스트 관계에 관계없이 포리스트 경계를 벗어나 적용할 수는 없습니다. Kerberos 제한 위임은 어떤 시나리오에서도 도메인 또는 포리스트 경계를 벗어날 수 없습니다.

일부 SharePoint Server 서비스의 경우 기본 Kerberos 위임을 사용하도록 구성할 수 있지만, 제한 위임을 반드시 사용해야 하는 서비스도 있습니다. C2WTS(Windows 토큰 서비스에 대한 클레임)를 사용하는 모든 서비스는 Kerberos 제한 위임을 사용해야 합니다. 그래야 C2WTS가 Kerberos 프로토콜의 변환 기능을 사용하여 클레임을 Windows 자격 증명으로 변환할 수 있습니다.

다음 서비스 응용 프로그램 및 제품에서는 C2WTS 및 Kerberos 제한 위임을 사용해야 합니다.

Excel Services
PerformancePoint Services
InfoPath Forms Services
Visio Services

다음 서비스 응용 프로그램

Business Data Connectivity 서비스 및 Microsoft Business Connectivity Services
Access Services
Microsoft SQL Server Reporting Services(SSRS)
Microsoft Project Server 2010

다음 서비스 응용 프로그램에서는 클라이언트 자격 증명을 위임할 수 없으므로 이러한 요구 사항의 영향을 받지 않습니다.

Microsoft SQL Server PowerPivot for Microsoft SharePoint

클레임 주요 사항

클레임 개념 및 클레임 기반 인증에 대한 소개는 클레임 소개(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=196648&clcid=0x412)(영문일 수 있음) 및 SharePoint 클레임 기반 ID(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=196647&clcid=0x412)(영문일 수 있음)를 참조하십시오.

Kerberos 프로토콜 주요 사항

Kerberos 프로토콜에 대한 자세한 내용은 Microsoft Kerberos(Windows)(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=196645&clcid=0x412)(영문일 수 있음), Kerberos 설명(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=196649&clcid=0x412)(영문일 수 있음) 및 Directory Services 팀에 질문하세요: 관리자의 부담을 덜어 주는 Kerberos 인증(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=196650&clcid=0x412)(영문일 수 있음)을 참조하십시오.

Kerberos 프로토콜의 장점

SharePoint Server 또는 웹 응용 프로그램에서 Kerberos 프로토콜을 사용하도록 구성하는 방법을 자세히 설명하기 전에, Kerberos 프로토콜과 Kerberos 프로토콜을 사용하는 이유에 대해 개괄적으로 설명하겠습니다.

일반적으로 Kerberos 프로토콜을 사용하는 주요 이유는 다음의 세 가지입니다.

클라이언트 자격 증명 위임 - Kerberos 프로토콜을 사용하면 서비스가 클라이언트 ID를 가장하여 가장 서비스가 해당 ID를 클라이언트 대신 다른 네트워크 서비스로 전달할 수 있습니다. NTLM에서는 이러한 위임이 허용되지 않습니다. 이와 같은 NTLM의 제한을 "이중 홉 규칙"이라고 합니다. 클레임 인증도 Kerberos 인증과 같이 클라이언트 자격 증명을 위임하는 데 사용할 수 있지만, 클레임의 경우 백 엔드 응용 프로그램이 클레임을 인식해야 합니다.
보안 - AES 암호화, 상호 인증, 데이터 무결성/데이터 개인 정보 지원 등의 기능으로 인해 Kerberos 프로토콜은 NTLM 프로토콜보다 안전합니다.
성능 향상 가능성 - Kerberos 인증은 NTLM에 비해 도메인 컨트롤러에 대해 필요한 트래픽이 더 적습니다(PAC 확인에 따라 달라짐. 자세한 내용은 Microsoft Open Specifications 지원 팀 블로그: Microsoft Kerberos PAC 유효성 검사 이해(영문일 수 있음) 참조). PAC 확인이 사용하지 않도록 설정되어 있거나 필요하지 않은 경우 클라이언트를 인증하는 서비스는 DC에 대해 RPC 호출을 수행할 필요가 없습니다. 자세한 내용은 Windows 2000 또는 Windows Server 2003의 도메인 구성원에 대해 고용량 서버 프로그램을 실행할 때 사용자 인증 프로세스가 지연됨을 참조하십시오. 또한 Kerberos 인증을 사용하는 경우 NTLM을 사용할 때에 비해 클라이언트와 서버 간에 필요한 트래픽도 더 적습니다. NTLM에서는 일반적으로 3발 핸드셰이크가 수행되는 데 비해, Kerberos에서는 클라이언트가 2회의 요청/응답으로 웹 서버에 인증할 수 있습니다. 그러나 일반적으로 대기 시간이 짧은 네트워크에서는 트랜잭션별로 이와 같이 개선된 기능을 확인할 수 없으며, 전반적인 시스템 처리량을 통해 확인할 수 있습니다. 다양한 환경적 요인이 인증 성능에 영향을 줄 수 있으므로, Kerberos 인증과 NTLM의 성능을 작업 환경에서 테스트한 후에 어떤 방법의 성능이 보다 뛰어난지를 결정해야 합니다.

위에서 설명한 내용은 Kerberos 프로토콜을 사용하는 경우의 장점 중 일부일 뿐입니다. 그 외에도 상호 인증, 플랫폼 간 상호 운용성, 전이적 도메인 간 트러스트 등의 여러 가지 장점이 있습니다. 그러나 대부분의 경우에는 위임과 보안 면의 장점으로 인해 Kerberos 프로토콜을 도입하게 됩니다.

Kerberos 위임, 제한 위임 및 프로토콜 전환

Windows 플랫폼의 Kerberos 버전 5 프로토콜은 기본(제한되지 않은) 위임과 제한 위임의 두 가지 ID 위임 종류를 지원합니다.

유형	장점	단점
기본 위임	단일 포리스트에서 여러 도메인에 적용할 수 있습니다. 제한 위임에 비해 구성해야 하는 항목이 더 적습니다.	프로토콜 전환을 지원하지 않습니다. 안전성이 뛰어납니다. 프런트 엔드 서비스가 위협을 받는 경우 Kerberos 인증을 허용하는 포리스트의 서비스로 클라이언트 ID를 위임할 수 있습니다.
제한 위임	Kerberos가 아닌 들어오는 인증 프로토콜을 Kerberos로 전환할 수 있습니다(예: NTLM이나 클레임에서 Kerberos로). 보다 안전합니다. 지정된 서비스로만 ID를 위임할 수 있습니다.	여러 도메인에 적용할 수 없습니다. 설정을 추가로 구성해야 합니다.

Kerberos를 사용하도록 설정된 서비스는 여러 서비스 및 여러 홉에 걸쳐 ID를 여러 번 위임할 수 있습니다. ID가 서비스 간을 이동할 때는 위임 방법이 기본 위임에서 제한 위임으로 변경될 수 있습니다(제한 위임에서 기본 위임으로는 변경될 수 없음). 이 디자인 세부 정보를 반드시 이해해야 합니다. 예를 들어 백 엔드 서비스에서 여러 도메인에 걸쳐 ID를 위임하기 위해 기본 인증이 필요한 경우 백 엔드 서비스 전면의 모든 서비스는 기본 위임을 사용해야 합니다. 프런트 엔드 서비스에서 제한 위임을 사용하는 경우에는 백 엔드 서비스에서 위임을 여러 도메인에 적용하기 위해 제한 토큰을 제한되지 않은 토큰으로 변경할 수 없습니다.

Kerberos를 사용하도록 설정된 인증 서비스(프런트 엔드 서비스)에서는 프로토콜 전환을 통해 Kerberos가 아닌 ID를 Kerberos ID로 변환할 수 있으며, 이렇게 변환된 ID는 Kerberos를 사용하도록 설정된 다른 서비스(백 엔드 서비스)에 위임할 수 있습니다. 프로토콜을 전환하려면 KErberos 제한 위임을 사용해야 하므로, 프로토콜이 전환된 ID는 여러 도메인에 걸쳐 적용할 수 없습니다. 프런트 엔드 서비스에서의 사용자 권한에 따라, 프로토콜 전환에서 반환되는 Kerberos 티켓은 ID 토큰이거나 가장 토큰일 수 있습니다. 제한 위임 및 프로토콜 전환에 대한 자세한 내용은 다음 문서를 참조하십시오.

일반적으로는 Kerberos 위임을 수행해야 하는 경우 가능하면 제한 위임을 사용하는 것이 좋습니다. 여러 도메인에 위임을 적용해야 하는 경우에는 위임 경로의 모든 서비스가 기본 위임을 사용해야 합니다.

Windows 2008 R2 및 Windows 7의 Kerberos 인증 변경 내용

Windows Server 2008 R2 및 Windows 7에는 Kerberos 인증에 새로운 기능이 도입되었습니다. 변경 내용에 대한 간략한 정보는 Kerberos 인증의 변경 내용(https://go.microsoft.com/fwlink/?linkid=196655&clcid=0x412) 및 Kerberos 향상 내용(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=196656&clcid=0x412)(영문일 수 있음)을 참조하십시오. 또한, SharePoint Server 팜에서는 지원되지 않더라도 IIS(인터넷 정보 서비스) 7.0 커널 모드 인증 설정(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=196657&clcid=0x412)(영문일 수 있음)에 설명되어 있는 IIS 7.0 커널 모드 인증에 대해 파악해야 합니다.

SharePoint 2010 제품의 Kerberos 구성 변경 내용

SharePoint 2010 제품의 Kerberos 인증 구성과 관련된 기본 개념은 대부분 변경되지 않았습니다. 즉, 새 버전에서도 서비스 사용자 이름을 구성해야 하며 컴퓨터 및 서비스 계정에 대해 위임 설정을 구성해야 합니다. 그러나 다음과 같은 사항은 변경되었습니다.

제한 위임 - Windows 토큰 서비스에 대한 클레임을 사용하는 서비스의 경우 제한 위임을 사용해야 합니다. 프로토콜 전환을 통해 클레임을 Windows 토큰으로 변환하려면 제한된 위임이 필요합니다.
서비스 응용 프로그램 - Office SharePoint Server 2007에서는 SSP 서비스에서 위임을 사용하려면 특수 SPN 및 서버 레지스트리를 변경해야 했습니다. SharePoint 2010 제품에서는 서비스 응용 프로그램이 클레임 인증 및 Windows 토큰 서비스에 대한 클레임을 사용하므로 더 이상 이전 버전과 같이 변경하지 않아도 됩니다.
Windows Identity Foundation(WIF) - WIF C2WTS(Windows 토큰 서비스에 대한 클레임)는 SharePoint 2010 제품에서 위임 시나리오를 위해 Windows 토큰에 대한 클레임을 변환하는 데 사용하는 새로운 서비스입니다.

Office SharePoint Server 2007에서 업그레이드할 때의 고려 사항

Office SharePoint Server 2007 팜을 SharePoint Server 2010으로 업그레이드하는 경우, 업그레이드 완료 시 다음과 같은 사항을 고려해야 합니다.

응용 프로그램의 URL이 변경되는 경우에는 DNS 이름을 반영하여 서비스 사용자 이름을 업데이트해야 합니다.
SPP 서비스 사용자 이름은 SharePoint Server 2010에서 더 이상 필요하지 않으므로 삭제합니다.
위임이 필요한 서비스 응용 프로그램(예: Excel Services, Visio Graphics Service)을 실행하는 서버에서 Windows 토큰 서비스에 대한 클레임을 시작합니다.
C2WTS에 대해 Kerberos 제한 위임을 사용할 수 있도록 "모든 인증 프로토콜 사용" 옵션을 사용하여 Kerberos 제한 위임을 구성합니다.
IIS에서 커널 모드 인증을 사용하지 않도록 설정합니다.