Microsoft Edge를 사용한 Kerberos 비제한 이중 홉 인증(Chromium)

적용 대상: 인터넷 정보 서비스

소개

Kerberos 인증 프로토콜을 기반으로 Windows 인증을 설정하는 것은 특히 IIS 및 ASP.NET 컨텍스트에서 프런트 엔드 사이트에서 백 엔드 서비스로 ID 위임과 같은 시나리오를 처리하는 경우 복잡한 작업이 될 수 있습니다. 이 문서의 단계에 따라 인증 티켓 위임을 설정하고 Microsoft Edge 버전 87 이상과 같은 최신 브라우저에서 서비스를 사용합니다.

이 문서에서는 아래 다이어그램에 표시된 것과 유사한 아키텍처를 설정한다고 가정합니다.

• Workstation-Client1 컴퓨터는 주 웹 서버와 동일한 Active Directory의 일부이며, Primary-IIS-SRV 및 백 엔드 웹 서버(Backend-Web-SRV)라고 합니다.
• 컴퓨터 Workstation-Client1 의 사용자는 Windows Active Directory 계정을 사용하여 컴퓨터에 로그온합니다.
• 그런 다음 브라우저(Microsoft Edge)를 시작하고, Primary-IIS-SRV에 사용되는 별칭 이름인 웹 서버에 있는 웹 사이트로 이동하고, Kerberos를 사용하여 통합 Windows 인증 통해 인증합니다.
• 웹 서버에 있는 웹 사이트는 인증된 사용자의 자격 증명을 사용하여 API-Server(Backend-Web-SRV의 별칭)를 사용하여 Kerberos 자격 증명 위임을 사용하여 사용자를 대신하여 애플리케이션 데이터를 검색합니다.

아래 단계는 이 시나리오를 해결하는 데 도움이 됩니다. 설정은 Internet Explorer에서 작동하지만 사용자가 Microsoft Edge를 채택할 때 더 이상 자격 증명 위임 기능을 사용할 수 없습니다. Kerberos 자격 증명 위임을 사용하려면 먼저 Internet Explorer에서 Kerberos 오류 문제 해결을 참조하세요.

제한되거나 제한되지 않은 위임

위의 시나리오에서 두 구성을 통해 사용자는 프런트 엔드 웹 서버를 통해 연결하는 동안 컴퓨터 Workstation-Client1 의 사용자 세션에서 백 엔드 API 서버로 자격 증명을 위임할 수 있습니다.

제한되지 않은 Kerberos 위임 구성에서 애플리케이션 풀 ID는 웹 서버에서 실행되며 Active Directory에서 모든 서비스에 대한 위임을 신뢰할 수 있도록 구성됩니다. 웹 서버에서 실행되는 애플리케이션 풀의 계정은 해당 서버에 호스트된 웹 사이트의 인증된 사용자의 자격 증명을 Active Directory의 다른 서비스에 위임할 수 있습니다. 예를 들어 SMTP 서버, 파일 서버, 데이터베이스 서버, 다른 웹 서버 등이 있습니다. 이 위임은 애플리케이션 풀 계정에 연결한 서비스에 자격 증명을 위임할 수 있는 권한(제한되지 않음)이 있기 때문에 제한되지 않은 위임이라고 합니다.

제한된 위임 구성에서 애플리케이션 풀 ID로 사용되는 Active Directory 계정은 인증된 사용자의 자격 증명을 위임할 권한이 있는 서비스 목록에만 위임할 수 있습니다. Web-Server라는 서버에 있는 웹 애플리케이션도 데이터베이스에 연결하고 사용자를 대신하여 인증해야 하는 경우 이 SPN(서비스 사용자 이름)을 권한 있는 서비스 목록에 추가해야 합니다.

