Kerberos 제한 위임 문제 해결

2025-05-03

SSO(Single Sign-On) 메서드는 애플리케이션마다 다릅니다. Microsoft Entra 애플리케이션 프록시는 기본적으로 KCD(Kerberos 제한 위임)를 제공합니다. 애플리케이션 프록시에서 사용자는 Kerberos를 사용하여 프라이빗 애플리케이션에 인증합니다.

이 문서에서는 KCD 구성에서 가장 일반적인 문제를 해결하는 방법을 설명합니다. 여기에는 더 복잡한 구현을 위해 수행할 수 있는 진단 단계가 포함되어 있습니다.

이 문서에서는 다음과 같이 가정합니다.

Microsoft Entra 애플리케이션 프록시가 배포되고 KCD가 아닌 애플리케이션에 대한 일반 액세스 권한이 있습니다.

자세한 내용은 애플리케이션 프록시 시작하기참조하세요.
게시된 애플리케이션은 IIS(인터넷 정보 서비스) 및 Microsoft Kerberos 구현을 기반으로 합니다.
서버 및 애플리케이션 호스트는 단일 Microsoft Entra 도메인에 있습니다.

도메인 간 및 포리스트 시나리오에 대한 자세한 내용은 애플리케이션 프록시를 사용한 Kerberos 제한 위임 이해 백서를 참조하세요.
애플리케이션은 사전 인증을 사용하도록 설정된 Microsoft Entra 테넌트에 게시됩니다. 사용자는 양식 기반 인증을 사용하여 인증해야 합니다.

리치 클라이언트 인증 시나리오는 이 문서에서 다루지 않습니다.

고려 사항

다음 목록에서는 KCD 구성 및 Microsoft Entra 애플리케이션 프록시와 함께 사용하기 위한 기본 고려 사항에 대해 설명합니다.

기본 구성 오류 또는 일반적인 실수는 대부분의 문제를 발생합니다. 문제 해결을 시작하기 전에 애플리케이션 프록시에서 KCD SSO 사용의 모든 필수 구성 요소를 확인합니다.
커넥터 호스트는 특정 DC(로컬 사이트 도메인 컨트롤러)와만 통신하도록 제한되지 않습니다. 변경될 수 있으므로 사용하는 DC를 확인합니다.
도메인 간 시나리오는 커넥터 호스트를 로컬 네트워크 경계 외부에 있을 수 있는 DC로 안내하는 조회를 사용합니다. 이러한 경우 다른 각 도메인을 나타내는 DC로 트래픽을 전송하는 것이 똑같이 중요합니다. 그렇지 않으면 위임이 실패합니다.
핵심 RPC(원격 프로시저 호출) 트래픽의 간섭으로 인해 커넥터 호스트와 DC(도메인 컨트롤러) 간의 활성 IPS(침입 방지 시스템) 또는 IDS(침입 감지 시스템) 디바이스를 방지합니다.
간단한 시나리오에서 위임을 테스트합니다. 시나리오에서 더 많은 변수를 도입할수록 구성 및 문제 해결이 더 복잡해집니다. 시간을 절약하려면 테스트를 단일 커넥터로 제한합니다. 문제가 해결된 후 커넥터를 더 추가합니다.
환경 요인은 문제의 원인에 영향을 줄 수 있습니다. 이러한 요소를 방지하려면 테스트하는 동안 아키텍처를 최대한 최소화합니다. 예를 들어 잘못 구성된 내부 ACL(방화벽 액세스 제어 목록)이 일반적입니다. 가능하면 커넥터에서 DC 및 백 엔드 애플리케이션으로 직접 모든 트래픽을 보냅니다.
커넥터를 배치하는 가장 좋은 위치는 대상에 최대한 가깝습니다. 커넥터를 테스트할 때 인라인으로 배치되는 방화벽은 불필요한 복잡성을 더하고 조사를 연장할 수 있습니다.
KCD 문제를 나타내는 것은 무엇인가요? 몇 가지 일반적인 오류는 KCD SSO가 실패했음을 나타냅니다. 문제의 첫 번째 징후가 브라우저에 나타납니다.

