내보내기(0) 인쇄
모두 확장

Azure 가상 컴퓨터에 Windows Server Active Directory를 배포하기 위한 지침

업데이트 날짜: 2014년 4월

이 백서에서는 Windows Server AD DS(Active Directory 도메인 서비스) 및 ADFS(Active Directory Federation Services)를 온-프레미스로 배포하는 경우와 Windows Azure VM(가상 컴퓨터)에 배포하는 경우의 중요한 차이점에 대해 설명합니다.

목차

이 백서는 Active Directory를 온-프레미스로 배포한 경험이 이미 있는 사용자를 대상으로 합니다. 이 백서에서는 Active Directory를 Windows Azure 가상 컴퓨터/Windows Azure 가상 네트워크에 배포하는 경우와 기존의 온-프레미스 Active Directory 배포의 차이점을 살펴봅니다. Windows Azure 가상 컴퓨터와 Windows Azure 가상 네트워크는 클라우드에서 컴퓨팅 리소스를 활용하는 조직을 위한 IaaS(Infrastructure-as-a-Service) 제품의 일부입니다.

AD 배포에 익숙하지 않은 사용자는 필요에 따라 AD DS 배포 가이드 또는 AD FS 2.0 배포 가이드를 참조하십시오.

이 백서에서는 독자가 다음과 같은 개념에 익숙하다고 가정합니다.

  • Windows Server AD DS 배포 및 관리

  • Windows Server AD DS 인프라를 지원하기 위한 DNS의 배포 및 구성

  • Windows Server AD FS 배포 및 관리

  • Windows Server AD FS 토큰을 사용할 수 있는 신뢰 당사자 응용 프로그램(웹 사이트 및 웹 서비스) 배포, 구성 및 관리

  • 가상 컴퓨터, 가상 디스크 및 가상 네트워크의 구성 방법과 같은 일반적인 가상 컴퓨터 개념

이 백서에서는 Windows Server AD DS 또는 AD FS가 일부는 온-프레미스로 배포되고 일부는 Windows Azure 가상 컴퓨터에 배포된 하이브리드 배포 시나리오에 대한 요구 사항을 강조하여 설명합니다. 먼저 Windows Server AD DS 및 AD FS를 Windows Azure 가상 컴퓨터에서 실행하는 경우와 온-프레미스로 실행하는 경우의 중요한 차이점과 디자인 및 배포에 영향을 미치는 중요한 결정 사항을 살펴봅니다. 그 다음에는 각 결정 사항에 대한 지침과 해당 지침을 다양한 배포 시나리오에 적용하는 방법을 자세히 설명합니다.

이 백서에서는 클라우드 응용 프로그램을 위한 ID 관리 및 액세스 제어 기능을 제공하는 REST 기반 서비스인 Windows Azure Active Directory의 배포와 구성은 다루지 않습니다. 그러나 Windows Azure AD와 Windows Server AD DS는 지금의 하이브리드 IT 환경과 최신 응용 프로그램을 위한 ID 및 액세스 관리 솔루션을 제공하기 위해 함께 작동하도록 디자인되었습니다. Windows Server AD DS와 Windows Azure AD의 차이점과 관계를 쉽게 이해하려면 다음 사항을 고려하십시오.

  1. Windows Azure를 사용하여 온-프레미스 데이터 센터를 클라우드로 확장하는 경우 클라우드의 Windows Azure 가상 컴퓨터에서 Windows Server AD DS를 실행할 수 있습니다.

  2. SaaS(Software-as-a-Service) 응용 프로그램에 대한 Single Sign-On을 사용자에게 제공하기 위해 Windows Azure Active Directory를 사용할 수 있습니다. 예를 들어 Microsoft Office 365는 이 기술을 사용하며 Windows Azure 또는 다른 클라우드 플랫폼에서 실행되는 응용 프로그램도 이 기술을 사용할 수 있습니다.

  3. 사용자가 Facebook, Google, Microsoft 및 기타 ID 공급자의 ID를 사용하여 클라우드에 호스팅되거나 온-프레미스로 호스팅된 응용 프로그램에 로그인할 수 있도록 하기 위해 Windows Azure Active Directory(액세스 제어 서비스)를 사용할 수 있습니다.

이러한 차이점에 대한 자세한 내용은 Windows Azure ID를 참조하십시오.

Windows Server Active Directory를 Windows Azure 가상 컴퓨터에 배포하기 위한 기본적인 요구 사항은 온-프레미스의 가상 컴퓨터(및 어느 정도까지는 물리적 컴퓨터)에 배포하는 경우와 거의 다르지 않습니다. 예를 들어 Windows Server AD DS의 경우 Windows Azure 가상 컴퓨터에 배포하는 DC(도메인 컨트롤러)가 기존 온-프레미스 회사 도메인/포리스트에서 복제본이면 다른 모든 추가 Windows Server Active Directory 사이트를 처리하는 것과 동일한 방식으로 Windows Azure 배포를 대부분 처리할 수 있습니다. 즉, 서브넷을 Windows Server AD DS에서 정의하고 사이트를 만들어야 하며 서브넷을 이 사이트에 연결하고 적절한 사이트 링크를 사용하여 다른 사이트에 연결해야 합니다. 그러나 모든 Windows Azure 배포에 공통적인 몇 가지 차이점이 있으며 특정 배포 시나리오에 따라 다른 일부 차이점도 있습니다. 두 가지 근본적인 차이점에 대한 개요와 자세한 설명이 아래에 나와 있습니다.

  1. Windows Azure 가상 컴퓨터에 온-프레미스 회사 네트워크에 대한 연결이 제공되어야 할 수 있습니다.

    Windows Azure 가상 컴퓨터를 온-프레미스 회사 네트워크에 연결하려면 Windows Azure 가상 컴퓨터와 온-프레미스 컴퓨터를 매끄럽게 연결할 수 있는 사이트 간 또는 사이트와 지점 간 VPN(가상 사설망) 구성 요소가 포함된 Windows Azure 가상 네트워크가 필요합니다. 이 VPN 구성 요소를 사용하면 온-프레미스 도메인 멤버 컴퓨터가 Windows Azure 가상 컴퓨터에 독점적으로 호스팅된 도메인 컨트롤러를 소유한 Windows Server Active Directory 도메인에 액세스할 수도 있습니다. 하지만 VPN에 오류가 발생하는 경우 Windows Server Active Directory에 의존하는 인증 및 기타 작업도 실패하게 된다는 점에 유의해야 합니다. 기존 캐시된 자격 증명을 사용하여 로그온이 가능할 수 있지만 티켓이 발행되어야 하거나 유효하지 않게 된 모든 피어 투 피어 또는 클라이언트와 서버 간 인증 시도가 실패합니다.

    데모 비디오와 프레미스 간 연결이 포함된 가상 네트워크 만들기를 비롯한 단계별 자습서의 목록을 보려면 네트워킹을 참조하십시오.

    note참고
    Windows Server Active Directory를 온-프레미스 네트워크와 연결되지 않은 Windows Azure 가상 네트워크에도 배포할 수 있습니다. 그러나 이 항목의 지침은 Windows Azure 가상 네트워크가 Windows Server에 필수적인 IP 주소 지정 기능을 제공하기 때문에 사용된다고 가정합니다.

  2. 고정 IP 주소는 Windows Azure 가상 컴퓨터에서 지원되지만 Windows Azure PowerShell을 사용하여 구성해야 합니다.

    동적 주소는 기본적으로 할당됩니다. 동적 주소를 할당하려면 Windows Azure 가상 네트워크를 만들어야 합니다. Windows Azure 가상 네트워크에 연결된 Windows Azure 가상 컴퓨터의 동적 IP 주소는 가상 컴퓨터의 수명 동안 계속 유지됩니다. 따라서 IP 주소 지정에 대한 Windows Server Active Directory 및 DNS 요구 사항이 충족됩니다.

    그러나 VM을 종료하면 동적 IP 주소 할당이 취소됩니다. IP 주소의 할당이 취소되지 않도록 하려면 Set-AzureStaticVNetIP cmdlet을 사용하여 고정 IP 주소를 할당하면 됩니다.

    자세한 내용은 IP 주소 지정 및 DNS를 참조하십시오.

