인터넷 Explorer Kerberos 오류 문제 해결

아티클
11/11/2023

이 문서는 인터넷 Explorer Kerberos 인증을 사용하도록 구성된 웹 사이트에 액세스할 때 다양한 오류의 원인을 격리하고 해결하는 데 도움이 됩니다. 잠재적인 문제의 수는 문제를 해결하는 데 사용할 수 있는 도구 수만큼 많습니다.

Kerberos 실패 시 일반적인 증상

Windows 통합 인증이 구성되어 있고 Kerberos 인증 프로토콜을 사용할 것으로 예상되는 웹 사이트에 액세스하려고 합니다. 이 경우 브라우저는 다음과 같이 자격 증명을 즉시 묻는 메시지를 표시합니다.

자격 증명에 대한 프롬프트의 스크린샷.

유효한 사용자 이름과 암호를 입력하더라도 다시 메시지가 표시됩니다(총 3개의 프롬프트). 그런 다음 원하는 리소스에 액세스할 수 없다는 화면이 표시됩니다. 화면에는 다음 오류와 유사한 HTTP 401 상태 코드가 표시됩니다.

권한 없음
HTTP 오류 401. 요청된 리소스에는 사용자 인증이 필요합니다.

H T TP 오류 401의 스크린샷

Microsoft 인터넷 정보 서비스(IIS) 서버에서 웹 사이트 로그에는 다음 로그와 같은 401.2 상태 코드로 끝나는 요청이 포함됩니다.

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken  
DateTime IP GET /whoami.aspx - 80 – IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 1270  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 8

또는 화면에 다음 로그와 같은 401.1 상태 코드가 표시됩니다.

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 105  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 1 2148074245 18

Kerberos 사용 여부 확인

Kerberos 인증 실패 문제를 해결하는 경우 구성을 최소한으로 간소화하는 것이 좋습니다. 즉, 기본 포트에서 실행되는 클라이언트 1개, 서버 1개 및 IIS 사이트 1개입니다. 또한 몇 가지 기본 문제 해결 단계를 따를 수 있습니다. 예를 들어 테스트 페이지를 사용하여 사용되는 인증 방법을 확인합니다. ASP.NET 사용하는 경우 이 ASP.NET 인증 테스트 페이지를 만들 수 있습니다.

클래식 ASP를 사용하는 경우 다음 Testkerb.asp 페이지를 사용할 수 있습니다.

<%
    authType=UCase(Request.ServerVariables("AUTH_TYPE"))
    authHeader=Request.ServerVariables("HTTP_AUTHORIZATION")
    response.write " Authentication Method : " & authType & "<BR>"
    LenAuthHeader = len(authHeader)
    response.write " Protocol : "
    if Len(authType ) =0 then response.write " Anonymous" else if authType<>"NEGOTIATE" then response.write authType else if LenAuthHeader>1000 then response.write "Kerberos" else response.write  "NTLM"
%>

다음 도구를 사용하여 Kerberos가 사용되는지 여부를 확인할 수도 있습니다.

Fiddler
HttpWatch
네트워크 모니터
브라우저의 개발자 도구

이러한 추적을 생성하는 방법에 대한 자세한 내용은 클라이언트 쪽 추적을 참조하세요.

Kerberos를 사용하는 경우 헤더에 Kerberos 티켓이 포함되어 있기 때문에 HTTP_AUTHORIZATION 클라이언트에서 보낸 요청이 2,000바이트 이상입니다. 다음 요청은 Kerberos 기반 Windows 인증을 사용하여 들어오는 사용자를 인증하는 페이지에 대한 것입니다. GET 요청의 크기는 4,000바이트 이상입니다.

4,000바이트 이상의 요청 스크린샷

NTLM 핸드셰이크를 사용하는 경우 요청이 훨씬 작아집니다. 다음 클라이언트 쪽 캡처는 NTLM 인증 요청을 보여줍니다. GET 요청은 훨씬 작습니다(1,400바이트 미만).

1,400바이트 미만의 요청 스크린샷

Kerberos 인증이 실패하는 것으로 확인되면 지정된 순서로 다음 항목을 각각 검사.

Kerberos 인증이 실패할 경우 검사 항목

다음 섹션에서는 Kerberos 인증이 실패하는 경우 검사 데 사용할 수 있는 항목에 대해 설명합니다.

클라이언트와 서버가 동일한 도메인에 있나요?

