NGINX Plus를 통한 Microsoft Active Directory Federation Services 고가용성 구현

Armand Sultantono

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

실제로 AD FS를 사용하면 페더레이션에 속한 회사의 직원은 로컬 환경에만 로그인하면 됩니다. 직원이 신뢰할 수 있는 비즈니스 파트너의 웹 애플리케이션에 액세스하면 로컬 AD FS 서버가 직원의 ID 정보를 보안 토큰 형태로 파트너의 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 서버로 장애 조치를 수행할 수 있습니다.

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

AD FS의 표준 HA 토폴로지

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

그러나 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 워커 프로세스가 업스트림 그룹의 서버에 대한 구성 및 런타임 상태 정보에 액세스할 수 있도록 합니다.
• hash는 소스 IP 주소(클라이언트의 IP 주소)를 기반으로 클라이언트와 AD FS 서버 간의 세션 지속성을 설정합니다. 클라이언트가 AD FS 서버와 단일 TCP 연결을 설정하더라도 이 설정이 필요합니다. 특정 조건에서는 세션 지속성을 사용하도록 설정하지 않으면 일부 애플리케이션에서 로그인 리디렉션이 여러 번 발생할 수 있기 때문입니다.
• status_zone은 NGINX Plus API가 이 서버의 메트릭을 수집한다는 의미이며, 수집된 메트릭은 기본 제공되는 실시간 활동 모니터링 대시보드에 표시할 수 있습니다(API와 대시보드는 별도로 구성).

stream {    upstream adfs_ssl {
        zone adfs_ssl 64k;
        server 10.11.0.5:443; # AD FS server 1
        server 10.11.0.6:443; # AD FS server 2
        hash $remote_addr;
    }

    server {
        status_zone adfs_ssl;
        listen 10.0.5.15:443;
        proxy_pass adfs_ssl;
    }
}

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

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

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

이제 외부 클라이언트에서 WAP 서버로 들어오는 HTTPS 연결의 부하를 분산하도록 NGINX Plus를 구성합니다. 모범 사례에 따르면 트래픽이 AD FS 서버에 도달할 때까지 SSL로 암호화된 상태를 유지해야 하므로, NGINX Plus가 HTTPS 트래픽을 WAP 서버로 전달하도록 구성할 때 SSL 패스스루 또는 SSL 재암호화의 두 가지 방식 중 하나를 사용합니다.

SSL 패스스루 구성

더 간단한 구성 방법은 NGINX Plus가 SSL로 암호화된 TCP 트래픽을 변경하지 않고 WAP 서버로 전달하도록 하는 것입니다. 이를 위해 stream 컨텍스트에서 앞서 AD FS 서버의 부하 분산을 위해 구성한 가상 서버와 유사한 가상 서버를 구성합니다.

여기서 NGINX Plus는 별도의 고유 IP 주소인 10.0.5.100에서 외부 트래픽을 수신합니다. 프로덕션 환경에서는 게시된 애플리케이션의 외부 FQDN이 퍼블릭 영역의 DNS 호스트 A 레코드 형식으로 이 주소를 가리켜야 합니다. 테스트할 때는 클라이언트 시스템의 hosts 파일에 항목을 추가하는 것으로 충분합니다.

참고: 이 서버와 동일한 IP 주소에서 수신 대기하도록 stream 컨텍스트에 HTTPS 서비스를 추가로 구성하려면, ssl_preread 지시문과 map을 사용하여 서버 이름 표시(SNI)를 활성화해야 트래픽을 서로 다른 업스트림으로 올바르게 라우팅할 수 있습니다. 이 내용은 이 블로그의 범위를 벗어나지만, NGINX 참조 문서에서 예제를 확인할 수 있습니다.

stream {    upstream wap {
        zone wap 64k;
        server 10.11.0.5:443; #WAP server 1
        server 10.11.0.6:443; #WAP server 2
        least_time connect;
    }
  
    server {
        status_zone wap_adfs;
        listen 10.0.5.100:443;
        proxy_pass wap;
    }
}

HTTPS 재암호화 구성

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

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

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

WAP 서버에 관련 정보를 전달하고 로그에도 기록할 수 있도록 proxy_set_header 지시어를 사용합니다:

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

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

http {    upstream wap {
        zone wap 64k;
        server 10.0.5.11:443;
        server 10.0.5.10:443;
        least_time header;
    }

    server {
        listen 10.0.5.100:443 ssl;
        status_zone fs.example.com;
        server_name fs.example.com;
        ssl_certificate     	/etc/ssl/example.com/example.com.crt;
        ssl_certificate_key 	/etc/ssl/example.com/example.com.key;

        location / {
            proxy_pass https://wap; # 'https' enables reencrypt 
            proxy_ssl_server_name on;
            proxy_ssl_name $host;
            proxy_set_header Host $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 $server_name;
        }
    }
}

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 서버로 직접 부하 분산합니다.

upstream adfs {    zone adfs 64k;
    server 192.168.5.5:443; # AD FS Server 1
    server 192.168.5.6:443; # AD FS Server 2
    least_time header;
 }

server {
    listen 10.0.5.110:443 ssl;
    status_zone adfs_proxy;
    server_name fs.example.com;
    ssl_certificate         /etc/ssl/example.com/example.com.crt;
    ssl_certificate_key     /etc/ssl/example.com/example.com.key;
  
    location / {
        proxy_pass https://adfs;
        proxy_ssl_server_name on;
        proxy_ssl_name $host;
        proxy_set_header Host $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 $server_name;
    }
 }

AD FS 배포 환경에서 NGINX Plus를 사용해 보세요. 지금 30일 무료 평가판을 시작하거나 문의하여 사용 사례에 대해 상담해 보세요.

작성자 소개

Armand Sultantono

Armand Sultantono의 다른 블로그 게시물