다음 용어 목록은 다양한 관련 Windows Azure 기술을 정의하며 이 문서의 이해에 도움이 될 것입니다. 전체 용어집을 보려면 Windows Azure 용어집을 참조하십시오.

  • Windows Azure 가상 컴퓨터: 고객이 기존의 온-프레미스 서버 작업을 거의 모두 실행하는 VM을 배포할 수 있도록 하는 Windows Azure의 IaaS 제품입니다.

  • Windows Azure 가상 네트워크: 고객이 Windows Azure에서 가상 네트워크를 만들고 관리하며 VPN(가상 사설망)을 사용하여 자신의 온-프레미스 네트워킹 인프라에 안전하게 연결할 수 있도록 하는 Windows Azure의 네트워킹 서비스입니다.

  • VIP(가상 IP 주소): 특정 컴퓨터나 네트워크 인터페이스 카드에 바인딩되지 않은 인터넷 연결 IP 주소입니다. 클라우드 서비스에는 Windows Azure VM으로 리디렉션되는 네트워크 트래픽을 받기 위한 VIP가 할당됩니다. VIP는 Windows Azure 가상 컴퓨터를 하나 이상 포함할 수 있는 클라우드 서비스의 속성입니다. Windows Azure 가상 네트워크에도 클라우드 서비스가 하나 이상 포함될 수 있습니다. VIP는 기본 부하 분산 기능을 제공합니다.

  • DIP(동적 IP 주소): DHCP에 의해 Windows Azure 가상 컴퓨터의 가상 네트워크 어댑터에 동적으로 할당될 IP 주소입니다. 그러나 IP 주소는 DHCP 예약이 개별 MAC 주소에 연결되는 것과 동일하게 배포의 전체 수명 동안 해당 가상 컴퓨터와 함께 지속됩니다.

  • 서비스 복구: Windows Azure에서 서비스가 실패했음을 감지한 후 자동으로 서비스를 실행 중 상태로 다시 되돌리는 프로세스입니다. 서비스 복구는 가용성과 복원력을 지원하는 Windows Azure의 측면 중 하나입니다. 가능성은 낮지만 VM에서 실행되는 DC에 대한 서비스 복구 인시던트 이후의 결과는 계획되지 않은 다시 부팅과 유사합니다. 그러나 다음과 같은 몇 가지 부작용이 있습니다.

    • VM의 가상 네트워크 어댑터가 변경됩니다.

    • 가상 네트워크 어댑터의 MAC 주소가 변경됩니다.

    • VM의 프로세서/CPU ID가 변경됩니다.

    • VM이 가상 네트워크에 연결되어 있고 VM의 IP 구성이 가상 네트워크 또는 VM 자체(게스트 운영 체제가 아님)의 일부로 정의되는 한 가상 네트워크 어댑터의 IP 구성이 변경되지 않습니다.

    하지만 이러한 동작은 MAC 주소 또는 프로세서/CPU ID에 의존하지 않기 때문에 Windows Server Active Directory에 영향을 주지 않습니다. Windows Azure의 모든 Windows Server Active Directory 배포는 위에서 설명한 대로 Windows Azure 가상 네트워크에서 실행되는 것이 좋으며 이렇게 하면 IP 주소가 서비스 복구를 통해 지속됩니다.

Windows Server Active Directory DC를 Windows Azure 가상 컴퓨터에 배포하는 경우 가상 컴퓨터에서 온-프레미스로 DC를 실행하는 경우와 동일한 지침이 적용됩니다. 가상화된 DC를 실행하는 작업은 DC 백업 및 복원 지침을 따르는 한 안전합니다. 가상화된 DC 실행에 대한 제약 조건과 지침은 Hyper-V에서 도메인 컨트롤러 실행을 참조하십시오.

하이퍼바이저는 Windows Server Active Directory를 비롯한 많은 분산 시스템에서 문제를 일으킬 수 있는 기술을 제공합니다. 예를 들어 물리적 서버에서 디스크를 복제하거나 SAN 사용 등의 지원되지 않는 방법을 사용하여 서버의 상태를 롤백할 수 있지만 물리적 서버에서 이렇게 하는 것은 하이퍼바이저에서 가상 컴퓨터 스냅숏을 복원하는 것보다 훨씬 어렵습니다. Windows Azure에서는 스냅숏 복원 기능이 제공되지 않지만 동일한 바람직하지 않은 조건을 발생시킬 수 있는 기능이 제공됩니다. 예를 들어 정기적으로 백업하는 대신 DC의 VHD 파일을 복사하면 안 됩니다. 이 파일을 복원하면 스냅숏 복원 기능을 사용하는 경우와 유사한 상황이 발생할 수 있기 때문입니다.

이러한 롤백은 DC 간 상태가 영구적으로 달라지게 할 수 있는 USN 거품을 만들며 이로 인해 다음과 같은 문제가 발생할 수 있습니다.

  • 느린 개체

  • 일관되지 않은 암호

  • 일관되지 않은 특성 값

  • 스키마 마스터가 롤백되는 경우의 스키마 불일치

DC에 미치는 영향에 대한 자세한 내용은 USN 및 USN 롤백을 참조하십시오.

Windows Server 2012부터는 기본 하이퍼바이저 플랫폼이 VM-GenerationID를 지원하는 경우 가상화된 도메인 컨트롤러를 앞에 언급된 문제로부터 보호할 수 있도록 AD DS에 추가 세이프가드가 기본 제공됩니다. Windows Azure에서는 VM-GenerationID가 지원되며, 이는 Windows Azure 가상 컴퓨터에서 Windows Server 2012 이상을 실행하는 도메인 컨트롤러에 추가 세이프가드가 있음을 의미합니다. 자세한 내용은 AD DS(Active Directory 도메인 서비스) 가상화 소개를 참조하십시오.

대부분의 Windows Server AD DS 배포 시나리오는 Windows Azure에서 VM으로 배포하는 데 적합합니다. 예를 들어 유럽의 회사가 아시아의 원격 위치에서 사용자를 인증해야 한다고 가정해 보겠습니다. 이 회사는 배포 비용과 배포 후 서버를 관리할 전문 기술 부족 때문에 아시아에서 Windows Server Active Directory DC를 이전에 배포하지 않았습니다. 그 결과 아시아의 인증 요청이 유럽의 DC로 처리되며 결과는 만족스럽지 않습니다. 이 경우에 아시아의 Windows Azure 데이터 센터 내에서 실행되도록 지정한 VM에 DC를 배포할 수 있습니다. 이 DC를 원격 위치에 직접 연결된 Windows Azure 가상 네트워크에 연결하면 인증 성능이 향상됩니다.

Windows Azure는 비용이 많이 드는 DR(재해 복구) 사이트 대신 사용하기에도 적합합니다. 적은 수의 도메인 컨트롤러와 단일 가상 네트워크를 Windows Azure에서 호스팅하는 비용이 비교적 낮기 때문에 매력적인 대안이 됩니다.

마지막으로 SharePoint와 같은 네트워크 응용 프로그램을 Windows Azure에 배포하려고 할 수 있습니다. 이렇게 하려면 Windows Server Active Directory가 필요하지만 온-프레미스 네트워크 또는 회사 Windows Server Active Directory에 의존하지 않습니다. 이 경우에 SharePoint 서버의 요구 사항을 충족하기 위해 분리된 포리스트를 Windows Azure에 배포하는 것이 가장 적합합니다. 이 경우에도 온-프레미스 네트워크와 회사 Active Directory에 대한 연결이 필요한 네트워크 응용 프로그램을 배포하는 것이 지원됩니다.

note참고
VPN 구성 요소는 계층 3 연결을 제공하므로 Windows Azure 가상 네트워크와 온-프레미스 네트워크를 연결하는 데 VPN 구성 요소를 사용하면 온-프레미스로 실행되는 멤버 서버가 Windows Azure 가상 네트워크에서 Windows Azure 가상 컴퓨터로 실행되는 DC를 활용할 수도 있습니다. 그러나 VPN을 사용할 수 없는 경우 온-프레미스 컴퓨터와 Windows Azure 기반 도메인 컨트롤러 간의 통신이 작동하지 않고 인증 및 다양한 다른 오류가 발생합니다.  

  • 둘 이상의 VM이 포함된 Windows Server Active Directory 배포 시나리오의 경우 IP 주소 일관성을 위해 Windows Azure 가상 네트워크를 사용하는 것이 좋습니다. 이 가이드에서는 DC가 Windows Azure 가상 네트워크에서 실행되고 있다고 가정합니다.

    Windows Azure 가상 네트워크에서 IP 주소 일관성은 DHCP 예약과 유사한 세 번째 새로운 개념적 IP 주소 유형을 사용하여 얻을 수 있습니다. 현재 고정 IP 주소는 운영 체제 내에서 특정 네트워크 인터페이스 카드에 할당됩니다. 동적 주소는 DHCP 서버에 정의된 범위에 따라 DHCP 서버에서 자동으로 임대됩니다.

    세 번째 개념적 주소 유형은 Windows Azure 가상 네트워크에서 도입되었으며 DHCP 주소 할당과 약간만 다릅니다. Windows Azure 가상 컴퓨터를 사용하는 경우 DHCP에서 IP 주소를 입대하도록 VM을 구성해야 합니다. 그러나 임대가 만료될 때 변경될 수 있는 일반적인 동적 주소와 달리 Windows Azure 가상 네트워크에서 동적 주소는 VM을 종료하지 않으면 DHCP 예약의 경우와 매우 유사하게 가상 컴퓨터의 수명 동안 보장됩니다.

    VM을 종료하면 IP 주소 할당이 취소되고 VM을 다시 시작할 때 다른 IP 주소가 해당 VM에 할당될 수 있습니다. 종료 시 IP 주소의 할당이 취소되지 않도록 하려면 Set-AzureStaticVNetIP cmdlet을 사용하여 고정 IP 주소를 할당하면 됩니다. Set-AzureStaticVNetIP를 사용하는 방법에 대한 자세한 내용은 VM에 대해 고정 내부 IP 주소(DIP) 구성Windows Azure VM에 개인 고정 IP를 할당하는 방법을 참조하십시오.

    Important중요
    VM 내에서 고정 IP 주소를 구성하면 결국 해당 주소에 대한 연결이 완전히 손실됩니다.

  • 가상 네트워크에 VM을 배포한다고 해서 온-프레미스 네트워크에 연결될 수 있는 것은 아니며 연결되어야 하는 것도 아닙니다. 가상 네트워크는 그 가능성을 보장할 뿐입니다. Windows Azure와 온-프레미스 네트워크 간의 개인 통신에 사용할 가상 네트워크를 만들어야 하고, 온-프레미스 네트워크에 VPN 끝점을 배포해야 합니다. VPN은 Windows Azure에서 온-프레미스 네트워크로 열립니다. 자세한 내용은 가상 네트워크 개요Tutorial 2: Creating a Virtual Network for cross-premises connectivity을 참조하십시오.

    note참고
    지점 및 사이트 간 VPN 만들기에 대한 옵션을 사용하여 개별 Windows 기반 컴퓨터를 Windows Azure 가상 네트워크에 직접 연결할 수 있습니다.

  • 가상 네트워크를 만드는 것과 관계없이 Windows Azure는 송신 트래픽에 요금을 부과하지만 수신 트래픽에는 요금을 부과하지 않습니다. 다양한 Windows Server Active Directory 디자인 선택은 배포에서 생성하는 송신 트래픽의 양에 영향을 미칠 수 있습니다. 예를 들어 RODC를 배포하는 경우 아웃바운드 복제가 수행되지 않기 때문에 송신 트래픽이 제한됩니다. 트래픽 요금에 대한 자세한 내용은 Windows Azure 가격 개요를 참조하십시오.

  • 개별 Windows Azure 가상 네트워크가 서로 직접 연결되어 있지 않은 점도 유의해야 합니다. 즉, 지리적으로 분산되어 있을 수 있는 두 가상 네트워크를 만드는 경우 여기에 연결된 Windows Azure VM 간의 통신은 두 가상 네트워크를 사이트 간 VPN 기능을 통해 동일한 회사 네트워크에 연결하는 방법으로만 수행할 수 있습니다. 이때 두 가상 네트워크 간의 통신은 회사 네트워크를 통해 트래픽을 라우팅하는 방식으로만 가능합니다. 따라서 서로 다른 가상 네트워크에 있는 지리적으로 분산된 DC 간 통신은 가상 네트워크와 회사 네트워크를 둘 다 트래버스해야 합니다. 예를 들어 아시아의 가상 네트워크에 있는 Windows Azure VM이 남아메리카의 가상 네트워크에 있는 Windows Azure VM과 통신하려면 종단 간 통신이 내부 네트워크를 트래버스해야 합니다.

  • Windows Azure에서 RAM 크기 및 디스크 크기와 같은 온-프레미스 VM에 사용할 서버 리소스를 완전히 제어할 수 있을 때 미리 구성된 서버 크기의 목록에서 선택해야 합니다. DC의 경우 Windows Server Active Directory 데이터베이스를 저장하기 위해 운영 체제 디스크 외에도 데이터 디스크가 필요합니다. 사용할 수 있는 컴퓨팅 리소스에 대한 자세한 내용은 Windows Azure 용량에 대해 알아야 할 7가지를 참조하십시오.

