SharePoint Server에서 Kerberos 인증 계획
적용 대상:
2013 2016 2019 Subscription Edition 
SharePoint in Microsoft 365
Kerberos 프로토콜은 신뢰할 수 있는 원본에서 제공하는 티켓을 사용하는 인증 방법을 지원합니다. Kerberos 티켓은 클라이언트 컴퓨터에 연결된 사용자의 네트워크 자격 증명이 인증되었음을 나타냅니다. Kerberos 프로토콜은 사용자가 네트워크 서비스와 상호 작용하여 네트워크 리소스 액세스 권한을 얻는 방법을 정의합니다. Kerberos KDC(키 배포 센터)는 사용자를 대신하여 클라이언트 컴퓨터에 대해 TGT(허용 티켓)를 발급합니다. Windows에서 클라이언트 컴퓨터는 AD DS(Active Directory 도메인 서비스) 도메인 구성원이고 TGT는 도메인 컨트롤러에서 사용자 자격 증명을 인증했다는 증명입니다.
네트워크 서비스에 대한 네트워크 연결을 설정하기 전에 클라이언트 컴퓨터는 해당 TGT를 KDC에 제공하고 서비스 티켓을 요청합니다. 클라이언트 컴퓨터가 인증되었음을 확인하는 이전에 발급된 TGT에 따라 KDC는 클라이언트 컴퓨터에 서비스 티켓을 발급합니다. 그런 다음 클라이언트 컴퓨터가 서비스 티켓을 네트워크 서비스에 제출합니다. 서비스 티켓에는 서비스를 식별하는 SPN(서비스 사용자 이름)도 포함되어야 합니다. Kerberos 인증을 사용하도록 설정하려면 클라이언트 및 서버 컴퓨터에 KDC에 대한 신뢰할 수 있는 연결이 이미 있어야 합니다. 클라이언트 및 서버 컴퓨터도 AD DS에 액세스할 수 있어야 합니다.
Kerberos 인증 및 SharePoint Server
Kerberos 인증을 고려해야 하는 이유는 다음과 같습니다.
Kerberos 프로토콜은 가장 강력한 Windows 통합 인증 프로토콜이며 AES(Advanced Encryption Standard) 암호화 및 클라이언트와 서버의 상호 인증을 비롯한 고급 보안 기능을 지원합니다.
Kerberos 프로토콜을 사용하는 경우 클라이언트 자격 증명을 위임할 수 있습니다.
사용 가능한 여러 보안 인증 방법 중에서 AD DS 도메인 컨트롤러에 대해 필요한 네트워크 트래픽의 양이 가장 적은 방법이 Kerberos입니다. Kerberos를 사용하면 페이지 대기 시간이 감소하는 경우도 있고, 프런트 엔드 웹 서버가 처리할 수 있는 페이지 수가 증가하는 경우도 있습니다. 또한 Kerberos는 도메인 컨트롤러에 대한 로드도 줄일 수 있습니다.
Kerberos 프로토콜은 다수의 플랫폼과 공급업체에서 지원하는 개방형 프로토콜입니다.
Kerberos 인증이 적합하지 않을 수 있는 이유는 다음과 같습니다.
다른 인증 방법과 달리 Kerberos 인증이 정상적으로 작동하려면 인프라와 환경에서 추가 구성을 수행해야 합니다. 대부분의 경우에는 Kerberos 인증을 구성하려면 도메인 관리자 권한이 필요한데, 이 권한은 설정 및 관리하기가 어려울 수 있습니다. Kerberos를 잘못 구성하는 경우 사이트에 올바르게 인증하지 못할 수 있습니다.
Kerberos 인증을 사용하려면 클라이언트 컴퓨터를 KDC 및 AD DS 도메인 컨트롤러에 연결해야 합니다. Windows 및 SharePoint 배포에서는 KDC가 AD DS 도메인 컨트롤러입니다. 조직 인트라넷에서는 이러한 네트워크 구성이 흔히 사용되지만, 인터넷 연결 배포는 보통 이러한 방식으로 구성되지 않습니다.
Kerberos 위임
Kerberos 인증에서는 클라이언트 ID 위임이 지원됩니다. 즉, 서비스가 인증된 클라이언트의 ID를 가장할 수 있습니다. 이러한 가장을 통해 서비스가 인증된 ID를 클라이언트 대신 다른 네트워크 서비스로 전달할 수 있습니다. 클레임 기반 인증을 사용하여 클라이언트 자격 증명을 위임할 수도 있지만, 이렇게 하려면 백 엔드 응용 프로그램이 클레임을 인식해야 합니다.
Kerberos 위임을 SharePoint Server와 함께 사용하는 경우 프런트 엔드 서비스에서 클라이언트를 인증한 다음 클라이언트의 ID를 사용하여 백 엔드 시스템에 인증할 수 있습니다. 그러면 백 엔드 시스템에서 자체 인증을 수행합니다. 클라이언트가 Kerberos 인증을 사용하여 프런트 엔드 서비스에 인증할 때는 Kerberos 위임을 사용하여 클라이언트의 ID를 백 엔드 시스템으로 전달할 수 있습니다. Kerberos 프로토콜은 다음과 같은 두 가지 유형의 위임을 지원합니다.
기본 Kerberos 위임(제한 없음)
Kerberos 제한 위임
기본 Kerberos 위임 및 Kerberos 제한 위임
기본 Kerberos 위임의 경우 동일한 포리스트에서 여러 도메인에 적용할 수 있지만 포리스트 경계를 벗어나 적용할 수는 없습니다. Kerberos 제한 위임은 Windows Server 2012를 실행하는 도메인 컨트롤러를 사용 중인 경우를 제외하면 도메인 또는 포리스트 경계를 벗어나 적용할 수 없습니다.
SharePoint Server 배포에 포함되는 서비스 응용 프로그램에 따라 SharePoint Server와 함께 Kerberos 인증을 구현하려면 Kerberos 제한 위임을 사용해야 할 수 있습니다.
중요
다음 서비스 애플리케이션을 사용하여 Kerberos 인증을 배포하려면 SharePoint Server 및 모든 외부 데이터 원본이 동일한 Windows 도메인에 있어야 합니다. > Excel Services PerformancePoint Services > InfoPath Forms Services >> Visio Services > 이러한 서비스 애플리케이션은 SharePoint Foundation 2013에서 사용할 수 없습니다. Excel Services is not available in SharePoint Server 2016.
다음 서비스 응용 프로그램 또는 제품과 함께 Kerberos 인증을 배포하려는 경우 SharePoint Server는 기본 Kerberos 위임 또는 Kerberos 제한 위임을 사용할 수 있습니다.
Business Data Connectivity 서비스(SharePoint Foundation 2013에서는 이 서비스 응용 프로그램을 사용할 수 없음)
Access Services(SharePoint Foundation 2013에서는 이 서비스 응용 프로그램을 사용할 수 없음)
SQL Server Reporting Services(SSRS)(별도 제품)
Project Server 2016(별도 제품)
Kerberos 인증에 사용하도록 설정된 서비스는 ID를 여러 번 위임할 수 있습니다. ID가 서비스에서 서비스로 이동함에 따라 위임 메서드는 기본 Kerberos에서 Kerberos로 제한될 수 있습니다. 그러나 그 반대는 불가능합니다. 위임 메서드는 Kerberos 제한에서 기본 Kerberos로 변경할 수 없습니다. 따라서 백 엔드 서비스에 기본 Kerberos 위임이 필요한지 여부를 예측하고 계획하는 것이 중요합니다. 이는 도메인 경계의 계획 및 디자인에 영향을 줄 수 있습니다.
Kerberos 사용 가능 서비스는 프로토콜 전환을 통해 Kerberos가 아닌 ID를 Kerberos ID(다른 Kerberos 사용 가능 서비스로 위임 가능)로 변환할 수 있습니다. 예를 들어 이 기능을 사용하면 프런트 엔드 서비스의 Kerberos가 아닌 ID를 백 엔드 서비스의 Kerberos ID로 위임할 수 있습니다.
중요
프로토콜 전환 시에는 Kerberos 제한 위임을 사용해야 합니다. 따라서 프로토콜이 전환된 ID는 도메인 간에 전달할 수 없습니다.
Kerberos 위임 대신 클레임 기반 인증을 사용할 수 있습니다. 클레임 기반 인증을 사용하는 경우 서비스가 다음 기준을 모두 충족하면 서로 다른 서비스 간에 클라이언트의 인증 클레임을 전달할 수 있습니다.
서비스 간에 트러스트 관계가 있어야 합니다.
서비스가 클레임을 인식해야 합니다.
Kerberos 인증에 대한 자세한 내용은 다음 리소스를 참조하십시오.
Kerberos 인증 및 클레임 기반 인증
SharePoint 2013 및 SharePoint Server 2016은 클레임 기반 인증을 지원합니다. 클레임 기반 인증은 클레임 기반 ID를 구현하는 데 사용되는 .NET Framework 클래스 집합인 WIF(Windows Identity Foundation)를 기반으로 합니다. 클레임 기반 인증은 WS-Federation 및 WS-Trust와 같은 표준을 사용합니다. 클레임 기반 인증에 대한 자세한 내용은 다음 리소스를 참조하세요.
중앙 관리를 사용하여 UNRESOLVED_TOKEN_VAL(SharePoint Server) 웹 응용 프로그램을 만들 때는 클레임 기반 인증 유형을 하나 이상 선택해야 합니다. New-SPWebApplication Microsoft PowerShell cmdlet을 사용하여 UNRESOLVED_TOKEN_VAL(SharePoint Server) 웹 응용 프로그램을 만들 때는 클레임 인증 및 클레임 인증 유형이나 클래식 모드 인증을 지정할 수 있습니다. 모든 UNRESOLVED_TOKEN_VAL(SharePoint Server) 웹 응용 프로그램에는 클레임 인증을 사용하는 것이 좋습니다. 클레임 인증을 사용하는 경우 지원되는 모든 인증 유형을 웹 응용 프로그램에서 사용할 수 있으며 서버 간 인증 및 앱 인증을 활용할 수 있습니다. 자세한 내용은 What's new in authentication for SharePoint Server 2013을 참조하십시오.
중요
The following service applications in SharePoint Server require the translation of claims-based credentials to Windows credentials. 이 변환 프로세스에서는 C2WTS(Windows 토큰 서비스 클레임): >Excel Services>PerformancePoint Services>InfoPath Forms Services>Visio Services>> 이러한 서비스 애플리케이션은 SharePoint Foundation 2013에서 사용할 수 없습니다. Excel Services is not available in SharePoint Server 2016.
C2WTS를 사용해야 하는 서비스 응용 프로그램의 경우 Kerberos 제한 위임을 사용해야 합니다. C2WTS에서는 프로토콜 전환을 수행해야 하는데, 프로토콜 전환은 Kerberos 제한 위임에서만 지원되기 때문입니다. 위 목록에 포함된 서비스 응용 프로그램의 경우 C2WTS는 팜 내의 클레임을 나가는 인증용 Windows 자격 증명으로 변환합니다. 이러한 서비스 응용 프로그램은 들어오는 인증 방법이 Windows 클레임 또는 Windows 클래식 모드인 경우에만 C2WTS를 사용할 수 있습니다. 웹 응용 프로그램을 통해 액세스하며 SAML(Security Assertion Markup Language) 클레임 또는 양식 기반 인증 클레임을 사용하는 서비스 응용 프로그램은 C2WTS를 사용하지 않으므로 클레임을 Windows 자격 증명으로 변환할 수 없습니다.
Kerberos 인증 및 새로운 SharePoint 앱 모델
사용자 인증에 대해 Windows 클래식 모드를 사용하는 경우 웹 응용 프로그램이 NTLM을 인증 프로토콜로 대신 사용하지 않고 Kerberos 인증만 사용하도록 구성되어 있으면 앱 인증이 작동하지 않습니다. 자세한 내용은 SharePoint Server의 앱 인증 계획을 참조하십시오.