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

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

업데이트 날짜: 2014년 11월

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

목차

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

AD 배포에 익숙하지 않은 사용자는 필요에 따라 AD DS 배포 가이드 또는 AD FS 배포 계획을 참조하세요.

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

  • Windows Server AD DS 배포 및 관리

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

  • Windows Server AD FS 배포 및 관리

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

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

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

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

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

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

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

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

Azure 가상 컴퓨터 준비 평가(영문)를 다운로드 및 실행할 수도 있습니다. 평가는 온-프레미스 환경을 자동으로 검사하고, 환경을 Azure로 마이그레이션하는 데 도움이 되도록 이 항목의 지침에 따라 사용자 지정 보고서를 생성합니다.

먼저 다음 주제를 다루는 자습서, 가이드 및 동영상을 검토하는 것이 좋습니다.

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

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

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

    데모 비디오와 관리 포털에서 사이트 간 VPN 구성을 비롯한 단계별 자습서의 목록은 가상 네트워크를 참조하세요.

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

  2. 고정 IP 주소는 Azure PowerShell을 사용하여 구성해야 합니다.

    동적 주소는 기본적으로 할당되지만 대신 고정 IP 주소를 할당하려면 Set-AzureStaticVNetIP cmdlet을 사용해야 합니다. 이 cmdlet은 서비스 복구 및 VM 종료/재시작 중에 유지되는 고정 IP 주소를 설정합니다. 자세한 내용은 VM에 대한 고정 DIP(내부 IP 주소) 구성을 참조하세요.

아래의 용어 목록은 다양한 관련 Azure 기술을 정의하며 이 문서의 이해에 도움이 될 것입니다.

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

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

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

  • DIP(동적 IP 주소): 내부용으로만 사용되는 IP 주소입니다. DC/DNS 서버 역할을 호스트하는 VM의 경우 고정 IP 주소로 구성해야 합니다(Set-AzureStaticVNetIP cmdlet 사용).

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

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

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

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

    • 가상 네트워크 어댑터의 IP 구성은 VM이 가상 네트워크에 연결되어 있고 VM의 IP 주소가 고정 IP 주소인 한 변경되지 않습니다.

    하지만 이러한 동작은 MAC 주소 또는 프로세서/CPU ID에 의존하지 않기 때문에 Windows Server Active Directory에 영향을 주지 않습니다. Azure의 모든 Windows Server Active Directory 배포는 위에서 설명한 대로 Azure 가상 네트워크에서 실행되도록 권장됩니다.

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

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

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

  • 느린 개체

  • 일관되지 않은 암호

  • 일관되지 않은 특성 값

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

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

Windows Server 2012부터 추가 보호 조치가 AD DS에 기본 제공됩니다. 이러한 보호 조치는 기본 하이퍼바이저 플랫폼이 VM-GenerationID를 지원하는 한 앞서 언급한 문제로부터 가상화된 도메인 컨트롤러를 보호하도록 도와줍니다. Azure에서는 VM-GenerationID를 지원하며, 이는 Azure 가상 컴퓨터에서 Windows Server 2012 이상을 실행하는 도메인 컨트롤러에 추가 세이프가드가 있음을 의미합니다.

