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

AD FS 2.0 이상에서는 고가용성(HA)을 활성화하여 애플리케이션 인증 서비스에 복원성과 확장성을 추가할 수 있습니다. 

AD FS 팜(HA 클러스터)에서는 여러 AD FS 서버가 단일 데이터 센터 내에 배치되거나 여러 데이터 센터에 분산 배포될 수 있습니다.

모든 활성-활성 HA 구성된 클러스터에는 AD FS 서버에 대한 트래픽을 균등하게 분배하기 위해 로드 밸런서가 필요합니다. 

반면, 활성-수동 HA 배포에서는 로드 밸런서가 기본 서버의 장애 발생 시 백업 AD FS 서버로의 장애 조치를 제공합니다.

이 게시물은 각각 AD FS 3.0 및 AD FS 4.0이 실행되는 환경(Windows Server 2012 R2 및 Windows Server 2016)에서

 NGINX Plus를 사용해 HA를 제공하도록 구성하는 방법을 설명합니다.

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

이 게시물은 예시 목적으로 표준 AD FS 팜 토폴로지를 사용하며, 이는 권장 사항이 아니며 모든 배포 시나리오를 다루지 않습니다.

온프레미스 배포의 경우, 표준 팜은 DMZ 네트워크에 배치된 하나 이상의 웹 애플리케이션 프록시(WAP) 서버와 

내부 회사 인트라넷의 하나 이상의 AD FS 서버로 구성됩니다. 

WAP 서버는 외부 사용자가 회사 인트라넷에서 호스팅되는 웹 애플리케이션에 액세스할 수 있도록 역방향 프록시 역할을 수행합니다.

하지만, WAP에는 HA를 지원하거나 서버 클러스터를 구성하는 기본 기능이 없으므로 WAP 서버 앞에 로드 밸런서를 배포해야 합니다. 

로드 밸런서는 또한 AD FS HA를 활성화하기 위해 DMZ와 인트라넷 경계에 배치됩니다. 

표준 AD FS 팜에서는 Windows Server 2012 및 2016의 네트워크 로드 밸런싱(NLB) 기능이 로드 밸런서 역할을 합니다. 

마지막으로, 방화벽은 로드 밸런서의 외부 IP 주소와 네트워크 영역 사이에 배치되어 보안을 강화합니다.

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

언급했듯이 NLB는 AD FS 팜의 트래픽 부하 분산을 수행할 수 있으나, 

기본적인 상태 검사와 제한된 모니터링 기능 등 매우 기본적인 기능만 제공합니다. 

반면, NGINX Plus는 가볍지만 HA를 위해 중요한 고급 기능을 제공하여 프로덕션 AD FS 환경에 적합합니다.

이 게시물의 표준 토폴로지 배포에서는 NGINX Plus가 NLB를 대체하여 WAP 및 AD FS 팜의 모든 트래픽을 로드 밸런싱합니다. 

그러나 AD FS 서버의 올바른 동작을 보장하기 위해 NGINX Plus는 AD FS 서버에 대한 SSL 연결을 종료하지 않습니다. 

이는 WAP 서버에서 실제 SSL 인증서를 확인해야 하기 때문입니다(자세한 내용은 Microsoft TechNet 문서 참조).

NGINX Plus 자체의 HA 구현은 권장되지만, 본 게시물에서는 다루지 않습니다. 

추가 정보는 NGINX Plus 관리자 가이드의 온프레미스 배포 관련 고가용성 지침을 참고하세요.

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

AD FS 서버 부하 분산을 위한 NGINX Plus 구성은 간단합니다. 

바로 위에서 언급했듯이 AD FS 서버는 WAP 서버의 실제 SSL 인증서를 확인해야 하므로 

DMZ 인트라넷 경계에서 NGINX Plus 인스턴스를 구성하여 SSL 암호화 트래픽을 종료하거나 

다른 방식으로 처리하지 않고 AD FS 서버로 전달합니다.

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

• zoneNGINX Plus 작업자 프로세스 모두가 업스트림 그룹의 서버에 대한 구성 및 런타임 상태 정보에 액세스할 수 있는 공유 메모리 영역을 할당합니다.
• hash클라이언트와 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.comA )을 NGINX Plus가 수신 대기하는 IP 주소에 매핑해야 합니다. 

프로덕션 배포의 경우 DMZ에 DNS 호스트 레코드를 추가합니다. 

테스트 배포의 경우 각 WAP 서버의 호스트 파일에 항목을 만드는 것으로 충분합니다. 

여기서는 fs.example.com을 호스트 파일 에서 10.0.5.15에 바인딩하는 작업을 합니다 .

WAP 서버의 트래픽이 AD FS 서버에 도달하는지 테스트하기 위해 

ipconfig /flushdnsDNS를 플러시하는 명령을 실행한 다음 

브라우저에서 SSO 페이지인 https://fs.example.com/adfs/ls/idpinitiatedsignon.htm 에서 AD FS에 로그인합니다 .

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

이제 NGINX Plus를 구성하여 외부 클라이언트에서 WAP 서버로 HTTPS 연결을 로드 밸런싱합니다. 

모범 사례에 따르면 트래픽은 AD FS 서버에 도달할 때에도 

SSL 암호화되므로 NGINX Plus를 구성하여 HTTPS 트래픽을 WAP 서버로 전달하기 위해 

SSL 패스스루 또는 SSL 재암호화라는 두 가지 방법 중 하나를 사용합니다.

SSL 패스스루 구성

더 쉬운 구성은 NGINX Plus가 SSL 암호화된 TCP 트래픽을 변경하지 않고 WAP 서버로 전달하는 것입니다. 

이를 위해 AD FS 서버의 부하 분산을 위해 이전stream 과 유사한 컨텍스트 에서 가상 서버를 구성합니다 .

여기서 NGINX Plus는 다른 고유한 IP 주소인 10.0.5.100에서 외부 트래픽을 수신합니다. 

프로덕션 환경의 경우 게시된 애플리케이션의 외부 FQDN은 퍼블릭 존의 DNS 호스트 레코드 형태로 이 주소를 가리켜야 합니다. 

테스트의 경우 클라이언트 머신의 호스트 파일 A에 있는 항목 으로 충분합니다.

참고:stream 이 서버와 동일한 IP 주소에서 수신 대기하도록 컨텍스트 에서 추가 HTTPS 서비스를 구성하려는 경우 , 

맵ssl_preread 이 있는 지시문을 사용하여 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 패스스루의 대안으로, HTTPS 트래픽을 허용하도록 컨텍스트에서 가상 서버를 구성하여 

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에 캡처된 소스(클라이언트) IP 주소가 포함되어 있습니다 $remote_addr.
• 클라이언트 요청의 헤더를 전달 X-Forwarded-For하는데, 헤더에 클라이언트의 IP 주소를 첨부합니다(클라이언트 요청에 헤더가 없으면 해당 주소만 첨부).
• 헤더 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 서버를 제거하고 NGINX Plus를 DMZ와 인트라넷 경계에 배치하여 

내부 AD FS 서버로의 요청을 처리하고 인증할 수 있습니다. 

이를 통해 하드웨어, 소프트웨어 및 운영 비용을 절감할 수 있습니다.

그림 5. WAP 서버가 없는 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;
    }
 }