다음 스크린샷은 모두 SSO 실패의 동일한 증상을 보여 줍니다. 애플리케이션에 대한 사용자 액세스가 거부됩니다.

문제 해결

KCD 문제는 세 단계로 해결할 수 있습니다. KCD 프로세스의 이러한 부분을 다음 순서대로 확인합니다.

클라이언트 사전 인증
위임 서비스
대상 애플리케이션

클라이언트 사전 인증

클라이언트 사전 인증 은 브라우저를 통해 애플리케이션에서 인증하는 외부 사용자를 나타냅니다. KCD SSO가 작동하려면 Microsoft Entra ID를 사전 인증하는 기능이 필요합니다.

먼저 클라이언트 사전 인증을 테스트하고 문제를 해결합니다. 사전 인증 단계는 KCD 또는 게시된 애플리케이션과 관련이 없습니다. 주체 계정이 Microsoft Entra ID에 있는지 확인하여 불일치를 쉽게 수정할 수 있습니다. 애플리케이션을 사용할 수 없거나 차단되지 않는지 확인합니다. 브라우저의 오류 응답은 일반적으로 원인을 설명할 만큼 충분히 설명적입니다.

위임 서비스

Kerberos 위임 서비스는 KDC(Kerberos 키 배포 센터)에서 Kerberos 서비스 티켓을 가져오는 프라이빗 네트워크 커넥터입니다. 앱 사용자는 티켓을 통해 애플리케이션을 인증합니다.

클라이언트와 Azure 프런트 엔드 간의 외부 통신은 제한된 위임에 영향을 주지 않습니다. 이러한 통신을 통해 KCD만 작동합니다. 애플리케이션 프록시 서비스에는 Kerberos 티켓을 가져오는 유효한 사용자 ID가 제공됩니다. 이 ID가 없으면 KCD가 발생할 수 없으며 SSO가 실패합니다.

브라우저 오류 메시지는 로그인이 실패하는 이유에 대한 유용한 정보를 제공합니다. 애플리케이션 로그인에 대한 응답으로 TransactionID 및 Timestamp 값을 기록합니다. 이 정보는 애플리케이션 프록시 이벤트 로그에 표시되는 이벤트와 동작의 상관 관계를 지정하는 데 도움이 됩니다.

Kerberos 제한 위임 구성 오류 메시지를 보여 주는 스크린샷

이벤트 로그의 해당 항목은 이벤트 ID 13019 또는 12027입니다. 커넥터 이벤트 로그를 보려면 애플리케이션 및 서비스 로그>Microsoft>Entra 프라이빗 네트워크>커넥터>Admin로 이동합니다.

제한된 위임 문제를 해결하려면 다음을 수행합니다.

애플리케이션 주소에 대한 내부 DNS(도메인 이름 시스템)에서 CNAME 레코드가 아닌 A 레코드를 사용합니다.
커넥터 호스트가 대상 계정의 SPN(서비스 사용자 이름)에 위임할 수 있는 권한으로 구성되어 있는지 확인합니다. 인증 프로토콜 사용이 선택되어 있는지 확인합니다. 자세한 내용은 SSO 구성을 참조하세요.
MICROSOFT Entra ID에 SPN 인스턴스가 하나만 있는지 확인합니다. 단일 SPN을 확인하려면 도메인 멤버 호스트의 명령 프롬프트에서 실행 setspn -x합니다.
발급된 Kerberos 토큰의 최대 크기를 제한하는 도메인 정책이 적용되는지 확인합니다. 정책은 토큰 크기가 설정된 최대값을 초과하는 경우 커넥터가 토큰을 가져오는 것을 중지합니다.
커넥터 호스트와 도메인 KCD 간의 교환을 캡처하는 네트워크 추적을 실행하는 것이 문제에 대한 자세한 내용을 가져오는 다음 가장 좋은 단계입니다. 자세한 내용은 Microsoft Entra 애플리케이션 프록시 문제 해결에 대한 자세한 백서를 검토할 수 있습니다.