note참고
Azure 관리 포털의 종료 옵션을 사용하는 대신 게스트 운영 체제 내의 Azure에서 도메인 컨트롤러 역할을 실행하는 VM을 종료했다가 다시 시작해야 합니다. 현재는 관리 포털을 사용하여 VM을 종료하면 VM 할당이 취소됩니다. VM의 할당이 취소되면 비용이 발생하지 않는다는 이점은 있지만 VM-GenerationID가 다시 설정되므로 DC에는 바람직하지 않습니다. VM-GenerationID가 다시 설정되면 AD DS 데이터베이스의 invocationID도 다시 설정되고 RID 풀이 삭제되며 SYSVOL이 신뢰할 수 없는 것으로 표시됩니다. 자세한 내용은 AD DS(Active Directory 도메인 서비스) 가상화 소개(수준 100)안전하게 DFSR 가상화를 참조하세요.

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

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

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

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

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

  • 온-프레미스 DC와 마찬가지로 고정 IP 주소를 사용하는 것이 좋습니다. 고정 IP 주소는 Azure PowerShell로만 구성할 수 있습니다(VM에 대한 고정 DIP(내부 IP 주소) 구성 참조). 게스트 운영 체제 내에서 고정 IP 주소 구성을 확인하는 모니터링 시스템 또는 기타 솔루션이 있는 경우 VM의 네트워크 어댑터 속성에 동일한 고정 IP 주소를 할당할 수 있습니다. 그러나 VM에서 서비스 복구를 진행하거나 VM이 관리 포털에서 종료되고 해당 주소가 할당 취소된 경우에는 네트워크 어댑터가 삭제됩니다. 이 경우 게스트 내의 고정 IP 주소를 다시 설정해야 합니다.

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

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

  • 가상 네트워크를 만드는 것과 관계없이 Azure는 송신 트래픽에 요금을 부과하지만 수신 트래픽에는 요금을 부과하지 않습니다. 다양한 Windows Server Active Directory 디자인 선택은 배포에서 생성하는 송신 트래픽의 양에 영향을 미칠 수 있습니다. 예를 들어 RODC를 배포하는 경우 아웃바운드 복제가 수행되지 않기 때문에 송신 트래픽이 제한됩니다. 그러나 RODC를 배포하기로 결정한 경우에는 DC에 대해 쓰기 작업을 수행해야 하는지 여부, 사이트의 응용 프로그램 및 서비스와 RODC와의 호환성 등을 비교 검토해야 합니다. 트래픽 요금에 대한 자세한 내용은 Azure 가격 책정 한눈에 보기을 참조하십시오.

  • Azure에서 RAM 크기 및 디스크 크기와 같은 온-프레미스 VM에 사용할 서버 리소스를 완전히 제어할 수 있을 때 미리 구성된 서버 크기의 목록에서 선택해야 합니다. DC의 경우 Windows Server Active Directory 데이터베이스를 저장하기 위해 운영 체제 디스크 외에도 데이터 디스크가 필요합니다.