Kerberos 티켓은 DC(도메인 컨트롤러)에 의해 전달되므로 Kerberos를 사용하려면 도메인이 필요합니다. 다음과 같은 경우 고급 시나리오도 가능합니다.

클라이언트와 서버는 동일한 도메인이 아니라 동일한 포리스트의 두 도메인에 있습니다.
클라이언트와 서버는 서로 다른 두 포리스트에 있습니다.

이러한 가능한 시나리오는 이 문서의 작업하는 데 사용되었지만 두 포리스트 간에 Kerberos 위임이 실패하는 이유 섹션에서 설명합니다.

IIS가 통합 인증을 사용하도록 구성되어 있나요?

Windows 인증 설정의 스크린샷.

인터넷 Explorer 통합 인증이 사용하도록 설정되어 있나요?

인터넷 옵션 페이지에서 Windows 통합 인증 사용 옵션을 선택합니다.

자격 증명을 보낼 수 있는 보안 영역에 resolve 사용되는 URL을 수행합니다.

항상 다음 사이트에 대해 이 검사 실행합니다.

브라우저의 로컬 인트라넷 영역과 일치하는 사이트입니다.
신뢰할 수 있는 사이트 영역의 사이트입니다.

브라우저에서 사이트를 포함하기로 결정하는 영역을 검사 수 있습니다. 이렇게 하려면 인터넷 Explorer 파일 메뉴를 열고 속성을 선택합니다. 속성 창에는 브라우저에서 탐색 중인 사이트를 포함하기로 결정한 영역이 표시됩니다.

인터넷 Explorer 속성에서 영역을 확인합니다.

사이트가 포함된 영역이 자동 로그온을 허용하는지 여부를 검사 수 있습니다. 이렇게 하려면 인터넷 Explorer 인터넷 옵션 메뉴를 열고 보안 탭을 선택합니다. 원하는 영역을 선택한 후 사용자 지정 수준 단추를 선택하여 설정을 표시하고 자동 로그온이 선택되어 있는지 확인합니다. (일반적으로 이 기능은 인트라넷 및 신뢰할 수 있는 사이트 영역에 대해 기본적으로 켜져 있습니다.)

자동 로그온이 선택되어 있는지 확인합니다.

참고

이 구성이 일반적이지 않더라도(클라이언트가 DC에 액세스해야 하므로) Kerberos를 인터넷 영역의 URL에 사용할 수 있습니다. 이 경우 기본 설정이 변경되지 않는 한 브라우저는 항상 사용자에게 자격 증명을 묻는 메시지를 표시합니다. Kerberos 위임은 인터넷 영역에서 작동하지 않습니다. 인터넷 Explorer 인트라넷 및 신뢰할 수 있는 사이트 영역의 URL에 대해서만 Kerberos 위임을 허용하기 때문입니다.

WWW-Authenticate: Negotiate 헤더를 보내도록 구성된 IIS 서버인가요?

IIS 서버가 WWW-Authenticate: Negotiate 헤더를 보내도록 구성되었는지 확인합니다.

IIS에서 이 헤더를 보내지 않는 경우 IIS 관리자 콘솔을 사용하여 NTAuthenticationProviders 구성 속성을 통해 Negotiate 헤더를 설정합니다. 자세한 내용은 Windows 인증 공급자 공급자를 <참조하세요>. IIS 관리자에서 Windows 인증 세부 정보의 공급자 설정을 통해 콘솔에 액세스할 수 있습니다.

인증의 공급자 설정입니다.

참고

기본적으로 NTAuthenticationProviders 속성은 설정되지 않습니다. 이로 인해 IIS는 Negotiate 및 Windows NT LAN Manager(NTLM) 헤더를 모두 보냅니다.

클라이언트와 서버가 동일한 컴퓨터에 설치되어 있나요?

기본적으로 Kerberos는 이 구성에서 사용하도록 설정되지 않습니다. 이 동작을 변경하려면 레지스트리 키를 설정 DisableLoopBackCheck 해야 합니다. 자세한 내용은 KB 926642 참조하세요.

클라이언트가 Kerberos 티켓을 받을 수 있나요?

KLIST(Kerberos 목록) 도구를 사용하여 클라이언트 컴퓨터가 지정된 서비스 주체 이름에 대한 Kerberos 티켓을 가져올 수 있는지 확인할 수 있습니다. 이 예제에서 SPN(서비스 사용자 이름)은 http/web-server입니다.

참고

KLIST는 서버 쪽 운영 체제용 Windows Server 2008 및 클라이언트 쪽 운영 체제용 Windows 7 서비스 팩 1 이후의 네이티브 Windows 도구입니다.

