NGINX Plus를 사용한 Microsoft Active Directory Federation Services의 고가용성

Microsoft Active Directory Federation Services (AD FS)를 사용하면 Windows Server에서 애플리케이션을 호스팅하는 조직이 엑스트라넷을 통해 신뢰할 수 있는 비즈니스 파트너의 직원에게 SSO(Single Sign‑On) 액세스를 확장할 수 있습니다. 비즈니스 파트너 간의 신원 정보 공유를 연합 이라고 합니다.

실제로 AD FS를 사용하면 연합에 속한 회사의 직원은 로컬 환경에만 로그인하면 됩니다. 신뢰할 수 있는 비즈니스 파트너의 웹 애플리케이션에 액세스하면 로컬 AD FS 서버는 보안 토큰 형태로 파트너의 AD FS 서버로 식별 정보를 전달합니다. 토큰은 여러 개의 클레임 으로 구성되며, 클레임은 로컬 Active Directory에 저장된 직원의 개별 속성(사용자 이름, 비즈니스 역할, 직원 ID 등)입니다. 파트너의 AD FS 서버는 토큰의 클레임을 파트너의 애플리케이션에서 이해하는 클레임에 매핑한 다음, 직원에게 요청된 종류의 액세스에 대한 권한이 있는지 확인합니다.

AD FS 2.0 이상에서는 고가용성 (HA)을 활성화하여 애플리케이션의 인증 서비스에 복원력과 확장성을 추가할 수 있습니다. AD FS HA 클러스터(AD FS 팜 이라고도 함)에서는 여러 AD FS 서버가 단일 데이터 센터 내에 배포되거나 여러 데이터 센터에 분산됩니다. 모든 활성 HA를 위해 구성된 클러스터에는 AD FS 서버 전체에 트래픽을 균등하게 분산하는 부하 분산 장치가 필요합니다. 활성-수동 HA 배포에서 로드 밸런서는 기본 서버에 장애가 발생하면 백업 AD FS 서버로 장애 조치를 제공할 수 있습니다.

이 게시물에서는 각각 AD FS 3.0 및 AD FS 4.0 Server 2012 R2와 Windows Server 2016을 실행하는 환경에서 HA를 제공하도록 NGINX Plus를 구성하는 방법을 설명합니다.

AD FS를 위한 표준 HA 토폴로지

이 게시물에서는 설명을 위해 표준 AD FS 팜 토폴로지를 사용합니다. 이는 권장사항이 아니며 모든 가능한 배포 시나리오를 포괄하는 것은 아닙니다. 온-프레미스 배포의 경우 표준 팜은 회사 인트라넷에 있는 하나 이상의 AD FS 서버와 DMZ 네트워크에 있는 하나 이상의 WAP( 웹 애플리케이션 프록시 ) 서버로 구성됩니다. WAP 서버는 외부 사용자가 회사 인트라넷에 호스팅된 웹 애플리케이션에 액세스할 수 있도록 하는 역방향 프록시 역할을 합니다.

그러나 WAP에는 서버 클러스터를 구성하거나 HA를 지원하는 기본 제공 방식이 없으므로 WAP 서버 앞에 로드 밸런서를 배포해야 합니다. AD FS에 대한 HA를 활성화하기 위해 DMZ와 인트라넷 사이의 경계에 부하 분산 장치도 배치됩니다. 표준 AD FS 팜에서는 Windows Server 2012 및 2016의 NLB( 네트워크 부하 분산 ) 기능이 부하 분산 장치 역할을 합니다. 마지막으로, 방화벽은 일반적으로 로드 밸런서의 외부 IP 주소 앞과 네트워크 영역 사이에 구현됩니다.

표준 HA 토폴로지에서 NGINX Plus 사용

앞서 언급했듯이 NLB는 AD FS 팜에 대한 부하 분산을 수행할 수 있습니다. 하지만 기능 세트는 매우 기본적입니다(기본적인 상태 점검과 제한적인 모니터링 기능만 제공). NGINX Plus는 프로덕션 AD FS 환경에서 HA에 필수적인 많은 기능을 갖추고 있으면서도 가볍습니다.

여기에 설명된 표준 토폴로지를 배포하면 NGINX Plus가 NLB를 대체하여 모든 WAP 및 AD FS 팜의 트래픽 부하를 분산합니다. 그러나 올바른 AD FS 작업을 위해서는 WAP 서버에서 실제 SSL 인증서를 확인해야 하므로 NGINX Plus에서 AD FS 서버에 대한 SSL 연결을 종료하지 않도록 주의하세요(자세한 내용은 Microsoft TechNet 문서 참조).

프로덕션 환경에서는 NGINX Plus 자체에 대한 HA도 구현하는 것이 좋지만, 여기서는 표시하지 마세요. 자세한 지침은 NGINX Plus 관리자 가이드의 온프레미스 배포에서 NGINX Plus에 대한 고가용성 지원을 참조하세요.

AD FS 서버 부하 분산을 위한 NGINX Plus 구성