제한된 위임은 최소 권한 원칙에 따라 제한되지 않은 위임보다 더 안전합니다. 애플리케이션에는 작동하는 데 필요한 권한과 그 이상의 권한이 부여되는 반면, 제한되지 않은 위임은 애플리케이션이 사용자를 대신하여 연락해서는 안 되는 리소스에 연결할 수 있도록 허용합니다.

웹 서버로 보내기 위해 클라이언트에서 얻은 Kerberos 티켓이 제한되거나 제한되지 않은 위임을 사용하는지 여부를 어떻게 알 수 있나요?

Windows에 있는 klist 명령 도구를 사용하여 클라이언트 컴퓨터의 Kerberos 티켓 캐시를 나열합니다(위 다이어그램의 Workstation-Client1 ). 웹 서버의 HTTP/<이름이라는 티켓을 찾습니다>. 참고: <웹 서버> 의 이름은 Kerberos를 통해 연결하고 인증하려는 서비스의 SPN입니다. 티켓에는 몇 가지 플래그도 포함되어 있습니다. 그 중 두 가지가 관심이 있습니다. forwardable ok_as_delegate

• 첫 번째 플래그는 forwardableKDC(키 배포 센터)가 필요한 경우 새 네트워크 마스크를 사용하여 새 티켓을 발급할 수 있음을 나타냅니다. 이렇게 하면 사용자가 원격 시스템에 로그인하고 원격 시스템에서 사용자가 로컬로 원격 시스템에 로그인한 것처럼 다른 백 엔드 시스템에 로그인할 수 있도록 사용자를 대신하여 새 티켓을 얻을 수 있습니다.

• 두 번째 플래그 ok_as_delegate 는 사용자가 인증하려는 서비스의 서비스 계정(위 다이어그램의 경우 웹 애플리케이션을 호스팅하는 IIS 애플리케이션 풀의 애플리케이션 풀 계정)이 제한되지 않은 위임에 대해 신뢰할 수 있음을 나타냅니다.

이러한 서비스가 제한되지 않은 위임을 사용하는 경우 클라이언트 컴퓨터의 티켓에는 플래그가 ok_as_delegate forwardable 포함됩니다. 대부분의 경우 제한된 위임이 구성된 경우 티켓에는 플래그가 ok_as_delegate 포함되지 않지만 플래그가 forwardable 포함됩니다.

제한되지 않은 위임이 Microsoft Edge가 아닌 Internet Explorer에서 작동하는 이유는 무엇인가요?

Kerberos 기반 인증을 사용하여 웹 사이트에 인증을 시도하면 브라우저는 Windows API를 호출하여 인증 컨텍스트를 설정합니다. 문제의 API는 .입니다 InitializeSecurityContext. 이 API는 브라우저에서 사용자가 받은 티켓을 허용하는 delegatable 지 여부를 나타내는 일련의 플래그를 수신할 수 있습니다. 티켓은 사용자가 인증하려는 서비스에 제한되지 않은 방식으로 자격 증명을 위임할 수 있는 권한이 있기 때문에 표시됩니다 delegatable . 그러나 인증을 시도하는 애플리케이션(이 경우 브라우저)이 이 용량을 사용해야 한다는 의미는 아닙니다.

기본적으로 Internet Explorer는 플래그를 전달하여 InitializeSecurityContext티켓을 위임할 수 있는 경우 위임해야 함을 나타냅니다. 버전 87 이상의 Microsoft Edge는 티켓이 플래그로 표시되어 있기 때문에 플래그 InitializeSecurityContext 를 ok_as_delegate 전달하지 않습니다. 애플리케이션에 필요한 것보다 더 많은 권한을 부여하므로 애플리케이션에서 제한되지 않은 위임을 사용하지 않는 것이 좋습니다. 애플리케이션은 사용자의 ID를 도메인의 다른 서비스에 위임하고 사용자로 인증할 수 있습니다. 이는 자격 증명 위임을 사용하는 대부분의 애플리케이션에 필요하지 않습니다. 애플리케이션은 제한된 위임을 설정할 때 지정된 목록의 서비스만 연결해야 합니다.