AD FS는 Windows Azure 가상 컴퓨터에 배포할 수 있도록 지원되지만, 부하 분산 및 고가용성과 같은 AD FS에서 제공하는 기능 이상의 기술이 필요한 최상의 방법이 있습니다. 이러한 기술은 AD FS의 기본 기능 집합의 일부가 아니기 때문에 기본 인프라에서 제공되어야 합니다. 예를 들어 AD FS 프록시 및 STS(보안 토큰 서비스) 역할 모두 부하가 분산되고 가용성이 높은 것이 좋습니다. Windows Azure는 가상 컴퓨터의 개인 인터페이스(DIP)에서 이러한 부하 분산 및 고가용성 요구 사항을 충족할 수 없으므로 일부 AD FS 배포 구성에 대해 절충해야 합니다.

모든 최상의 방법을 충족하고 아무 것도 손상시키지 않는 AD FS를 사용하는 가능한 배포 구성 한 가지는 온-프레미스 DMZ에서 Windows Azure로 AD FS 프록시를 이동하는 것입니다. 이 구성은 AD FS 실행을 위한 부하 분산 및 고가용성 최상의 방법을 완벽하게 충족하는 VIP용 Windows Azure의 부하 분산 기능에 의존합니다. 이 시나리오에 대한 자세한 내용은 2. AD FS: 클레임 인식 온-프레미스 프런트 엔드 응용 프로그램을 인터넷으로 확장을 참조하십시오.

그러한 손상이 불가피한 가능한 AD FS 배포 구성을 보다 정확하게 이해하려면 AD FS가 온-프레미스에 일반적으로 배포되는 방법에 대한 아래의 설명을 고려하고 Windows Azure 가상 컴퓨터를 사용하는 현재의 가능성과 비교해 보십시오. AD FS 배포 계획에서 가져온 다음 다이어그램에서는 일반적인 AD FS 배포를 보여 줍니다.

AD FS WID 및 프록시

STS는 회사 방화벽 내부에 배포되고 부하 분산을 위해 NLB를 사용합니다. 회사 네트워크에 연결되어 있고 corp.fabrikam.com 도메인에 로그온한 사용자가 이 시나리오에서 Office 365에 액세스하려는 경우 STS 앞에 있는 부하가 분산되고 가용성이 높은 끝점으로 리디렉션됩니다.

AD FS 프록시는 경계 네트워크에 배포되며, 역시 NLB를 사용하여 외부 사용자의 요청에 대한 부하를 분산합니다. 외부 요청은 최종적으로 AD FS 프록시에 의해 STS 앞에 있는 부하가 분산되고 가용성이 높은 끝점에 전달됩니다.

모든 경우, 권장 사항을 따르면 사용되는 인터페이스는 부하가 분산되고 가용성이 높아집니다. 이를 수행하는 방법은 중요하지 않으며 NLB는 하나의 가능한 예로 사용됩니다.

note참고
이 시나리오에서 사용자가 인증되는 방법은 ADFS가 Office 365와 작동하는 방식을 참조하십시오.

대부분의 경우 AD FS가 사용하는 응용 프로그램은 중요 업무용이므로 이러한 응용 프로그램의 오류는 허용되지 않습니다. 따라서 이제 AD FS가 응용 프로그램 액세스를 위한 중요한 경로에 있기 때문에 위의 다이어그램에 나와 있는 다음과 같은 최상의 방법을 따라야 합니다.

  1. STS를 인터넷에 직접 노출하지 않습니다.

    보안을 위한 최상의 방법으로 STS 인스턴스를 방화벽 뒤에 두고 이 인스턴스를 회사 네트워크에 연결하여 인터넷에 노출되지 않게 하십시오. 이는 STS 역할이 보안 토큰을 발급하기 때문에 중요합니다. 따라서 STS 인스턴스를 도메인 컨트롤러와 동일한 보호 수준으로 처리해야 합니다. STS가 손상되면 악의적인 사용자가 신뢰 당사자 응용 프로그램과 신뢰 조직의 다른 STS를 선택할 수 있는 권리를 잠재적으로 포함하는 액세스 토큰을 발급할 수 있습니다.

  2. AD FS 서비스는 가용성이 높아야 합니다.

    AD FS가 필요한 응용 프로그램이 중요 업무용인 경우 AD FS 서비스의 가용성이 높아야 응용 프로그램에 대한 액세스를 유지할 수 있습니다. 가용성을 높이기 위해 일반적으로 부하 분산 장치가 AD FS 프록시 및 STS 앞에 배포됩니다.

이제 이 구성을 Windows Azure 가상 컴퓨터에 배포하는 방법을 고려해 보겠습니다. 녹색 확인 표시는 최상의 방법의 요구 사항이 손상 없이 충족될 수 있음을 나타내고, 빨간색 X는 Windows Azure 가상 컴퓨터를 사용하여 요구 사항을 충족할 수 없음을 나타냅니다.

Windows Azure의 AD FS 및 프록시

STS에 부하 분산 기능 및 고가용성을 제공할 수 없습니다. DIP는 부하 분산 기능을 제공하지 않는 반면 VIP는 기본 부하 분산 기능을 제공하기 때문에 STS의 부하를 분산하는 유일한 방법은 VIP를 사용하여 STS를 노출하는 것입니다. 그러나 이 방법은 최상의 방법 #1(STS를 인터넷에 직접 노출하지 않음)을 위반합니다.

요약하자면 솔루션을 위해서는 고가용성 또는 보안을 양보해야 합니다. AD FS는 응용 프로그램 액세스를 위한 중요 경로에 있기 때문에 응용 프로그램이 중요 업무용인 경우에는 일반적으로 이러한 타협이 허용되지 않습니다.

VIP를 사용하고 방화벽을 구성하여 STS를 배포하는 방법은 어떻습니까?

VIP 자체에 방화벽 제약 조건을 적용할 수도 있지만, 제공된 값을 기준으로 장기적인 안정성, 구성 및 유지 관리 요구 사항을 합리적으로 개선해야 합니다. 추가해야 할 규칙이나 프록시와 온-프레미스 사용자가 부하가 분산된 VIP 끝점에 액세스할 수 있도록 허용하는 VIP 방화벽 규칙을 표현하는 방법을 고려하십시오. 또한, 시간이 경과함에 따라 회사의 네트워크 공급자가 변경될 때 ACL을 유지하기 위한 물류 및 결과적으로 발생하는 응용 프로그램에 대한 액세스 권한 손실도 고려하십시오. Windows Azure에 있는 STS에 연결되는 온-프레미스에 부하 분산 기술을 배포하여 부하 분산 요구 사항을 충족할 수도 있지만 이 경우 매우 복잡한 솔루션이 만들어지고 오류가 발생할 경우 문제 해결 또한 어려워집니다. 이 경우 처음에 Windows Azure로 전환하는 목적(단순화, 비용 절감 등)에 근본적으로 위배될 수 있습니다.

목표가 Office 365뿐인 경우의 대안

목표가 Office 365뿐인 경우 온-프레미스에서 암호 동기화를 사용하는 DirSync를 배포하여 배포 복잡성을 0에 가깝게 줄이면서 동일한 최종 결과를 얻을 수 있습니다. 참고: 이 방법에는 AD FS 또는 Windows Azure가 필요하지 않습니다.

다음 표에서는 AD FS를 배포하는 경우와 배포하지 않는 경우에 로그온 프로세스가 어떻게 작동하는지를 비교합니다.

 