KLIST 도구를 사용하여 클라이언트 컴퓨터가 지정된 서비스 주체 이름에 대한 Kerberos 티켓을 가져올 수 있는지 확인합니다.

Kerberos 티켓 요청이 실패하면 Kerberos 인증이 사용되지 않습니다. 요청된 SPN이 DC에 알려지지 않아 NTLM 대체가 발생할 수 있습니다. DC에 연결할 수 없는 경우 NTLM 대체가 발생하지 않습니다.

SPN을 선언하려면 다음 문서를 참조하세요.

인터넷 정보 서비스에서 호스트되는 웹 애플리케이션을 구성할 때 SPN을 사용하는 방법입니다.

웹 서버에서 기본 포트가 아닌 포트를 사용하나요(80)

기본적으로 인터넷 Explorer Kerberos 티켓을 요청하는 데 사용되는 SPN에 포트 번호 정보를 포함하지 않습니다. IIS를 사용하여 여러 포트 및 ID에서 여러 사이트를 호스트하는 경우 문제가 될 수 있습니다. 이 구성에서 Kerberos 인증은 Active Directory에서 모든 SPN이 올바르게 선언된 경우에도 특정 사이트에 대해서만 작동할 수 있습니다. 이 문제를 해결하려면 레지스트리 값을 설정 FEATURE_INCLUDE_PORT_IN_SPN_KB908209 해야 합니다. 키를 선언하는 방법에 대한 자세한 내용은 인터넷 Explorer 기능 키 섹션을 참조하세요. 이 설정은 인터넷 Explorer Kerberos 티켓을 요청하는 데 사용되는 SPN에 포트 번호를 포함하도록 강제합니다.

인터넷 Explorer 예상 SPN을 사용하나요?

CNAME(별칭 이름)을 사용하여 웹 사이트에 액세스하는 경우 인터넷 Explorer 먼저 DNS 확인을 사용하여 별칭 이름을 ANAME(컴퓨터 이름)에 resolve. 그런 다음 컴퓨터 이름을 사용하여 SPN을 빌드하고 Kerberos 티켓을 요청합니다. 인터넷 Explorer 주소 표시줄에 입력된 URL이 인 경우에도 MYWEBSITE가 http://MYWEBSITEMYSERVER(ANAME)의 별칭(CNAME)인 경우 인터넷 Explorer HTTP/MYSERVER에 대한 SPN을 요청합니다. 레지스트리 키를 사용하여 이 동작을 FEATURE_USE_CNAME_FOR_SPN_KB911149 변경할 수 있습니다. (키를 선언하는 방법에 대한 자세한 내용은 인터넷 Explorer 기능 키를 참조하세요.)

네트워크 모니터 추적은 다음 예제와 같이 Kerberos 티켓과 연결된 SPN을 검사 좋은 방법입니다.

