dongclee

[Dongclee의 2013년 4월 첫 번째 번째 포스팅] “고급 보안이 포함된 Windows 방화벽(Windows Firewall with Advanced Security)”을 사용한 손 쉬운 Domain & Server Isolation 구현 Step-by-Step 가이드

2013-04-07T21:33:00Z

안녕하세요…. 이동철입니다.

4월 초인데 날씨가 오락가락 하네요,, 잠시 화창한 봄 날씨가 같더니,, 갑자기 비바람이 몰아치고, 누구의 마음같네요 ^-^

이 글을 쓰는 시점이 4월 초인데,, 지난 3월 말에 대한민국을 강타했던 대형 보안 사고가 터졌던 사실을 여러분들도 모두 아실 겁니다. 뭐 늘 보안을 강조하고 나름대로 기업에서 보안을 강화하고 있지만, 늘 부족한 것이 현실이지요,, 그래서 제가 이런 보안 강화를 위한 이번 블로그를 포스팅하고 있지만, 실제 보안 사고는 늘 주변에서 도사리고 있습니다. 그래도, 기업 IT 관리자 및 보안 관리자 입장에서는 보안을 최대한 신경 써야 하는 점이 숙명입니다.

이번 보안 사고를 보면서, Windows Vista 以後의 운영체제를 사용하고 있는 고객이라면, 기본적으로 제공되는 “고급 보안이 포함된 Windows 방화벽(Windows Firewall with Advanced Security)” 도구를 사용했으면, 그나마 외부 허가되지 않고 인증되지 않은 컴퓨터들부터 내부 컴퓨터를 보호할 수 있을 것으로 생각됩니다. 물론, 내부 컴퓨터에 연결된 이동 저장 장치를 통한 바이러스 침투는 “고급 보안이 포함된 Windows 방화벽”이 막을 수 없고, 이러한 침투 경로는 PC 바이러스 제품으로 보호해야 할 것입니다. 다만, “고급 보안이 포함된 Windows 방화벽” 기능을 사용하면, 외부의 허가되지 않고, 인증되지 않은 컴퓨터로부터 내부 컴퓨터로의 네트워크 연결을 事前에 차단할 수 있습니다. 다만, 이러한 내부 컴퓨터라는 정의는 기본적으로 Active Directory 내의 죠인된 클라이언트 및 서버 컴퓨터라는 제약 사항이 있습니다. Active Directory 내의 죠인된 멤버 컴퓨터들 사이에서 IPsec 통신을 사용하여 안전한 네트워크를 수행하는 기법을 “Domain Isolation” 이라고 합니다. 즉, Active Directory 내의 컴퓨터가 아닌 외부 컴퓨터들이 죠인된 멤버 컴퓨터들과 물리적으로 동일한 네트워크 대역에 연결되었을 경우에도, 실제 죠인된 멤버 컴퓨터들과 IP 수준의 네트워크 통신을 수행할 수 없습니다. 이러한 Domain Isolation 기법을 사용하면, 허가되지 않고 인증되지 않은 외부 컴퓨터들이 내부 컴퓨터들에 연결할 수 없어, 일차적으로 보안을 강화할 수 있습니다. 이미 아래 링크의 블로그에서 IPsec Service 및 Agent를 사용한 Domain Isolation 및 Server Isolation을 구현하는 방법을 설명해 드렸습니다.