AD FS 및 DirSync를 사용하는 Office 365 Single Sign-On DirSync + 암호 동기화를 사용하는 동일한 Office 365 로그온
  1. 사용자가 회사 네트워크에 로그온하고 Windows Server Active Directory에 인증됩니다.

  2. 사용자가 Office 365에 액세스를 시도합니다(나는 @contoso.com임).

  3. Office 365는 사용자를 Windows Azure AD로 리디렉션합니다.

  4. Windows Azure AD는 사용자를 인증할 수 없고 온-프레미스에서 AD FS 트러스트가 있음을 알고 있으므로 사용자를 AD FS로 리디렉션합니다.

  5. 사용자가 Kerberos 티켓을 AD FS STS에 보냅니다.

  6. AD FS는 Kerberos 티켓을 필요한 토큰 형식/클레임으로 변환하고 사용자를 Windows Azure AD로 리디렉션합니다.

  7. 사용자가 Windows Azure AD에 인증됩니다(또 다른 변환이 발생함).

  8. Windows Azure AD는 사용자를 Office 365로 리디렉션합니다.

  9. 사용자가 Office 365에 자동으로 로그인됩니다.

  1. 사용자가 회사 네트워크에 로그온하고 Windows Server Active Directory에 인증됩니다.

  2. 사용자가 Office 365에 액세스를 시도합니다(나는 @contoso.com임).

  3. Office 365는 사용자를 Windows Azure AD로 리디렉션합니다.

  4. Windows Azure AD는 Kerberos 티켓을 직접 수락할 수 없고 트러스트 관계가 없으므로 사용자에게 자격 증명을 입력하도록 요청합니다.

  5. 사용자는 동일한 온-프레미스 암호를 입력하고 Windows Azure AD는 DirSync에 의해 동기화된 사용자 이름과 암호에 대해 유효성을 검사합니다.

  6. Windows Azure AD는 사용자를 Office 365로 리디렉션합니다.

  7. 사용자가 Windows Azure AD 토큰을 사용하여 Office 365와 OWA에 로그온할 수 있습니다.

DirSync + 암호 동기화 시나리오(AD FS 없음)에서는 Single-Sign-On이 'Same-Sign-On'으로 바뀝니다. 여기서 "Same"이란 사용자가 Office 365에 액세스할 때 동일한 온-프레미스 자격 증명을 다시 입력해야 함을 의미합니다. 이 데이터가 기억되도록 하여 후속 프롬프트 수를 줄일 수 있습니다.

결론

Windows Azure VM에 AD FS를 배포하는 것은 위험을 감수할 것인지 보상을 받을 것인지의 문제입니다. Windows Azure에서 AD FS를 배포하여 얻을 수 있는 보상은 감수해야 하는 위험보다 크지만 이는 배포 시나리오의 컨텍스트에서 내려야 하는 결정입니다. 다음 표에서는 의사 결정 매트릭스를 파악합니다.

 

배포 보상 위험

DIP만 사용하여 STS 배포

최상의 방법을 따르는 안전한 배포

고가용성 및 부하 분산 손상

VIP를 사용하여 STS 배포

고가용성 및 부하 분산 획득

보안과 관련된 합법적인 최상의 방법 무시

VIP와 방화벽 규칙을 사용하여 STS 배포

보안 및 고가용성 획득

단순성 손상 및 취약한 구성

Windows Azure에서 DIP만 사용하는 STS에 연결되도록 온-프레미스에서 부하 분산 장치 배포

보안 및 고가용성 획득

문제 해결의 단순 용이성 손상

추가로 생각할 문제

  • Windows Server AD FS 프록시를 Windows Azure 가상 컴퓨터에 배포하는 경우 AD FS STS에 대한 연결이 필요합니다. AD FS STS가 온-프레미스에 있는 경우 프록시가 STS와 통신할 수 있도록 가상 네트워크에서 제공하는 사이트 간 VPN 연결을 활용하는 것이 좋습니다.

  • Windows Server AD FS STS를 Windows Azure 가상 컴퓨터에 배포하는 경우 Windows Server Active Directory 도메인 컨트롤러, 특성 저장소 및 구성 데이터베이스에 대한 연결이 필요하며 사이트 간 VPN도 필요할 수 있습니다.

  • 요금은 모든 Windows Azure 가상 컴퓨터 송신 트래픽에 적용됩니다. 비용이 주요 요인인 경우 AD FS 프록시를 Windows Azure에 배포하여 STS를 온-프레미스에 두는 것이 좋습니다. STS도 Windows Azure 가상 컴퓨터에 배포하면 온-프레미스 사용자를 인증하기 위한 추가 비용이 발생합니다. VPN을 순회 중인지 여부와 관계없이 송신 트래픽으로 인해 비용이 발생합니다.

  • AD FS STS의 고가용성을 위해 Windows Azure의 기본 서버 부하 분산 기능을 사용하기로 결정하는 경우, 부하 분산은 클라우드 서비스 내에서 가상 컴퓨터의 상태를 확인하는 데 사용되는 프로브를 제공한다는 사실에 유의하십시오. Windows Azure 가상 컴퓨터의 경우(웹 또는 작업자 역할과 반대됨) 기본 프로브에 응답하는 에이전트가 Windows Azure 가상 컴퓨터에 없으므로 사용자 지정 프로브를 사용해야 합니다. 간단히 사용자 지정 TCP 프로브를 사용할 수 있습니다. 이 경우 가상 컴퓨터 상태를 확인하기 위해 TCP 연결(syn ack)이 성공적으로 설정되기만 하면 됩니다. 가상 컴퓨터에서 수신 대기하는 TCP 포트를 사용하도록 사용자 지정 프로브를 구성할 수 있습니다. 이렇게 하려면 Windows Azure 부하 분산 장치 프로브를 참조하십시오.

    note참고
    동일한 포트 집합(예: 포트 80 및 443)을 인터넷에 직접 노출해야 하는 컴퓨터는 동일한 클라우드 서비스를 공유할 수 없습니다. 따라서 응용 프로그램과 Windows Server AD FS에 대한 포트 요구 사항이 겹칠 가능성을 방지하기 위해 Windows Server AD FS 서버의 전용 클라우드 서비스를 만드는 것이 좋습니다.

다음 섹션에서는 고려해야 하는 중요한 사항을 강조하는 일반적인 배포 시나리오에 대해 간략하게 설명합니다. 각 시나리오에는 고려할 결정 사항과 요인에 대한 자세한 내용의 링크가 있습니다.

클라우드 전용 AD DS 배포

그림 1

SharePoint가 Windows Azure 가상 컴퓨터에 배포되고 응용 프로그램이 회사 네트워크 리소스에 의존하지 않습니다. 응용 프로그램에 Windows Server AD DS가 필요하지만 회사 Windows Server AD DS는 필요하지 않습니다. 사용자가 응용 프로그램을 통해 클라우드의 Windows Azure 가상 컴퓨터에서도 호스팅되는 Windows Server AD DS 도메인으로 자체 프로비전되기 때문에 Kerberos 또는 페더레이션된 트러스트가 필요하지 않습니다.

  • 네트워크 토폴로지: 프레미스 간 연결(사이트 간 연결이라고도 함) 없이 Windows Azure 가상 네트워크를 만듭니다.

  • DC 배포 구성: 새로운 도메인 컨트롤러를 도메인이 하나인 새로운 Windows Server Active Directory 포리스트에 배포합니다. Windows DNS 서버와 함께 배포해야 합니다.

  • Windows Server Active Directory 사이트 토폴로지: 기본 Windows Server Active Directory 사이트(모든 컴퓨터가 Default-First-Site-Name에 있음)를 사용합니다.

  • IP 주소 지정 및 DNS:

    • DHCP 임대 주소를 사용하거나, VM을 종료하고 DHCP 임대 주소를 유지하려는 경우에는 Set-AzureStaticVNetIP Windows Azure PowerShell cmdlet을 사용합니다.

    • Windows Server DNS를 Windows Azure의 도메인 컨트롤러에 설치하고 구성합니다.

    • DC 및 DNS 서버 역할을 호스트하는 VM의 이름과 IP 주소를 사용하여 가상 네트워크 속성을 구성합니다.

  • 글로벌 카탈로그: 포리스트의 첫 번째 DC는 글로벌 카탈로그 서버여야 합니다. 단일 도메인 포리스트에서 글로벌 카탈로그는 DC에서 추가 작업을 필요로 하지 않기 때문에 추가 DC도 GC로 구성해야 합니다.

  • Windows Server AD DS 데이터베이스 및 SYSVOL의 배치: Windows Server Active Directory 데이터베이스, 로그 및 SYSVOL을 저장하기 위해 Windows Azure VM으로 실행되는 DC에 데이터 디스크를 추가합니다.

  • 백업 및 복원: 시스템 상태 백업을 저장할 위치를 결정합니다. 필요한 경우 DC VM에 데이터 디스크를 더 추가하여 백업을 저장합니다.

크로스-프레미스 연결이 있는 페더레이션

그림 2

온-프레미스로 성공적으로 배포되고 회사 사용자가 사용하는 클레임 인식 응용 프로그램이 인터넷에서 직접 액세스될 수 있어야 합니다. 응용 프로그램이 데이터를 저장하고 검색하는 SQL 데이터베이스에 대한 웹 프런트 엔드 역할을 합니다. 응용 프로그램에서 사용하는 SQL Server도 회사 네트워크에 있습니다. 두 개의 Windows Server AD FS STS 및 부하 분산 장치가 회사 사용자에게 액세스를 제공하기 위해 온-프레미스로 배포되었습니다. 이제 응용 프로그램은 자체 회사 ID를 사용하는 비즈니스 파트너와 기존 회사 사용자에 의해 인터넷을 통해 직접 추가로 액세스되어야 합니다.