티켓팅이 올바르게 작동하는 경우 애플리케이션이 401 오류를 반환했기 때문에 인증이 실패했음을 나타내는 이벤트가 로그에 표시될 수 있습니다. 이 이벤트는 대상 애플리케이션이 티켓을 거부했음을 나타냅니다. 문제 해결의 다음 단계로 이동합니다.

애플리케이션

대상 애플리케이션은 커넥터에서 제공하는 Kerberos 티켓을 처리합니다. 이 단계에서 커넥터는 백 엔드에 대한 첫 번째 애플리케이션 요청의 헤더로 Kerberos 서비스 티켓을 포함합니다.

애플리케이션 문제를 해결하려면 다음을 수행합니다.

애플리케이션에 액세스할 수 있는지 확인합니다. Azure Portal에 정의된 내부 URL을 사용하여 커넥터 호스트의 브라우저에서 직접 로그인합니다. 로그인이 성공하면 애플리케이션에 액세스할 수 있습니다.
브라우저와 애플리케이션이 인증에 Kerberos를 사용하고 있는지 확인합니다. 커넥터 호스트에서 Internet Explorer의 DevTools( F12 누름) 또는 Fiddler 를 사용하여 내부 URL을 통해 애플리케이션에 액세스합니다. 애플리케이션 응답의 웹 권한 부여 헤더에서 "협상" 또는 "Kerberos"를 찾습니다.

애플리케이션에 대한 브라우저 응답에는 Kerberos가 실행 중임을 확인하는 Kerberos 블롭으로 YII로 시작하는 것이 포함됩니다. 반면 Microsoft NTLM(NT LAN Manager)의 응답은 항상 .로 TlRMTVNTUAAB시작합니다. Base64에서 디코딩된 경우 이 응답은 NTLMSSP(NTLM Security Support Provider)를 읽습니다. Blob이 TlRMTVNTUAAB으로 시작하면 Kerberos를 사용할 수 없습니다. 그렇지 않다면 Kerberos를 사용할 수 있을 것입니다.

메모

Fiddler를 사용하는 경우 IIS의 애플리케이션 구성에서 확장된 보호를 일시적으로 사용하지 않도록 설정해야 합니다.

이 스크린샷의 Blob은 TIRMTVNTUAAB으로 시작하지 않습니다. 따라서 이 예제에서는 Kerberos를 사용할 수 있으며 Kerberos Blob은 .로 YII시작하지 않습니다.
IIS 사이트의 공급자 목록에서 NTLM을 일시적으로 제거합니다. 커넥터 호스트의 Internet Explorer에서 직접 앱에 액세스합니다. NTLM은 더 이상 공급자 목록에 없으므로 Kerberos를 사용해야만 애플리케이션에 액세스할 수 있습니다. 액세스가 실패하면 애플리케이션의 구성에 문제가 표시됩니다. 애플리케이션이 Kerberos 인증을 처리하지 않습니다.
Kerberos를 사용할 수 없는 경우 IIS에서 애플리케이션의 인증 설정을 확인합니다. Negotiate가 맨 위에 나열되고 NTLM이 바로 아래에 있는지 확인합니다. 협상 안됨, Kerberos 또는 협상, PKU2U 중 하나가 나타날 경우, Kerberos가 작동하는 경우에만 계속 진행하십시오.
Kerberos 및 NTLM이 있는 경우 포털에서 애플리케이션에 대한 사전 인증을 일시적으로 사용하지 않도록 설정합니다. 외부 URL을 사용하여 브라우저에서 애플리케이션에 액세스합니다. 인증하라는 메시지가 표시됩니다. 이전 단계에서 사용한 것과 동일한 계정을 사용합니다. 인증하고 로그인할 수 없는 경우 KCD가 아닌 백 엔드 애플리케이션에 문제가 있습니다.
포털에서 사전 인증을 다시 사용하도록 설정합니다. 외부 URL을 통해 애플리케이션에 연결을 시도하여 Azure를 통해 인증합니다. SSO가 실패하면 브라우저에 "사용할 수 없음" 오류 메시지가 표시되고 로그에 이벤트 ID 13022가 표시됩니다.