예. Azure 가상 컴퓨터에서 Windows Server AD FS를 배포할 수 있습니다. 온-프레미스의 AD FS 배포 모범 사례가 Azure의 AD FS 배포에도 동일하게 적용됩니다. 그러나 부하 분산, 고가용성 등 이러한 모범 사례 중 일부에는 AD FS에서 자체적으로 제공하는 기능 이상의 기술이 필요합니다. 이러한 기술은 기본 인프라에서 제공되어야 합니다. 이러한 모범 사례 중 일부를 검토하고 Azure VM과 Azure VNet을 사용하여 모범 사례를 따르는 방법을 살펴보겠습니다.

  1. STS(보안 토큰 서비스) 서버는 인터넷에 직접 표시하지 않습니다.

    이는 STS 역할이 보안 토큰을 발급하기 때문에 중요합니다. 따라서 AD FS 서버와 같은 STS 서버는 도메인 컨트롤러와 동일한 보호 수준으로 처리해야 합니다. STS가 손상되면 악의적인 사용자가 신뢰 당사자 응용 프로그램과 신뢰 조직의 다른 STS 서버를 선택할 수 있는 권리를 잠재적으로 포함하는 액세스 토큰을 발급할 수 있습니다.

  2. 모든 사용자 도메인의 Active Directory 도메인 컨트롤러를 AD FS 서버와 같은 네트워크에 배포합니다.

    AD FS 서버는 Active Directory 도메인 서비스를 사용하여 사용자를 인증합니다. 따라서 도메인 컨트롤러는 AD FS 서버와 같은 네트워크에 배포하는 것이 좋습니다. 그러면 Azure 네트워크와 온-프레미스 네트워크 간의 링크가 끊어져도 업무를 중단하지 않고 계속할 수 있으며 로그인 성능을 높이고 대기 시간을 줄일 수 있습니다.

  3. 가용성을 높이고 부하를 분산시킬 수 있도록 여러 AD FS 노드를 배포합니다.

    대부분의 경우 보안 토큰이 필요한 응용 프로그램은 중요 업무용이므로 AD FS를 통해 사용하는 응용 프로그램의 오류는 허용되지 않습니다. 이러한 이유로, 그리고 이제는 중요 업무용 응용 프로그램에 액세스하려면 AD FS를 반드시 거쳐야 하므로 여러 AD FS 프록시 및 AD FS 서버를 통해 AD FS 서비스의 가용성을 높여야 합니다. 요청을 분산시키기 위해 AD FS 프록시와 AD FS 서버 전면에 대개 부하 분산 장치를 배포합니다.

  4. 인터넷 액세스용으로 하나 이상의 웹 응용 프로그램 프록시 노드를 배포합니다.

    사용자가 AD FS 서비스로 보호되는 응용 프로그램에 액세스해야 하는 경우 인터넷을 통해 AD FS 서비스를 제공해야 합니다. 이렇게 하려면 웹 응용 프로그램 프록시 서비스를 배포합니다. 고가용성 및 부하 분산을 위해 둘 이상의 노드를 배포하는 것이 좋습니다.

  5. 내부 네트워크 리소스만 웹 응용 프로그램 프록시 노드에서 액세스할 수 있도록 제한합니다.

    외부 사용자가 인터넷에서 AD FS에 액세스하도록 허용하려면 웹 응용 프로그램 프록시 노드(이전 버전 Windows Server에서는 AD FS 프록시)를 배포해야 합니다. 웹 응용 프로그램 프록시 노드는 인터넷에 직접 표시됩니다. 이러한 노드는 도메인에 가입하지 않아도 되며 TCP 포트 443 및 80을 통한 AD FS 서버 액세스 권한만 있으면 됩니다. 다른 모든 컴퓨터(특히 도메인 컨트롤러)에 대한 통신은 차단하는 것이 좋습니다.

    온-프레미스에서는 이를 위해 일반적으로 DMZ를 사용합니다. 방화벽은 작업 허용 목록 모드를 사용하여 DMZ에서 온-프레미스 네트워크로의 트래픽을 제한합니다. 이 경우 지정된 IP 주소로부터의 트래픽과 지정된 포트를 통과하는 트래픽만 허용되고 기타 트래픽은 모두 차단됩니다.

다음 다이어그램에는 일반적인 온-프레미스 AD FS 배포의 DMZ 사용 방식이 나와 있습니다.

DMZ를 사용하는 Prem의 ADFS

그러나 Azure에서는 완전하게 작동하는 기본 방화벽 기능을 제공하지 않으므로 다른 옵션을 사용하여 트래픽을 제한해야 합니다. 다음 표에는 각 옵션과 해당 장단점이 나와 있습니다.

 

옵션 장점 단점

Azure 네트워크 ACL

초기 구성이 보다 저렴하고 간단합니다.

새 VM을 배포에 추가하는 경우 네트워크 ACL 구성을 추가로 수행해야 합니다.

Barracuda NG Firewall

작업 허용 목록 모드가 사용되며 네트워크 ACL 구성이 필요하지 않습니다.

초기 설정 비용이 증가하고 작업이 복잡해집니다.

이러한 경우 AD FS를 배포하는 대략적인 단계는 다음과 같습니다.

  1. VPN 또는 Express 경로를 사용하여 크로스 프레미스 연결을 사용하는 가상 네트워크를 만듭니다.

  2. 가상 네트워크에서 도메인 컨트롤러를 배포합니다. 이 단계는 반드시 수행해야 하는 것은 아니지만 수행하는 것이 좋습니다.

  3. 가상 네트워크에서 도메인에 가입된 AD FS 서버를 배포합니다.

  4. AD FS 서버를 포함하며 가상 네트워크 내에서 새 개인 IP 주소(DIP)를 사용하는 내부 부하 분산된 집합을 만듭니다

    1. DNS를 업데이트하여 내부 부하 분산된 집합의 개인 IP 주소(DIP)를 가리키는 FQDN을 만듭니다.

  5. 웹 응용 프로그램 프록시 노드용으로 클라우드 서비스 또는 별도의 가상 네트워크를 만듭니다.

  6. 클라우드 서비스 또는 가상 네트워크에 웹 응용 프로그램 프록시 노드를 배포합니다.

    1. 웹 응용 프로그램 프록시 노드를 포함하는 외부 부하 분산된 집합을 만듭니다.

    2. 외부 DNS 이름(FQDN)이 클라우드 서비스 공용 IP 주소(VIP)를 가리키도록 업데이트합니다.

    3. AD FS 서버의 내부 부하 분산된 집합에 해당하는 FQDN을 사용하도록 AD FS 프록시를 구성합니다.

    4. 클레임 공급자에 대해 외부 FQDN을 사용하도록 클레임 기반 웹 사이트를 업데이트합니다.

  7. AD FS 가상 네트워크의 모든 컴퓨터에 대해 웹 응용 프로그램 프록시 간의 액세스를 제한합니다.