이 새로운 요구 사항의 배포 및 구성 요구를 단순화하고 충족하기 위해 추가 웹 프런트 엔드 두 개와 Windows Server AD FS 프록시 서버 두 대를 Windows Azure 가상 컴퓨터에 설치하도록 결정했습니다. 모든 4개의 VM이 인터넷에 직접 노출되고 Windows Azure 가상 네트워크의 사이트 간 VPN 기능을 사용하여 온-프레미스 네트워크에 연결됩니다.

  • 네트워크 토폴로지: Windows Azure 가상 네트워크를 만들고 프레미스 간 연결을 구성합니다.

    note참고
    각각의 Windows Server AD FS 인증서에 대해 인증서 템플릿 내에 정의된 URL과 생성된 인증서가 Windows Azure에서 실행되는 Windows Server AD FS 인스턴스에서 액세스될 수 있는지 확인합니다. 이를 위해서는 프레미스 간 연결이 PKI 인프라의 일부여야 할 수 있습니다. 예를 들어 CRL의 끝점이 LDAP 기반이고 온-프레미스에 독점적으로 호스팅되는 경우 프레미스 간 연결이 필요합니다. 이것이 바람직하지 않은 경우 인터넷을 통해 액세스할 수 있는 CRL을 소유한 CA에서 발행하는 인증서를 사용해야 할 수 있습니다.

  • 클라우드 서비스 구성: 부하 분산된 두 VIP를 제공하기 위해 클라우드 서비스가 두 개 있어야 합니다. 첫 번째 클라우드 서비스의 VIP는 포트 80과 443의 두 Windows Server AD FS 프록시 VM으로 연결됩니다. Windows Server AD FS 프록시 VM은 Windows Server AD FS STS에 연결되는 온-프레미스 부하 분산 장치의 IP 주소를 가리키도록 구성됩니다. 두 번째 클라우드 서비스의 VIP는 역시 포트 80 및 443에서 웹 프런트 엔드를 실행 중인 두 VM으로 연결됩니다. 부하 분산 장치가 작동하는 Windows Server AD FS 프록시 및 웹 프런트 엔드 VM으로만 트래픽을 전달하도록 하려면 사용자 지정 프로브를 구성합니다.

  • 페더레이션 서버 구성: Windows Server AD FS를 클라우드에서 만들어진 Windows Server Active Directory 포리스트의 보안 토큰을 생성하기 위한 페더레이션 서버(STS)로 구성합니다. ID를 허용하려는 다른 공급자와 페더레이션 클레임 공급자 트러스트 관계를 설정하고 토큰을 생성하려는 다른 응용 프로그램과 신뢰 당사자 트러스트 관계를 구성합니다.

    대부분의 시나리오에서 Windows Server AD FS 프록시 서버는 보안을 위해 인터넷 연결 환경에서 배포되지만 해당하는 Windows Server AD FS 페더레이션은 직접적인 인터넷 연결에서 분리되어 있습니다. 배포 시나리오와 관계없이 두 개의 Windows Server AD FS STS 인스턴스 또는 프록시 인스턴스에서 부하를 분산할 수 있는 공개적으로 노출된 IP 주소 및 포트를 제공할 VIP를 사용하여 클라우드 서비스를 구성해야 합니다.

  • Windows Server AD FS 고가용성 구성: 장애 조치(Failover) 및 부하 분산을 위해 서버가 두 대 이상 포함된 Windows Server AD FS 팜을 배포하는 것이 좋습니다. Windows Server AD FS 구성 데이터에 WID(Windows 내부 데이터베이스)를 사용하는 것을 고려할 수도 있으며, Windows Azure의 기본 서버 부하 분산 기능을 사용하여 들어오는 요청을 팜의 서버들에 분산시킬 수도 있습니다. Windows Azure의 기본 부하 분산 기능은 인터넷 연결 VIP를 사용할 때만 지원됩니다. DIP의 경우 부하를 분산할 수 없습니다.

    자세한 내용은 AD FS 2.0 배포 가이드를 참조하십시오.

크로스-프레미스 AD DS 배포

그림 3

Windows 통합 인증을 지원하고 Windows Server AD DS를 구성 데이터와 사용자 프로필 데이터의 리포지토리로 사용하는 LDAP 인식 응용 프로그램이 Windows Azure 가상 컴퓨터에 배포됩니다. 기존의 회사 Windows Server AD DS를 활용하고 Single Sign-On을 제공하는 것이 응용 프로그램에 바람직합니다. 응용 프로그램은 클레임을 인식하지 못합니다. 또한 사용자는 인터넷에서 직접 응용 프로그램에 액세스해야 합니다. 성능과 비용 면에서 최적화하기 위해 회사 도메인의 일부인 두 개의 추가 도메인 컨트롤러를 Windows Azure에 응용 프로그램과 함께 배포하도록 결정했습니다.

  • 네트워크 토폴로지: 프레미스 간 연결이 포함된 Windows Azure 가상 네트워크를 만듭니다. 이렇게 하려면 회사 네트워크의 가장자리에 호환되는 VPN 끝점을 배포해야 합니다. 자세한 내용은 가상 네트워크용 VPN 장치 정보를 참조하십시오.

  • 설치 방법: 회사 Windows Server Active Directory 도메인의 복제본 DC를 배포합니다. 복제본 DC를 위해 Windows Server AD DS를 VM에 설치할 수 있으며 필요에 따라 IFM(미디어에서 설치) 기능을 사용하여 설치 중에 새로운 DC에 복제되어야 하는 데이터 양을 줄일 수 있습니다. 자습서를 보려면 Install a replica Active Directory DC in Windows Azure Virtual Network를 참조하십시오. IFM을 사용하는 경우에도 온-프레미스에 가상 DC를 구축하고 설치 중에 Windows Server AD DS를 복제하는 대신 전체 VHD를 클라우드로 이동하는 것이 더 효율적일 수 있습니다. 안전을 위해 VHD가 Windows Azure에 복사되었으면 온-프레미스 네트워크에서 VHD를 삭제하는 것이 좋습니다.

  • Windows Server Active Directory 사이트 토폴로지: Active Directory 사이트 및 서비스에서 새로운 Windows Azure 사이트를 만듭니다. Windows Azure 가상 네트워크를 나타낼 Windows Server Active Directory 서브넷 개체를 만들어 사이트에 추가합니다. 새로운 Windows Azure 사이트와 Windows Azure에 대한 Windows Server Active Directory 트래픽을 제어하고 최적화하기 위해 Windows Azure 가상 네트워크 VPN 끝점이 배치된 사이트가 포함된 새 사이트 링크를 만듭니다.

  • IP 주소 지정 및 DNS:

    • DHCP 임대 주소를 사용하거나, VM을 종료하고 DHCP 임대 주소를 유지하려는 경우에는 Set-AzureStaticVNetIP Windows Azure PowerShell cmdlet을 사용합니다.

    • Windows Server DNS를 Windows Azure의 도메인 컨트롤러에 설치하고 구성합니다.

    • DC 및 DNS 서버 역할을 호스트하는 VM의 이름과 IP 주소를 사용하여 가상 네트워크 속성을 구성합니다.

  • 지리적으로 분산된 DC: 필요에 따라 추가 가상 네트워크를 구성합니다. 가상 네트워크 간의 직접 통신이 필요한 경우 두 가상 네트워크는 사이트 간 VPN 기능을 사용하도록 구성되어야 하며 가상 네트워크 간의 모든 트래픽은 내부 회사 네트워크를 통해 라우팅됩니다.

  • 읽기 전용 DC: Windows Azure 사이트에서 RODC를 배포할 수도 있는데 이는 DC에 대해 쓰기 작업을 수행하기 위한 요구 사항과 RODC가 포함된 사이트에서 응용 프로그램과 서비스의 호환성에 따라 결정됩니다. 응용 프로그램 호환성에 대한 자세한 내용은 읽기 전용 도메인 컨트롤러 응용 프로그램 호환성 가이드를 참조하십시오.

  • 글로벌 카탈로그: GC는 다중 도메인 포리스트에서 로그온 요청을 처리하는 데 필요합니다. Windows Azure 사이트에서 GC를 배포하지 않는 경우 인증 요청 시 다른 사이트에서 GC를 쿼리해야 하므로 송신 트래픽 비용이 발생합니다. 이 트래픽을 최소화하기 위해 Active Directory 사이트 및 서비스에서 Windows Azure 사이트에 대한 유니버설 그룹 멤버 자격 캐싱을 사용하도록 설정할 수 있습니다.

    GC를 배포하는 경우에는 Windows Azure 사이트의 GC가 동일한 부분 도메인 파티션을 복제해야 하는 다른 GC에서 원본 DC로 선호되지 않도록 사이트 링크와 사이트 링크 비용을 구성합니다.

  • Windows Server AD DS 데이터베이스 및 SYSVOL의 배치: Windows Server Active Directory 데이터베이스, 로그 및 SYSVOL을 저장하기 위해 Windows Azure VM에서 실행되는 DC에 데이터 디스크를 추가합니다.

  • 백업 및 복원: 시스템 상태 백업을 저장할 위치를 결정합니다. 필요한 경우 DC VM에 데이터 디스크를 더 추가하여 백업을 저장합니다.

다음 표에는 위의 시나리오에서 영향을 받는 Windows Server Active Directory 기술 영역과 고려할 해당 결정 사항 및 아래의 자세한 내용에 대한 링크가 요약되어 있습니다. 일부 배포 시나리오에는 적용되지 않는 기술 영역도 있으며 어떤 기술 영역은 다른 기술 영역보다 배포 시나리오에 더 중요할 수도 있습니다.