Microsoft Entra private network connector can't authenticate the user because the backend server responds to Kerberos authentication attempts with an HTTP 401 error.
IIS 애플리케이션을 확인합니다. 구성된 애플리케이션 풀과 SPN이 Microsoft Entra ID에서 동일한 계정을 사용하도록 구성되어 있는지 확인합니다. IIS에서 다음 스크린샷과 같이 폴더로 이동합니다.

ID를 확인한 다음 이 계정이 SPN으로 구성되었는지 확인합니다. 명령 프롬프트에서 setspn –q http/spn.contoso.com을 실행합니다.
포털에서 애플리케이션 설정에 대해 정의된 SPN을 확인합니다. 애플리케이션의 앱 풀이 대상 Microsoft Entra 계정에 대해 설정된 것과 동일한 SPN을 사용하는지 확인합니다.
IIS에서 애플리케이션에 대한 구성 편집기 옵션을 선택합니다. system.webServer/security/authentication/windowsAuthentication으로 이동합니다. UseAppPoolCredentials의 값이 True인지 확인합니다.

필요한 경우 값을 True 로 변경합니다. 다음 명령을 실행하여 백 엔드 서버에서 캐시된 Kerberos 티켓을 모두 제거합니다.
```
Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}
```
커널 모드를 사용하도록 설정하면 Kerberos 작업이 향상됩니다. 그러나 요청된 서비스에 대한 티켓도 컴퓨터 계정을 사용하여 암호 해독해야 합니다. 이 계정을 로컬 시스템이라고도 합니다. 애플리케이션이 팜의 둘 이상의 서버에서 호스트될 때 KCD를 중단하려면 이 값을 True 설정합니다.
또 다른 검사에서는 확장된 보호를 사용하지 않도록 설정합니다. 일부 테스트 시나리오에서는 확장된 보호가 특정 구성에서 사용하도록 설정되었을 때 KCD를 손상시켰습니다. 이러한 경우 애플리케이션은 기본 웹 사이트의 하위 폴더로 게시되었습니다. 이 애플리케이션은 익명 인증에 대해서만 구성됩니다. 모든 대화 상자는 비활성 상태이며 사용 가능한 선택 항목이 없으므로 자식 개체가 활성 설정을 상속하지 않음을 시사합니다. 테스트하는 것이 좋지만 가능하면 이 값을 사용하도록 복원하는 것을 잊지 마세요.

이 추가 검사는 게시된 애플리케이션 사용을 준비하게 해 줍니다. 위임하도록 구성된 커넥터를 더 많이 생성할 수 있습니다. 자세한 내용은 Microsoft Entra 애플리케이션 프록시 문제 해결에 대한 자세한 기술 연습을 참조하세요.

여전히 애플리케이션 인증 문제를 해결할 수 없는 경우 포털에서 직접 지원 티켓을 만듭니다.

기타 시나리오

Microsoft Entra 애플리케이션 프록시는 애플리케이션에 요청을 보내기 전에 Kerberos 티켓을 요청합니다. 일부 애플리케이션은 이 인증 방법을 지원하지 않습니다. 이러한 애플리케이션은 보다 일반적인 인증 단계에 응답하도록 설정됩니다. 첫 번째 요청은 익명이므로 애플리케이션이 401 오류를 통해 지원하는 인증 유형으로 응답할 수 있습니다. SSO에 대한 Kerberos 제한 위임에 설명된 단계를 완료하여 이러한 유형의 Kerberos 협상을 설정할 수 있습니다.

다중 홉 인증은 애플리케이션이 계층화될 때 일반적으로 사용됩니다. 계층에는 백 엔드와 프런트 엔드가 포함됩니다. 두 계층 모두 인증이 필요합니다. 예를 들어 SQL Server Reporting Services를 사용하여 계층화된 애플리케이션을 만들 수 있습니다. 자세한 내용은 웹 등록 프록시 페이지에 대한 Kerberos 제한 위임을 구성하는 방법을 참조하세요.

관리되는 도메인에서 KCD 설정