통합 Windows 인증 정보
통합 Windows 인증(Integrated Windows Authentication)은 IIS와 사용자가 동일한 Active Directory 도메인에 속한 경우 자동으로 사용자의 자격 증명을 IIS에 제공하는 메커니즘입니다. ASP.NET의 C#에서 사이트를 만들면 사용자 인증된 판정 및 인증된 사용자 정보를 얻을 수 있습니다.
이를 통해 사용자는 추가 로그인 작업 없이 IIS에서 호스팅(또는 연동)하는 웹 응용 프로그램에 액세스할 수 있으며 다른 응용 프로그램 서버와 SSO 연동을 수행할 수 있습니다.
그런데 웹 서버(IIS)를 로드 밸런서 아래에 두고 통신을 SSL/TLS로 암호화한 환경에서는 이 Windows 인증이 제대로 작동하지 않는 경우가 있습니다.왜?
포인트는 Windows 인증 메커니즘 그리고 로드 밸런서 동작 에 있습니다.
NTLM은 각 클라이언트와 서버 간에 단일 TCP 연결에서 챌린지/응답을 수행하는 인증 방법입니다. 한편, Kerberos의 경우도, 클라이언트는 서비스 식별자 (SPN)에 근거해 티켓을 취득해, IIS에 송신합니다. 이러한 자격 증명은 HTTP 헤더(Authorization: Negotiate ... 등)에 올려져 교환됩니다. 그러나 레이어 7 로드 밸런서는 클라이언트의 HTTPS 연결을 자체 장치에서 종단하여 내용을 구문 분석하고 새 요청으로 백엔드 IIS로 전달합니다. 이 과정에서클라이언트와 IIS 간의 종단 간 TLS 세션 연결이 끊어짐또한 NTLM과 같은 연결 유지 형 자격 증명이 인계되지 않기 때문에 인증 처리가 실패합니다.
이상의 배경을 바탕으로 본 기사에서는 "로드 밸런서 + SSL 환경에서 IIS의 통합 Windows 인증을 성공적으로 구성 를 고려합니다. 전형적인 구성 패턴을 3개 들 수 있으며, 각각에 대해 Windows 인증의 대응 여부, 그 기술적 이유, 한층 더 구성상의 메리트·데메리트를 해설합니다.
각 구성안의 기술적 검증
①：L7 로드 밸런서 SSL 종단+IIS(80 or 443)로 전송
클라이언트 ──HTTPS──▶ L7 로드 밸런서(SSL 종단) ──HTTP(S)──▶ IIS(80 or 443)
대응 여부
Windows 인증은 이 구성에서대응 불가입니다.
이유
클라이언트와 IIS 간의 TLS 세션이 로드 밸런서에서 한 번 끝나기 때문에,엔드 투 엔드 자격 증명 인수가 불가능합니다.부터입니다. L7 로드 밸런서는 받은 HTTPS를 해독하고 클라이언트 대신 IIS에 액세스합니다. 이 때 원래 클라이언트에서 IIS로 보내야합니다. Authorization: Negotiate 헤더(Kerberos 티켓 및 NTLM 토큰을 포함하는 인증 헤더)가 올바르게 IIS까지 도착하지 않습니다. 특히 NTLM에서는 초기 요청에 IIS가 보내는 인증 챌린지 응답 (WWW-Authenticate)를 기반으로 클라이언트가 다시 요청을 보냅니다. LB를 통해동일한 TCP 세션이 유지되지 않음때문에 NTLM 핸드 셰이크가 성립하지 않습니다.
실제로 AWS 환경에서도 Application Load Balancer(ALB)나 HTTP 리스너에서는 Windows 인증이 작동하지 않고 Network Load Balancer(NLB) 등 TCP 레벨의 LB가 필요하다고 합니다.참고]. 또한 Azure Application Gateway v2는 통합 인증이 포함된 HTTP 헤더를 백엔드에 투명하게 지원하지 않습니다.참고].
이와 같이 각 클라우드 벤더의 매니지드 LB에서 공식적으로 지원되지 않는 점에서도 L7 레벨에서 Windows 인증을 유지하는 것이 어려움을 알 수 있습니다.
②: L4 로드 밸런서(TLS 패스 스루) + IIS 전송
클라이언트 ──HTTPS──▶ L4 로드 밸런서(TLS 패스스루) ── HTTPS──▶ IIS(443)
대응 여부
이 구성은 Windows 인증에대응 가능입니다.
이유
L4 로드 밸런서(OSI 계층 4에서 동작하는 LB)는 패킷을 TCP 레벨에서 중계하므로,클라이언트와 IIS 간의 TLS 세션 엔드 투 엔드 유지됩니다. 로드 밸런서는 암호화를 종단하지 않고, TCP 커넥션 자체를 각 서버에 배분할 뿐이므로, NTLM 인증이 요구하는 「동일 TCP 접속상에서의 교환」도 유지됩니다. Kerberos에 대해서도, 클라이언트로부터 보면 IIS(서비스)의 FQDN에 직접 접속하고 있는 것과 같은 상태를 재현할 수 있으므로, 적절하게 SPN 설정만 해 두면 티켓 베이스의 인증이 그대로 통과합니다. AWS NLB와 클래식 LB의 TCP 리스너 모드, Azure의 내부 로드 밸런서, F5의 L4 모드 등은 이 카테고리에 속하며(그 외 HAProxy의 TCP 모드, nginx stream 등이 해당) Windows 통합 인증을 투명하게 할 수 있습니다.
장점
TLS 세션이 클라이언트에서 서버까지 중단되지 않기 때문에,Windows 인증 프로토콜이 본래의 동작을 유지수 있습니다. NTLM의 3웨이 핸드셰이크도 단일 연결 내에서 완료되며 Kerberos 티켓도 백엔드 서버에서 올바르게 수신합니다. 또한 LB는 L4 동작으로 인해 오버헤드가 작고 높은 처리량을 기대할 수 있습니다.
단점
경로 기반이나 호스트 이름 기반의 섬세한 라우팅이 불가능한 점은 L4 로드 밸런서 구성에서 가장 큰 과제입니다. 예를 들어 URL 경로(예:/api,,,/chat)마다 다른 백엔드 서버로 나누는 것은 L7(HTTP)에서만 실현할 수 있는 기능이며 L4(TCP)에서는 불가능합니다.
따라서 시스템 요구 사항에 따라 여러 FQDN을 준비하고 각 용도마다 다른 가상 서버(웹 서버, Windows 인증용 서버 등)를 로드 밸런서에 할당해야 하며 구성의 난이도가 높아지는 단점이 있습니다.
또한 Windows 인증에 필요한 다음 설정은 모두 로드 밸런서의 FQDN을 설정한다는 점도 주의가 필요합니다.
- Windows 인증에 필요한 인터넷 옵션 보안 탭로컬 인트라넷의 사이트 설정
- Windows 인증 페이지에 FQDN (정규화 된 도메인 이름)으로 액세스하는 경우 SPN 등록
- IIS 사이트 바인딩 설정 및 SSL 인증서(로드 밸런서 자체에 인증서 설치 필요 없음)
※ 로드 밸런서의 FQDN이 lb.example.com인 경우 Kerberos가 성공할 때까지의 흐름
[Client]
| 1. DNS解決: lb.example.com → LB
|
| 2. Kerberos: SPN = HTTP/lb.example.com
| → ドメインコントローラーにTGSを要求
|
| 3. TLSハンドシェイク: SNI = lb.example.com
| → IISで一致する証明書必要
|
| 4. リクエスト送信: Hostヘッダ = lb.example.com
[IIS]
→ SPN受け入れOK、証明書OK、認証成功③：L7 로드 밸런서 SSL 종단+IIS로 리디렉션 구성
클라이언트 ──HTTPS──▶ L7 로드 밸런서(SSL 종단)
LB ──HTTP 302(리디렉션 응답)→ 클라이언트
클라이언트 - HTTPS - IIS (443에 직접 액세스)
대응 여부
이 구성은 Windows 인증에대응 가능입니다.
이유
아이디어로서는 「로드 밸런서에서는 실제의 통신을 중계하지 않고, 한 번 리디렉션(HTTP 302 응답)으로 클라이언트를 백엔드의 IIS 직통으로 유도하는」방법입니다. 처음에는 사용자가 LB URL에 액세스하지만 L7 로드 밸런서는 SSL을 종료하면서 내용을 구문 분석하고 적절한 IIS 주소(예: 각 IIS가 가진 개별 호스트 이름 또는 IP 주소)에 HTTPS로 연결하도록 Location 헤더가 있는 302 응답을 반환합니다. 클라이언트 브라우저는 이 리디렉션을 받고 자동으로 지정된 IIS에 직접 HTTPS로 다시 요청을 보냅니다.
결과,두 번째 요청에서는 클라이언트와 IIS가 직접 TLS로 연결됩니다.따라서 Kerberos / NTLM 자격 증명도 그대로 엔드 투 엔드로 교환됩니다. 로드 밸런서는 인증 처리 중에는 개입하지 않으므로, 구성안 ①과 같은 인증 헤더 소실 문제를 회피할 수 있습니다.
장점
TLS가 클라이언트에서 IIS까지 직접 연결되므로 Windows 인증이 쉽게 성공할 수 있다는 점이 큰 이점입니다.
IIS 단독으로 인증이 성공하고 있으면, 그 구성을 그대로 살릴 수 있기 때문에, 로드 밸런서를 중계했다고 해도 난이도가 오르는 일은 없습니다.
또한 리디렉션을 활용하여 로드 밸런서측 어느 정도 유연한 라우팅 제어가 가능합니다. 예를 들어, 첫 번째 액세스 URL 경로와 호스트 이름에 따라 다른 백엔드 IIS URL로 리디렉션하면 경로 기반 할당에 가깝습니다. LB 부하에 다수의 서비스가 있는 경우, 일단 공통의 엔트리 포인트로서 LB에 집약해, 거기로부터 각 서비스의 실 URL에 유도하는 것으로 표면적으로는 하나로 보이는, 같은 구성도 가능합니다.
단점
LB 뒤에 IIS를 배포할 수 없고, 공개 서버로서 IIS용으로 다른 엔드포인트 설계, 및 LB와는 다른 증명서의 배치가 필요하게 되는 점은 단점입니다.
또한 처음 액세스할 때 리디렉션이 발생하는 점도 단점이지만 실제로는 HTTP 302 응답을 통한 즉각적인 재연결이 이루어질 뿐이며 사용자 체감적인 영향은 거의 무시할 수 있는 수준입니다.
IIS로 리디렉션 후 Windows 인증을 거쳐 당사 서비스에 로그인할 때까지의 속도의 참고는, 이쪽의동영상를 참고하세요.
각 구성의 비교표
| 구성 | 개요 | Windows 인증 | 비고 |
|---|---|---|---|
| ① | L7 LB(SSL 종단) → IIS | ❌ 불가 | ・TLS 분단, NTLM/Kerberos 비투과 |
| ② | L4 LB (TLS 패스 스루) → IIS | ✅ 가능 | · 경로 기반 라우팅 불가, 여러 FQDN으로 가상 서버를 LB로 설정하여 라우팅 ・IIS측에 증명서 설정(LB에 증명서 불필요) · IIS 443 포트는 LB에서 인바운드 연결만 허용 · 전체적으로 공식 문서가 적고 난이도 높음 |
| ③ | L7 LB (SSL 종단) → IIS로 리디렉션 | ✅ 가능 | · 경로 기반 라우팅 가능 ・IIS측 및 로드 밸런서에 증명서가 필요 ・IIS 443 포트는 ANY로 인바운드 접속을 허가 ・IIS 단체로 테스트를 할 수 있기 때문에 난이도 저 |
요약
Windows 인증(NTLM/Kerberos)이 제대로 작동하려면 TLS 세션이 클라이언트에서 IIS까지 일관되게 유지되는 것이 절대 조건입니다.
안②의 L4 로드 밸런서 구성은, TLS가 중계되지 않고, IIS까지 스트레이트에 도착하기 때문에 인증이 통과합니다. 그러나 경로 기반의 미세한 라우팅이 불가능하며 로드 밸런서 내에 여러 가상 서버를 구성해야 하는 점은 구성 난이도가 높습니다.
한편, 안③의 리다이렉트 구성은, 최초 회만 L7 로드 밸런서로 처리해, 그 후에는 IIS에 직결하는 형태를 취하기 때문에, TLS와 인증의 관점에서는 이상적인 흐름이 됩니다. 특정 경로에 대해 IIS의 FQDN으로 리디렉션하면 L7에서 규칙 제어와 Windows 인증의 양립을 도모할 수 있습니다. LB 뒤에 없는 IIS가 443 포트를 ANY에서 허용한다는 점은 정책적으로 문제가 없는지 확인이 필요합니다.
반대로 안①과 같이, L7 로드 밸런서가 TLS 종단 또는 HTTP 해석을 사이에 두는 구성에서는, 인증 정보가 단절되기 때문에, Windows 인증은 성립하지 않습니다.
견고한 인증 시스템을 유지하면서, 부하 분산과 암호화 통신을 양립시키는 구성의 검토에, 이 기사가 도움이 되면 다행입니다.