예를 들어 복제본 DC를 가상 네트워크에 배포하고 포리스트에 단일 도메인만 있는 경우에는 추가 복제 요구 사항을 만들지 않기 때문에 글로벌 카탈로그 서버를 배포하도록 선택하는 것이 배포 시나리오에 중요하지 않습니다. 반면에 포리스트에 여러 도메인이 있는 경우에는 글로벌 카탈로그를 가상 네트워크에 배포하는 결정이 사용 가능한 대역폭, 성능, 인증, 디렉터리 조회 등에 영향을 미칠 수 있습니다.

 

항목 번호

Windows Server Active Directory 기술 영역

결정 사항

요인

1

네트워크 토폴로지

가상 네트워크를 만듭니까?

회사 리소스에 액세스하기 위한 요구 사항

인증

계정 관리

2

DC 배포 구성

  • 트러스트를 사용하지 않는 별도의 포리스트를 배포합니까?

  • 페더레이션이 포함된 새 포리스트를 배포합니까?

  • Kerberos에 대한 Windows Server Active Directory 포리스트 트러스트를 사용하는 새 포리스트를 배포합니까?

  • 복제본 DC를 배포하여 회사 포리스트를 확장합니까?

  • 새 자식 도메인 또는 도메인 트리를 배포하여 회사 포리스트를 확장합니까?

보안

규정 준수

비용

복원력 및 내결함성

응용 프로그램 호환성

3

Windows Server Active Directory 사이트 토폴로지

트래픽을 최적화하고 비용을 최소화하기 위해 Windows Azure 가상 네트워크를 사용하여 서브넷, 사이트 및 사이트 링크를 구성하는 방법

서브넷 및 사이트 정의

사이트 링크 속성 및 변경 알림

복제 압축

4

IP 주소 지정 및 DNS

IP 주소와 이름 확인을 어떻게 구성합니까?

Windows Azure DHCP 임대 주소만 사용

Windows Server DNS 서버 설치

5

지리적으로 분산된 DC

각기 분리된 가상 네트워크에서 DC에 어떻게 복제합니까?

지리적으로 분리된 가상 네트워크 간의 직접 통신 없음

6

읽기 전용 DC

읽기 전용 DC를 사용합니까, 아니면 쓰기 가능 DC를 사용합니까?

HBI/PII 특성 필터링

암호 필터링

아웃바운드 트래픽 제한

7

글로벌 카탈로그

글로벌 카탈로그를 설치합니까?

단일 도메인 포리스트의 경우 모든 DC를 GC로 만들기

다중 도메인 포리스트의 경우 GC가 인증에 필요함

8

설치 방법

Azure에서 DC를 어떻게 설치합니까?

Important중요
SYSPREP를 사용하여 DC를 복제하지 마십시오. 그러나 Windows Server 2012를 실행하는 Windows Azure 가상 컴퓨터로 복제하는 가상 도메인 컨트롤러를 사용할 수 있습니다.

  • Windows PowerShell 또는 Dcpromo를 사용하여 AD DS 설치

또는

  • 온-프레미스 가상 DC의 VHD 이동

9

Windows Server AD DS 데이터베이스 및 SYSVOL의 배치

Windows Server AD DS 데이터베이스, 로그 및 SYSVOL을 어디에 저장합니까?

Dcpromo.exe 기본값 변경

Important중요
이러한 중요한 Active Directory 파일은 쓰기 캐싱을 구현하는 운영 체제 디스크 대신 Windows Azure 데이터 디스크에 배치되어야 합니다.

10

백업 및 복원

데이터를 어떻게 보호하고 복구합니까?

시스템 상태 백업 만들기

VHD 파일을 복사하거나 복제하면 안 됨

11

페더레이션 서버 구성

클라우드에서 페더레이션이 포함된 새 포리스트를 배포합니까?

AD FS를 온-프레미스로 배포하고 클라우드에서 프록시를 노출합니까?

보안

규정 준수

비용

비즈니스 파트너의 응용 프로그램 액세스

12

클라우드 서비스 구성

클라우드 서비스는 처음으로 가상 컴퓨터를 만들 때 암시적으로 배포됩니다. 추가 클라우드 서비스를 배포해야 합니까?

VM에서 인터넷에 대한 직접 노출이 필요합니까?

서비스에 부하 분산이 필요합니까?

13

공용 및 개인 IP 주소 지정(DIP 및 VIP)에 대한 페더레이션 서버 요구 사항

Windows Server AD FS 인스턴스가 인터넷에서 직접 액세스되어야 합니까?

클라우드에서 배포되는 응용 프로그램에 고유한 인터넷 연결 IP 주소 및 포트가 필요합니까?

배포에 필요한 VIP마다 클라우드 서비스를 하나씩 만들기

14

Windows Server AD FS 고가용성 구성

Windows Server AD FS 서버 팜에 노드가 몇 개 있습니까?

Windows Server AD FS 프록시 팜에 배포할 노드가 몇 개 있습니까?

복원력 및 내결함성

Windows Server AD DS의 IP 주소 일관성과 DNS 요구 사항을 충족하려면 먼저 Windows Azure 가상 네트워크를 만들고 여기에 가상 컴퓨터를 연결해야 합니다. 만드는 동안 필요에 따라 온-프레미스 회사 네트워크에 대한 연결을 확장하여 Windows Azure 가상 컴퓨터가 온-프레미스 컴퓨터에 투명하게 연결되도록 할지 여부를 결정해야 합니다. 이렇게 하려면 기존 VPN 기술을 사용해야 하고 VPN 끝점이 회사 네트워크의 가장자리에서 노출되어야 합니다. 즉, VPN이 Windows Azure에서 회사 네트워크로 시작되며 그 반대로는 시작되지 않습니다.

가상 네트워크를 온-프레미스 네트워크로 확장하는 경우 각 VM에 적용되는 표준 요금 외에 추가 요금이 적용됩니다. 특히 Windows Azure 가상 네트워크 게이트웨이의 CPU 시간에 대한 요금과 VPN에서 온-프레미스 컴퓨터와 통신하는 각 VM에서 생성하는 송신 트래픽에 대한 요금이 있습니다. 네트워크 트래픽 요금에 대한 자세한 내용은 Windows Azure 가격 개요를 참조하십시오.

DC를 구성하는 방법은 Windows Azure에서 실행하려는 서비스에 대한 요구 사항에 따라 달라집니다. 예를 들어 디렉터리 서비스가 필요하지만 내부 회사 리소스에 대한 특정 액세스는 필요하지 않은 개념 증명, 새 응용 프로그램 또는 기타 단기 프로젝트를 테스트하기 위해 자체 회사 포리스트에서 분리된 새 포리스트를 배포할 수 있습니다.

한 가지 이점으로, 분리된 포리스트 DC는 온-프레미스 DC를 사용하여 복제하지 않으므로 시스템 자체에서 생성되는 아웃바운드 네트워크 트래픽이 감소하여 비용이 직접적으로 줄어듭니다. 네트워크 트래픽 요금에 대한 자세한 내용은 Windows Azure 가격 개요를 참조하십시오.

또 다른 예로 서비스에 대한 개인 정보 보호 요구 사항이 있지만 서비스가 내부 Windows Server Active Directory에 액세스해야 하는 경우, 클라우드에서 서비스에 대한 데이터를 호스팅할 수 있으면 내부 포리스트에 대한 새로운 자식 도메인을 Windows Azure에 배포할 수도 있습니다. 이 경우 개인 정보 보호 문제를 처리하기 위한 글로벌 카탈로그 없이 새로운 자식 도메인에 대한 DC를 배포할 수 있습니다. 이 시나리오에서는 복제본 DC 배포와 함께 온-프레미스 DC와 연결하기 위한 가상 네트워크가 필요합니다.

새 포리스트를 만드는 경우 Active Directory 트러스트 또는 페더레이션 트러스트를 사용할지 여부를 선택합니다. 또한 호환성, 보안, 규정 준수, 비용 및 복원력으로 지정된 요구 사항의 균형을 맞춰야 합니다. 예를 들어 선택 인증을 활용하려면 새 포리스트를 Windows Azure에 배포하고 온-프레미스 포리스트와 클라우드 포리스트 간에 Windows Server Active Directory 트러스트를 만들도록 선택할 수 있습니다. 그러나 클레임 인식 응용 프로그램의 경우 Active Directory 포리스트 트러스트 대신 페더레이션 트러스트를 배포할 수 있습니다. 또 다른 요인은 온-프레미스 Windows Server Active Directory를 클라우드로 확장하여 데이터를 더 복제하거나 인증 및 쿼리 로드의 결과로 아웃바운드 트래픽을 더 생성하는 비용입니다.

가용성 및 내결함성에 대한 요구 사항도 선택에 영향을 줍니다. 예를 들어 링크가 중단되는 경우 Kerberos 트러스트 또는 페더레이션 트러스트를 활용하는 모든 응용 프로그램은 Windows Azure에 충분한 인프라가 배포되지 않는 한 완전히 작동하지 않을 가능성이 높습니다. 복제본 DC(쓰기 가능 또는 RODC)와 같은 대체 배포 구성은 링크 중단을 허용할 수 있는 가능성을 높입니다.