- Http: Request, GET /whoami.aspx , Using GSS-API Authorization
    Command: GET
  - URI: /whoami.aspx
     Location: /whoami.aspx
    ProtocolVersion: HTTP/1.1
    Accept:  image/gif, image/jpeg, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */*
    Accept-Language:  en-US,en;q=0.5
    UserAgent:  Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729)
    Accept-Encoding:  gzip, deflate
    Host:  web-server
    Connection:  Keep-Alive
  - Authorization: Negotiate
   - Authorization:  Negotiate YIILcAYGKwYBBQUCoIILZDCCC2CgMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCCyoEggsmYIILIgYJKoZIhvcSAQICAQBuggsRMIILDaADAgEFoQMCAQ6iBwMFACAAAACjggRtYYIEaTCCBGWgAwIBBaEOGwxPREVTU1kuTE9DQUyiKjAooAMCAQKhITAfGwRIVFRQG
      WhiteSpace:  
    - NegotiateAuthorization:
       Scheme: Negotiate
     - GssAPI: 0x1
      - InitialContextToken:
       + ApplicationHeader:
       + ThisMech: SpnegoToken (1.3.6.1.5.5.2)
       - InnerContextToken: 0x1
        - SpnegoToken: 0x1
         + ChoiceTag:
         - NegTokenInit:
          + SequenceHeader:
          + Tag0:
          + MechTypes: Prefer MsKerberosToken (1.2.840.48018.1.2.2)
          + Tag2:
          + OctetStringHeader:
          - MechToken: 0x1
           - MsKerberosToken: 0x1
            - KerberosInitToken:
             + ApplicationHeader:
             + ThisMech: KerberosToken (1.2.840.113554.1.2.2)
             - InnerContextToken: 0x1
              - KerberosToken: 0x1
                 TokId: Krb5ApReq (0x100)
               - ApReq: KRB_AP_REQ (14)
                + ApplicationTag:
                + SequenceHeader:
                + Tag0:
                + PvNo: 5
                + Tag1:
                + MsgType: KRB_AP_REQ (14)
                + Tag2: 0x1
                + ApOptions:
                + Tag3:
                - Ticket: Realm: ODESSY.LOCAL, Sname: HTTP/web-server.odessy.local
                 + ApplicationTag:
                 + SequenceHeader:
                 + Tag0:
                 + TktVno: 5
                 + Tag1:
                 + Realm: ODESSY.LOCAL
                 + Tag2: 0x1
                 + Sname: HTTP/web-server.odessy.local
                 + Tag3: 0x1
                 + EncPart:
                + Tag4:

애플리케이션 풀 ID가 SPN과 연결된 계정과 일치하나요?

Kerberos 티켓이 인터넷 Explorer IIS 서버로 전송되면 티켓은 프라이빗 키를 사용하여 암호화됩니다. 프라이빗 키는 SPN과 연결된 사용자 계정에 사용되는 암호의 해시입니다. 따라서 이 계정으로 실행되는 애플리케이션만 티켓을 디코딩할 수 있습니다.

다음 절차는 Kerberos 인증 알고리즘에 대한 요약입니다.

인터넷 Explorer 주소 표시줄에 입력된 URL을 사용하여 SPN을 결정합니다.
SPN은 SSPI(보안 지원 공급자 인터페이스) API(InitializeSecurityContext)를 통해 Windows 보안을 담당하는 시스템 구성 요소(LSASS(로컬 보안 기관 하위 시스템 서비스) 프로세스)에 전달됩니다. 이 단계에서는 인터넷 Explorer 코드가 Kerberos 티켓을 생성하는 코드를 구현하지 않는 것을 볼 수 있습니다. 인터넷 Explorer SSPI API만 호출합니다.
LSASS는 전달된 SPN을 사용하여 DC에 Kerberos 티켓을 요청합니다. DC가 요청(알려진 SPN)을 제공할 수 있는 경우 Kerberos 티켓을 만듭니다. 그런 다음 SPN과 연결된 계정에 대한 사용자 계정 암호의 해시에서 생성된 키를 사용하여 티켓을 암호화합니다. 그런 다음 LSASS는 티켓을 클라이언트에 보냅니다. 인터넷 Explorer 관한 한 티켓은 불투명한 Blob입니다.
인터넷 Explorer 헤더에서 LSASS Authorization: Negotiate 에서 제공하는 Kerberos 티켓을 캡슐화한 다음 IIS 서버로 티켓을 보냅니다.
IIS는 요청을 처리하고 지정된 호스트 헤더를 사용하여 올바른 애플리케이션 풀로 라우팅합니다.
애플리케이션 풀은 SSPI/LSASS API를 사용하고 다음 조건에 따라 티켓의 암호를 해독하려고 합니다.
- 티켓의 암호를 해독할 수 있으면 Kerberos 인증이 성공합니다. 티켓과 연결된 모든 서비스(가장, 티켓이 허용하는 경우 위임 등)를 사용할 수 있습니다.
- 티켓을 해독할 수 없는 경우 Kerberos 오류(KRB_AP_ERR_MODIFIED)가 반환됩니다. 이 오류는 티켓이 전송 중에 어떤 방식으로 변경되었음을 나타내는 일반적인 오류입니다. 따라서 티켓의 암호를 해독할 수 없습니다. 이 오류는 Windows 이벤트 로그에도 기록됩니다.

SPN을 명시적으로 선언하지 않으면 Kerberos 인증은 다음 애플리케이션 풀 ID 중 하나에서만 작동합니다.

네트워크 서비스
ApplicationPoolIdentity
LOCALSYSTEM 또는 LOCALSERVICE와 같은 다른 시스템 계정

그러나 이러한 ID는 보안 위험이므로 권장되지 않습니다. 이 경우 Kerberos 티켓은 컴퓨터(이 경우 IIS가 실행 중인 서버)가 도메인에 추가되면 Active Directory에서 만든 기본 SPN을 사용하여 빌드됩니다. 이 기본 SPN은 컴퓨터 계정과 연결됩니다. IIS에서 컴퓨터 계정은 네트워크 서비스 또는 ApplicationPoolIdentity에 매핑됩니다.

애플리케이션 풀에서 나열된 ID 이외의 ID를 사용해야 하는 경우 SPN(SETSPN 사용)을 선언합니다. 그런 다음 애플리케이션 풀 ID에 사용되는 계정과 연결합니다. 일반적인 실수는 계정이 다른 유사한 SPN을 만드는 것입니다. 예를 들면

SETSPN http/mywebsite UserAppPool1
SETSPN http/mywebsite UserAppPool2

Http/mywebsite SPN의 Kerberos 티켓이 UserAppPool1 또는 UserAppPool2 암호를 사용하여 암호화되는지 여부를 확인할 수 있는 결정적인 방법이 없기 때문에 이 구성은 작동하지 않습니다. 이 구성은 일반적으로 KRB_AP_ERR_MODIFIED 오류를 생성합니다. 이 잘못된 중복 SPN 시나리오에 있는지 확인하려면 다음 문서에 설명된 도구를 사용합니다.

AD 2012 R2 및 AD 2016에서 여전히 중복 SPN을 사용할 수 있는 이유

Windows Server 2008부터 대상 계정에 대한 새 SPN을 선언할 때 명령을 사용하여 setspn –X 중복 SPN을 검색할 수 있는 업데이트된 버전의 WINDOWS용 SETSPN을 사용할 수도 있습니다. 자세한 내용은 Setspn을 참조하세요.

또한 다음 문서를 검토하는 것이 좋습니다.

IIS 6에서 작동하더라도 IIS 7 이상 버전에서 Kerberos 인증이 실패하나요?

커널 모드 인증은 IIS 7에서 도입된 기능입니다. 다음과 같은 이점을 제공합니다.

커널 모드-사용자 모드 전환이 더 이상 이루어지지 않으므로 성능이 향상됩니다.
Kerberos 티켓 디코딩은 애플리케이션 풀 ID가 아닌 컴퓨터 계정을 사용하여 이루어집니다. 이 변경을 통해 SPN을 선언하지 않고도 여러 애플리케이션 풀이 다른 ID에서 실행되도록 할 수 있습니다.

경고

특정 사용자 계정(애플리케이션 풀 ID로도 사용됨)에 대해 SPN이 선언된 경우 커널 모드 인증은 컴퓨터 계정을 사용하기 때문에 Kerberos 티켓의 암호를 해독할 수 없습니다. 이 문제는 웹 팜 시나리오에서 일반적입니다. 이 시나리오는 일반적으로 (가상) NLB 호스트 이름에 대한 SPN을 선언합니다. 이 문제를 방지하려면 다음 방법 중 하나를 사용합니다.

커널 모드 인증을 사용하지 않도록 설정합니다. (성능 관점에서는 권장되지 않습니다.)
useAppPoolCredentials를true로 설정합니다. 이렇게 하면 커널 모드 인증의 성능 이점을 유지하면서 Kerberos 티켓을 애플리케이션 풀 ID에서 디코딩할 수 있습니다. 자세한 내용은 보안 인증 인증 <을 참조하세요>.

Kerberos 인증이 작동하지만 위임이 실패하는 이유

이 시나리오에서는 다음 항목을 검사.

URL에 사용되는 인터넷 Explorer 영역입니다. Kerberos 위임은 인트라넷 및 신뢰할 수 있는 사이트 영역에만 허용됩니다. 즉, 결정된 영역이 ISC_REQ_DELEGATE 인트라넷 또는 신뢰할 수 있는 사이트인 경우에만 Internet Explorer InitializeSecurityContext를 호출할 때 플래그를 설정합니다.
사이트를 호스팅하는 IIS 애플리케이션 풀의 사용자 계정에는 Active Directory 내에서 위임에 대해 신뢰할 수 있는 플래그가 설정되어 있어야 합니다.

위임이 여전히 실패하는 경우 IIS에 Kerberos Configuration Manager 사용하는 것이 좋습니다. 이 도구를 사용하면 Kerberos 인증 및 대상 계정의 연결된 SPN에 대한 IIS 구성을 진단하고 수정할 수 있습니다. 자세한 내용은 README.md 참조하세요. 여기에서 도구를 다운로드할 수 있습니다.

Kerberos 인증을 사용할 때 성능이 저하되는 이유

Kerberos는 Windows Server 2008 SP2 및 Windows Server 2008 R2와 같은 이전 버전의 Windows Server에서 요청 기반 인증 프로토콜입니다. 즉, 클라이언트는 서버에 대해 만들어진 각 요청과 함께 Kerberos 티켓(상당히 큰 Blob일 수 있습니다)을 보내야 합니다. NTLM을 사용하는 인증 방법과는 반대입니다. 기본적으로 NTLM은 세션 기반입니다. 즉, 브라우저는 서버에 대한 TCP 연결을 열 때 하나의 요청만 인증합니다. 동일한 TCP 연결의 각 후속 요청에는 더 이상 요청을 수락하기 위한 인증이 필요하지 않습니다. 최신 버전의 IIS에서는 Windows 2012 R2부터 Kerberos도 세션 기반입니다. 새 TCP 연결에 대한 첫 번째 요청만 서버에서 인증해야 합니다. 후속 요청에는 Kerberos 티켓을 포함할 필요가 없습니다.

IIS 7 이상 버전에서 실행하는 경우 authPersistNonNTLM 속성을 사용하여 이 동작을 변경할 수 있습니다. 속성이 true로 설정되면 Kerberos는 세션 기반이 됩니다. 그렇지 않으면 요청 기반이 됩니다. 매번 서버로 보낼 더 많은 양의 데이터를 포함해야 하기 때문에 성능이 저하됩니다. 자세한 내용은 요청 기반 및 세션 기반 Kerberos 인증(또는 AuthPersistNonNTLM 매개 변수)을 참조하세요.

참고

모든 개체에서 Kerberos 인증을 맹목적으로 사용하는 것은 좋지 않을 수 있습니다. Kerberos 인증을 사용하여 수정되지 않은 응답 304 를 생성할 가능성이 높은 조건부 GET 요청을 사용하여 수백 개의 이미지를 가져오는 것은 망치를 사용하여 비행을 죽이는 것과 같습니다. 이러한 메서드는 명백한 보안 향상을 제공하지 않습니다.

두 포리스트 간에 Kerberos 위임이 실패하는 이유는 무엇인가요?

다음과 같은 경우를 생각해볼 수 있습니다.

애플리케이션의 사용자는 포리스트 A 내의 도메인에 있습니다.
애플리케이션은 포리스트 B 내의 도메인에 있습니다.
포리스트 간에 트러스트 관계가 있습니다.

이 시나리오에서는 이전에 작동했지만 포리스트 또는 도메인을 변경하지 않았더라도 Kerberos 위임이 작동을 중지할 수 있습니다. Kerberos 인증은 이 시나리오에서 여전히 작동합니다. 위임만 실패합니다.

이 문제는 Microsoft가 2019년 3월과 2019년 7월에 릴리스한 Windows Server에 대한 보안 업데이트로 인해 발생할 수 있습니다. 이러한 업데이트는 모든 신규 및 기존 트러스트에 대한 포리스트 경계를 넘어 제약 없이 Kerberos 위임(애플리케이션에서 백 엔드 서비스로 Kerberos 토큰을 위임하는 기능)을 사용하지 않도록 설정합니다. 자세한 내용은 Windows Server에서 들어오는 트러스트에서 TGT 위임에 업데이트 참조하세요.

인터넷 Explorer 기능 키

이러한 키는 브라우저의 일부 기능을 켜거나 끄는 레지스트리 키입니다. 키는 다음 레지스트리 위치에 있습니다.

HKEY_USERS\<UserSID>\Software\Microsoft\Internet Explorer\Main\FeatureControl – 사용자 수준에서 정의된 경우
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\ - 컴퓨터 수준에서 정의된 경우

기능을 켜거나 끌지 여부에 따라 다음 위치 중 하나에서 기능 키를 만들어야 합니다.

컴퓨터의 모든 사용자에 대해
특정 계정의 경우

이러한 키는 해당 경로 아래에 만들어야 합니다. 키 내에서 이름이 인 iexplorer.exe DWORD 값을 선언해야 합니다. 각 키의 기본값은 원하는 기능 설정에 따라 true 또는 false여야 합니다. 기본적으로 기능 키 FEATURE_INCLUDE_PORT_IN_SPN_KB908209 와 FEATURE_USE_CNAME_FOR_SPN_KB911149의 값은 false입니다. 완전성을 위해 Kerberos 티켓에 포트 번호를 포함하도록 기능 키를 true로 설정하여 레지스트리를 내보내는 예제는 다음과 같습니다.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_INCLUDE_PORT_IN_SPN_KB908209]
"iexplore.exe"=dword:00000001

추가 정보

Windows 통합 인증 문제 해결을 위한 진단 페이지