기본적으로 Microsoft Edge는 제한된 위임에서 작동합니다. 여기서 웹 서버에서 실행되는 IIS 웹 사이트는 아래에 나열된 Active Directory의 애플리케이션 풀 ID 계정 구성에 표시된 것처럼 API-Server에서 호스트되는 백 엔드 API 사이트에만 연결할 수 있습니다.

Active Directory에서 Edge-Chromium이 제한되지 않은 위임으로 작동하도록 설정

호환성을 위해 Kerberos를 통해 제한되지 않은 위임을 사용하여 애플리케이션을 유지 관리해야 하는 경우 Microsoft Edge에서 티켓 위임을 허용하도록 설정합니다. 아래 단계는 이 문서의 다음 섹션에 자세히 설명되어 있습니다.

1. Active Directory에 그룹 정책 중앙 저장소에 대한 관리 템플릿을 설치합니다(아직 없는 경우).
2. Microsoft Edge 관리 템플릿을 설치합니다.
3. 새 그룹 정책 개체를 만듭니다.
4. 서버에 인증할 때 제한되지 않은 위임을 허용하도록 그룹 정책의 구성을 편집합니다.
5. (선택 사항) Microsoft Edge에서 올바른 위임 플래그를 사용하고 있는지 확인합니다.

1단계: Active Directory용 관리 템플릿 설치

1. 관리 템플릿(.admx)에서 템플릿을 다운로드합니다(Windows Server 2019용).

2. 설치 관리자를 다운로드하고 선택한 폴더에 콘텐츠를 추출합니다. 패키지의 기본 지정된 위치(C:\Program Files (x86)\Microsoft Group Policy\Windows 10 2018년 10월 업데이트(1809) v2\PolicyDefinitions)로 추출할 수 있습니다.

3. 패키지의 압축을 풀면 도메인 컨트롤러에서 Sysvol 폴더를 찾습니다. 폴더의 경로는 C:\Windows\SYSVOL\sysvol\입니다. Sysvol 폴더 내에는 Active Directory 이름과 이름이 같은 폴더가 있습니다(샘플의 경우 Oddessy.local). 여기에서 정책 폴더로 이동합니다. 없는 경우 아래와 같이 정책 정의라는 폴더를 만듭니다.

   

4. 도메인 컨트롤러의 sysvol 폴더에 있는 도메인 내에서 만든 PolicyDefinitions 폴더(설치 관리자에서 추출된 PolicyDefinitions 폴더)의 콘텐츠를 복사합니다.

   참고 항목

   설치 관리자가 추출한 파일에는 지역화된 콘텐츠도 포함됩니다. 공간을 절약하려면 원하는 언어에 대해서만 지역화된 파일을 전송합니다. 예를 들어 fr-FR 폴더에는 프랑스어로 지역화된 모든 콘텐츠가 포함됩니다.

5. 전송이 완료되면 Active Directory에서 템플릿을 사용할 수 있는지 확인합니다. 이렇게 하려면 Microsoft 관리 콘솔의 그룹 정책 관리 스냅인을 엽니다(Windows+R을 누른 다음 gpmc.msc를 입력하여 시작). 그룹 정책 관리 내에서 그룹 정책 개체를 찾아 편집합니다.

   

   위의 스크린샷에 표시된 것처럼 컴퓨터 구성 노드 아래에는 정책 노드 및 관리 템플릿 노드가 있습니다.

2단계: Microsoft Edge 관리 템플릿 설치

도메인 컨트롤러에 정책 관리 템플릿 을 시작할 수 있지만 이 브라우저를 통해 이중 홉 제한 위임을 사용하도록 설정하기 위한 정책에 액세스할 수 있도록 Microsoft Edge 정책 파일을 설치해야 합니다. Microsoft Edge 정책 파일을 설치하려면 다음 단계를 수행합니다.

1. 비즈니스용 Microsoft Edge 다운로드 사이트로 이동합니다.