트래픽을 최적화하고 비용을 최소화하기 위해 사이트와 사이트 링크를 올바르게 정의해야 합니다. 사이트, 사이트 링크 및 서브넷은 DC와 인증 트래픽 흐름 간의 복제 토폴로지에 영향을 미칩니다. 다음 트래픽 요금을 고려한 다음 배포 시나리오의 요구 사항에 따라 DC를 배포하고 구성하십시오.

  • 게이트웨이 자체에는 시간당 아주 적은 수수료가 있습니다.

    • 적절하게 시작하고 중지할 수 있습니다.

    • 중지한 경우 Windows Azure VM이 회사 네트워크에서 분리됩니다.

  • 인바운드 트래픽이 무료입니다.

  • 아웃바운드 트래픽은 Windows Azure 가격 개요에 따라 요금이 부과됩니다. 다음과 같이 온-프레미스 사이트와 클라우드 사이트 간의 사이트 링크 속성을 최적화할 수 있습니다.

    • 가상 네트워크를 여러 개 사용하는 경우 Windows Server AD DS가 무료로 동일한 수준의 서비스를 제공할 수 있는 사이트보다 Windows Azure 사이트에 높은 우선 순위를 부여하지 못하도록 사이트 링크와 해당 비용을 적절하게 구성합니다. 또한 BASL(Bridge All Site Link) 옵션(기본적으로 사용하도록 설정됨)을 사용하지 않도록 설정하는 것도 좋습니다. 이렇게 하면 직접 연결된 사이트만 서로 복제하며, 전이적으로 연결된 사이트의 DC는 더 이상 서로 직접 복제할 수 없고 일반 사이트를 통해 복제해야 합니다. 특정 이유로 중개 사이트를 사용할 수 없게 되는 경우 전이적으로 연결된 사이트의 DC 간 복제는 사이트 간 연결을 사용할 수 있는 경우에도 발생하지 않습니다. 마지막으로, 전이적 복제 동작이 바람직한 곳에 온-프레미스, 회사 네트워크 사이트와 같은 적절한 사이트와 사이트 링크가 포함된 사이트 링크 브리지를 만듭니다.

    • 의도하지 않은 트래픽을 방지하기 위해 적절하게 사이트 링크 비용을 구성합니다. 예를 들어 가장 가까운 다음 사이트 시도 설정을 사용하도록 설정한 경우 Windows Azure 사이트를 회사 네트워크에 연결하는 사이트 링크 개체와 관련된 비용을 증가시켜 가상 네트워크 사이트가 가장 가까운 다음 사이트가 아니도록 합니다.

    • 일관성 요구 사항과 개체 변경 비율에 따라 사이트 링크 간격일정을 구성합니다. 복제 일정을 대기 시간 허용치에 맞게 조정합니다. DC는 값의 마지막 상태만 복제하므로 개체 변경 비율이 충분한 경우 복제 간격을 줄이면 비용을 절약할 수 있습니다.

  • 비용 최소화가 매우 중요한 경우 복제를 예약하고 변경 알림을 사용하도록 설정해야 합니다(사이트 간 복제 시 기본 구성임). 이는 RODC를 가상 네트워크에 배포하는 경우에는 중요하지 않은데, RODC는 아웃바운드 변경을 복제하지 않기 때문입니다. 그러나 쓰기 가능 DC를 배포하는 경우 불필요한 빈도로 업데이트를 복제하도록 사이트 링크가 구성되지 않았는지 확인해야 합니다. GC(글로벌 카탈로그) 서버를 배포하는 경우에는 GC가 포함된 다른 모든 사이트가 Windows Azure 사이트의 GC보다 비용이 낮은 사이트 링크로 연결된 사이트의 원본 DC에서 도메인 파티션을 복제하는지 확인합니다.

  • 복제 압축 알고리즘을 변경하여 사이트 간 복제에서 생성되는 네트워크 트래픽을 더 줄일 수 있습니다. 압축 알고리즘은 REG_DWORD 레지스트리 항목 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Replicator compression algorithm으로 제어됩니다. 기본값 3은 Xpress 압축 알고리즘과 관련이 있습니다. 이 값을 2로 변경할 수 있으며, 이렇게 하면 알고리즘이 MSZip으로 변경됩니다. 대부분의 경우 이렇게 변경하면 압축이 증가하지만 CPU 사용률을 희생하게 됩니다. 자세한 내용은 Active Directory 복제 토폴로지의 작동 방식을 참조하십시오.

Windows Azure 가상 컴퓨터에는 "DHCP 임대 주소"가 기본적으로 할당됩니다. Windows Azure 가상 네트워크 동적 주소가 가상 컴퓨터의 수명 동안 가상 컴퓨터와 함께 지속되기 때문에 Windows Server AD DS의 요구 사항이 충족됩니다.

따라서 Windows Azure에서 동적 주소를 사용하는 경우 임대 기간 동안 라우팅이 가능하고 임대 기간이 클라우드 서비스의 수명과 동일하기 때문에 고정 IP 주소를 사용하는 것과 마찬가지입니다.

그러나 VM을 종료하면 동적 주소 할당이 취소됩니다. IP 주소의 할당이 취소되지 않도록 하려면 Set-AzureStaticVNetIP를 사용하여 고정 IP 주소를 할당하면 됩니다.

이름 확인을 위해 자체 DNS 서버 인프라를 배포하거나 기존 DNS 서버 인프라를 활용합니다. Windows Azure에서 제공하는 DNS는 Windows Server AD DS의 고급 이름 확인 요구 사항을 충족하지 않습니다. 예를 들어 동적 SRV 레코드 등을 지원하지 않습니다. 이름 확인은 DC와 도메인에 가입된 클라이언트에 대한 중요한 구성 항목입니다. DC는 리소스 레코드를 등록하고 다른 DC의 리소스 레코드를 확인할 수 있어야 합니다.

내결함성과 성능상의 이유로 Windows Azure에서 실행되는 DC에 Windows Server DNS 서비스를 설치하는 것이 최적입니다. 그런 다음 DNS 서버의 이름과 IP 주소를 사용하여 Azure 가상 네트워크 속성을 구성합니다. 이렇게 하면 가상 네트워크의 다른 VM이 시작될 때 해당 DNS 클라이언트 해결 프로그램 설정이 동적 IP 주소 할당의 일부분으로 DNS 서버와 함께 구성됩니다.

note참고
인터넷을 통해 직접 Windows Azure에 호스팅된 Windows Server AD DS Active Directory 도메인에 온-프레미스 컴퓨터를 가입시킬 수 없습니다. Active Directory에 대한 포트 요구 사항과 도메인 가입 작업으로 인해 필요한 포트와 사실상 전체 DC를 인터넷에 직접 노출하는 것은 적합하지 않습니다.

VM은 시작할 때나 이름 변경이 있을 때 DNS 이름을 자동으로 등록합니다.

이 예제와 첫 번째 VM을 프로비전하여 거기에 AD DS를 설치하는 방법을 보여 주는 다른 예제를 보려면 Windows Azure에서 새로운 Active Directory 포리스트 설치를 참조하십시오. Windows PowerShell 사용에 대한 자세한 내용은 Windows Azure PowerShellWindows Azure 관리 Cmdlet을 참조하십시오.

Windows Azure에서는 서로 다른 가상 네트워크에 여러 DC를 호스팅하는 경우 이점이 제공됩니다.

  • 다중 사이트 내결함성

  • 지점에 대한 물리적 근접성(보다 짧은 대기 시간)

그러나 Windows Azure 가상 네트워크 간의 직접 통신은 존재하지 않습니다. 서로 다른 Windows Azure 가상 네트워크 간의 모든 통신이 온-프레미스 네트워크를 통해 라우팅되어야 하며, 이 경우 많은 양의 아웃바운드 트래픽(및 이 트래픽과 관련된 비용)이 생성될 수 있습니다.

가상 네트워크 간 연결 없음

그림 4

읽기 전용 DC를 배포할지 아니면 쓰기 가능 DC를 배포할지를 선택해야 합니다. 대개 RODC를 배포하기 쉬운데, 그 이유는 RODC를 물리적으로 제어할 수는 없지만 RODC가 지점과 같이 물리적 보안이 위험한 곳에 배포되도록 디자인되었기 때문입니다.

Windows Azure가 지점의 물리적 보안 위험을 제공하지는 않지만, RODC가 제공하는 기능은 매우 다른 이유 때문임에도 불구하고 이러한 환경에 적합하기 때문에 RODC가 보다 비용 효율적일 수 있습니다. 예를 들어 RODC는 아웃바운드 복제를 수행하지 않으며 선택적으로 암호를 채울 수 있습니다. 하지만 암호가 없는 경우 요청 시 발생하는 아웃바운드 트래픽이 사용자나 컴퓨터가 인증할 때 유효성을 검사해야 할 수 있습니다. 그러나 암호는 선택적으로 미리 채워지고 캐싱될 수 있습니다.

중요한 데이터가 포함된 특성을 RODC FAS(복제가 제한된 특성 집합)에 추가할 수 있기 때문에 RODC는 HBI 및 PII 문제와 관련하여 추가 이점을 제공합니다. FAS는 RODC에 복제되지 않는 특성의 집합으로, 사용자 지정이 가능합니다. Windows Azure에서 PII 또는 HBI를 저장할 수 없거나 저장하지 않으려는 경우 FAS를 안전 장치로 사용할 수 있습니다. 자세한 내용은 RODC 복제가 제한된 특성 집합을 참조하십시오.

응용 프로그램이 사용하려는 RODC와 호환되는지 확인하십시오. 많은 Windows Server Active Directory 사용 응용 프로그램이 RODC와 원활하게 작동하지만, 일부 응용 프로그램은 쓰기 가능 DC에 액세스할 수 없는 경우 비효율적으로 수행하거나 실패할 수 있습니다. 자세한 내용은 읽기 전용 DC 응용 프로그램 호환성 가이드를 참조하십시오.