AD FS 서버의 부하 분산을 위한 NGINX Plus 구성은 간단합니다. 바로 위에서 언급했듯이 AD FS 서버는 WAP 서버에서 실제 SSL 인증서를 확인해야 하므로 DMZ 인트라넷 경계에서 NGINX Plus 인스턴스를 구성하여 SSL 암호화 트래픽을 종료하거나 다른 방식으로 처리하지 않고도 AD FS 서버로 전달하도록 합니다.

필수 지침 외에도 구성에 다음 지침을 포함합니다.

• zone은 NGINX Plus 작업자 프로세스 모두가 업스트림 그룹의 서버에 대한 구성 및 런타임 상태 정보에 액세스할 수 있는 공유 메모리의 영역을 할당합니다.
• 해시는 소스 IP 주소(클라이언트의 IP 주소)를 기반으로 클라이언트와 AD FS 서버 간의 세션 지속성을 설정합니다. 클라이언트가 AD FS 서버와 단일 TCP 연결을 설정하는 경우에도 이 기능이 필요한데, 특정 조건에서는 세션 지속성이 활성화되어 있지 않으면 일부 애플리케이션이 여러 번 로그인 리디렉션될 수 있기 때문입니다.
• status_zone 은 NGINX Plus API가 이 서버에 대한 메트릭을 수집한다는 것을 의미하며, 이는 내장된 라이브 활동 모니터링 대시보드에 표시될 수 있습니다( API와 대시보드는 별도로 구성됨 ).