트래픽을 제한하려면 TCP 포트 80 및 443으로 보내는 트래픽만 허용하고 부하 분산된 집합의 내부 DIP로 보내는 기타 모든 트래픽은 삭제되도록 Azure 내부 부하 분산 장치의 부하 분산된 집합을 구성해야 합니다.

ADFS 네트워크 ACL

AD FS 서버에 대한 트래픽은 다음 원본을 통해서만 허용됩니다.

  • Azure 내부 부하 분산 장치

  • 온-프레미스 네트워크의 관리자 IP 주소

Warning경고
웹 응용 프로그램 프록시 노드는 Azure 가상 네트워크의 기타 VM이나 온-프레미스 네트워크의 모든 위치에 연결할 수 없도록 디자인해야 합니다. 이렇게 하려면 Express 경로 연결용 온-프레미스 어플라이언스 또는 사이트 간 VPN 연결용 VPN 장치에서 방화벽 규칙을 구성합니다.

이 옵션을 사용하는 경우의 단점은 내부 부하 분산 장치, AD FS 서버 및 가상 네트워크에 추가하는 기타 서버를 포함한 여러 장치에 대해 네트워크 ACL을 구성해야 한다는 것입니다. 장치에 대한 트래픽을 제한하기 위해 네트워크 ACL을 구성하지 않고 배포에 장치를 추가하면 전체 배포가 위험해질 수 있습니다. 웹 응용 프로그램 프록시 노드의 IP 주소가 변경되면 네트워크 ACL을 다시 설정해야 합니다. 즉, 고정 DIP를 사용하도록 프록시를 구성해야 합니다.

네트워크 ACL을 사용하는 Azure의 ADFS

Barracuda NG Firewall 어플라이언스를 사용하여 AD FS 프록시 서버와 AD FS 서버 간의 트래픽을 제어하는 옵션을 사용할 수도 있습니다. 이 옵션은 보안 및 고가용성 모범 사례를 따릅니다. 그리고 Barracuda NG Firewall 어플라이언스는 방화벽 관리 허용 목록 모드를 제공하며 Azure 가상 네트워크에 직접 설치할 수 있기 때문에 초기 설치 후 수행해야 하는 관리 작업이 줄어듭니다. 따라서 새 서버를 배포에 추가할 때 네트워크 ACL을 구성하지 않아도 됩니다. 그러나 이 옵션을 사용하는 경우에는 초기 배포 비용이 증가하며 작업이 복잡해집니다.

이 옵션에서는 가상 네트워크 하나가 아닌 두 개가 배포됩니다. VNet1에는 프록시가 포함되고 VNet2에는 회사 네트워크로 다시 연결되는 네트워크 연결과 STS가 포함됩니다. 따라서 VNet1은 VNet2에서 사실상 물리적으로 분리되며 회사 네트워크에서도 분리됩니다. VNet1은 TINA(Transport Independent Network Architecture)라는 특수 터널링 기술을 통해 VNet2에 연결됩니다. TINA 터널은 Barracuda NG Firewall을 사용하여 각 VNet에 연결됩니다(각 VNet에 Barracuda가 하나씩 있음). 고가용성을 유지하려면 각 VNet에 Barracuda 두 개(활성/수동 하나씩)를 배포하는 것이 좋습니다. 그러면 매우 효율적인 방화벽 기능이 제공되므로 Azure에서도 기존의 온-프레미스 DMZ와 비슷한 작동 방식을 사용할 수 있습니다.