글로벌 카탈로그를 설치할지 여부를 선택해야 합니다. 단일 도메인 포리스트에서 모든 DC를 GC(글로벌 카탈로그) 서버로 구성해야 합니다. 추가 복제 트래픽이 없으므로 비용이 증가하지 않습니다.

다중 도메인 포리스트에서 GC는 인증 프로세스 중에 유니버설 그룹 멤버 자격을 확장하는 데 필요합니다. GC를 배포하지 않는 경우 Windows Azure에서 DC에 대해 인증하는 가상 네트워크의 작업은 각 인증 시도 중에 온-프레미스의 GC를 쿼리하기 위해 아웃바운드 인증 트래픽을 간접적으로 생성합니다.

GC와 관련된 비용은 GC가 모든 도메인을 호스팅하기 때문에(부분적으로) 예측하기가 어렵습니다. 작업이 인터넷 연결 서비스를 호스팅하고 Windows Server AD DS에 대해 사용자를 인증하는 경우 비용은 완전히 예측 불가능할 수 있습니다 인증 중에 클라우드 사이트 외부의 GC 쿼리를 줄이려면 유니버설 그룹 멤버 자격 캐싱을 사용하도록 설정할 수 있습니다.

가상 네트워크에서 DC를 설치하는 방법을 선택해야 합니다.

DC에 Windows Azure 가상 컴퓨터만 사용합니다(Windows Azure "웹" 또는 "작업자" 역할 VM과 반대됨). Azure 가상 컴퓨터는 지속성이 있으며 DC에 대한 상태의 지속성이 필요합니다. Windows Azure 가상 컴퓨터는 DC와 같은 작업을 위해 디자인되었습니다.

SYSPREP를 사용하여 DC를 배포하거나 복제하지 마십시오. DC를 복제하는 기능은 Windows Server 2012부터만 사용할 수 있습니다. 복제 기능을 사용하려면 기본 하이퍼바이저에서 VMGenerationID에 대한 지원이 필요합니다. Windows Server 2012의 Hyper-V와 Windows Azure 가상 네트워크는 타사 가상화 소프트웨어 공급업체와 마찬가지로 VMGenerationID를 지원합니다.

Windows Server AD DS 데이터베이스, 로그 및 SYSVOL을 배치할 위치를 선택합니다. 이들은 Windows Azure 데이터 디스크에 배포되어야 합니다. “

note참고
Windows Azure 데이터 디스크는 1TB로 제한됩니다.

데이터 디스크 드라이브에서는 기본적으로 쓰기를 캐시하지 않습니다. VM에 연결된 데이터 디스크 드라이브는 동시 쓰기 캐싱을 사용합니다. 동시 쓰기 캐싱은 VM의 운영 체제 측면에서 트랜잭션이 완료되기 전에 쓰기가 지속성이 있는 Windows Azure 저장소에 커밋되도록 하며, 쓰기 속도가 약간 느려지는 대신 지속성을 제공합니다.

임시 쓰기 디스크 캐싱이 DC에서 설정하는 가정을 무효화하기 때문에 동시 쓰기 캐싱은 Windows Server AD DS에 중요합니다. Windows Server AD DS는 쓰기 캐싱을 사용하지 않도록 설정하려고 하지만 디스크 IO 시스템에 따라 쓰기 캐싱이 적용됩니다. 쓰기 캐싱을 사용하지 않도록 설정하지 못하면 특정 상황에서 USN 롤백이 생성되어 느린 개체와 기타 문제가 발생합니다.

가상 DC의 경우 모범 사례로 다음을 수행합니다.

  • Windows Azure 데이터 디스크의 호스트 캐시 기본 설정을 NONE으로 지정합니다. 그러면 AD DS 작업에 대한 쓰기 캐싱에서 문제를 방지할 수 있습니다.

  • 데이터베이스, 로그 및 SYSVOL을 동일한 데이터 디스크나 별도의 데이터 디스크에 저장합니다. 일반적으로 이러한 디스크는 운영 체제 자체에 사용되는 디스크와 별도입니다. 다시 말하자면, Windows Server AD DS 데이터베이스 및 SYSVOL은 Windows Azure 운영 체제 디스크 유형에 저장되지 않아야 합니다. 기본적으로 AD DS 설치 프로세스는 Windows Azure에 권장되지 않는 %systemroot% 폴더에 이러한 구성 요소를 설치합니다.

일반적인 DC와 특히 VM에서 실행되는 DC의 백업 및 복원에 지원되는 것과 지원되지 않는 것을 알아두어야 합니다. 가상화된 DC에 대한 백업 및 복원 고려 사항을 참조하십시오.

Windows Server 백업과 같은 Windows Server AD DS에 대한 백업 요구 사항을 특별히 인식하는 백업 소프트웨어만 사용하여 시스템 상태 백업을 만듭니다.

정기 백업을 수행하는 대신 DC의 VHD 파일을 복사하거나 복제하지 마십시오. 복원이 필요한 경우 Windows Server 2012 및 지원되는 하이퍼바이저 없이 복제되거나 복사된 VHD를 사용하여 복원하면 USN 거품이 생성됩니다.

Windows Server AD FS 페더레이션 서버(STS)의 구성은 Windows Azure에 배포하려는 응용 프로그램이 온-프레미스 네트워크의 리소스에 액세스해야 하는지 여부에 따라 부분적으로 결정됩니다.

응용 프로그램이 다음과 같은 조건을 충족하는 경우 온-프레미스 네트워크에서 분리된 상태로 응용 프로그램을 배포할 수 있습니다.

  • SAML 보안 토큰을 허용하는 경우

  • 인터넷에 노출 가능한 경우

  • 온-프레미스 리소스에 액세스하지 않는 경우

이 경우 다음과 같이 Windows Server AD FS STS를 구성합니다.

  1. Windows Azure에서 분리된 단일 도메인 포리스트를 구성합니다.

  2. Windows Server AD FS 페더레이션 서버 팜을 구성하여 포리스트에 대한 페더레이션된 액세스를 제공합니다.

  3. 온-프레미스 포리스트에서 Windows Server AD FS(페더레이션 서버 팜 및 페더레이션 서버 프록시 팜)를 구성합니다.

  4. Windows Server AD FS의 온-프레미스 인스턴스와 Windows Azure 인스턴스 간에 페더레이션 트러스트 관계를 설정합니다.

반면에 응용 프로그램이 온-프레미스 리소스에 액세스해야 하는 경우 다음과 같이 Windows Azure에서 응용 프로그램으로 Windows Server AD FS를 구성할 수 있습니다.

  1. 온-프레미스 네트워크와 Windows Azure 간의 연결을 구성합니다.

  2. 온-프레미스 포리스트에서 Windows Server AD FS 페더레이션 서버 팜을 구성합니다.

  3. Windows Azure에서 Windows Server AD FS 페더레이션 서버 프록시 팜을 구성합니다.

이 구성은 경계 네트워크에서 응용 프로그램으로 Windows Server AD FS를 구성하는 경우와 유사하게 온-프레미스 리소스의 노출을 줄이는 이점이 있습니다.

두 시나리오에서 비즈니스 간 공동 작업이 필요한 경우 추가 ID 공급자와 트러스트 관계를 설정할 수 있습니다.

클라우드 서비스는 VM을 인터넷에 직접 노출하거나 부하가 분산된 인터넷 연결 응용 프로그램을 노출하려는 경우에 필요합니다. 이는 각 클라우드 서비스가 구성 가능한 단일 VIP를 제공하기 때문에 가능합니다.

각 Windows Azure 가상 컴퓨터는 DIP를 수신합니다. DIP는 Windows Azure 내에서만 액세스할 수 있는 개인 주소입니다. 그러나 대부분의 경우 Windows Server AD FS 배포에 대해 VIP를 구성해야 합니다. VIP는 페더레이션된 파트너와 클라이언트가 인증과 지속적 관리를 위해 사용할 Windows Server AD FS 끝점을 인터넷에 노출하는 데 필요합니다. VIP는 Windows Azure 가상 컴퓨터가 하나 이상 포함된 클라우드 서비스의 속성입니다. Windows Azure에 배포된 클레임 인식 응용 프로그램과 Windows Server AD FS가 둘 다 인터넷에 연결되어 있고 공통 포트를 공유하는 경우, 각각에 자체 VIP가 필요하며 각 VIP는 응용 프로그램과 Windows Server AD FS에 대한 클라우드 서비스를 하나씩 만드는 데 필요합니다.

VIP 및 DIP 용어에 대한 정의는 용어 및 정의를 참조하십시오.

독립 실행형 Windows Server AD FS 페더레이션 서비스를 배포할 수 있지만, 프로덕션 환경의 AD FS STS 및 프록시에 대한 노드가 두 개 이상 포함된 팜을 배포하는 것이 좋습니다.

특정 요구 사항에 가장 적합한 배포 구성 옵션을 결정하려면 AD FS 2.0 디자인 가이드에서 AD FS 2.0 배포 토폴로지 고려 사항을 참조하십시오.

note참고
Windows Azure에서 Windows Server AD FS 끝점에 대한 부하 분산 기능을 사용하려면 동일한 클라우드 서비스에 있는 Windows Server AD FS 팜의 모든 멤버를 구성하고 HTTP 포트(기본값 80)와 HTTPS 포트(기본값 443)에 Windows Azure의 부하 분산 기능을 사용합니다. 자세한 내용은 Windows Azure 부하 분산 장치 프로브를 참조하십시오.

Windows Server NLB(네트워크 부하 분산)는 Windows Azure에서 지원되지 않습니다.

표시:
© 2014 Microsoft