[Dongclee의 2011년 9월 첫 번째 번째 포스팅] IPsec을 이용한 Domain & Server Isolation 방법 ( http://blogs.technet.com/b/dongclee/archive/2011/09/30/dongclee-2011-9-ipsec-domain-amp-server-isolation.aspx )

그러나, 위 링크의 IPsec Service 및 Agent를 사용하여 Domain Isolation 및 Server Isolation을 구현하는 방법은 굉장히 복잡하고 어려운 작업입니다.

이러한 IPsec을 통한 Domain Isolation 및 Server Isolation을 구현하는 방법의 단점을 해결한 기능이 바로 “고급 보안이 포함된 Windows 방화벽”입니다. 고급 보안이 포함된 Windows 방화벽은 호스트-기반 방화벽과 IPsec 구현이 결합된 신규 기능입니다. 또한, 고급 보안이 포함된 Windows 방화벽은 IPsec 기반의 연결 보안 규칙을 생성할 수 있는 신규 기능도 제공합니다. IPsec 기반의 연결 보안 규칙은 컴퓨터 인증, 데이터 무결 및 데이터 기밀과 같은 중요 보안 기능을 제공합니다. 즉, “고급 보안이 포함된 Windows 방화벽”은 IPsec과 호스트-기반 방화벽이 결합된 기능이므로, 이제 더 이상 IPsec을 구현하기 위하여 복잡한 그룹 정책이 아니라, “고급 보안이 포함된 Windows 방화벽” 기반의 단순한 그룹 정책을 사용하여 손 쉽게 IPsec 통신을 구현할 수 있습니다. 특히, “고급 보안이 포함된 Windows 방화벽”은 Active Directory내에서 그룹 정책을 통하여 중앙에서 제어가 가능하므로, 로컬 컴퓨터 관리자의 방화벽 규칙 변경도 제어할 수 있는 장점이 있습니다. “고급 보안이 포함된 Windows 방화벽”의 여러 가지 기능 중에서, 본 블로그의 첨부 문서에 다룬 내용은 아래와 같습니다.

기본 인바운드 및 아웃바운드 방화벽 규칙을 설정하기 위하여 고급 보안이 포함된 Windows 방화벽을 사용합니다. 아래 그림은, TCP 포트 23에만 인바운드 네트워크 트래픽이 허용되도록 제한하는 Telnet 예외 규칙을 생성하는 개략적인 구성도입니다.
도메인 내의 모든 컴퓨터에 방화벽 설정을 구성하기 위하여 그룹 정책 개체을 생성하였고, 사용자 계정들이 이러한 도메인 수준의 방화벽 설정을 override 할 수 없음을 확인했습니다. 아래 그림은 그룹 정책에서 도메인 프로필 속성에서 로컬 컴퓨터에서 방화벽 생성을 금지하는 설정입니다.
도메인 멤버가 아닌 컴퓨터들이 도메인 멤버 컴퓨터들에 접근하지 못 하도록 제한하는 기본 Domain Isolation 규칙 집합을 생성했습니다. 아래 그림은 도메인 멤버 서버 및 클라이언트 컴퓨터들이 인증되고 허가된 IPsec 터널을 통해 안전하게 Telnet 통신을 하는 예제입니다.
승인된 그룹의 구성원인 도메인 컴퓨터들만이 민감한 정보를 소유한 서버에 접근할 수 있도록 연결 보안 규칙을 생성했습니다. 이러한 연결 보안 규칙은 Server Isolation을 구성하는 주요 방법입니다. 아래 그림은 특정 그룹의 구성원인 도메인 사용자만이 특정 서버에 연결할 수 있는 Server Isolation을 구현한 예제입니다. 즉, CORP\User1 사용자만이 WFASSVR1 서버의 Telnet에 IPsec 터널을 통해 안전하게 Telnet 통신을 연결할 수 있습니다.

특정 신뢰된 컴퓨터들이 도메인 수준의 차단 방화벽 규칙을 무시하도록 “차단 규칙 무시” 설정을 포함한 방화벽 규칙을 생성했습니다. 즉, “차단 규칙 무시” 설정을 포함한 방화벽 허용 규칙은 동일 트래픽에 대해서 차단 규칙에 우선하여 허용 규칙이 적용됩니다. 아래 그림은 Telnet 차단 규칙을 우선하여 Telnet 허용 규칙이 적용되는 예제입니다. 아래 그림 중앙 하단 부분에 “차단 규칙 무시”라는 설정을 확인할 수 있습니다. 즉, Telnet 허용 규칙의 속성에서 동일 트래픽의 차단 규칙을 무시하는 설정을 수행함으로써, Telnet 차단 규칙을 무시하고, Telnet 허용 규칙이 우선 적용됩니다.
마지막으로, IPsec 터널 모드를 구성하여, 공용 네트워크 상의 클라이언트가 내부 네트워크에 IPsec 터널을 통해 안전하게 접근할 수 있는 방법을 확인합니다. 공용 네트워크 대역에 존재하는 CLIENT1W8(131.107.0.201)에서, 특정 네트워크 주소(10.0.0.x 사설 네트워크 대역)를 목적지로 하는 네트워크 트래픽은 IPsec을 통해 보호되고, 이 IPsec 트래픽은 기본 게이트 서버(131.107.0.200 : WFASSVR1 서버의 공용 네트워크 어댑터 주소)로 라우팅됩니다. 라우팅된 IPsec 네트워크 트래픽은 해독되어 plaintext 트래픽 상태로 목적지 서버(10.0.0.1 : DC1)에 전송됩니다.

이상과 같이 본 가이드의 대표적인 내용을 개략적으로 소개해 드렸습니다. 본 가이드에서는 위 대표적인 내용이외에도 다양한 시나리오에 기반한 구현 방법을 소개해 드렸습니다. 이러한 시나리오를 여러분들의 사정에 맞게 좀 더 수정하여 사용하신다면, 훌륭한 보안 강화 방안이 될 것으로 생각됩니다.

여러분들 오늘 블로그는 내용이 좀 길었네요..

다음 번 포스팅까지 모두들 건강하게 잘 지내세요

[Dongclee의 2013년 3월 첫 번째 포스팅] Windows Assessment and Deployment Kit을 활용한 부팅 성능 개선을 위한 분석 방법 Step-By-Step 가이드

2013-03-09T07:58:12Z

안녕하세요… 이동철입니다. 지난 2월 포스팅할 시점에 엄청 눈이 왔었는데, 3월 포스팅하는 이 시점에 보니,, 낮 기온이 20도 가까이 올라갔네요,, 역시 세월은 변함없이 흘러가네요 ^-^

토요일 오후 날씨 너무 좋습니다. 이런 날씨에는 전망 좋은 산에 올라가서 호연지기를 키우는 게 제격인데,,, 여러분들 바깥 공기 좀 쐬세요…

오늘 소개할 내용은 사실 제 전문 분야는 아닙니다. 저는 Windows 서버 운영 체제의 효과적인 활용을 위한 설치 및 구성이 전문 분야인데,,, 가끔 성능 데이터 분석이 필요할 때가 있는데, 그 때마다 제 한계를 느끼죠,,, 그런데, 제가 최근에 아주 좋은 성능 분석 도구를 하나 발견했어요,,, 저 같은 성능 분석 비전문가도 이 도구를 활용하면 어느 정도 수준의 성능 분석을 할 수 있습니다. 그리고, 성능 분석을 위해서 반드시 필요한 과정이 정확한 데이터 수집인데, 이 또한 비전문가에게는 어렵고도 힘든 일입니다. 그러나, 이 도구는 정형화된 다양한 스크립트를 미리 제공하여, 데이터 수집의 평이성도 제공합니다. 그럼 과연 이 도구는 무엇일까요? 바로 아래 도구입니다.

Windows Assessment and Deployment Kit (ADK) for Windows® 8 ( http://www.microsoft.com/en-us/download/details.aspx?id=30652 )

Windows ADK는 무료로 제공되는 도구이고, Microsoft 다운로드 사이트에서 다운로드 받을 수 있습니다. 이 도구는 기본적으로 아래와 같은 구성 요소를 포함합니다.

“Windows 평가 서비스” 구성 요소는 바로 앞서 언급한 데이터 수집을 위한 다양한 스크립트를 사전에 제공합니다. 아래 그림이 “Windows 평가 서비스”에서 제공하는 다양한 시나리오를 기반으로 한 데이터 스크립트의 GUI 화면입니다. 즉, 아래 그림과 같이 다양한 시나리오에 대해서 사전에 필요한 성능 데이터 항목을 정의한 스크립트를 Windows 평가 서비스 도구에서 제공합니다.

“배포 도구” 및 “Windows 사전 설치 환경(Windows PE)” 구성 요소는 성능 수집 시에 표준(Baseline) 컴퓨터를 자동으로 배포하기 위한 도구입니다. 이 도구를 사용하여 원격으로 표준(Baseline) 컴퓨터를 자동으로 생성할 수 있습니다. 표준(Baseline) 컴퓨터를 자동으로 배포하기 위해서는 실제 물리적인 컴퓨터는 PXE 부팅이 가능한 PC이어야 합니다. 또한, 事前에 WDS 및 DHCP 인프라가 동일 네트워크에 구축되어 있어야 합니다.

본 포스팅에서는 Windows ADK 도구에서 제공하는 다양한 성능 분석 시나리오 중에서, 클라이언트 PC의 부팅 속도의 개선을 위한 방법을 소개합니다. 본 데모 환경에서는 아래와 같은 단계로 진행됩니다.

Windows ADK 설치 및 구성
Windows ADK의 자동화 스크립트, WDS 및 Windows PE를 활용하여, 표준 이미지를 표준(Baseline) 컴퓨터에 설치하는 과정을 자동화
Windows 평가 서비스의 스크립트를 사용하여, 표준 이미지가 적용된 표준 컴퓨터에서 표준 부팅 성능 데이터 수집을 자동화
Windows 평가 서비스의 스크립트를 사용하여, 부팅 속도가 느린 문제 컴퓨터에서 부팅 성능 데이터 수집을 자동화
표준 부팅 성능 데이터 와 느린 부팅 성능 데이터를 비교 분석하는 과정을 통해 문제 원인 파악 및 해결

위 5단계를 수행하게 되면, 부팅 속도가 느린 컴퓨터의 원인을 손 쉽게 파악할 수 있습니다. 물론, 본 포스팅을 완벽하게 수행하고 이해한 후, 모든 부팅 성능 데이터를 완벽하게 파악할 수는 없을 수도 있습니다. 다만, 이 과정을 통해 데이터 수집 및 분석 방법을 습득하고, 다른 성능 데이터 수집 및 분석을 위한 기초 단계로 이해하셨으면 합니다.

본 데모 환경은 아래 그림과 같습니다.

본 포스팅을 하면서, 혹시라도 전문가께서 이 포스팅을 보시면, 제가 잘 못 전달한 내용이 많다는 것을 바로 아실 수 있을 겁니다. 괜찮으시면, 전문가께서는 제 포스팅에 대해서 잘못된 내용을 바로 지적해 주시면 더욱 감사하겠습니다.

다음 번 포스팅에서 찾아뵙겠습니다.

감사합니다.

[Dongclee의 2013년 2월 첫 번째 포스팅] Windows Server 2012 Series 20 : Volume Activation 서비스 역할의 Step-by-Step 가이드

2013-02-04T16:40:00Z

안녕하세요,,, 이동철입니다.

2월 초인데 엄청 눈이 내렸네요… 나이 먹으니 눈 많이 오는 것도 싫네요. 여러분들 길 미끄러우니 조심들 하세요.

오늘 여러분들에게 소개해 드릴 내용은 지난 1월에 잠시 건너 뛰었던 Windows Server 2012의 신규 기능 중의 하나인 “볼륨 정품 인증 서비스” 역할입니다. “볼륨 정품 인증 서비스”에 대한 개략적인 설명은 아래와 같습니다.

사실 “볼륨 정품 인증 서비스”는 이미 “VAMT(Volume Activation Management Tool)” 도구를 통하여 제공되었던 기능입니다. 볼륨 라이선스 미디어로 설치된 Windows 기반 OS 들의 정품 인증을 위하여, Windows Server 2012 및 Windows 8 以前 환경에서는 VAMT(Volume Activation Management Tool)을 사용하여 KMS 호스트를 구축했습니다. 그러나, KMS 호스트 기반의 정품 인증은 최소 정품 인증 클라이언트 개수(25개)가 네트워크 上에 존재해야만, 정품 인증이 진행되는 등 몇 가지 단점이 있었습니다. 그러나, Windows Server 2012에서 “볼륨 정품 인증 서비스” 를 역할로써 제공합니다. 즉, 정품 인증만을 위해서, 별도의 VAMT를 다운로드 받지 않고도, “볼륨 정품 인증 서비스” 역할을 설치 및 구성하여 볼륨 정품 인증을 구성할 수 있습니다. 또한, 旣存 KMS 호스트 정품 인증 방식 이외에, 신규로 Active Directory 기반 정품 인증 방식을 지원합니다. Active Directory 기반 정품 인증은 최소 1개의 클라이언트만 존재해도 정품 인증을 진행할 수 있는 장점이 있고, 정품 인증 개체를 Active Directory에 저장하는 장점도 제공합니다.

그럼 이제 “볼륨 정품 인증 서비스”의 3가지 방식을 간단하게 소개해 드리겠습니다.

Active Directory 기반 정품 인증 방법

Active Directory 기반 정품 인증은 정품 인증 개체를 저장하기 위하여 AD DS(Active Directory 도메인 서비스)를 사용하는 Windows Server 2012 역할 서비스입니다. Active Directory 기반 정품 인증 방법은 볼륨 정품 인증 서비스 유지 관리 작업을 크게 단순화할 수 있습니다. Active Directory 기반 정품 인증 방법은 Windows Server 2012에서 신규로 소개된 역할 서비스입니다. Active Directory 기반 정품 인증을 사용하면, KMS 클라이언트 설정 키(GVLK)를 소유한 Windows 8 또는 Windows Server 2012 도메인 컴퓨터는 사용자 개입 없이 자동으로 정품 인증 작업이 수행됩니다. 이러한 클라이언트는 도메인 구성원으로 유지되면, 지속적으로 정품 인증될 것이며 도메인 컨트롤러와 정기적으로 연결 상태를 유지할 것입니다. 정품 인증은 “소프트웨어 보호 서비스(Software Protection Service)”가 시작된 이후에 실행됩니다. 소프트웨어 보호 서비스가 시작되면, Windows 8 또는 Windows Server 2012를 실행하는 컴퓨터는 AD DS에 자동으로 연결하고, 정품 인증 개체를 수신하고, 사용자 개입 없이 정품 인증이 수행됩니다.

KMS 정품 인증 방법

Windows 8 및 Windows Server 2012 以前 버전의 OS에 대한 정품 인증을 위해서 반드시 KMS 호스트를 구축해야 합니다. KMS 호스트를 위한 전용 서버는 반드시 필요하지 않고, KMS는 다른 서비스와 함께 단일 서버에 존재할 수도 있습니다. KMS 호스트는 Windows Server 2012, Windows 8, Windows Server 2008 R2, Windows Server 2008, Windows 7 또는 Windows Vista SP1이나 SP2를 실행하는 모든 물리적 또는 가상 시스템에서 실행할 수 있습니다. Windows 8, Windows 7 또는 Windows Vista에서 실행되는 KMS 호스트는 클라이언트 운영 체제를 실행하는 컴퓨터만을 정품 인증할 수 있습니다. 다음 표는 Windows Server 2012 및 Windows 8 클라이언트를 포함하는 인프라를 위한 KMS 호스트 및 클라이언트 요구 사항에 대한 요약입니다.

MAK 정품 인증 방법

MAK는 마이크로소프트가 직접 운영하는 정품 인증 서비스로써, 일회성 정품 인증을 지원합니다. 각 MAK 키에는 허용된 정품 인증 횟수가 미리 정해져 있습니다. 횟수는 볼륨 라이선스 계약에 의해 제한되며, 조직의 정확한 라이선스 개수와는 일치하지 않습니다. MAK를 사용한 각 정품 인증은 정품 인증 제한 개수까지 카운트합니다. MAK 정품 인증은 회사 네트워크에 자주 또는 전혀 연결하지 않는 컴퓨터에 권장되며, 정품 인증이 필요한 물리적 컴퓨터 수량이 KMS 정품 인증 임계 값에 맞지 않는 환경에서 권장됩니다.

본 데모 환경에서는 “Active Directory 기반 정품 인증” 및 “KMS 정품 인증” 방법 2개에 대한 step-by-step 가이드를 제공합니다. 기본적인 데모 환경은 아래와 같습니다.

또한, 본 문서에는 “볼륨 정품 인증 서비스” 구현을 위해 사전에 고려해야 할 클라이언트 유형, 조직 내의 네트워크 특성에 대해서도 언급하였으므로, 여러분들께서는 이러한 고려 사항을 숙지하셔야 여러분들 조직에 맞는 “정품 인증 서비스” 인프라를 구성해야 합니다.

여러분들 아직 날씨가 쌀쌀합니다. 건강에 유의하세요.

P.S.) 참고로 이번 포스팅의 첨부 문서는 상당 부분 Technet 한글 자료를 차용했고, 제가 설명 및 스크린샷을 추가했음을 미리 알려 드립니다. 이 점 양해해 주세요 ^-^

[Dongclee의 2013년 1월 첫 번째 포스팅] RDP 프로토콜의 보안 강화 방안 : NLA, CredSSP, SSL/TLS 등의 상관 관계는 무엇일까요…

2013-01-23T08:51:25Z

안녕하세요.

계사년(癸巳年) 새해가 밝았습니다. 새해 인사가 너무 늦었죠,,, 제가 1월도 포스팅이 너무 늦었네요,, 늘 반성하고 다시 각오를 다져봅니다.^-^

오늘 말씀드릴 주제는 바로 “RDP 프로토콜의 보안 강화 방안”입니다. 사실 이 주제는 예전부터 제가 정리를 한 번 할려고 했는데, 제 주변의 동료가 문의를 해 와서 이번 기회에 정리를 하게 되었네요….

RDP는 Windows Server 2000 이후로 제공되는 윈도우 서버의 원격 접근을 가능하게 해 주는 프로토콜입니다. 그런데, RDP 클라이언트와 RDP 서버 사이의 네트워크 트래픽 보안성이 사용자 입장에서 늘 걱정이었습니다. 대표적으로 RDP 프로토콜은 “MITM(Man-In-The-Middle)” 공격에 취약한 부분이 존재하고 있는 것이 사실입니다. 아래 그림은 MITM 공격의 한 예제 그림입니다.

즉, 위 그림과 같이 공격자가 원본 연결이 아닌 가공의 연결을 중간에 설정하여 RDP 클라이언트와 RDP 서버 사이의 데이터를 위변조 할 수 있는 취약성이 존재합니다.

이러한 MITM 공격으로 부터 RDP 프로토콜을 보호하기 위한 방안은 대표적으로 아래와 같이 총 4개 정도의 방법이 존재합니다.

Network Level Authentication (NLA)
Pure SSL/TLS
네트워크 레벨의 보안 강화 (ex, IPSec)
VPN 터널링

위 4가지 방법 중에서 NLA 및 Pure SSL/TLS 방법이 Windows Server 2003 R2, 2008, 2008 R2, 2012 의 RDP 자체에서 구현할 수 있는 가장 최적의 방안입니다. 나머지 IPSec 및 VPN은 별도의 서버 및 구현 기술이 필요하므로, 사실 운영자 입장에서는 고려 대상이 아닐 수도 있지만, 일단 RDP 프로토콜의 MITM 공격을 예방할 수 있는 방안이 될 수도 있습니다.

아래 표는 NLA 및 Pure SSL/TLS의 구성 가능한 서버 범위 및 실제 접근 가능한 클라이언트 OS를 정리한 표입니다.

서버가 Windows Server 2008 이후 버전이라면, NLA를 반드시 사용하는 것이 RDP 프로토콜의 보안 강화의 가장 적합한 방법입니다. NLA의 특징은 아래와 같습니다.

네트워크 수준 인증은 사용자가 세션을 만들기 전에 RD 세션 호스트 서버에 인증하도록 요구함으로써 RD 세션 호스트 서버 보안을 강화하는 데 사용할 수 있는 인증 방법입니다.
네트워크 수준 인증은 원격 데스크톱 연결을 설정하고 로그온 화면이 나타나기 전(前)에 사용자 인증을 완료합니다. 이는 보다 안전한 인증 방법으로, 악의적인 사용자와 악성 소프트웨어로부터 원격 컴퓨터를 보호하는 데 도움이 됩니다. 네트워크 수준 인증의 이점은 다음과 같습니다.
초기에 필요한 원격 컴퓨터 리소스가 더 적습니다. 원격 컴퓨터는 이전 버전에서처럼 전체 원격 데스크톱 연결을 시작하는 대신 사용자를 인증하기 전에 제한된 수의 리소스를 사용합니다.
DoS(서비스 거부) 공격의 위험을 줄임으로써 보안 향상에 도움을 줄 수 있습니다.

실제 NLA 인증 방법을 구현하는 프로토콜은 Microsoft CredSSP 입니다. Microsoft CredSSP 프로토콜의 특징은 아래와 같습니다.

CredSSP는 RDP 클라이언트와 RDP 서버 사이의 암호화된 채널을 형성하기 위해 TLS(TransportLayer Security)를 사용합니다. 암호화된 채널로써 TLS 연결을 사용하게 되면, TLS에서 가용한 클라이언트/서버 인증서비스 뿐만 아니라, 신분(Identity)을 검증할 수도 있습니다. CredSSP 프로토콜은 GSS(Generic Security Services) 메커니즘을 협상하기 위해 SPNEGO(Simple and Protected Generic Security Service Application Program Interface Negotiation Mechanism) 프로토콜 확장을 사용합니다. TLS 채널에 안전하게 바인딩 및 RDP 목적 서버의 Credential을 암호화하기 위해, GSS 메커니즘은 상호 인증 및 GSS 비밀 서비스를 수행합니다. 모든 GSS 보안 토큰은 암호화된 TLS 채널을 통하여 전송됩니다. 이러한 토큰의 종류는 NTLM, Kerberos 또는 PKI 인증 등이 있습니다.

NLA는 RDP 서버와 RDP 클라이언트의 상황에 따라, NLA with Kerberos, NLA with NTLM 및 NLA with SSL/TLS 인증 방법이 사용됩니다, 좀 더 자세한 사항은 본문을 참조하시면 될 것 같습니다.

본 문서에서는 Active Directory Certificate Service 인프라를 사용하여, RDP 전용 인증서 구성 및 설치를 그룹 정책을 통해 진행할 수 있는 방법을 step-by-step으로 제공합니다. 데모 환경은 아래와 같습니다.

여러분들,,, 이제 무의식적으로 RDP 프로토콜을 허술하게 사용하지 마시고, NLA 또는 Pure SSL/TLS 를 RDP 프로토콜에 바인당하여 좀 더 안전하게 RDP 프로토콜을 사용하세요…

2월 포스팅에서 다시 찾아뵙겠습니다. 여러분들 건강 조심하세요.

아참 첨부 문서의 Appendix 항목은 약간의 영어가 존재함을 양해해 주세용 ^-^

[Dongclee의 2012년 12월 첫 번째 포스팅] Windows Server 2012 Series 19 : Active Directory Rights Management Services 간단 Step-by-Step 가이드

2012-12-19T06:04:24Z

이동철입니다.

이 글을 올리고 있는 현재 지금 12월 19일 역사적인 18대 대선 투표일입니다. 저도 막 한 표 행사하고 지금 돌아와서 포스팅 하고 있습니다. 제가 투표한 후보가 당선되어 좀 더 상식적이고 공정한 대한민국이 되기를 기원합니다.

오늘 제가 포스팅할 내용은 AD RMS 입니다. AD RMS는 이미 Windows Server 2003 부터 add-on으로 지원하기 시작한, Microsoft 사의 유일한 문서 보안 솔루션입니다. 국내의 M 모사, F 모사, S 모사 등이 대표적인 문서 보안 솔루션 업체들인데, 이 업체들이 제공하는 문서 보안 솔루션을 Windows Server 에서도 지원합니다. Windows Server 2008 부터는 AD RMS 라는 이름으로 제공되는 “역할” 중의 하나입니다. 기존의 Windows Server 2008 AD RMS에 대한 내용은 아래 제 블로그를 참조하시면 될 것 같습니다.

[Dongclee의 2011년 3월 2번째 포스팅 : 다른 조직의 ADRMS를 사용할 수 있는 최상의 방안은? ADFS + ADRMS ( http://blogs.technet.com/b/dongclee/archive/2011/03/28/dongclee-2011-3-2-adrms-adfs-adrms.aspx )
[Dongclee의 12월 포스팅] Windows 2003 기반의 RMS 를 AD RMS R2의 마이그레이션 어떻게 할까요? ( http://blogs.technet.com/b/dongclee/archive/2010/12/09/dongclee-12-windows-2003-rms-ad-rms-r2.aspx )
[Dongclee 의 두 번째 posting] Windows Server 2008 R2 AD RMS 와 Exchange2010 , SharePoint2010 통합 Step-by-Step 가이드 ( http://blogs.technet.com/b/dongclee/archive/2010/09/29/dongclee-posting-windows-server-2008-r2-ad-rms-exchange2010-sharepoint2010-step-by-step.aspx )

Windows Server 2012 AD RMS는 기본적으로 Windows Server 2008 AD RMS와 크게 다른 점은 없어 보입니다. 다만, Windows Server 2012 AD RMS의 “암호화 모드”는 기본적으로 “2 (RSA 2048)”를 선택할 수 있습니다. 물론, Windows Server 2012 AD RMS의 “암호화 모드”를 “1 (RSA 1024)”도 선택할 수 있습니다. “암호화 모드”의 가장 중요한 점은 암호화에 사용되는 키의 비트 길이입니다. 비트 길이가 길수록 보안은 더 강화되는 것은 당연한 일이겠죠?

만약, Windows Server 2012 AD RMS의 “암호화 모드”를 “2”로 선택한다면, 아래와 같은 클라이언트 OS가 AD RMS를 사용할 수 있습니다. 즉, 아래 각 AD RMS 클라이언트 OS에 필요한 핫픽스를 설치해야 합니다. 특히, Windows XP 클라이언트는 절대 “암호화 모드” “2”를 지원하지 않음을 절대 유의해야 합니다.

For Windows Vista SP2-based RMS client computers, install the hotfix that is described in KB article 2627272
For Windows Server 2008-based (with SP2 )RMS client computers, install the hotfix that is described in KB article 2627272
For Windows 7 SP1-based RMS client computers or for Windows Server 2008 R2 SP1-based RMS client computers, install the hotfix that is described in KB article 2627273
For Windows Server 2008 R2 SP1-based RMS server computers, install the hotfix that is described in KB article 2627272

물론, Windows Server 2012 AD RMS의 “암호화 모드”를 “1”로 선택한다면, Windows XP 클라이언트가 지원됩니다. 아래 그림은 Windows Server 2012 AD RMS의 구성 시에, “암호화 모드”를 지정하는 화면입니다.

본 데모 환경에서는, AD RMS 클러스터를 구성하기 위해, 총 2대의 RMS 서버를 구성하였고, 이 2대의 부하 분산을 위해 Windows Server 2012 네트워크 부하 분산(NLB) 기능을 구성하였습니다. 또한, AD RMS의 구성 데이터베이스는 외부의 SQL 서버에 구성하였습니다. 아래는 기본적인 데모 환경입니다.

올 한 해도 이제 거의 다 가고 있네요. 제가 올 초에 매달 한 개 이상의 글을 포스팅하기로 제 자신에 약속했는데, 이 점을 지킨 것 같아 제 스스로 좀 뿌듯하네요 ^-^

여러분들로 올 한해 잘 마무리하시고, 내년에 계획 잘 세우시기를 기원합니다.

Merry Christmas & Happy New Year

[Dongclee의 2012년 11월 첫 번째 포스팅] Windows Server 2012 Series 18 : Remote Access 서비스의 A to G Step-by-Step 가이드

2012-11-28T16:49:46Z

안녕하세요… 이동철입니다.

11월이 거의 끝나가는 29일 새벽입니다. 점차 게을러지는 제 모습을 보면서 이젠 서서히 제 능력의 딸림을 느끼게 됩니다. 12월에는 정말 최대한 빨리 좋은 포스팅을 하겠습니다.

오늘 여러분들에게 소개해 드릴 내용은 Windows Server 2012 Remote Service에 대한 A to G 입니다. A to G 로 제가 정한 이유는 Remote Access 서비스의 전체 내용을 모두 소개하지는 못 해서 추후 포스팅을 염두에 둔 제목입니다. ^-^

Windows Server 2012 Remote Access 서비스는 바로 기존 OS의 DirectAccess 서비스와 RRAS 서비스를 결합한 것입니다. 실제 Windows Server 2012 Remote Access 역할을 선택하게 되면, “DirectAccess and VPN (RAS)” 및 “Routing” 2가지 역할 서비스를 선택할 수 있음을 확인할 수 있습니다.

기존 버전에 비해서 Windows Server 2012 Remote Access 서비스의 향상된 주요 기능은 아래와 같습니다.

DirectAccess 및 RRAS 공존 (共存)

DirectAccess 및 RRAS 는 적대적인 인바운드 트래픽으로 부터 서버를 보호하기 위한 보안 기능을 구현할 수 있습니다. Windows Server 2012 以前 버전에서는, DirectAccess 및 RRAS가 동일 서버에 존재한다면, 각각의 보안 기능을 방해합니다. 그러므로, 동일 서버에 2개의 서비스를 구성하게 되면, 각 서비스는 서로의 기능을 방해합니다. DirectAccess 서버와 클라이언트 연결을 위해, IPv6 변환(變換, transition) 기술을 사용합니다. 반면에, 보안을 강화하기 위해, RRAS는 IKEv2 (Internet Key Exchange v2) IPsec을 사용합니다. IKEv2 IPsec 기술은 IPv6 변환(變換, transition) 기술을 사용하는 모든 패킷을 차단하도록 incoming 및 outgoing 패킷 필터를 구성합니다. 즉, DirectAccess 구현을 위해 반드시 필요한 IPv6 변환(變換, transition) 패킷은 RRAS의 IKEv2에 의해 차단됩니다. 그러므로, Windows Server 2012 以前 버전에서는, DirectAccess 와 RRAS는 동일 서버에 공존할 수가 없습니다. DirectAccess는 회사 내부 네트워크의 자원을 보호하기 위해 IPsec DoSP (Denial of Service Proection)를 구현합니다. ICMPv6 패킷을 제외한, “IPsec에 의해 보호되지 않은 IPv6 트래픽” 및 “모든 IPv4 트래픽”을 DoSP는 차단합니다. 즉, RRAS에 의해 전달되는 non-IPsec IPv6 트래픽 및 모든 IPv4 트래픽은 DirectAccess에 의해 차단될 수 있습니다. Windows Server 2012 의 DirectAccess는 RRAS 트래픽을 허용하도록 IPsec DoSP 기능을 수정하였습니다. 또한, Windows Server 2012 RRAS는 IPv6 변환(變換, transition) 기술을 허용하도록 IKEv2 정책을 수정하였습니다. 즉, 이러한 기능 및 정책의 변경을 통해, DirectAccess 및 RRAS는 동일 서버에 공존할 수 있습니다.

DirectAccess 구성의 PKI 전제조건(前提條件) 제거

Windows 7 DirectAccess는 서버 및 클라이언트 인증서 기반 인증을 위해 반드시 PKI 환경이 필요합니다. 즉, PKI 환경이 Windows 7 DirectAccess 배포의 가장 큰 장애물이기도 했습니다. Windows Server 2012 DirectAccess에서, Kerberos 프록시 기반의 HTTPS를 구현함으로써 상호 인증 기능을 수행할 수 있습니다. 클라이언트 인증 요청은 DirectAccess 서버에서 수행되는 Kerberos 프록시 서비스에 보내집니다. Kerberos 프록시는 클라이언트 대신에 도메인 컨트롤러에 Kerberos 요청을 보냅니다.

내부 IPv4-only 자원 접근을 위한 NAT64 및 DNS64 지원

내부 IPv4-only 자원에 접근하기 위해서, DirectAccess 클라이언트의 IPv6 통신을 IPv4 통신으로 변경하기 위하여 Windows Server 2012 DirectAccess는 NAT64 및 DNS64 게이트웨이 기능을 지원합니다.

사용자 및 서버 상태 모니터링 (User 및 Server Health Monitoring)

RRAS 및 DirectAccess의 모니터링 및 진단 기능은 Windows Server 2008 R2에서는 극히 제약적이었습니다. DirectAccess를 위한 모니터링 기능은 DirectAccess 및 구성요소의 기본적인 상태 모니터링을 포함합니다. 가용한 모니터링 데이터 및 통계 정보는 관리자에게 약간 부족하고 분명하지 않습니다. Windows Server 2012에 소개된 사용자 및 서버 상태 모니터링 기능을 사용하여, 관리자는 DirectAccess 클라이언트 및 연결의 모든 상태 및 동작을 확인할 수 있습니다. 모니터링 콘솔은 DirectAccess 서버의 부하, 사용자 행위 및 현재 자원 사용률을 추적하기 위해 사용됩니다. 관리자는 이러한 정보를 사용하여 잠재적으로 원하지 않는 또는 적절하지 않은 사용 행태를 구분합니다. 진단 추적은 모니터링 콘솔에서 활성화할 수 있습니다.

본 포스팅에서는 기존 인트라넷 서버 환경이 IPv4 주소 만으로 구성되었을 경우, 외부 네트워크에서 별도의 VPN 연결 없이 내부 인트라넷 서버를 접근할 수 있는 DirectAccess 서버 및 기타 구성에 대한 Step-by-Step 을 소개합니다. DirectAccess를 위해 필요한 각종 기반 기술 및 IPv6 변환 기술등은 아래 링크를 참조하시기 바랍니다.

[Dongclee의 11월달 첫 번째 포스팅] IPv4 만을 지원하는 Legacy 서버 어플리케이션을 위한 Forefront UAG DirectAccess 구축 가이드 ( http://blogs.technet.com/b/dongclee/archive/2010/11/01/dongclee-11-ipv4-legacy-forefront-uag-directaccess.aspx )
[Dongclee 의 DirectAccess 에 관한 첫 번째 포스팅] IPv6 over IPv4 기술을 활용한 기존 VPN 대체 기술 ( http://blogs.technet.com/b/dongclee/archive/2010/10/13/dongclee-directaccess-ipv6-over-ipv4-vpn.aspx )
[Dongclee 의 IPv6 에 대한 첫 번째 포스팅] IPv6 over IPv4 기술의 이해를 위한 Windows 2008 기반의 ISATAP 라우터 구현하기 ( http://blogs.technet.com/b/dongclee/archive/2010/10/07/dongclee-ipv6-ipv6-over-ipv4-windows-2008-isatap.aspx )

기본적인 데모 환경은 아래와 같습니다.

본 가이드는 크게 Windows Server 2012 DirectAccess 서버가 Windows 8 클라이언트만을 지원하도록 구성하는 방법과 Windows 8 및 Windows 7 클라이언트를 동시에 지원할 수 있도록 구성하는 방법등 총 2가지 부분으로 나누어져 있습니다.

앞서, Windows Server 2012 Remote Access 서비스의 주요 기능으로써, DirectAccess 2012는 PKI 인프라가 필요 없음을 장점으로 소개했습니다. 그러나, 이 부분은 DirectAccess 클라이언트가 Windows 8 만이 있을 경우에도 가능한 부분입니다. 만약, Windows 7 클라이언트가 DirectAccess 클라이언트로 작동할려면, 반드시 PKI 인프라가 미리 구축되어 있어야 합니다. 여러분 이점 꼭 유념해 주시기를 바랍니다.

한 가지 양해의 말씀은 첨부 파일의 스크린샷 화면이 영어 OS 및 한글 OS로 혼재 되어 있음을 알려 드립니다.

저는 12월에 이번 포스팅 환경을 그대로 사용하여, DirectAccess 서버와 VPN 서버를 동시에 한 서버에 구축하는 내용을 소개할 예정입니다. 날씨가 급 추워지고 있습니다. 감기 조심하세요.

[Dongclee의 2012년 10월 첫 번째 포스팅] Windows Server 2012 Series 17 : 장애조치 클러스터의 New, Update 및 Remove 기능에 대한 모든 소개 및 Step-by-Step 가이드

2012-10-22T07:47:03Z

이동철입니다.

매월 첫 번째 주에는 블로그 포스팅을 할려고 마음 먹었는데,, 10월은 제 스스로의 약속을 지키지 못 하고 10월말 즈음에 포스팅하게 되네요….

지금 포스팅 글을 쓰는 날씨가 갑자기 차갑고 스산한 바람이 전형적인 늦가을 날씨네요,, 이럴땐 어디든 떠나야 하는데… 역시 사설이 길지요 ^-^

오늘 포스팅할 내용은 바로 Windows Server 2012 장애조치 클러스터에 대한 얘기입니다. 제가 以前 Windows Server 2012 시리즈 블로그에서 몇 차례 Windows Server 2012 장애조치 클러스터에 관해서 언급 및 실제 구축 가이드도 소개한 적이 있었습니다.

이번 포스팅에서는 Windows Server 2012 장애조치 클러스터에 관해서 총체적으로 새롭게 추가된 기능, 변경된 기능 및 향후 없어질 기능에 대해서 소개하고자 합니다. 물론, 장애조치 클러스터의 설치부터 각종 신규 기능의 데모에 대한 Step-by-Step 가이드도 소개해 드립니다.

대표적으로 Windows Server 2012 장애조치 클러스터에 신규 및 업그레이드 기능은 하나씩 살펴볼까요.

클러스터 확장성 : Windows Server 2012 장애조치 클러스터는 최대 64개 노드까지 원하고, 이러한 64개 노드에서 최대 8,000여개의 VM을 지원합니다.
서버 관리자 및 장애조치 클러스터 관리자를 사용한 대용량 클러스터 관리 : Windows Server 2012의 서버 관리자 및 장애조치 클러스터 관리자 도구는 다수의 클러스터 집합을 관리할 수 있는 기능을 신규로 제공합니다. 신규 서버 관리자는 클러스터 내의 노드들을 검색하고 관리할 수 있습니다. 즉, 관리자는 하나의 서버 관리자를 사용하여 클러스터 내의 모든 노드들을 검색하고, 등록한 후, 중앙 집중적으로 여러 서버를 관리할 수 있습니다. 또한, 서버 관리자 GUI 내에서 장애조치 클러스터 관리자를 수행할 수 있고, 원격 역할 및 기능 설치, 원격 다중 서버 관리등을 수행할 수 있습니다.
클러스터된 VM 및 기타 클러스터 역할의 관리 및 이동성 : Windows Server 2012 에서, 클러스터 워크로드를 처리하기 위한 자원을 효율적으로 할당하기 위해, 관리자는 VM 및 클러스터 역할의 시작 및 배치에 관한 우선 순위 같은 설정을 구성할 수 있습니다. 예를 들어, VDI 환경에서, VIP 전용 VM을 우선적으로 시작하고, 일반 VM을 순차적으로 시작하도록, VM들의 구동 순서를 지정할 수 있습니다. 또한, 특정 Hyper-V 호스트에서만 VIP 전용 VM들이 배치되도록 구성할 수도 있습니다.
CSV (Cluster Shared Volume) v2 : SMB 3.0 프토로콜을 사용한 대량으로 CSV 트래픽 처리가 가능하고, CSV 볼륨도 BitLocker 적용도 가능합니다. 또한, Windows Server 2012 저장�� 공간 기능과 통합하여 디스크 자원을 효율적으로 사용할 수 있습니다.
Scale-Out File Server 지원
Cluster-Aware 업데이트 : CAU는 클러스터 노드 내의 호스트 운영체제 또는 다른 시스템 구성 요소에 필요한 업데이트를 자동적으로 적용할 수 있는 자동화된 기능입니다. CAU는 업데이트가 진행되는 동안 여전히 클러스터 자원의 가용성을 자동적으로 유지할 수 있는 기능도 제공합니다. 이러한 기능은 업데이트 프로세스 동안에 각 노드의 자동화된 draining 및 failback을 제공합니다.
VM 어플리케이션 모니터링 및 관리 : Windows Server 2012 기반의 클러스터 환경에서, 관리자는 Windows Server 2012 기반의 클러스터 VM 내의 서비스를 모니터 할 수 있습니다. 이 신규 기능은 Windows Server 2008 R2 장애조치 클러스터 내에 구현된 VM의 고-단계 모니터링으로 확대할 수 있습니다. VM내의 서비스가 fail된다면, 서비스는 재시작 될 수 있거나, 클러스터 VM은 다른 노드로 이동 또는 다른 노드에서 재시작 될 것입니다
향상된 클러스터 검증 테스트 : 장애조치 클러스터 관리자내의 “Validate a Configuration” 마법사는 장애조치 클러스터 노드들에서 사용되는 하드웨어 및 소프트웨어 검증의 단계를 단순화합니다. 이러한 향상된 검증 테스트 단계는 대규모의 장애조치 클러스터 구성을 좀 더 빠르게 진행할 수 있도록 합니다.
Active Directory 도메인 서비스 통합 : Windows Server 2008 R2 장애조치 클러스터 환경에서는, 클러스터 관련 컴퓨터 객체의 생성 컨테이너는 “Computers” 컨테이너로 강제 지정되는 반면에, Windows Server 2012 장애조치 클러스터 환경에서는 클러스터 관련 컴퓨터 객체 생성 위치(ex, Container 또는 OU)를 관리자가 지정할 수 있습니다. 특정 OU에 생성된 클러스터 컴퓨터 객체는 AD 환경 내의 관리 권한 위임과 같은 기능을 활용하여 관리에 편이성을 제공할 수 있습니다. 또한, Windows Server 2012 장애조치 클러스터 서비스 시작은 이제 더 이상 도메인 사용자 계정을 필요로 하지 않습니다. 각 클러스터 노드 내의 로컬 시스템 계정을 사용하여 클러스터 서비스를 시작합니다.
쿼럼 구성 및 동적 쿼럼 : 노드의 상태(online 또는offline)에 기반하여, 쿼럼 결정에 참여하는 노드들이 자동적으로 관리됩니다. 노드가 셧다운 또는 크래시 되었을 때, 해당 노드에서 쿼럼 결정 투표 권한이 사라집니다. 쿼럼 결정 투표 권한이 자동적으로 수정됨으로써, 클러스터는 쿼럼 결정에 필요한 노드 개수를 증가 또는 감소시킬 수 있습니다. 이러한 동적 쿼럼 기능은을 통하여, 연속적인 노드 실패 및 셧다운 상황에도 서비스에 대한 중단 상황을 피할 수 있습니다.
클러스터 업그레이드 및 마이그레이션 : Windows Server 2012 내의 향상된 “Migrate a Cluster” 마법사를 사용하게 되면, 관리자는 Windows Server 2012, Windows Server 2008 R2 및 Windows Server 2008에서 운영되는 클러스터로부터 “클러스터 역할(以前, 클러스터 서비스 및 어플리케이션)”의 구성 설정을 Windows Server 2012로 마이그레이션 할 수 있습니다.
작업 스케줄러 통합 : Windows Server 2012에서, 관리자가 클러스터된 작업을 구성할 수 있도록, 작업 스케줄러는 장애조치 클러스터와 통합되어 있습니다. 클러스터된 작업은 모든 클러스터 노드에 등록되는 작업 스케줄러 작업입니다. 이 작업의 용도에 따라서, 모든 노드 또는 특정 노드에서 작업이 활성화될 수 있습니다.

위와 같이 신규 및 변경된 기능을 살펴보았고, 반면에 아래와 같이 제거 및 축소된 기능도 있습니다.

Cluster.exe 명령어 도구는 기능은 상당히 축소되었고, Failover Clustering 도구를 설치하면 선택적으로 설치할 수 있습니다. 장애조치를 위한 Windows PowerShell cmdlet이 Cluster.exe 명령어와 동일한 기능을 제공합니다.
MSClus(Cluster Automation Server) COM 인터페이스도 축소되었고, Failover Clustering 도구를 설치하면 선택적으로 설치할 수 있습니다.
32비트 클러스터 리소스 DLL들에 대한 지원도 축소되었고, 32비트 DLL들은 선택적으로 설치될 수 있습니다. 관리자는 64비트 DLL들로 반드시 클러스터 리소스 DLL들을 업데이트해야 합니다.
프린터 서버 역할은 고가용성 마법사에서 삭제되었고, 장애 조치 관리자 도구에서 구성될 수 없습니다.
Add-ClusterPrintServerRole cmdlet은 축소되었고, Windows Server 2012에서는 지원되지 않습니다.

위와 같이 Windows Server 2012 장애조치 클러스터의 각종 기능에 대한 개략적인 소개를 했고, 아래 데모 환경을 기반으로 위에 소개된 각종 기능을 Step-By-Step 가이드를 만들어 보았습니다.

이상과 같이 오늘 포스팅을 마치구요,, 11월에는 반드시 첫 번째 주에 여러분들과 만나뵙도록 하겠습니다.

[Dongclee의 2012년 9월 첫 번째 포스팅] Windows Server 2012 Series 16 : RD Connection Broker의 High Availability 구성 Step-by-Step 가이드

2012-09-06T07:06:47Z

안녕하세요,,,
이동철입니다.

8월의 혹독한 더위가 언제인지 기억이 가물 가물할 정도로, 선선한 바람이 부는 9월입니다. 여러분들 늘 환절기에는 감기 조심하세요 ^-^..

드디어 Windows 8 클라이언트에 이어서 Windows Server 2012가 정식 발매되었습니다. 이제는 Public 및 Private 클라우드에 최적화된 Windows Server 2012 도입을 심도있게 고민해야 할 시점이 도래되었습니다. 제 포스팅에 아직 클라우드 관련된 내용이 거의 全無한데, 제가 아직 능력이 딸려서 준비를 많이 못 했습니다. 최대한 능력을 끌어올려서 클라우드에 관한 내용도 많이 다루도록 하겠습니다.

오늘은 지난 8월 Windows Server 2012 RDS A to Z ( http://blogs.technet.com/b/dongclee/archive/2012/08/04/dongclee-2012-8-windows-server-2012-series-15-remote-desktop-service-session-virtualization-a-to-z.aspx
) 에 이어서, RD Connection Broker의 High Availability 구현에 관한 내용을 여러분에게 소개하고자 합니다. 미리 말씀드리지만, 이번 포스팅의 첨부 문서는 앞서Windows Server 2012 RDS A to Z 를 완전한 구현한 후, 이어지는 내용이기 때문에, 여러분들이RD
Connection Broker의 High Availability 구현하기 위해서는 반드시Windows Server 2012 RDS A to Z 포스팅의 첨부 문서를 완료해야 합니다.

그럼, 기본적으로 Windows Server 2012 RDS 환경에서 RD Connection Broker 역할은 무엇일까요? 아래와 같이 정리할 수 있습니다.

사용자들의 기존 가상화 데스크톱, RemoteApp 프로그램 및 세션 기반 데스크톱에 다시 연결할 수 있는 기능을 제공합니다.
세션 집합 내의 RDSH 서버들 또는 Pooled 가상화 데스크톱 집합 내의 Pooled 가상화 데스크톱들에 대한 부하 분산 기능을 제공합니다.
가상화 데스크톱 집합 내의 가상화 데스크톱에 대한 접근을 지원합니다.

즉, RD Connection Broker 서버가 물리적으로 손상되거나, 서비스가 중단된다면, Windows Server 2012의 VDI 및 Session Vritualization 서비스는 지속될 수가 없습니다. 이러한 구조에서, 가장 필수적으로 관리자가 고려해야 할 점은 바로 RD Connection Broker의 High Availability 입니다. RDCB의 HA는 사실 Windows Server 2008 R2 시절에도 제공되었습니다. 그럼, Windows Server 2008 R2 RDCB의 HA 와 Windows Server 2012 RDCB HA의 치명적인 차이점은 무엇일까요?

Windows Server 2012 와 Windows Server 2008의 RD Connection Broker HA 구성의 가장 큰 차이점은 바로 Failover Clustering의 존재 여부입니다. Windows Server 2008의 RD Connection Broker HA는 Failover Clustering 기반으로 구성되기 때문에, Active-Standby 가 기본 구조입니다. 즉, RD Connection Broker 서버들 중에서 특정 시점에 RD Connection Broker 역할을 수행하는 서버는 오로지 하나의 서버입니다. 아래 그림은Windows Server 2008 R2 RDCB의 HA의 기본적인 구조입니다.

반면에, Windows Server 2012의 RD Connection Broker HA 구성은 Failover Clustering 가 필요하지 않는 Active-Active 구조입니다. Active-Active 구조를 지원하기 위해서는 부하분산 기술이 반드시 필요합니다. DNS Round Robin, NLB 및 L4 와 같은 부하 분산 기술이 필요합니다. 즉, RD Connection Broker 서버들은 모두 RD Connection Broker 역할을 동시에 처리할 수 있습니다. 아래 그림은Windows Server 2012 RDCB의 HA의 기본적인 구조입니다. 본 데모 환경에서Windows Server 2012 RDCB의 HA를 위해 DNS Round Robin을 사용하여 구성했습니다.

즉, Windows Server 2012 RDCB의 HA는 Active-Active 구조이기 때문에, 서버의 사용률 측면에서 훨씬 더 만족할 수 있는 구조입니다.

여러분 이제 확실하게Windows Server 2008 R2 RDCB의 HA 와 Windows Server 2012 RDCB HA의 치명적인 차이점을 아셨죠? 그리고, 반드시Windows Server 2012 RDCB HA를 기본적으로 구축해야 할 당위성도 파악이 되셨죠?

여러분들, Windows Server 2012 서버는 늘 그렇듯이 굉장히 효율적이고 멋 있는 기능들이 많이 들어 있습니다. 저와 더불어 Windows Server 2012 세계에 빠져보시죠,,, 다음 포스팅에 좀 더 좋은 내용으로 찾아 뵙겠습니다.

[Dongclee의 2012년 8월 첫 번째 포스팅] Windows Server 2012 Series 15 : Remote Desktop Service의 Session Virtualization 구축의 A to Z

2012-08-04T07:36:51Z

안녕하세요,,, 거의 한 달만에 블로그에 글을 남기네요,, 요즘 너무 게을러진 것 같아 제 스스로 반성을 하게 됩니다. 요즘 거의 살인적인 폭염으로 절대 죽을 지경이네요, 여러분들도 폭염에 건강 조심하시구요,,,

드디어, Windows 8 및 Windows Server 2012 RTM(Release To Manufacturing) 버전이 8월 1일자로 발표되었습니다. 물론, 당장에 여러분들에게는 제공되지 않지만, 앞으로 출시될 정식 버전과 동일한 제품입니다. 여러분들도 이제는 새롭고 신기한 Windows 8 및 Windows Server 2012 환경에 적응하셔야 겠죠,,,, 적응하시는데 저의 블로그 내용이 도움이 되었으면 하는 조그마한 바램입니다.

오늘 주제는 바로 Windows Server 2012의 Remote Desktop Service 입니다. 물론, 이 기능은 동일한 이름으로 Windows Server 2008 R2에서도 제공되고 있었습니다. 기능 상으로 거의 동일한데 용어가 약간 바뀌었네요…. Windows Server 2012의 Remote Desktop Service는 크게 2가지 기능이 제공됩니다.

Session Virtualization : 과거 Remote Desktop Session Host, Remote Desktop Connection Broker 및 Remote Desktop Web Access 구성 요소에 의해 지원되는 Presentation Virtualization과 동일한 기능입니다. Session Virtualization 기능에 대한 자세한 설명은 여기에서 별도로 드리지는 않을께요,,, 설명이 너무 길어질 것 같아서요, 단순히 설명 드리면, 클라이언트 측의 자원은 사용하지 않고, 모든 어플리케이션의 실행은 서버에서 수행되고, 클라이언트 측에서는 결과 화면만 보여지는 가상화 기술입니다.
Virtualization Desktop Infrastructure : Remote Desktop Virtualization Host, Remote Desktop Connection Broker 및 Remote Desktop Web Access 구성 요소에 의해 지원되는 데스크톱 가상화 기술입니다. Windows Server 2012 RDS의 VDI 기술은 Windows Server 2008 R2 RDS의 VDI 기술과는 비교할 수 없을 정도의 다양한 기능을 제공합니다. 이제는 Windows Server 2012 RDS의 VDI 만으로도 충분히 데스크톱 가상화 기술을 구현할 수 있습니다.

특히, Windows Server 2012 RDS는 서버 관리자의 향상된 기능으로 중앙화된 콘솔에서 구축 작업을 몇 번의 마우스 클릭으로 손 쉽게 구축할 수 있습니다. 즉, 기존의 RDS의 각 구성 요소 별로 설치를 진행한 후, 별도의 구성 작업을 거쳐야 했지만, Windows Server 2012의 RDS는 중앙화된 콘솔을 사용하여 설치 및 구성 작업을 한 번에 수행할 수 있습니다. 이러한 기능을 이용하여, RDS에 익숙하지 않은 관리자도 손 쉽게 RDS를 설치 및 구축 할 수 있습니다. 아래는 RDS 각 구성 요소의 설치 및 구성이 동시에 하나의 콘솔에서 완료되는 화면입니다.

아래 그림은 RDS 각 구성 요소의 설치가 완료된 후, 배포의 전체적인 개요를 한 눈에 확인해 볼 수 있는 관리 화면입니다. 아래 + 로 표시된 구성 요소는 배포 및 구성되지 않은 구성 요소입니다.

또한, Windows Server 2012 RDS는 Quick Start 배포 방식을 지원합니다. 실제 대규모 RDS 배포 前에, 테스트 베드 성격의 RDS를 구축할 수 있는 배포 방식이 Quick Start 배포 방식입니다. 이 방식을 사용하여, 하나의 서버에 RDS에 필요한 모든 구성 요소를 설치하여, 손 쉽게 RDS의 다양한 기능을 접해 볼 수 있습니다. 아래 그림은 RDS 구성 마법사에서, “Quick Start” 와 “Standard Deployment” 방식을 선택할 수 있는 화면입니다.

그 외에 Windows Server 2012 RDS의 향상된 기능은 본 첨부 문서의 RDS 개요 부분을 참조하시면 쉽게 확인하실 수 있습니다.

본 문서에서는 Windows Server 2012 RDS의 Session Virtualization 구현 부분만 살펴봅니다. VDI 구현 부분은 아쉽게도 제가 소유한 하드웨어 적인 제약으로 다룰 수가 없는 점 이해 부탁 드립니다. 제가 하드웨어를 준비하는 대로, 반드시 VDI 구현 부분도 여러분에게 가이드를 제공해 드릴 것을 약속합니다.

본 문서의 소개한 내용을 간단하게 소개해 드리도록 하겠습니다.

① 첫 번째로, RDS Session Virtualization의 Quick Start 배포입니다. Session Virtualization 구현에 필요한 RDSH, RDCB 및 RDWA 구성 요소를 하나의 서버에 전부 구성한 예입니다. 이 방식은 앞서도 설명 드렸듯이 실제 운영 환경보다는 테스트 베드 성격의 Session Virtualization 구현 방식입니다. 아래는 구현 예제입니다.

② 두 번째로, RDS Session Virtualization의 Standard 배포 방식입니다. 이 방식은 실제 운영 환경에서 Session Virtualization을 설치 및 구성을 지원합니다. 즉, Session Virtualization 구현에 필요한 구성 요소를 별도의 분리된 여러 서버에 설치 및 구성할 수 있는 방식이 바로 “Standard 배포” 방식입니다. 물론, 이 구현 방식은 중앙화된 콘솔에서 몇 번의 마우스 클릭으로 진행할 수 있습니다. 이러한 설치 및 구성 방식이 가능한 이유는 바로 향상된 Windows Server 2012 Server Manager의 원격 설치 기능 때문입니다. 아래 그림은 “Standard 배포” 방식의 데모 환경입니다.

③ 세 번째로, 앞서 Session Virtualization의 Standard 배포가 완료된 이후에, 특정 어플리케이션(ex, Calculator, Wordpad 등등)에 대한 Session Virtualization을 위하여, 어플리케이션의 배포 및 구성을 살펴보고, 클라이언트에서 배포된 어플리케이션을 접근하는 방법을 확인해 봅니다.

④ 네 번째로, RDS의 라이선스 상황을 전사적인 차원에서 자동적으로 확인할 수 있는 Remote Desktop Licensing을 구현하는 방법을 확인합니다. 아래 그림은 Remote Desktop Licensing을 구현한 예제입니다. 아래 그림을 확인해 보면, 클라이언트가 RDS를 통해 배포된 특정 어플리케이션을 연결하여 사용하면, 최종적으로 RDSH 서버가 RD Licensing 서버에 라이선스 상황을 보고하도록 되어 있습니다.

⑤ 다섯 번째로, 회사 외부의 네트워크에서 RDS를 사용할 수 있도록, RD Gateway 구성 방법을 확인합니다. 본 데모 환경에서는, RD Gateway 서버에 2개의 NIC을 설치하여, 회사 내부 및 외부 네트워크 연결하도록 구성했습니다.

이상과 같이 총 5개 항목으로 Windows Server 2012 RDS의 Session Virtualization 구성에 대한 AtoZ 를 확인해 보았습니다. 물론, 제 나름대로의 판단이지만, 이러한 5가지 주제에 대해서 확인하면, Windows Server 2012 RDS의 Session Virtualization의 거의 모든 부분을 섭렵할 수 있다고 자부합니다.

추후, 포스팅에서 가능하면 Windows Server 2012 RDS의 VDI에 대해서 반드시 소개하도록 하겠습니다.

여러분 더운 여름 건강하게 지내시기를 기원합니다.

[Dongclee의 2012년 7월 첫 번째 포스팅] Windows Server 2012 Series 14 : Certificate Enrollment Web Service 와 Certificate Enrollment Policy Web Service를 사용하면 뭐가 더 좋을까요?

2012-07-04T05:22:00Z

안녕하세요?

벌써 2012년도 반이 훌쩍 지나가 버렸네요.. 요즘 너무 비가 오지 않아서 농작물 및 생물들이 생기가 없어 보입니다. 비가 너무 많이 와도 문제지만, 비가 너무 안 오니 진짜로 걱정이 더 많네요.. 우리 농민들이 늘 걱정없이 생업에 전념하기를 도시에 사는 보잘 것 없는 제가 빌어봅니다.

이번에 소개해 드릴 주제는 바로Certificate Enrollment Web Service (CES) 와 Certificate Enrollment Policy Web Service (CEP) 입니다. 이 기능은 사실 Windows Server 2008 에서부터 지원되어 왔었는데, 이번에 제가 Windows Server 2012의 새로운 기능을 살펴보면서, Windows Server 2012에 맞게 Step-By-Step 가이드를 만들어 보았습니다. CEP 및 CES의 필요성 및 기본적인 개요를 한 번 살펴보겠습니다.

Windows Server 2008 以前 운영 체제는 사용자 및 컴퓨터 인증서 발급에 필요한 인증 방법으로써 Kerberos를 사용합니다. 또한, 이러한 인증서 발급 요청은 트랜스포트 층을 통하여 전송됩니다. 이때, 인증 및 인증서 발급 요청은 DCOM 구성 요소를 사용합니다. DCOM를 사용한 인증서 발급 방법은 인증서 서비스를 활용하기 위한 여러 가지 시나리오를 적용할 수 없습니다. 예를 들어, “포리스트 사이의 인증서 자동 등록” 또는 “회사 내부 네트워크에 직접적으로 연결할 수 없는 컴퓨터들의 인증서 발급”은 기존 DCOM을 사용하는 프로토콜에서 불가능합니다. 왜냐하면, 회사 내부의 중요 서버인 CA 서버는 방화벽 내부에 위치하는 것이 통상적인 배치입니다. 그리고, 이러한 방화벽은 RPC 및 DCOM을 위한 포트는 보안상의 이유로 블로킹합니다. 이러한 방화벽 제어 때문에, 인증서 서비스를 다양한 시나리오에서 사용하기에 제약을 받을 수 있습니다. 물론, Windows Server의 CA는 이러한 DCOM구성 요소를 사용한 인증서 발급 외에, IIS를 사용한 Web Enrollment (ex, http://localhost/certsrv ) 방법을 대안으로 제시했습니다. 그러나, Web Enrollment 방법은 “인증서 갱신” 등을 포함한 여러 가지 기능 상의 제약점이 많습니다. 그래서, Web Enrollment 방법은 앞서 언급했던 전통적인 인증서 발급의 제약점을 해결하기 위한, 최종적인 방안이 아니라 Workaround수준의 방법입니다. 아래 그림이 기존의 인증서 발급을 위한 전통적인 방법입니다. 즉, CEP 및 CES를 사용하지 않는 인증서 발급 방법입니다.

이러한 전통적인 인증서 발급의 제약 사항을 제거하고, 인증서 서비스의 다양한 시나리오 적용을 위하여, Microsoft는 Windows Server 2008 R2 에서 WS-Trust 기반의 신규 인증서 등록 프로토콜을 지원합니다. 이러한 신규 인증서 등록 프로토콜을 지원하기 위하여, Windows Server 2008 R2에서 새로운 2가지 역할 서비스를 제공합니다. 새로운 2가지 역할 서비스는 바로 CEP 및 CES 입니다. CEP 및 CES 역할 서비스는 인증서 발급 요청 메시지를 TLS로 암호화하여 HTTPS로 전송할 수 있고, 인증서 발급을 위해 필요한 “인증 (Authentication)”을 위해 Kerberos에만 의존하지 않습니다. 즉, CEP 및 CES는 웹 서비스로 개발된 역할 서비스이기 때문에, RPC 및 DCOM과 같은 동적 포트를 사용하지 않고, 443과 같은 HTTPS 포트를 사용합니다. 즉, 443 포트를 사용하여, 클라이언트 컴퓨터는 CEP 및 CES에 인증서 발급 요청을 하고, 이러한 발급 요청을 CEP 및 CES는 방화벽 내부의 CA 서비스에 전달합니다. 이러한 구조를 이용하면, 포리스트 사이 및 웹을 통한 이러한 자동 인증서 발급과 같은 다양하고 보안성을 높힐 수 있는 인증서 발급 시나리오를 구성할 수 있습니다. 다만, CEP 및 CES 서비스를 사용할 수 있는 클라이언트는 Windows 7 및 Windows Server R2 이후 운영체제 입니다. 아래 그림은 CEP/CES 서비스를 사용하여 HTTPS를 통한 인증서 발급 구조입니다.

혹시 이 블로그를 보시면서, 기존 Web Enrollment와 다른 점이 무엇일까 궁금해 하시는 분이 계실 깁니다. CEP 및 CES를 구성하시게 되면, 클라이언트 컴퓨터에서 웹 브라우저가 아닌 “인증서 스냅-인(MMC)”를 사용하여 인증서 발급 및 갱신할 수 있습니다. 첨부 문서를 보시면 이 점을 좀 더 명확하게 아실 수 있습니다.

추가적으로 CEP 및 CES를 구성하실 때, 필요한 port에 대해서 아래 그림에서 확인하실 수 있습니다.

위 그림을 보시면 CES 및 CEP를 DMZ 구간에 위치시키고, 실제 CA 서버와 DCOM 통신이 필요한 것은 클라이언트가 아니라 CEP임을 확인할 수 있습니다.

제가 앞서 인증서 서비스의 CRL을 확인하기 위한 OCSP 관련 블로그를 포스팅했는데, OCSP 와 더불어 CEP 및 CES까지 구성하신다면, Microsoft CA 서비스의 최종적인 Blueprint가 아닐까 하는 생각을 개인적으로 해봅니다.

무더운 날씨에 다들 건강 조심하시구, 다음 포스팅에서 뵙겠습니다.