방화벽을 사용하는 Azure의 ADFS

자세한 내용은 2. AD FS: 클레임 인식 온-프레미스 프런트 엔드 응용 프로그램을 인터넷으로 확장를 참조하세요.

Office 365 SSO만 사용하려는 경우 AD FS 배포 대신 사용할 수 있는 방법

Office 365에 대한 로그온만 사용하려는 경우에는 AD FS를 배포하는 대신 다른 방법을 사용할 수 있습니다. 이러한 경우에는 온-프레미스에서 암호 동기화를 사용하는 DirSync를 배포하면 복잡한 배포 작업은 최소화하면서 최종적으로는 같은 결과를 얻을 수 있습니다. 이 방식에서는 AD FS나 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는 사용자를 Azure AD로 리디렉션합니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

추가로 생각할 문제

  • Azure 가상 컴퓨터에서 AD FS 프록시를 배포하는 경우에는 AD FS 서버에 연결해야 합니다. AD FS 서버가 온-프레미스에 있는 경우 웹 응용 프로그램 프록시 노드가 AD FS 서버와 통신할 수 있도록 가상 네트워크에서 제공하는 사이트 간 VPN 연결을 활용하는 것이 좋습니다.

  • Azure 가상 컴퓨터에서 AD FS 서버를 배포하는 경우에는 Windows Server Active Directory 도메인 컨트롤러, 특성 저장소 및 구성 데이터베이스에 연결해야 하며 Azure 가상 네트워크와 온-프레미스 네트워크 간의 사이트 간 VPN 연결 또는 Express 경로도 필요할 수 있습니다.

  • Azure 가상 컴퓨터로부터의 모든 트래픽(송신 트래픽)에 요금이 부과됩니다. 비용이 주요 요인인 경우 웹 응용 프로그램 프록시 노드를 Azure에 배포하고 AD FS 서버는 온-프레미스에 유지하는 것이 좋습니다. AD FS 서버도 Azure 가상 컴퓨터에 배포하면 온-프레미스 사용자를 인증하기 위한 추가 비용이 발생합니다. Express 경로를 통과하는지 아니면 VPN 사이트 간 연결을 통과하는지에 관계없이 송신 트래픽에 대해서는 비용이 발생합니다.

  • AD FS 서버의 고가용성을 위해 Azure의 기본 서버 부하 분산 기능을 사용하기로 결정하는 경우 부하 분산에서는 클라우드 서비스 내에서 가상 컴퓨터의 상태를 확인하는 데 사용되는 프로브가 제공됩니다. 웹 또는 작업자 역할과 달리 Azure 가상 컴퓨터에서는 기본 프로브에 응답하는 에이전트가 Azure 가상 컴퓨터에 없으므로 사용자 지정 프로브를 사용해야 합니다. 작업을 간단하게 수행하려는 경우에는 사용자 지정 TCP 프로브를 사용할 수 있습니다. 이 경우 가상 컴퓨터 상태를 확인하기 위해 TCP 연결(TCP SYN ACK 세그먼트를 사용하여 TCP SYN 세그먼트를 전송하고 응답을 받음)만 정상적으로 설정되면 됩니다. 가상 컴퓨터에서 실제로 수신 대기하는 TCP 포트를 사용하도록 사용자 지정 프로브를 구성할 수 있습니다. 이렇게 하려면 부하 분산된 집합 구성을 참조하세요.

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

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

클라우드 전용 AD DS 배포

그림 1

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

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

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

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

  • IP 주소 지정 및 DNS:

    • Set-AzureStaticVNetIP Azure PowerShell cmdlet을 사용하여 DC의 고정 IP 주소를 설정합니다.

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

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

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

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

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

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