2. 채널/버전 드롭다운에서 다운로드할 버전을 선택합니다. 안정적인 최신 버전을 사용하는 것이 좋습니다.

3. 빌드 드롭다운에서 원하는 빌드를 선택하고 마지막으로 플랫폼 드롭다운에서 대상 운영 체제를 선택합니다. 선택 사항이 만들어지면 단추와 링크가 두 개 더 나타납니다.

   

4. 정책 파일 가져오기를 클릭하고 사용권 계약에 동의하여 MicrosoftEdgePolicyTemplates.cab 파일을 다운로드합니다. 이 파일에는 Microsoft Edge에 대한 정책 정의 파일이 포함되어 있습니다.

5. 파일을 두 번 클릭하여 콘텐츠를 탐색합니다(같은 이름의 zip 보관 파일).

6. zip 보관 파일의 콘텐츠를 로컬 디스크의 폴더에 추출합니다. 추출된 콘텐츠에는 Admx라는 하위 폴더를 찾을 수 있는 Windows라는 폴더가 포함됩니다. 여기에는 관리 템플릿과 지역화된 버전이 포함됩니다(영어 이외의 언어로 필요).

   

7. 이전의 관리 템플릿이 전송된 Sysvol 디렉터리 아래의 동일한 폴더 내에 .admx 파일을 전송합니다(위 예제에서는 C:\Windows\SYSVOL\sysvol\odessy.local\Policies\PolicyDefinitions).

8. Active Directory 그룹 정책 편집기를 열고 편집할 기존 그룹 정책 개체를 선택하여 새로 전송된 Microsoft Edge 템플릿의 존재를 확인합니다. 이러한 폴더는 트리 보기의 관리 템플릿 폴더 아래에 있는 Microsoft Edge라는 폴더에 있습니다.

   

3단계: 새 그룹 정책 개체 만들기

Active Directory 그룹 정책 관리자 MMC 스냅인을 사용하여 새 그룹 정책 개체를 만드는 방법은 다음과 같습니다.

1. Windows+R 키를 눌러 도메인 컨트롤러에서 실행 메뉴를 엽니다.
2. Gpmc.msc를 입력하여 Microsoft 관리 콘솔을 열고 Active Directory 그룹 정책 관리자 스냅인을 로드합니다.
3. 콘솔의 트리 뷰에서 그룹 정책 개체 노드를 찾고 노드를 마우스 오른쪽 단추로 클릭하여 상황에 맞는 메뉴를 엽니다.
4. 새 메뉴 항목을 선택하고 만들려는 그룹 정책의 이름을 입력한 다음 확인을 클릭합니다.

4단계: 서버에 인증할 때 제약이 없는 위임을 허용하도록 그룹 정책 구성 편집

마지막 단계는 Windows 통합 사용 웹 사이트에 Kerberos를 사용하여 인증을 수행할 때 Microsoft Edge 브라우저가 API 호출에 플래그 InitializeSecurityContext 를 전달할 ok_as_delegate 수 있도록 하는 정책을 사용하도록 설정하는 것입니다. Microsoft Edge 브라우저가 NTLM이 아닌 Kerberos를 사용하여 인증하는지 여부를 모르는 경우 Internet Explorer의 Kerberos 오류 문제를 참조하세요.

Active Directory 그룹 정책 편집기에서 최종 사용자가 Kerberos 인증을 통해 인증하고 제한되지 않은 위임을 통해 해당 자격 증명을 백 엔드 서비스에 위임하도록 허용하려는 Active Directory 내의 컴퓨터에 적용할 그룹 정책 개체를 선택합니다. Microsoft Edge에서 제한되지 않은 위임을 사용하도록 설정하는 정책은 아래와 같이 Microsoft Edge 템플릿의 Http 인증 폴더 아래에 있습니다.

이 설정을 사용하여 Kerberos 티켓 위임이 허용되는 서버 목록을 구성합니다.