스트림 { 업스트림 adfs_ssl { 영역 adfs_ssl 64k ; 서버 10.11.0.5:443; # AD FS 서버 1 서버 10.11.0.6:443; # AD FS 서버 2 해시 $remote_addr ; } 서버 { 상태 영역 adfs_ssl ; 수신 10.0.5.15:443; 프록시 패스 adfs_ssl; } }

　
WAP 서버에서 NGINX Plus를 거쳐 AD FS 서버로 트래픽이 흐르게 하려면 페더레이션 서비스 이름(예시에서는 fs.example.com )을 NGINX Plus가 수신 대기하는 IP 주소에 매핑해야 합니다. 프로덕션 배포의 경우 DMZ에 DNS 호스트 A 레코드를 추가합니다. 테스트 배포의 경우 각 WAP 서버의 호스트 파일에 항목을 만드는 것으로 충분합니다. 여기서는 fs.example.com을 호스트 파일에 10.0.5.15로 바인딩하는 작업을 수행합니다.

WAP 서버의 트래픽이 AD FS 서버에 도달하는지 테스트하기 위해 ipconfig /flushdns 명령을 실행하여 DNS를 플러시한 다음 브라우저에서 SSO 페이지 https://fs.example.com/adfs/ls/idpinitiatedsignon.htm 에서 AD FS에 로그인합니다.

WAP 서버 부하 분산을 위한 NGINX Plus 구성

이제 외부 클라이언트에서 WAP 서버로 HTTPS 연결을 부하 분산하도록 NGINX Plus를 구성합니다. 모범 사례에 따르면 트래픽은 AD FS 서버에 도달할 때에도 여전히 SSL 암호화되므로 NGINX Plus를 구성하여 HTTPS 트래픽을 WAP 서버로 전달하기 위해 두 가지 방법 중 하나를 사용합니다. SSL 패스스루 또는 SSL 재암호화.

SSL 패스스루 구성

더 쉬운 구성은 NGINX Plus가 SSL로 암호화된 TCP 트래픽을 변경하지 않고 WAP 서버로 전달하는 것입니다. 이를 위해 AD FS 서버의 부하를 분산하기 위해 이전 과 유사한 스트림 컨텍스트에서 가상 서버를 구성합니다.

여기서 NGINX Plus는 다른 고유 IP 주소인 10.0.5.100에서 외부 트래픽을 수신합니다. 프로덕션 환경의 경우, 게시된 애플리케이션의 외부 FQDN은 공개 영역의 DNS 호스트 A 레코드 형태로 이 주소를 가리켜야 합니다. 테스트를 위해서는 클라이언트 머신의 호스트 파일에 항목을 추가하면 됩니다.

메모: 이 서버와 동일한 IP 주소에서 수신하도록 스트림 컨텍스트에서 추가 HTTPS 서비스를 구성하려는 경우 맵 과 함께 ssl_preread 지시문을 사용하여 서버 이름 표시(SNI)를 활성화하여 트래픽을 다른 업스트림으로 올바르게 라우팅해야 합니다. 이는 이 블로그의 범위를 벗어나지만, NGINX 참조 문서에는 예제가 포함되어 있습니다.

stream { 업스트림 wap {
zone wap 64k;
서버 10.11.0.5:443; #WAP 서버 1
서버 10.11.0.6:443; #WAP 서버 2
least_time 연결;
}

서버 {
status_zone wap_adfs;
listen 10.0.5.100:443;
proxy_pass wap;
}
}

HTTPS 재암호화 구성

SSL 패스스루의 대안으로, HTTPS 트래픽을 허용하도록 http 컨텍스트에서 가상 서버를 구성하여 NGINX Plus의 모든 레이어 7 기능을 활용할 수 있습니다. NGINX Plus는 클라이언트의 HTTPS 연결을 종료하고 WAP 서버에 대한 새로운 HTTPS 연결을 생성합니다.

인증서 및 비밀 키 파일( example.com.crt 및 example.com.key )에는 일반 이름( CN ) 또는 주체 대체 이름( SAN ) 속성에 게시된 애플리케이션의 외부 FQDN이 포함되어 있습니다. 이 예에서 FQDN은 fs.example.com 입니다.

proxy_ssl_server_name 및 proxy_ssl_name 지시어는 필수 서버 이름 표시(SNI) 헤더를 활성화하여 SSL 클라이언트 Hello에서 전송할 원격 호스트 이름을 지정합니다. 헤더는 게시된 애플리케이션의 외부 FQDN(이 예에서는 fs.example.com ) 과 일치해야 합니다.

proxy_set_header 지시문을 사용하여 관련 정보를 WAP 서버로 전달하고 로그에서 캡처할 수도 있습니다.

• X-Real-IP 헤더에는 $remote_addr 변수에 캡처된 소스(클라이언트) IP 주소가 포함되어 있습니다.
• X-Forwarded-For는 클라이언트 요청의 헤더에 클라이언트의 IP 주소를 첨부하여 전달합니다(클라이언트 요청에 헤더가 없으면 해당 주소만 첨부).
• x-ms-proxy 헤더는 사용자가 프록시 서버를 통해 라우팅되었음을 나타내며, NGINX Plus 인스턴스를 해당 서버로 식별합니다.

여기에 표시된 지침 외에도 NGINX와 NGINX Plus는 SSL/TLS의 성능과 보안을 향상할 수 있는 다양한 기능을 제공합니다. 자세한 내용은 블로그를 참조하세요.

http { 업스트림 wap { 영역 wap 64k; 서버 10.0.5.11:443; 서버 10.0.5.10:443; 최소_시간 헤더; } 서버 { 수신 10.0.5.100:443 ssl; 상태_영역 fs.example.com; 서버_이름 fs.example.com; ssl_certificate /etc/ssl/example.com/example.com.crt; ssl_certificate_key /etc/ssl/example.com/example.com.key; 위치 / { proxy_pass https://wap; # 'https'는 재암호화를 활성화합니다 proxy_ssl_server_name on ; proxy_ssl_name $host ; proxy_set_header 호스트 $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header x-ms-proxy $서버 이름; } } }

WAP 서버가 없는 토폴로지에서 NGINX Plus 구성

외부 클라이언트가 AD FS 서버에 액세스할 수 있도록 설정할 때 DMZ와 회사 인트라넷의 경계에서 외부 트래픽을 종료하고 x-ms-proxy 헤더를 삽입하여 외부 인증 시도를 식별하는 것이 가장 좋습니다. WAP 서버는 이 두 가지 기능을 모두 수행하지만, 이전 섹션에서 구성한 대로 NGINX Plus도 이 기능을 수행합니다.

일부 사용 사례에서는 WAP 서버가 필요하지 않습니다. 예를 들어 IP 네트워크 및 신뢰 수준과 같은 고급 클레임 규칙을 사용하지 않는 경우가 있습니다. 이러한 경우 WAP 서버를 제거하고 DMZ와 인트라넷의 경계에 NGINX Plus를 배치하여 내부 AD FS 서버에 대한 요청을 인증할 수 있습니다. 이를 통해 하드웨어, 소프트웨어 및 운영 비용이 절감됩니다.

이 구성은 표준 HA 토폴로지 에 대한 구성을 대체합니다. 이는 WAP 서버의 부하 분산을 위한 HTTPS 재암호화 구성 과 거의 동일하지만, 여기서 NGINX Plus는 외부 요청을 내부 네트워크의 AD FS 서버로 직접 부하 분산합니다.

업스트림 adfs { 영역 adfs 64k;
서버 192.168.5.5:443; # AD FS 서버 1
서버 192.168.5.6:443; # AD FS 서버 2
least_time 헤더;
}

서버 {
listen 10.0.5.110:443 ssl;
status_zone adfs_proxy;
서버 이름 fs.example.com;
ssl_certificate /etc/ssl/example.com/example.com.crt;
ssl_certificate_key /etc/ssl/example.com/example.com.key;

위치 / {
proxy_pass https://adfs;
proxy_ssl_server_name 켜짐;
proxy_ssl_name $host;
proxy_set_header 호스트 $host;
proxy_set_header X-실제-IP $remote_addr;
proxy_set_header X-전달-대상 $proxy_add_x_전달대상;
proxy_set_header x-ms-프록시 $server_name;
}
}

AD FS 배포에서 NGINX Plus를 사용해보세요. 오늘 무료 30일 평가판을 시작하거나 저희에게 연락하여 사용 사례에 대해 논의해보세요.