그림 2

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

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

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

    note참고
    각각의 Windows Server AD FS 인증서에 대해 인증서 템플릿 내에 정의된 URL과 생성된 인증서가 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 내부 데이터베이스)를 사용하는 것을 고려할 수도 있으며, Azure의 내부 부하 분산 기능을 사용하여 들어오는 요청을 팜의 서버들에 분산시킬 수도 있습니다.

    자세한 내용은 AD FS 배포 가이드를 참조하세요.

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

그림 3

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

  • 네트워크 토폴로지: 크로스-프레미스 연결이 포함된 Azure 가상 네트워크를 만듭니다.

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

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

  • IP 주소 지정 및 DNS:

    • Set-AzureStaticVNetIP Azure PowerShell cmdlet을 사용하여 DC의 고정 IP 주소를 설정합니다.

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

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

  • 지리적으로 분산된 DC: 필요에 따라 추가 가상 네트워크를 구성합니다. Active Directory 사이트 토폴로지에 따라 서로 다른 Azure 지역에 해당하는 지역에 DC가 있어야 하는 경우 그에 따라 Active Directory 사이트를 만들 수 있습니다.

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

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

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

  • Windows Server AD DS 데이터베이스 및 SYSVOL의 배치: Windows Server Active Directory 데이터베이스, 로그 및 SYSVOL을 저장하기 위해 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 사이트 토폴로지

트래픽을 최적화하고 비용을 최소화하기 위해 Azure 가상 네트워크를 사용하여 서브넷, 사이트 및 사이트 링크를 어떻게 구성합니까?

서브넷 및 사이트 정의

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

복제 압축

4

IP 주소 지정 및 DNS

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

Set-AzureStaticVNetIP cmdlet을 사용하여 고정 IP 주소를 할당합니다.

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

5

지리적으로 분산된 DC

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

Active Directory 사이트 토폴로지에 따라 서로 다른 Azure 지역에 해당하는 지역에 DC가 있어야 하는 경우 그에 따라 Active Directory 사이트를 만들 수 있습니다. 개별 VNet의 도메인 컨트롤러 간에 복제하도록 VNet 대 VNet 연결을 구성합니다.

6

읽기 전용 DC

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

HBI/PII 특성 필터링

암호 필터링

아웃바운드 트래픽 제한

7

글로벌 카탈로그

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

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

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

8

설치 방법

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

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

또는

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

9

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

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

Dcpromo.exe 기본값 변경

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

10

백업 및 복원

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

시스템 상태 백업 만들기

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

그러나 VM이 종료되면 동적 주소가 할당 취소됩니다. IP 주소가 할당 취소되지 않게 하려면 Set-AzureStaticVNetIP를 사용하여 고정 IP 주소를 할당(영문)할 수 있습니다.

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

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

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

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

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

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

  • 다중 사이트 내결함성

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

가상 네트워크 간의 직접 통신을 구성하는 방법에 대한 자세한 내용은 VNet 대 VNet 연결 구성을 참조하세요.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Azure 데이터 디스크의 호스트 캐시 기본 설정을 없음으로 설정합니다. 그러면 AD DS 작업에 대한 쓰기 캐시 문제가 방지됩니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

각 Azure 가상 컴퓨터는 DIP를 수신합니다. DIP는 Azure 내에서만 액세스할 수 있는 개인 주소입니다. 그러나 대부분의 경우 Windows Server AD FS 배포에 대해 VIP를 구성해야 합니다. VIP는 페더레이션된 파트너와 클라이언트가 인증과 지속적 관리를 위해 사용할 Windows Server AD FS 끝점을 인터넷에 노출하는 데 필요합니다. VIP는 Azure 가상 컴퓨터가 하나 이상 포함된 클라우드 서비스의 속성입니다. 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참고
Azure에서 Windows Server AD FS 끝점에 대한 부하 분산 기능을 사용하려면 동일한 클라우드 서비스에 있는 Windows Server AD FS 팜의 모든 멤버를 구성하고 HTTP 포트(기본값 80)와 HTTPS 포트(기본값 443)에 Azure의 부하 분산 기능을 사용합니다. 자세한 내용은 Azure 부하 분산 장치 프로브를 참조하십시오.

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

표시:
© 2014 Microsoft