새로 편집하는 그룹 정책 개체가 도메인 내의 클라이언트 컴퓨터에 적용된 후 Windows 통합 인증 문제 해결을 위한 진단 페이지의 테스트 인증 페이지로 이동하여 GitHub의 ASP.net 샘플 리포지토리에서 whoami.aspx 페이지를 다운로드합니다. 이제 자격 증명 위임이 허용되었음을 알리는 가장 대신 대리자의 ImpersonationLevel 설정을 생성합니다.

정책이 클라이언트 워크스테이션에 올바르게 적용되었는지 테스트하려면 새 Microsoft Edge 탭을 열고 edge://policy 입력합니다.

정책은 AuthNegotiateDelegateAllowlist Microsoft Edge에서 Kerberos 티켓 위임을 수행할 수 있는 서버 이름의 값을 나타내도록 설정해야 합니다. 목록에 정책이 표시되지 않으면 정책이 배포되지 않았거나 잘못된 컴퓨터에 배포되었습니다.

5단계(선택 사항): Microsoft Edge에서 올바른 위임 플래그를 사용하고 있는지 확인

다음은 문제 해결/선택적 확인 단계입니다.

정책이 구성되고 배포되면 다음 단계를 수행하여 Microsoft Edge가 올바른 위임 플래그를 전달하고 있는지 확인해야 합니다 IntializeSecurityContext. 이 단계에서는 Microsoft Edge에 이미 기본 제공되거나 온라인 서비스 사용할 수 있는 도구를 사용합니다.

1. Microsoft Edge에서 사용할 수 있는 로깅 기능을 사용하여 웹 사이트를 요청할 때 브라우저가 수행하는 작업을 기록합니다. 로깅을 사용하도록 설정하려면 다음을 수행합니다.

   1. 새 Microsoft Edge 창을 열고 edge://net-export/ 입력합니다.

   2. 추적할 때 쿠키 및 자격 증명 포함 옵션을 사용합니다. 이 옵션이 없으면 인증 추적 수준 데이터가 생략됩니다.

      

   3. 디스크에 로깅 시작 단추를 클릭하고 추적을 저장할 파일 이름을 제공합니다.

   4. 다른 Microsoft Edge 탭을 열고 Microsoft Edge를 사용하여 통합 Windows 인증 수행하려는 웹 사이트로 이동합니다.

   5. 인증을 시도했으면 추적이 설정된 이전 탭으로 돌아가서 로깅 중지 단추를 클릭합니다. 추적 인터페이스는 추적이 포함된 파일이 기록된 위치를 나타냅니다.

2. 추적이 포함된 JSON 파일을 사용하여 인증을 시도할 때 브라우저가 함수에 InitializeSecurityContext 전달한 매개 변수를 확인합니다. 추적을 분석하려면 netlog_viewer 사용합니다.

3. 구문 분석된 추적 내부에는 다음과 유사한 이벤트 로그가 있습니다.

   t=3076 [st=12]       +AUTH_LIBRARY_INIT_SEC_CTX  [dt=3]
                         --> flags = {"delegated":false,"mutual":false,"value":"0x00000000"}
                         --> spn = "HTTP/web-server.odessy.local"
   

   이 로그는 다음을 보여줍니다.

   • AUTH_LIBRARY_INIT_SEC_CTX 은 브라우저가 함수를 호출하는 것을 의미합니다 InitializeSecurityContext .
   • "delegated":false 는 티켓이 로 표시된 delegatable경우에도 티켓을 위임해서는 안 됨을 의미합니다.
   • "mutual":false 는 클라이언트(브라우저)에서 서버가 클라이언트에 인증하고 해당 ID를 증명할 필요가 없다는 것을 의미합니다. 클라이언트만 해당 ID를 증명하기 위해 서버에 인증해야 합니다.
   • HTTP/web-server.odessy.local 는 인증을 호출할 때 브라우저에서 사용하는 SPN입니다.

자세한 정보

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