Windows Server 2012

Transcription

1 Windows Server 2012 Remote Access A to D 회사외부의네트워크상에서, 전통적인 VPN 연결없이회사네트워크자원을연결할수있는새로운원격접근기능인 DirectAccess 는 Windows Server 2008 R2 에서소개되었습니다. DirectAccess 기능을사용할려면, 도메인에죠인된 Windows 7 Enterprise 및 Ultimate 클라이언트가필요합니다. 반면에, 전통적인클라이언트, 도메인에죠인되지않은클라이언트및 third-party 클라이언트를위해서, 여전히 Windows RRAS 기능이전통적인 VPN 을지원합니다. 또한, RRAS 는서버들사이의 site-to-site 연결을지원합니다. Windows Server 2008 R2 의 RRAS 는동일 edge 서버에 DirectAccess 기능과공존할수없습니다. 반드시, DirectAccess 와 RRAS 는물리적으로분리된서버에배포되어져야합니다.Windows Server 2012 에서, 신규통합서버역할에 DirectAccess 및 RRAS 역할서비스가결합되어제공됩니다. 신규 Remote Access 서버역할은 DirectAccess 및 VPN 기반원격접근서비스의중앙관리, 구성및모니터링기능을지원합니다. 게다가, Windows Server 2012 DirectAccess 는다중업데이트기능을지원합니다. 이동철

2 목차 데모환경... 4 Remote Access (DirectAccess, Routing and Remote Access) 개요... 5 Remote Access... 5 DirectAccess 및 RRAS 통합서버역할... 5 DirectAccess 및 RRAS 공존 ( 共存 )... 6 DirectAccess 배포단순화... 7 DirectAccess 구성의 PKI 전제조건 ( 前提條件 ) 제거... 7 내부 IPv4-only 자원접근을위한 NAT64 및 DNS64 지원... 8 NAT 디바이스배후 ( 背後 ) 의 DirectAccess 서버지원... 9 단순화된네트워크보안정책... 9 부하분산 (Load Balancing) 지원 다중도메인지원 NAP 통합 OTP 지원 (Token Based Authentication) 터널링강제를위한자동화된지원 IP-HTTPS 상호운용및성능향상 Manage-Out 지원 ( 단지원격관리용도의 DirectAccess 배포방법 ) Multisite 지원 페이지 1 / 89

3 Server Core 운영체제지원 PowerShell 지원 사용자및서버상태모니터링 (User 및 Server Health Monitoring) 서버운영상태 진단 (Diagnostics) Accounting 및 Reporting Site-to-Site IKEv2 IPsec 터널모드 VPN IPv4 only 네트워크환경에서 DirectAccess 설치및구성 개요 테스트랩개요 하드웨어및소프트웨어요구사항 DirectAccess 테스트랩구성절차 (for Windows 8 Client) Step 1 : 기본테스트랩설정 Step 2 : DC1 구성 Step 3 : EDGE1 구성 Step 4 : CLIENT1 구성 DirectAccess 클라이언트를위한 DirectAccess 구성절차 (for Windows 8 & Windows 7) 57 Step 1 : 기존 DirectAccess 구성제거 Step 2 : Windows 7 클라이언트준비 페이지 2 / 89

4 Step 3 : Windows 7 클라이언트를위한보안그룹생성 Step 4 : 기존도메인에 Private CA 설치확인 Step 5 : CA 의 CRL 외부공개구성 Step 6 : DirectAccess 서버및 DirectAccess 클라이언트의인증서확인 Step 7 : DirectAccess 서버구성 Step 8 : Windows 7 및 Windows 8 DirectAccess 클라이언트테스트 참조자료 페이지 3 / 89

5 데모환경 본문서의데모환경은아래와같습니다. 본데모환경의모든서버는오로지 IPv4 주소만할당되어있습니다. DirectAccess 클라이언트역할을수행하는 CLIENT1 및 CLIENT2W7 컴퓨터는기본적으로 IPv4 주소만을할당받았지만, EDGE1 서버에 DirectAccess 구성을완료한후, DirectAccess 클라이언트로지정받게되면, 네트워크위치에따라 IPv6 주소 (ex, IPHTTPS 인터페이스 ) 를자동으로할당받습니다. 아래데모환경에서 CLIENT2W7 이라는 Windows 7 도메인클라이언트가빠져있음을미리알려드립니다. 페이지 4 / 89

6 Remote Access (DirectAccess, Routing and Remote Access) 개요 ( ) Remote Access Windows Server 2012 에서, Remote Access 는하나의통합된서버역할에 2 가지의네트워크서비스가 결합되어있습니다. DirectAccess 및 RRAS 통합서버역할 회사외부의네트워크상에서, 전통적인 VPN 연결없이회사네트워크자원을연결할수있는새로운원격접근기능인 DirectAccess 는 Windows Server 2008 R2 에서소개되었습니다. DirectAccess 기능을사용할려면, 도메인에죠인된 Windows 7 Enterprise 및 Ultimate 클라이언트가필요합니다. 반면에, 전통적인클라이언트, 도메인에죠인되지않은클라이언트및 third-party 클라이언트를위해서, 여전히 Windows RRAS 기능이전통적인 VPN 을지원합니다. 또한, RRAS 는서버들사이의 site-to-site 연결을지원합니다. Windows Server 2008 R2 의 RRAS 는동일 edge 서버에 DirectAccess 기능과공존할수없습니다. 반드시, DirectAccess 와 RRAS 는물리적으로분리된서버에배포되어져야합니다. Windows Server 2012 에서, 신규통합서버역할에 DirectAccess 및 RRAS 역할서비스가결합되어제공됩니다. 신규 Remote Access 서버역할은 DirectAccess 및 VPN 기반원격접근서비스의중앙관리, 구성및모니터링기능을지원합니다. 게다가, Windows Server 2012 DirectAccess 는다중업데이트기능을지원합니다.(?) Windows Server 2008 R2 와달라진점 DirectAccess 및 RRAS 를위한신규통합서버역할은 Remote Access 서버배포를위한구성및관리의단일환경을제공합니다. Windows Server 2012 는 Windows 7 DirectAccess 및 RRAS 보다다음과같은향상된기능을제공합니다. DirectAccess and RRAS coexistence Simplified DirectAccess management for small and medium organization administrators Removal of PKI deployment as a DirectAccess prerequisite Built-in NAT64 and DNS64 support for accessing IPv4-only resources Support for DirectAccess server behind a NAT device Simplified network security policy Load balancing support Support for multiple domains 페이지 5 / 89

7 NAP integration Support for OTP (token based authentication) Automated support for force tunneling IP-HTTPS interoperability and performance improvements Manage-out support Multisite support Support for Server Core Windows PowerShell support User and server health monitoring Diagnostics Accounting and reporting Site-to-site IKEv2 IPsec tunnel mode VPN 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 는동일서버에공존할수있습니다. 페이지 6 / 89

8 DirectAccess 배포단순화 Windows Server 2012 DirectAccess 는특별히소형및중형조직에적합한배포방식을몇가지중요한기능을지원합니다. 중요한기능은 단순화된사전항목, 전체 PKI 배포필요성제거, 통합인증서배포 및 연속된 2 개의 IPv4 주소필요성제거 입니다. 이러한상세기능은추후각각은아래부분에서확인합니다. 관리자는신규 Getting Started 마법사를사용하여 DirectAccess 를배포할수있습니다. 이마법사는 DirectAccess 의손쉬운구성방법을제공합니다. 또한, 신규마법사는 DirectAccess 구성의복잡성을제거하고, 단순한몇단계의자동화된설치방법을제공합니다. IPv6 변환 ( 變換, transition) 기술및 NLS 배포와같은복잡한기술을습득하지않아도, 관리자는 DirectAccess 를손쉽게구성할수있습니다. DirectAccess 구성의 PKI 전제조건 ( 前提條件 ) 제거 Windows 7 DirectAccess 는서버및클라이언트인증서기반인증을위해반드시 PKI 환경이필요합니다. 즉, PKI 환경이 Windows 7 DirectAccess 배포의가장큰장애물이기도했습니다. 인터넷상의 DirectAccess 클라이언트로부터트래픽의인증및보호를위해, DirectAccess 기술은 IPsec AuthIP 정책을사용합니다. Kerberos 사용하여도메인자원을인증하기위해, DirectAccess 클라이언트는먼저, DNS 서버및도메인컨트롤러에연결합니다. AuthIP 정책에서 2 가지인증방법을구현함으로써, Windows 7 DirectAccess 는 DNS 서버및도메인컨트롤러연결을활성화할수있습니다. IPsec 터널인프라는첫번째인증은 컴퓨터인증서, 두번째인증은 사용자 NTLM 을사용하여구성됩니다. IPsec 터널이연결되고, 도메인컨트롤러가가용하면, 클라이언트는 Kerberos 토큰을획득할수있고, 첫번째및두번째인증방법으로써 컴퓨터인증서 및 사용자 Kerberos 를사용하여인트라넷 IPsec 터널을구축할수있습니다. 이러한구현방식은상호인증을위해컴퓨터인증서를 DirectAccess 서버및모든클라이언트에배포해야하는부담감이있습니다. 그러나, 대형조직이외의소형및중형조직에서내부 PKI 를유지하는것은비용및관리적인측면에서어려움이있습니다. Windows Server 2012 DirectAccess 에서, 관리및구성을단순화하기위해 PKI 배포가반드시필요하지는않습니다. Windows Server 2012 DirectAccess 에서, Kerberos 프록시기반의 HTTPS 를구현함으로써상호인증기능을수행할수있습니다. 클라이언트인증요청은 DirectAccess 서버에서수행되는 Kerberos 프록시서비스에보내집니다. Kerberos 프록시는클라이언트대신에도메인컨트롤러에 Kerberos 요청을보냅니다. Kerberos 프록시를포함한솔루션을자동적으로구성함으로써, 신규 Getting Started 마법사는관리자를위해매끄러운경험을제공합니다. 단순화된 DirectAccess 배포방법에서는, 터널링강제화, NAP 통합및 two-factor 인증과같은사용자수준구성은사용할수없습니다. 이러한단순배포방식은오로지하나의 IPsec 터널만필요합니다. 또한, 다음과같은요구사항이필요합니다 : 페이지 7 / 89

9 외부인터넷측면방화벽에서 IPsec 포트 (UDP 500/4500) 및 TCP 포트 443 이 open 되어야합니다. DirectAccess 서버자체개인방화벽은반드시 TCP 포트 443 을 open 해야합니다. DirectAccess 클라이언트에의해신뢰되는 CA 에의해발급된 TLS 용도의서버인증인증서가 DirectAccess 서버에설치되어야합니다. DirectAccess 서버에설치되는서버인증서를위해내부 PKI 배포가필요하지않고, 공개 CA 에의해발급된서버인증서를사용해야합니다. 이러한서버인증서가준비되지않았다면, DirectAccess 서버설치과정은필수적인 IP-HTTPS 및 KDC 프록시용도의 self-signed 인증서를구성할것입니다. 내부 IPv4-only 자원접근을위한 NAT64 및 DNS64 지원 내부 IPv4-only 자원에접근하기위해서, DirectAccess 클라이언트의 IPv6 통신을 IPv4 통신으로변경하기위하여 Windows Server 2012 DirectAccess 는 NAT64 및 DNS64 게이트웨이기능을지원합니다. NAT64 를사용한프로토콜변환은단방향 (unidirectional) 이기때문에, IPv4-only 인트라넷컴퓨터는원격관리를위한 DirectAccess 클라이언트의연결을초기화할수없습니다. IPv6-only DirectAccess 환경은주로아래와같은 3 가지경우에회사내부인트라넷자원에대한전체접근을지원하지않습니다. Windows Server 2003 파일서버및 IIS 와같이 IPv6 를지원하지않고, 오로지 IPv4 만을지원하는인트라넷서버 관리적인목적으로네트워크상에서 IPv6 를지원하지않는환경 Windows Server 2008 과같이 OS 수준에서 IPv6 를지원하지만, IPv6 를지원하지않는어플리케이션 DirectAccess 를통해위와같은자원에대한접근을허용하기위해, DirectAccess 서버와내부 IPv4-only 지원을사이에프로토콜변환 ( 變換, transition) 기술이필요합니다. NAT64 는클라이언트로부터 IPv6 트래픽을받아서, 내부인트라넷에 IPv4 트래픽을변환해서보내주는역할을담당합니다. NAT64 는 DNS64 와결합되어사용됩니다. DNS64 는 DirectAccess 클라이언트부터의 DNS 질의를가로채고, NAT64 에매핑된 IPv6 주소를 IPv4 주소로변환한후, 결과값을보냅니다. Windows Server 2012 DirectAccess 以前에는, DirectAccess 를위한프로토콜변환기술은오로지 Microsoft Forefront Unified Access Gateway DirectAccess 를통해지원되었습니다. 관리자의개입없이, DirectAccess 설치마법사는매끄럽게프로토콜변환구성요소를구성할것입니다. 관리자가프로토콜변환을위해구성해야할추가적인작업이필요없습니다. DirectAccess 서버의내부인터페이스에 IPv4 주소가할당되어있다면, 설치마법사는자동적으로 NAT64 및 DNS64 를활성화할페이지 8 / 89

10 것입니다. 이러한기능을지원하기위해, 설치마법사는 NAT64 를위한 IPv6 네트워크프리픽스를 구성할것입니다. 설치마법사는자동적으로 NAT64 프리픽스를할당하고, 이프리픽스를전체 네트워크의모든 IPv4 주소범위에적용합니다. NAT 디바이스배후 ( 背後 ) 의 DirectAccess 서버지원 Windows Server 2008 R2 DirectAccess 는 2 개의연속적인공용 IPv4 주소 2 개가할당된외부인터페이스는필수구성요소입니다. 이러한요건은 IPv6 변환 ( 變換, transition) 기술중의하나인 Teredo 서버를위해필요합니다. In order for clients behind a NAT to determine the Teredo server and the type of NAT device, the Teredo server requires two consecutive IPv4 addresses. (?) 그러나, 연속적인 2 개의공용 IPv4 주소를구성하는것은소형및중형조직에서는비용및관리적인부분에서어려움이많습니다. 또한, 최근공용 IPv4 주소의부족현상으로인해, DirectAccess 서버를위해 2 개의공용 IPv4 주소를확보하는것이 DirectAccess 서버확산에장애물로인식되고있는현실입니다. Windows Server 2012 DirectAccess 는 NAT 디바이스배후에 DirectAccess 서버를배포할수있는기능을지원합니다. DirectAccess 서버를 NAT 배후에배포한다면, DirectAccess 서버는단일 NIC 및다중 NIC 환경모두지원가능합니다. 즉, 이제더이상 DirectAccess 서버배포를위해 2 개의연속된공용 IPv4 주소가필요하지않습니다. Getting Started 마법사또는 Remote Access Setup 마법사가수행될때, DirectAccess 서버가 NAT 배후에위치하는지확인하기위해 DirectAccess 서버상의네트워크인터페이스상태를체크할것입니다. 이러한구성에서, 오로지 IP over HTTPS(IP-HTTPS) 가배포될것입니다. IP-HTTPS 프로토콜은안전한 HTTP 연결을사용하여설정된보안 IP 터널을이용할수있는 IPv6 변환 ( 變換, transition) 기술입니다 단순화된네트워크보안정책 Windows Server 2008 R2 DirectAccess 는회사내부네트워크에연결을설정하기위해 2 개의 IPsec 터널을사용합니다. DirectAccess 클라이언트는 DNS, DC 및관리서버 (ex, SCCM) 와같은기반 (Infrastructure) 자원에접근하기위해인프라터널이필요합니다. 기반터널 IPsec 정책의끝점으로써이러한기반서버들이나열됩니다. 이러한 IPsec 정책을통해구성된인트라넷터널은다른모든회사인트라넷자원을접근할수있는방법을제공합니다. DNS 서버또는도메인컨트롤러가추가및삭제되는상황과같은변경사항이발생하게될때, 기반터널 IPsec 정책에나열된끝점들은정기적인업데이트가필요합니다. 현재기반서버끝점을반영하기위한 IPsec 정책이업데이트되지않았을때, 클라이언트는도메인에대한연결이손상될수있습니다. 이러한손상된연결은오류를수정하기위한그룹정책업데이트를클라이언트가받는것을방해할수있습니다. 페이지 9 / 89

11 Windows Server 2012 에서, 단순화된 DirectAccess 모델은단일 IPsec 터널을통해 DirectAccess 를배포할수있는방법을제공합니다. 단일 IPsec 터널을통한 DirectAccess 는앞선문제점을제거할수있습니다. 그러나, 단순화된 DirectAccess 는특정기능을지원하지않고, 특정기능은인증서기반인증에의지합니다. 특정기능의예는스마트카드를사용한 2 단계인증및 NAP 통합과같은기능입니다. 이러한전체모든 DirectAccess 기능을요구하는회사는결국 2-터널모델을배포해야할것입니다. DirectAccess 전체기능을위해 2-터널모델이구성한다면, 기반터널을통해접근될수있는서버항목들을업데이트할수있는기능을관리자에게부가적으로제공합니다. 신규도메인컨트롤러및 SCCM 서버들은발견되고기반서버항목에추가됩니다. 더이상존재하지않는서버들은기반서버항목으로부터제거됩니다. 또한, 변경된 IP 주소를소유한서버항목들도업데이트됩니다. 부하분산 (Load Balancing) 지원 Windows Server 2008 R2 DirectAccess 는전체고가용성솔루션을지원하지않고, 단일-서버배포방법에서는제한됩니다. 제한된하드웨어중복을지원하기위해, DirectAccess 는 Hyper-V 라이브마이그레이션을위해구성된 Hyper-V 장애조치클러스터안에서구성할수있습니다. However, only one server node may be online at any time. (?) 단일서버가지원할수있는적절한프로세싱능력을벗어날정도로빠르게 DirectAccess 배포는확장될수있습니다. 즉, 이러한부하요구사항변경에대처하기위하여, 부가적인서버를빠르고투명하게배포할수있는유연성이반드시필요합니다. 부가적으로, DirectAccess 클라이언트가내부 / 외부네트워크를구분하기위해사용되는 NLS(Network Location Server) 는 2 대이상을준비하여고가용성을구축해야합니다. 내장된 Windows NLB 를사용하여, DirectAccess 및 RRAS 의고가용성및확장성을해결할수있습니다. NLB 구성은신규배포마법사인터페이스를통하여설치및자동화할수있습니다. 또한, third-party 외부하드웨어기반부한분산룰루션을위한통합된지원도설치과정에서지원합니다. 중요 Windows Server 2012 DirectAccess 는 NLB 를사용하여최대 8 노드까지기본장애조치솔루션을지원합니다. 서버부하가모든 NLB 노드사이에공유될지라도, 한서버가가용하지않았을때, 기존연결은자동적으로다른서버로전송되지않을것입니다. 다중도메인지원 Windows Server 2008 R2 DirectAccess 는오로지단일도메인만지원합니다. 즉, 다른도메인의원격클라이언트는다른도메인내의 DirectAccess 서버를통해연결할수없습니다. 게다가, 어플리케이션서버가다른도메인에존재한다면, 원격클라이언트는 DirectAccess 를통해원격으로어플리케이션서버를접근할수없습니다. 페이지 10 / 89

12 Windows Server 2008 R2 DirectAccess 에서관리자가수동으로다중도메인을지원하도록구성한다면, 설치가완료된후, DirectAccess 정책을수동으로수정해야합니다. Windows Server 2012 DirectAccess 는다른도메인에존재하는회사자원을원격클라이언트가접근할수있도록다중도메인구성을지원합니다. NAP 통합 인트라넷터널의 IPsec 상호인증을위하여 상태인증서 (Health Certificate) 를요구함으로써, Windows Server 2008 R2 DirectAccess 는 NAP 통합을지원합니다. 상태인증서는시스템상태 OID 가포함된인증서입니다. NAP 상태정책서버상에구성된시스템상태요구사항을준수하도록하기위해서, NAP 클라이언트는 HRA(Health Registration Authority) 로부터발급된상태인증서가필요합니다. Windows Server 2008 R2 DirectAccess 와 NAP 을통합하기위하여, DirectAccess 가배포된후, 관리자는 DirectAccess 설치마법사에의해생성된 GPO 및정책을수동으로편집해야합니다. 반면에, Windows Server 2012 DirectAccess 는설치사용자인터페이스를통해 NAP 상태체크를직접적으로구성할수있습니다. 즉, 이러한기능은 NAP 통합을위해필요한정책및 GPO 수정을자동적으로수행합니다. NAP 상태체크강제화는 Remote Access 설치마법사로부터활성화할수있습니다. 중요신규설치마법사는 DirectAccess 와 NAP 통합을단순화할수있어도, 실제 NAP 배포자체를자동활할수는없습니다. 부가적으로, 관리자는 NAP IPsec 강제화및 HRA 구조는별도구성을해야합니다. OTP 지원 (Token Based Authentication) 로그인보안을강화하기위해, 대부분조직은 OTP(One-Time Password) 2 단계인증을구성합니다. Windows Server 2008 R2 DirectAccess 는스마트카드와통합된 2 단계인증을지원하지만, RSA SecurID 와같은 OTP 벤더솔루션에통합된 2 단계인증은지원한지않습니다. 강화된보안을요구하는조직에서, OTP 를지원하지않는 DirectAccess 는사용이제한적일수밖에없습니다. Windows Server 2012 DirectAccess 는스마트카드또는 OTP 토큰기반솔루션모두지원합니다. 이러한 2 단계인증을사용하기위해서는, PKI 인프라는반드시배포되어야합니다. 스마트카드및 OTP 옵션을 DirectAccess 설치마법사에서선택한다면, User computer certificates 옵션은자동적으로선택되고, 반드시구성해야합니다. 표준스마트카드인증지원에추가적으로, DirectAccess 는 Windows Server 2012 에서지원되는 TPM (Trusted Platform Module) 기반가상스마트카드를사용할수있습니다. 클라이언트컴퓨터의 TPM 은 2 단계인증을위한가상스마트카드로사용될수있습니다. 그러므로, 스마트카드배포에발생하는오버헤드및비용을 TPM 을통해절약할수있습니다. 페이지 11 / 89

13 터널링강제를위한자동화된지원 기본적으로, DirectAccess 클라이언트는인터넷, 회사인트라넷및로컬 LAN 자원을동시에접근할수있습니다. 회사인트라넷에설정된연결만이 DirectAccess IPsec 터널을통해전송되기때문에, 이러한기능을 분리된-터널 (split-tunnel) 구성이라고합니다. 분리된터널링은인터넷상의자원접근시에최적의사용자환경을제공하고, 반면에, 인트라넷상의자원접근시에는강한보안을제공합니다. 이렇게분리된터널링은보안상의위험이존재하므로, 대부분의조직은 DirectAccess 클라이언트자신의 ID 를조사할수있도록회사프록시를통해모든트래픽이통과하도록강제합니다. 기존 VPN 연결을사용하면, 홈네트워크및회사네트워크사이에트래픽이교환됨으로써잠재적인위험이사용자에게존재합니다. 즉, 클라이언트컴퓨터는라우터와같이작동할수있습니다. 이러한기능때문에, 대부분의관리자는보안상의이유는 VPN 연결에서분리된터널링을비활성화합니다. 즉, VPN 클라이언트의인터넷및인트라넷통신은모두회사 VPN 연결을통해수행됩니다. 그러나, 이러한분리된터널링비활성화는불필요한인터넷트래픽도회사내부의네트워크를사용하게됨으로써, 비용및성능적인측면에서비효율적입니다. DirectAccess 가활성화된 IPsec 규칙은클라이언트를검증하기때문에, 분리된터널링에의해발생되는보안위험은 DirectAccess 시나리오에서는유효하지않습니다. 다른클라이언트가 DirectAccess 클라이언트를통해라우팅을시도한다면, 다른클라이언트즉트래픽원본이검증되지않기때문에, IPsec 은이러한연결을중단시킬것입니다. 그러나, 대부분조직은트래픽을조사할수있도록회사프록시를통해모든트래픽이통과하도록강제화하기위해, DirectAccess Force Tunneling 옵션은이러한기능을지원합니다. Force Tunneling 옵션은 Windows Server 2008 R2 DirectAccess 에서도지원되었습니다. 그러나, Force Tunneling 옵션을활성화하기위해그룹정책설정을통한수동설정이필요합니다. Force Tunneling 옵션을위해필요한설정을자동화하기위해설치마법사및관리 UI 는 Windows Server 2012 DirectAccess 와통합되어있습니다. Force Tunneling 옵션활성화는 DirectAccess 클라이언트의 IP- HTTPS 프로토콜사용을제약할수있습니다. 기본적으로, IPv4 프록시서버에보내질 IPv6 자원을변환하기위하여 DNS64/NAT64 서버로써 DirectAccess 서버를사용합니다. (Enabling the Force Tunneling option limits the DirectAccess client to using only the IP-HTTPS protocol for connectivity, and by default uses the DirectAccess server as the NAT64/DNS64 server to translate IPv6 resources to send to the IPv4 proxy server.)????? IP-HTTPS 상호운용및성능향상 특정네트워크상에서, 인터넷방화벽설정은 6to4 또는 Teredo IPv6 변환기술을사용하는클라이언트연결을방해할수있습니다. 모든 IPv6 변환기술이연결에실패할때, 마지막으로 443 포트를사용하여 DirectAccess 클라이언트가회사네트워크에연결할수있는방법이바로 IP-HTTPS 입니다. IP-HTTPS 페이지 12 / 89

14 기술은 Windows 7 에서부터지원됩니다. IP-HTTPS 는 IPv4 호스트에 unique, globally routable IPv6 주소를할당합니다. 그후, HTTP 터널상의전송을위해 IPv4 내의 IPv6 패킷을요약한후, 호스트와다른 globally routable IPv6 노드사이에서 IPv6 트래픽을라우팅합니다. Windows Server 2012 는 IP-HTTPS 의구현을위한여러가지향상된기능을제공합니다. IP-HTTPS 클라이언트가프록시구성정보를얻을수있도록기술적인변경이있습니다. 인증이요구되면 HTTP 프록시에인증요청을보낸다. 각 IP-HTTPS 클라이언트에클라이언트인증서를배포하는 Windows 7 환경의요구사항이더이상필요하지않습니다. IP-HTTPS 는클라이언트와서버사이에 SSL/TLS 연결을생성함으로써작동하고, 그후에연결사이에 IP 트래픽을전달합니다. 전달되는데이터는 IPsec 에의해암호화되고, 이것은데이터가두번암호화됨을의미합니다. 첫번째는 IPsec 에의해암호화되고, 두번째는 SSL 에의해암호화됩니다. 이러한암호화방식은 6to4 및 Teredo 와같은다른 IPv6 변환기술에비교하여성능저하및사용자환경에부정적인영향을미칩니다. 또한, 이러한암호화방식은 DirectAccess 서버의확장을제약합니다. DirectAccess 서버의확장성을증대시키고, 이러한연결방식에연관된오버헤드 (ex. 두번암호화 ) 를제거하기위해, Windows Server 2012 DirectAccess 는 IP-HTTPS 를위한여러가지성능향상방안을포함합니다. Send behavior 및 Receive buffers 를동시에묶는기능, 잠금경쟁최소화 및 NULL 암호화방식의 SSL 구현옵션 과같은변경사항이바로 IP-HTTPS 향상된기능입니다. (These optimizations include changes to batched send behavior and receive buffers, reduced lock contention, and the option to implement SSL with NULL encryption.) IP-HTTPS 는사용자컨텍스트보다는시스템컨텍스트상에서운영됩니다. 이러한컨텍스트는연결문제를발생시킬수있습니다. 예를들어, DirectAccess 클라이언트컴퓨터는인터넷접근을위해프록시를사용하는파트너회사의네트워크에존재하고, WPAD 자동검출이사용되지않는다면, 인터넷접근을위하여사용자는수동으로프록시설정을구성해야만합니다. 이러한프록시설정은사용자별로 IE 에서구성되고, 프록시설정은 IP-HTTPS 대신에직관적인방법으로추출될수없습니다. 추가적으로, 프록시사용에인증이필요하다면, 클라이언트는인터넷접근을위해 credential 을제공해야합니다. 그러나, IP-HTTPS 는 DirectAccess 를인증하기위해요구되는 credential 을제공하지않을것입니다. Windows Server 2012 에서, 새로운기능이이러한문제점을해결할수있습니다. Specifically, the user can configure IP-HTTPS to work when behind a proxy that is not configured using WPAD and IP- HTTPS will request and provide the proxy credentials needed to IP-HTTPS request authenticated, and relay it to the DirectAccess server. (??) DirectAccess 에서 IP-HTTPS 를구성할때, 관리자는 CA 에서발급된인증서를사용하거나, DirectAccess 설치시에자동으로설치된 self-signed 인증서를사용할수도있습니다. PKI 사용을원하지않는다면, self-signed 인증서가효과적일수있습니다. 페이지 13 / 89

15 Manage-Out 지원 ( 단지원격관리용도의 DirectAccess 배포방법 ) 사용자가로그인되어있지않았음에도불구하고, DirectAccess 클라이언트는인터넷연결이가능할때언제든지회사인트라넷에연결을설정합니다. DirectAccess 클라이언트컴퓨터가사무실에있지않더라도, IT 관리자는원격컴퓨터에보안컴플라이언스및보안패치에대한관리를할수있습니다. 특정고객들은바로이러한기능이 DirectAccess 의가장중요한장점이라고평가합니다. 단지, DirectAccess 를원격관리용으로사용한다면, 기존원격접근솔루션을그대로유지하는것이비용및관리적인측면에서나을수있습니다. Windows Server 2008 R2 DirectAccess 는 manage-out only 용도로제한하기위한자동화된방법을제공하지않습니다. 즉, 관리자들은설치마법사에의해생성된정책을수동으로편집하여 manage-out only 용도를지원할수있습니다. Windows Server 2012 DirectAccess 는배포마법사옵션을통해 manage-out only 구성방법을지원합니다. 클라이언트컴퓨터의원격관리용도만으로정책생성을제한할수있는방법이 manage-out only 배포방식입니다. 이배포방법에서, Force Tunneling, NAP 통합및 2 단계인증과같은사용자수준구성옵션은사용할수없습니다. Multisite 지원 인트라넷자원을위해가장근접한 입구지점 (Entry Points) 에좀더효율적인접근을지원하고용량을증대시키기위해, DirectAccess 서버는다중사이트에배포할수있습니다. 클라이언트가자신의각사이트에존재하면서, 조직내의다른사이트로이동하지않는다면, 가장근접한입구지점에접근하는메커니즘은잘동작합니다. 그러나, 클라이언트가사이트사이에이동할예정이라면, 클라이언트들이가장효율적라우팅을통해 DirectAccess 서버에연결하기위해, 다중사이트 DirectAccess 설정은좀더신중한계획및설계가필요합니다. 클라이언트가가장근접한 IP-HTTPS 서버, Teredo 서버, DNS 서버및도메인컨트롤러를찾을수있도록하기위해서, 다중사이트환경에서는많은고려사항이존재합니다. Windows Server 2012 DirectAccess 는지리적으로분산된다중 DirectAccess 입구지점의배포를위한솔루션을제공합니다. 그리고, Windows Server 2012 DirectAccess 는물리적인위치에무관하게클라이언트가가장효율적인방법으로회사내의자원을접근할수있는기능을제공합니다. 지리적으로분산된위치내의원격사용자가자신에게가장근접한다중사이트입구지점에연결할수있도록, Windows Server 2012 Remote Access 서버는다중사이트배포에서구성될수있습니다. Windows Server 2012 클라이언트컴퓨터를위해, 입구지점은자동적으로할당되거나, 클라이언트에의해수동으로선택될수있습니다. 또한, Windows 7 클라이언트컴퓨터를위해, 입구지점은통계적인방식으로할당될것입니다. 다중사이트사이의트래픽은외부전역부하분산기를사용하여분배및분산될것입니다. 페이지 14 / 89

16 Server Core 운영체제지원 Server Core 는디스크공간, 서비스, 관리요구사항을줄이기위해설계된최소서버설치옵션입니다. 또한, Server Core 는바이러스공격같은보안침해사고를감소시킬수있습니다. Server Core 시스템은 GUI 를지원하지않고, 관리자는필요한모든구성작업을위해원격관리도구또는명령어라인를사용해야합니다. Server Core 설치는전체 Windows Server 전체설치버전에비해제한적인기능을제공합니다. Windows Server 2008 R2 Server Core 는 DirectAccess 기능또는 Remote Access 서버역할을지원하지않습니다. 그러나, Windows Server 2012 Server Core 설치는 DirectAccess 및 RRAS 를위한단일서버역할을지원합니다. 신규 Remote Access 서버역할은설치, 구성및관리를위해사용될 Windows Server 2012 에완전한 Windows PowerShell 을지원합니다. 또한, Remote Access 서버역할은네트워트상의다른서버에서원격서버관리기능을통해구성될수있습니다. PowerShell 지원 Windows Server 2008 R2 DirectAccess 는구성옵션을위한명령어라인인터페이스및완벽한스크립팅이부족했습니다. Windows Server 2012 는 Remote Access 서버역할의설치, 구성, 관리, 모니터링및트러블슈팅을위한완전한 Windows PowerShell 을지원합니다. 사용자및서버상태모니터링 (User 및 Server Health Monitoring) RRAS 및 DirectAccess 의모니터링및진단기능은 Windows Server 2008 R2 에서는극히제약적이었습니다. DirectAccess 를위한모니터링기능은 DirectAccess 및구성요소의기본적인상태모니터링을포함합니다. 가용한모니터링데이터및통계정보는관리자에게약간부족하고분명하지않습니다. Windows Server 2012 에소개된사용자및서버상태모니터링기능을사용하여, 관리자는 DirectAccess 클라이언트및연결의모든상태및동작을확인할수있습니다. 모니터링콘솔은 DirectAccess 서버의부하, 사용자행위및현재자원사용률을추적하기위해사용됩니다. 관리자는이러한정보를사용하여잠재적으로원하지않는또는적절하지않은사용행태를구분합니다. 진단추적은모니터링콘솔에서활성화할수있습니다. 사용자모니터링 원격접근솔루션의관리자는원격서버에연결한사용자뿐만아니라사용자들이접근한자원들에대한 모니터링이기능이필요합니다. 원격사용자가특정서버및파일공유에접근할수없는반면에다른 페이지 15 / 89

17 사용자는동일자원에대해서성공적으로접근할수있다면, 관리자는현재이러한문제에대해서추적할수있는방법이없습니다. 특정사용자가과도하게대역폭을점유하는것과같은문제를트러블슈팅하기위해전통적으로여러도구및어플리케이션이필요합니다. 내비게이션창내의 Dashboard 탭을선택함으로써, 신규 Remote Access 서버관리콘솔에서 Dashboard 를접근할수있습니다. Dashboard 는전체적인운영상태및원격클라이언트상태및행위를보여줍니다. 또한관리자는 dashboard 로부터직접적인빠른보고서를볼수있습니다. 모니터링 dashboard 는다음항목을위한원격클라이언트연결상태의요약을보여줍니다. 다음정보는성능모니터카운터및 accounting 데이터로부터생성됩니다. Total number of active remote clients connected DirectAccess 및 VPN 서버모두연결된원격클라이언트전체숫자 Total number of active DirectAccess clients connected 오로지, DirectAccess 서버에연결된전체클라이언트숫자 Total number of active VPN clients connected 오로지, VPN 서버에연결된전체클라이언트숫자 Total unique users connected includes both DirectAccess and VPN users, based on the active connections Total number of cumulative connections the total number of connections serviced by the Remote Access Server since the last server restart Maximum number of remote clients connected the maximum concurrent remote users connected to the Remote Access Server since the last server restart Total data transferred the total inbound and outbound traffic from the Remote Access Server for both DirectAccess and VPN since the last server restart Inbound traffic Total bytes/traffic into the remote access server/gateway Outbound traffic Total bytes/traffic out of the remote access server/gateway 클러스터배포에서, Remote Access Dashboard 상의원격클라이언트행위및상태요약은클러스터내의모든노드의총합입니다. 관리자는현재연결된모든원격사용자들을확인할수있고, 특정원격사용자를클릭함으로써특정사용자가접근할수있는모든자원항목도볼수있습니다. Remote Access 관리콘솔내의 Remote Client Status 링크를선택함으로써, 관리자는원격사용자통계정보를볼수있습니다. 사용자통계정보는아래필드를통해필터링할수있습니다 : Field Name Username Value The user name or alias of the remote user. Wildcards may be used to select a group 페이지 16 / 89

18 of users, such as contoso\* or *\administrator. If no domain is specified, then *\username is assumed. Usergroup Hostname Type ISP address IPv4 address IPv6 address Protocol/Tunnel Accessing All the users in the specified AD security group. The computer account name of the remote user. An IPv4 or IPv6 address can be specified as well. Either DirectAccess or VPN. If DirectAccess is selected, then all remote users connecting using DirectAccess are listed. If VPN is selected, then all remote users connecting using VPN are listed. The IPv4 or IPv6 address of the remote user The inner IPv4 address of the tunnel connecting the remote user to the corporate network The inner IPv6 address of the tunnel connecting the remote user to the corporate network The transitioning technology used by the remote client Teredo, 6to4 or IP-HTTPS in case of DirectAccess users, and PPTP, L2TP, SSTP or IKEv2 in case of VPN users All users accessing a particular corporate resource or an endpoint. The value corresponding to this field is the hostname/ip address of the server/endpoint 서버운영상태관리자가중앙화된모니터링콘솔에서원격접근배포의상태를관리및모니터링할수기능이 서버운영상태 (Server Operational Status) 입니다. 주의가요구되는문제가검출될때마다, 이기능은관리자에게경보를알려줍니다. 이기능은문제해결단계를포함한상세진단정보를보여줍니다. 컨솔트리의 Dashboard 노드는 Remote Access Server 의상태를보여줍니다. 콘솔트리의서버 Operations Status 노드는 Remote Access Server 의상태를보여줍니다. 특정구성요소를클릭함으로써, 관리자는해당구성요소의상세상태, 변경기록및모니터링정보를볼수있습니다. Remote Access Server 가클러스터또는다중사이트에서배포되었다면, 클러스터또는다중사이트내의모든서버들은비동기적으로평가되고, 서버들의전반적인상태를볼수있습니다. 관리자는서버항목들을스크롤할수있고, DirectAccess 및 VPN 서버구성요소들을확장및축소하여확인할수있습니다. Server Operational Status 에서확인할수있는 Remote Access 구성요소는아래와같습니다 : 6to4 DNS 페이지 17 / 89

19 DNS64 Domain controller IP-HTTPS IPsec ISATAP Kerberos Management Servers NAT64 Network Adapters Network Location Server Network Security (IPsec DoSP) Services Teredo Load Balancing VPN addressing VPN connectivity 진단 (Diagnostics) RRAS 및 DirectAccess 서버에대한원격접근연결실패원인분석은현재제공되는제한된로깅때문에상당히복잡합니다. 전형적으로, 관리자는원인분석을위해네트워크모니터캡처및 RRAS 추적을사용합니다. 특히, 이벤트뷰어로그는원인분석을위해필요한정보를제공하지못합니다. Windows Server 2012 는원격접근원인분석을위해향상된진단기능을제공합니다. DirectAccess 를위한상세이벤트로깅 (Detailed event logging for DirectAccess) 추적및패킷캡처 (Tracing and Packet Capture) : Start tracing 태스크 로그상관관계 (Log Correlaton) 로그활성화및보기 (Enabling/Viewing Logs) Accounting 및 Reporting A Windows Server 2012 remote access server can leverage an existing RADIUS server deployment or Windows Internal Database (WID) for accounting purposes. The NPS accounting store only contains user statistics, and server statistics and configuration changes are not stored in the remote accounting store. Information and historical data for load and server status are available through system Performance Monitor counters, and are stored in the WID accounting store. Whenever any 페이지 18 / 89

20 connection is received or disconnected on the remote access server, all the remote user statistics (including the endpoints accessed) is saved in the accounting store as one user session. This allows session details to later be accessed for reporting and auditing purposes. The accounting and reporting functionality provided in the Remote Access Server Role includes the ability to measure specific metrics. Available metrics include the number of users connected to a particular DirectAccess server, access status, and total bytes transferred. Administrators can create custom reports to identify traffic and usage patterns, including a history of these patterns. DirectAccess and RRAS reporting capabilities enable administrators to generate rich usage reports on various user and server statistics such as remote user statistics, server availability and load. The inbox accounting store is leveraged to generate the usage report. Inbox accounting to a local WID database must be enabled in order to generate usage reports. NPS/RADIUS accounting is not used for generating reports. The usage report provides a display of usage history including which users established remote connections, what resources they accessed, the total number of unique users, and maximum server load generated. The administrator can select a specific timeframe from which to generate the data. Site-to-Site IKEv2 IPsec 터널모드 VPN 서비스호스팅제공자가고객어플리케이션및인프라를클라우드쪽으로마이그레이션할수있도록, Windows Server 2012 는 Cross Premise 연결을제공합니다. Cross Premise 연결기능은 site-to-site IKEv2 터널모드 VPN 연결솔루션및관리인터페이스를포함합니다. IKEv2 를지원하는 RRAS VPN 연결은 Windows Server 2008 R2 에서지원되었습니다. 클라이언트가특정네트워크에서다른네트워크로이동할때또는클라이언트의네트워크환경이유선에서무선으로변경될때, 이러한다양한네트워크환경변화에도탄력적으로 VPN 서버에 VPN 클라이언트가연결할수있는기능을 IKEv2 가지원합니다. IKEv2 및 IPsec 사용하여, 강한인증및보안방법을구현할수있습니다. Windows Server 2012 RRAS 는 site-to-site VPN 연결에서 IKEv2 를사용할수있는부가적인향상된기능을지원합니다. 페이지 19 / 89

21 IPv4 only 네트워크환경에서 DirectAccess 설치및구성 개요 테스트랩개요 아래와같이총 4 대의서버컴퓨터와 2 대의클라이언트컴퓨터를사용하여, 단일 DirectAccess 서버를구축하기위해방법을테스트합니다. 각컴퓨터의역할은아래와같습니다 : DC1 : Windows Server 2012, Domain Controller, Domain Name System (DNS), 및 Dynamic Host Configuration Protocol (DHCP) EDGE1 : Windows Server 2012, DirectAccess 서버 APP1 : Windows Server 2012, 일반어플리케이션서버, 웹서버 INET1 : Windows Server 2012, 인터넷 DHCP 서버, DNS 서버및웹서버 CLIENT1 : Windows 8, DirectAccess 클라이언트 NAT1 : Windows XP, Internet Connection 공유를사용한 NAT 디바이스역할 Direct Access 서버구축테스트환경을위해아래와같이총 3 개의네트워크를구성합니다 : 인터넷영역 : Internet ( /24). EDGE1 서버의인터넷네트워크영역과구분되는인트라넷영역 : Corpnet ( /24). 인터넷과연결된 NAT에의해구분되는홈네트워크영역 : Homenet ( /24) 컴퓨터들은아래그림과같이허브또는스위치를사용하여연결된각서브넷에존재합니다 페이지 20 / 89

22 Windows Server 2012 DirectAccess 는단순화된원격접근솔루션을배포하기위해 IPv6 배포또는 PKI 인프라가더이상필수조건이아닙니다. 본테스트환경에서, 인증서가필요하지않은 IPv4 환경에서만 DirectAccess 를구축하는방법을소개합니다. 하드웨어및소프트웨어요구사항 이번테스트랩에필요한하드웨어및소프트웨어구성요소는아래와같습니다. The product disc or files for Windows Server The product disc or files for Windows 8. Five computers or virtual machines that meet the minimum hardware requirements for Windows Server 페이지 21 / 89

23 DirectAccess 테스트랩구성절차 (for Windows 8 Client) Remote Access express 설정 을사용하여 DirectAccess 서버의배포를설정하기위해서는아래총 4 단계를수행해야합니다. Note 이과정을수행하기위해서는반드시 Domain Admins 그룹구성원으로각서버를로그인해야합니다. Step 1: Complete the Base Configuration Test Lab - 기본구성테스트랩을구성합니다. 기본테스트랩구성및 Homenet 기본테스트랩구성은다음링크를참조합니다. Test Lab Guide: Windows Server "8" Beta Base Configuration with Optional mini-module: Homenet subnet Step 2: Configure DC1. DC1 은사전에도메인컨트롤러구성되어있어야합니다. 또한, 추가적으로 DNS 및 DHCP 서비스가구성되어야합니다. DirectAccess 클라이언트를구성원으로지정할수있도록 Active Directory 에보안그룹을생성합니다. Step 3: Configure EDGE1. EDGE1 은사전에도메인멤버서버를구성되어있어야합니다. EDGE1 서버는 DirectAccess 서버로구성됩니다. Step 4: Configure CLIENT1. CLIENT1 컴퓨터는사전에도메인멤버클라이언트로구성되어있어야합니다. 이컴퓨터는추후 DirectAccess 클라이언트역할을수행합니다. 페이지 22 / 89

24 Step 1 : 기본테스트랩설정 이번단계에서는 Test Lab Guide: Windows Server "8" Beta Base Configuration 링크의 Steps for Configuring the Corpnet Subnet 및 Steps for Configuring the Internet Subnet 부분을참조하여 Corpnet 및 Internet 서브넷테스트환경구축을완료합니다. 또한, Optional mini-module: Homenet subnet 링크를참조하여 Homenet 서브넷구성도완료합니다. 본테스트환경에서는 PKI 인프라가필요치않으므로, 다음링크는 Optional mini-module: Basic PKI 수행하지않습니다. 페이지 23 / 89

25 Step 2 : DC1 구성 이번단계에서는 DirectAccess 클라이언트역할을수행하는도메인클라이언트컴퓨터들을구성하는보안그룹을 Active Directory 에생성합니다. DirectAccess 를구성할때, DirectAccess 설정을포함하는 GPO 를자동으로생성합니다. 이러한 GPO 설정은 DirectAccess 서버및클라이언트에적용됩니다. 아래단계는자동적으로생성되는 DirectAccess 클라이언트를위한 GPO 설정이적용될보안그룹을생성합니다. 1. 도메인관리자계정으로 DC1 서버에로그인합니다. 2. 도메인컨트롤러에서, Active Directory Administrative Center 도구를수행합니다. Start 를 클릭한후, Active Directory Administrative Center 를클릭합니다. 3. 콘솔트리에서, CORP (local) 를확장하기위해화살표를클릭한후, Users 를클릭합니다. 4. Tasks 창에서, New -> Group 를클릭합니다. 페이지 24 / 89

26 5. Create Group 다이얼로그에서, Group name 부분에 DirectAccessClients 를입력합니다. 6. Create Group 다이얼로그의 Members 부분에접근하기위해마우스를스크롤다운한후, Add 를클릭합니다. 페이지 25 / 89

27 7. Object Types 를클릭한후, Computers 를선택한후, OK 를클릭합니다. 8. CLIENT1 를입력한후, OK 를클릭합니다. 페이지 26 / 89

28 9. Create Group 다이얼로그를닫기위해 OK 를클릭합니다. 위와같이 DirectAccessClients 보안그룹을생성한후, 아래와같이 Active Directory Users and Computers 도구에서확인할수있습니다. 10. Active Directory Administrative Center 를닫습니다. 위전체과정은아래와같은 Windows PowerShell 을사용하여구성할수도있습니다. New-ADGroup -GroupScope global -Name DirectAccessClients Add-ADGroupMember -Identity DirectAccessClients -Members CLIENT1$ 페이지 27 / 89

29 Step 3 : EDGE1 구성 이번단계에서는, IPv4-only 환경에서 DirectAccess 서버구축을위해 EDGE1 서버에 Remote Access 서버역할설치및구성하는방법을확인합니다. 아래와같이 2 가지단계를통해설치및구성을진행합니다. EDGE1 서버에 Remote Access 서버역할설치 Getting Started 마법사를사용하여단순화된 DirectAccess 배포위 2 가지단계의상세절차는아래와같습니다. EDGE1 서버에 Remote Access 서버역할설치 Windows Server 2012 Remote Access 서버역할은 DirectAccess 기능과 RRAS 역할서비스가결합된형태로제공됩니다. 신규 Remote Access 서버역할은 DirectAccess 및 VPN 의관리, 구성및모니터링을수행하기위한중앙화된단일관리도구를제공합니다. 1. 도메인관리자계정으로 EDGE1 서버에로그인합니다. 2. 서버관리자가자동으로시작될것입니다. 만약, 서버관리자가자동으로시작되지않는다면, Start를클릭한후, servermanager.exe를입력하고, Server Manager를클릭합니다. 3. QUICK START 부분에서, Add roles and features를클릭합니다. 4. 서버역할선택페이지로진행하기위해, Next 를 3번연속클릭합니다. 5. 서버역할선택페이지에서, Remote Access 를선택한후, Add Features를선택한후, Next 를클릭합니다. 페이지 28 / 89

30 6. 기능, Remote Access 역할서비스및 Web 서버역할서비스의기본을그대로유지하기위해, Next 를 5 번연속클릭합니다. 7. Confirmation 페이지에서, Install 을클릭합니다. 페이지 29 / 89

31 8. 기능설치가완료된후, Close 를클릭합니다. 페이지 30 / 89

32 위전체과정은아래와같은 Windows PowerShell 을사용하여구성할수도있습니다. Install-WindowsFeature RemoteAccess -IncludeManagementTools Getting Started 마법사를사용하여단순화된 DirectAccess 배포 신규 Getting Started 마법사는 DirectAccess 구성을아주단순하게처리할수있는방법을제공합니다. 마법사는 DirectAccess 구성의복잡성을제거하고, 몇개의단순단계는자동화된설정방법을제공합니다. 또한, Windows Server 2008 R2 DirectAccess 구성시에필수적인요소인내부 PKI 배포는이제 Windows Server 2012 DirectAccess 구성시에는필수적인요소가아닙니다. 즉, Windows Server 2012 DirectAccess 구성에서 Kerberos Proxy 를자동적으로구성함으로써내부 PKI 배포를대체할수있습니다. 1. 도메인관리자계정으로 EDGE1 서버에로그인합니다. 2. EDGE1 서버에서, Remote Access Management 도구를수행합니다. Start 를클릭한후, Remote Access Management 를클릭합니다. 페이지 31 / 89

33 3. Remote Access Management 콘솔에서, Run the Getting Started 마법사를클릭합니다. 4. Deploy DirectAccess Only 를클릭합니다. 페이지 32 / 89

34 5. 네트워크토폴로지로써 Edge 방식이선택되어있음을확인합니다. Remote Access 클라이언트가연결할공개이름으로써 EDGE1.CONTOSO.com 을입력한후, Next 를 클릭합니다. 6. 마지막마법사페이지에서, 마법사설정을편집하기위해제공되는 Here 링크를클릭합니다. 7. Remote Access Review 다이얼로그에서, Remote Clients 옆의 Change 를클릭합니다. 페이지 33 / 89

35 8. Select Groups 페이지에서, Enable DirectAccess for the mobile computers only 체크상자를 비활성화합니다. 페이지 34 / 89

36 9. Domain Computers (CORP\Domain Computers) 를클릭한후, Remove 를클릭합니다. 10. Add 를클릭한후, DirectAccessClients 를입력한후, OK 를클릭합니다. 11. Next 를클릭한후, Finish 를클릭합니다. 추후, DirectAccess 클라이언트가 Internet 영역이나 Homenet 영역에서 DirectAccess 서버에정상적으로연결되면, Workplace Connection 으로 네트워크연결이름이보여짐을확인할수있습니다. 페이지 35 / 89

37 12. Remote Access Review 페이지에서 OK 를클릭한후, Finish 를클릭합니다. 페이지 36 / 89

38 13. 본테스트환경에서 PKI 환경이없으므로, 마법사는 IP-HTTPS 및 Network Location Server 용도의 self-signed 인증서를자동으로생성합니다. 또한, 마법사는자동적으로 Kerberos Proxy를활성화합니다. 또한, 마법사는 IPv4-only 환경을위해프로토콜전환을위한 NAT64 및 DNS64도자동적으로구성합니다. 마법사가성공적으로구성을완료한후, Close를클릭합니다. 페이지 37 / 89

39 14. Remote Access Management 콘솔의콘솔트리에서, Operation Status 를선택합니다. 모든 모니터항목의상태가 Working 로보여질때까지기다립니다. Monitoring -> Task 창에서, 디스플레이를정기적으로업데이트하기위해 Refresh 를클릭합니다. 15. 위와같이 DirectAccess 구성이성공적으로완료된후, GPMC 도구에서아래와같이 DirectAccess 구성에연관된 DirectAccess Clients Setting 및 DirectAccess Servers Setting 2 개의 GPO 가자동적으로생성되어있음을확인할수있습니다. 페이지 38 / 89

40 16. 또한, 아래와같이 DNS 에자동적으로 DirectAccess 서버구성과관련된 HOST 항목들이 등록되어있음을확인할수있습니다. 17. 또한, EDGE1 서버의 인증서 -> Local Computer -> Personal -> Certificates 에서총 3 개의 Self-Signed 인증서가자동적으로생성되어있음도확인할수있습니다. 페이지 39 / 89

41 Step 4 : CLIENT1 구성 CLIENT1 컴퓨터의 Remote Access 연결성에대한검증을위해아래와같이총 4 단계를수행합니다 : CLIENT1 컴퓨터를 Corpnet 서브넷에연결한후, 그룹정책업데이트 CLIENT1 컴퓨터를 Internet 서브넷에연결한후, 원격연결테스트 CLIENT1 컴퓨터를 Homenet 서브넷에연결한후, 원격연결테스트 EDGE1 DirectAccess 서버상에서클라이언트연결모니터 CLIENT1 컴퓨터를 Corpnet 서브넷에연결한후, 그룹정책업데이트 1. CLIENT1 컴퓨터를 Corpnet 서브넷에연결한후, 명령어창에서 gpupdate /force 를 수행합니다. 2. CLIENT1 컴퓨터에서, Windows PowerShell 도구를관리자권한으로수행합니다. Start 를 클릭한후, PowerShell 을입력한후, Windows PowerShell 를오른쪽마우스클릭한후, Run as Administrator 를클릭합니다. 페이지 40 / 89

42 3. Get-DnsClientNrptPolicy 를입력한후, Enter 를누릅니다. DirectAccess 를위한 NRPT(Name Resolution Policy Table) 항목이보여집니다. 이항목에서, NLS 서버배제항목이 DirectAccess- NLS.corp.contoso.com 으로보여짐을확인할수있습니다. DirectAccess- NLS.corp.contoso.com FQDN 은 Getting Started 마법사에서자동적으로생성된 DirectAccess 서버를위한 DNS 항목입니다. 또한, DirectAccess 서버가 NLS(Network Location Server) 역할을수행할수있도록, DirectAccess-NLS.corp.contoso.com 라는 Self-Signed 인증서도자동으로구성되어있습니다. 4. Get-NCSIPolicyConfiguration 를입력한후, Enter 를누릅니다. 마법사에의해배포된 네트워크연결성상태지시자 (Network Connectivity Status Indicator) 의항목을확인할수있습니다. DomainLocationDeterminationURL 값이 NLS.corp.contoso.com:443/insideoutside 임을확인합니다. NLS URL 을클라이언트에서연결가능하다면, 클라이언트는 Corp 서브넷에존재함을의미하고, 결론적으로 NRPT 설정은적용되지않습니다. 페이지 41 / 89

43 5. Get-DAConnectionStatus 를입력한후, Enter 를누릅니다. 클라이언트가 NLS URL 에접근할 수있기때문에, 상태는 ConnectedLocally 임을확인할수있습니다. CLIENT1 컴퓨터를 Internet 서브넷에연결한후, 원격연결테스트 1. CLIENT1 컴퓨터를 Internet 서브넷에연결합니다. 네트워크위치결정프로세스과정이완료된 후, 네트워크아이콘이인터넷영역을지시함을확인합니다. 2. CLIENT1 컴퓨터에서, Windows PowerShell 도구를관리자권한으로수행합니다. Start 를 클릭한후, PowerShell 을입력한후, Windows PowerShell 를오른쪽마우스클릭한후, Run 페이지 42 / 89

44 as Administrator 를클릭합니다. Get-DAConnectionStatus 를입력한후, Enter 를누릅니다. 상태는 ConnectedRemotely 임을확인할수있습니다. 3. 시스템알림영역내의네트워크아이콘을클릭합니다. Workplace Connection 항목이 Connected 상태임을확인합니다. 이네트워크연결항목이름은앞서 DirectAccess 마법사를 사용하여자동으로제공된이름입니다. ( 주의 ) Windows 8 클라이언트의경우, 위화면에서 Workplace Connection 부분이 연결중 상태가 유지되는경우가있을수있습니다. 이때, 아래명령어를사용하여 6to4 인터페이스를 비활성화 합니다. Netsh interface 6to4 set state state=disabled 4. Workplace Connection 을오른쪽마우스클릭한후, Properties 를클릭합니다. 상태가 Connected 임을확인할수있습니다. 페이지 43 / 89

45 5. PowerShell 에서, ping inet1.isp.example.com 을수행하여본테스트환경에서의인터넷연결 및이름해결이정상적임을확인합니다. 아래와같이 로부터총 4 번의응답을 확인할수있습니다. 6. 또한, 현재 CLIENT1 이인터넷영역에있음에도불구하고, DirectAccess 클라이언트기능을이용하여, 인트라넷영역의이름해결및연결이정상적임을확인하기위하여 ping app1.corp.contoso.com 을수행합니다. 응답이 IPv6 형식으로반환됨을확인합니다. 본테스트랩환경에서어떠한 IPv6 인프라도없기때문에, 자동으로생성된 APP1 서버의 NAT64 주소가반환됨을확인합니다. NAT64 를위해 DirectAccess 에의해자동으로할당된 Prefix 는 fdxx:xxxx:xxxx:7777::/96 형식임을반드시확인합니다. 페이지 44 / 89

46 7. CLIENT1 에서 IE 를수행합니다. 다음 2 개의웹사이트를접근하여정상적으로수행됨을 확인합니다. 및 서버의 IE 결과를확인합니다. 페이지 45 / 89

47 8. CLIENT1 에서윈도우탐색기를수행한후, 주소창에서 \\app1\files 라는공유폴더를 접근하여정상적으로공유폴더가접근됨을확인합니다. 9. PowerShell 에서, Get-NetIPAddress 를입력한후, ENTER 를누립니다. CLIENT1 컴퓨터의 IPv6 주소구성을확인합니다. 터널어댑터 iphttpsinterface 에유효한 IP-HTTPS 주소가활성화되어있음을확인합니다. CLIENT1 은 EDGE1 서버로의 IPv6 트래픽을터널링하기위해 IP-HTTPS 를사용합니다. 페이지 46 / 89

48 페이지 47 / 89

49 10. 또한, PowerShell 에서, Get-NetIPHTTPSConfiguration 를입력한후, ENTER 를누립니다. DirectAccess 클라이언트가 를연결하기위해그룹 정책에의해적용된설정사항을확인합니다. 11. CLIENT1 에서 Windows Firewall with Advanced Security 콘솔을수행하기위해, wf.msc 를명령어창에서수행합니다. Monitoring 항목에서, 연결된 IPsec SA 를확인하기위해 Security Association 를클릭합니다. 사용된인증방법이컴퓨터 Kerberos 및사용자 Kerberos 임을확인할수있습니다. 즉, 어떠한인증서기반의인증방법이사용되지않았음을확인할수있습니다. 즉, 앞서초기에언급한것처럼, Windows Server 2012 DirectAccess 단순구성방법에서자동으로구성한 Kerberos Proxy 방법이사용되었음을다시한번확인할수있습니다. 그러나, Enterprise 환경에서 DirectAccess 서버를 2 대이상운영하기위해서는, 인증서기반의인증방법을별도로구성해야함을유념해야합니다. 또한, DirectAccess 연결을위해사용된정책은 Connection Security Rules 항목에서확인할수있습니다. 페이지 48 / 89

50 12. Windows Firewall with Advanced Security 콘솔을닫습니다. 13. 마지막으로, EDGE1 서버의 Remote Access Management 콘솔의 REMOTE CLIENT STATUS 부분에서연결된 CLIENT1 컴퓨터를확인할수있습니다. 페이지 49 / 89

51 CLIENT1 컴퓨터를 Homenet 서브넷에연결한후, 원격연결테스트 1. CLIENT1 컴퓨터를 Homenet 서브넷에연결합니다. 네트워크위치결정프로세스과정이 완료된후, 네트워크아이콘이인터넷영역을지시함을확인합니다. 2. CLIENT1 컴퓨터에서, Windows PowerShell 도구를관리자권한으로수행합니다. Start 를클릭한후, PowerShell 을입력한후, Windows PowerShell 를오른쪽마우스클릭한후, Run as Administrator 를클릭합니다. Get-DAConnectionStatus 를입력한후, Enter 를누릅니다. 상태는 ConnectedRemotely 임을확인할수있습니다. 3. 시스템알림영역내의네트워크아이콘을클릭합니다. Workplace Connection 항목이 Connected 상태임을확인합니다. 이네트워크연결항목이름은앞서 DirectAccess 마법사를 사용하여자동으로제공된이름입니다. 페이지 50 / 89

52 4. Workplace Connection 을오른쪽마우스클릭한후, Properties 를클릭합니다. 상태가 Connected 임을확인할수있습니다. 5. 현재 CLIENT1 이 Homenet 영역에있음에도불구하고, DirectAccess 클라이언트기능을이용하여, 인트라넷영역의이름해결및연결이정상적임을확인하기위하여 ping app1.corp.contoso.com 을수행합니다. 응답이 IPv6 형식으로반환됨을확인합니다. 본테스트랩환경에서어떠한 IPv6 인프라도없기때문에, 자동으로생성된 APP1 서버의 NAT64 주소가반환됨을확인합니다. NAT64 를위해 DirectAccess 에의해자동으로할당된 Prefix 는 fdxx:xxxx:xxxx:7777::/96 형식임을반드시확인합니다. 페이지 51 / 89

53 6. CLIENT1 에서 IE 를수행합니다. 다음 2 개의웹사이트를접근하여정상적으로수행됨을 확인합니다. 및 서버의 IE 결과를확인합니다. 페이지 52 / 89

54 7. CLIENT1 에서윈도우탐색기를수행한후, 주소창에서 \\app1\files 라는공유폴더를 접근하여정상적으로공유폴더가접근됨을확인합니다. 8. PowerShell 에서, Get-NetIPAddress 를입력한후, ENTER 를누립니다. CLIENT1 컴퓨터의 IPv6 주소구성을확인합니다. 터널어댑터 iphttpsinterface 에유효한 IP-HTTPS 주소가활성화되어있음을확인합니다. CLIENT1 은 EDGE1 서버로의 IPv6 트래픽을터널링하기위해 IP-HTTPS 를사용합니다. 以前 DirectAccess 버전에서, 본테스트환경과같은 NAT 후면에위치한사설 IPv4 주소를가진클라이언트는 Teredo IPv6 주소변환기술을사용하여내부인트라넷자원에연결했었습니다. 그러나, Windows Server 2012 DirectAccess 는오로지 IP- HTTPS 기술만을사용하여내부인트라넷자원에연결합니다. 페이지 53 / 89

55 9. 또한, PowerShell 에서, Get-NetIPHTTPSConfiguration 를입력한후, ENTER 를누립니다. DirectAccess 클라이언트가 를연결하기위해그룹 정책에의해적용된설정사항을확인합니다. 10. CLIENT1 에서 Windows Firewall with Advanced Security 콘솔을수행하기위해, wf.msc 를명령어창에서수행합니다. Monitoring 항목에서, 연결된 IPsec SA 를확인하기위해 Security Association 를클릭합니다. 사용된인증방법이컴퓨터 Kerberos 및사용자 Kerberos 임을페이지 54 / 89

56 확인할수있습니다. 즉, 어떠한인증서기반의인증방법이사용되지않았음을확인할수있습니다. 즉, 앞서초기에언급한것처럼, Windows Server 2012 DirectAccess 단순구성방법에서자동으로구성한 Kerberos Proxy 방법이사용되었음을다시한번확인할수있습니다. 그러나, Enterprise 환경에서 DirectAccess 서버를 2 대이상운영하기위해서는, 인증서기반의인증방법을별도로구성해야함을유념해야합니다. 또한, DirectAccess 연결을위해사용된정책은 Connection Security Rules 항목에서확인할수있습니다. 11. Windows Firewall with Advanced Security 콘솔을닫습니다. 12. 마지막으로, EDGE1 서버의 Remote Access Management 콘솔의 REMOTE CLIENT STATUS 부분에서연결된 CLIENT1 컴퓨터를확인할수있습니다. 페이지 55 / 89

57 페이지 56 / 89

58 DirectAccess 클라이언트를위한 DirectAccess 구성절차 (for Windows 8 & Windows 7) 앞서 Getting Started 마법사를사용하여구성한 Windows Server 2012 DirectAccess 서버는오로지 Windows 8 클라이언트만지원가능합니다. Windows Server 2012 DirectAccess 서버에서 Windows 7 클라이언트를 DirectAccess 클라이언트로지원하기위해서는별도의설정이필요합니다. 기본적으로앞서 Getting Started 마법사를사용하여생성한 DirectAccess 구성은제거한후, 별도의구성방법을사용해야하고, 事前에 DirectAccess 클라이언트에게필요한 컴퓨터인증서 발급을위한 PKI 인프라도필요합니다. 페이지 57 / 89

59 Step 1 : 기존 DirectAccess 구성제거 이번단계에서는앞서구성한기존 DirectAccess 구성을제거합니다. 1. 도메인관리자계정으로 EDGE1 서버에로그인합니다. 2. EDGE1 서버에서, Remote Access Management 도구를수행합니다. Start 를클릭한후, Remote Access Management 를클릭합니다. 3. 원격액세스관리콘솔의작업 -> 일반 -> 구성설정제거링크를클릭하여, 기존구성을제거합니다. 4. 제거구성확인다이얼로그상자에서확인버튼을클릭하여제거작업을진행합니다. 페이지 58 / 89

60 5. 구성설정제거작업이아래와같이완료된후, 닫기버튼을클릭합니다. 6. 원격액세스관리콘솔의구성부분에서아래와같이 원격액세스구성 부분이보여짐을 확인할수있습니다. 페이지 59 / 89

61 이상과같이기존 DirectAccess 구성이성공적으로제거되었음을반드시확인합니다. 페이지 60 / 89

62 Step 2 : Windows 7 클라이언트준비 Windows Server 2012 DirectAcces 의 Windows 7 클라이언트지원을위한데모용 Windows 7 컴퓨터를 준비합니다. 기존 CORP 도메인에죠인된 Windows 7 Enterprise 버전이상의컴퓨터를준비합니다. 아래와같이데모용 Windows 7 컴퓨터를확인합니다. 페이지 61 / 89

63 Step 3 : Windows 7 클라이언트를위한보안그룹생성 이제앞서구성한 Windows 8 클라이언트를위한 DirectAccess 보안그룹을생성했습니다. 이번 단계에서는 Windows 7 클라이언트를위한 DirectAccess 보안그룹을생성합니다. 1. 도메인관리자계정으로 DC1 서버에로그인합니다. 2. 도메인컨트롤러에서, Active Directory 사용자및컴퓨터도구를수행합니다. Start 를클릭한 후, Active Directory 사용자및컴퓨터를클릭합니다. 3. Users 컨테이너를오른쪽마우스클릭한후, 새로만들기 -> 그룹순서로클릭합니다. 4. 그룹이름부분에 DirectAccessClientsWindows7 을입력한후, 확인버튼을클릭하여, 그룹을 생성합니다. 페이지 62 / 89

64 5. DirectAccessClientsWindows7 그룹의구성원으로써앞서준비한 CLIENT2W7 컴퓨터를 추가합니다. 이상과같이 Windows7 클라이언트를위한보안그룹의생성을완료합니다. 페이지 63 / 89

65 Step 4 : 기존도메인에 Private CA 설치확인 Windows 7 클라이언트를 DirectAccess 2012 에서지원하기위해서는, 반드시 PKI 인프라가필요합니다. 기존 CORP 도메인에아래링크를참조하여 Private CA 설치및인증서자동발급을위한구성을 완료합니다. Optional mini-module: Basic PKI ( ) 위구성을완료한후, 아래와같이설치되었음을확인합니다. 본테스트환경에서는위링크와는다르게 DC1 서버에 Private CA 를구성했습니다. 또한, DirectAccess 서버및 DirectAccess 클라이언트의인증서를위한인증서템플릿은위링크와는 다르게 컴퓨터 for MMC 로생성했습니다. 아래그림과같이 컴퓨터 for MMC 인증서템플릿이 CORP-DC1-CA 인증기관의인증서템플릿에추가되어있음을확인합니다. 페이지 64 / 89

66 컴퓨터 for MMC 인증서템플릿의자동발급을위해보안설정을확인합니다. 인증서템플릿 스냅 - 인 관리도구에서 컴퓨터 for MMC 인증서템플릿의속성 -> 보안설정을확인합니다. Domain Computers 그룹의권한이 읽기, 등록, 자동등록 으로설정되어있음을확인합니다. 컴퓨터 for MMC 인증서템플릿을사용하여 Domain Computers 그룹의모든컴퓨터들에게인증서를자동발급할수있도록, Default Domain Policy 의 컴퓨터구성 -> 정책 -> Windows 설정 -> 보안설정 -> 공개키정책 -> 인증서서비스클라이언트 자동등록 의속성이아래와같이설정되어있음을확인합니다. 페이지 65 / 89

67 페이지 66 / 89

68 Step 5 : CA 의 CRL 외부공개구성 DirectAccess 클라이언트는기본적으로외부네트워크상에서내부네트워크로접근하기위해서는 DirectAccess 서버를반드시경유해야합니다. 이때, DirectAccess 클라이언트와 DirectAccess 서버사이의통신을위해서사용되는네트워크인터페이스는 IPHTTPS 입니다. IPHTTPS 네트워크인터페이스를사용하기위해서는 DirectAccess 클라이언트및서버는반드시앞서구성한인증서가필요합니다. 여기에서중요한점은, DirectAccess 클라이언트및서버에발급된인증서에포함된 CRL(Certificate Revocation List) 이외부에서접근가능해야합니다. CRL 은기본적으로 LDAP 경로를정의되어있습니다. 1. 인증기관 -> 속성 -> 확장순서로클릭하여, CRL 의 ldap 경로가있음을확인할수있습니다. 페이지 67 / 89

69 2. DirectAccess 클라이언트가외부에서 CRL 경로를접근하기위해서는, 아래와같이 http 경로를활성화해야합니다. http 경로를선택한후, 아래옵션을모두선택합니다. CRL 에포함. 클라이언트에서델타 CRL 위치를찾도록해줍니다 (N). 발급된인증서의 CDP 확장에포함 (I) 발급된 CRL 의 IDP 확장에포함 (L) 3. 추가적인 CRL 의 http 경로를구성한후, CA 서비스를반드시재시작합니다. 페이지 68 / 89

70 Step 6 : DirectAccess 서버및 DirectAccess 클라이언트의인증서확인 앞서 컴퓨터 for MMC 인증서템플릿의자동발급을구성했으므로, DirectAccess 서버및 DirectAccess 클라이언트의인증서발급여부를확인합니다. 각컴퓨터의 인증서 -> 로컬컴퓨터 스냅 - 인관리 도구의 인증서 ( 로컬컴퓨터 ) -> 개인용 -> 인증서 폴더를확인합니다. EDGE1.CORP.CONTOSO.com (DirectAccess 서버 ) 인증서속성의 CRL 배포지점 의값에아래와같이 LDAP 및 HTTP 경로가있음을확인할수있습니다. 페이지 69 / 89

71 자동등록으로발급된인증서가아닌 EDGE1.CONTOSO.com 인증서가존재함을확인할수있습니다. 이인증서는별도로발급받아야합니다. 즉, 이인증서는 DirectAccess 클라이언트가외부에서 DirectAccess 서버를접근할때, 사용하는 Common Name ( 중요 : Public FQDN 과반드시동일해야함 ) 을포함한인증서입니다. 또한, 이인증서역시 CRL 배포지점에 HTTP 경로가존재함을확인할수있습니다. 페이지 70 / 89

72 CLIENT1.CORP.CONTOSO.com (DirectAccess 클라이언트 Windows 8) 아래와같이 CLIENT1.CORP.CONTOSO.com 인증서를확인합니다. 페이지 71 / 89

73 CLIENT2W7.CORP.CONTOSO.com (DirectAccess 클라이언트 Windows 7) 아래와같이 CLIENT2W7.CORP.CONTOSO.com 인증서를확인합니다. 페이지 72 / 89

74 Step 7 : DirectAccess 서버구성 이미 Windows 8 클라이어트의 DirectAccess 지원을위해 DirectAccess 서비스의설치를완료했습니다. 이제 Windows 7 및 Windows 8 의 DirectAccess 서비스지원을위한 DirectAccess 서버의구성을 진행합니다. 1. 도메인관리자계정으로 EDGE1 서버에로그인합니다. 2. EDGE1 서버에서, Remote Access Management 도구를수행합니다. Start 를클릭한후, Remote Access Management 를클릭합니다. 3. Remote Access Management 콘솔에서, 원격액세스설정마법사실행을클릭합니다. 4. Deploy DirectAccess 만배포를클릭합니다. 페이지 73 / 89

75 5. 원격액세스설정부분의단계 1 의 구성 버튼을클릭합니다. 6. DirectAccess 클라이언트설정부분의배포시나리오페이지에서, 배포시나리오선택에서 클라이언트액세스및원격관리용으로전체 DirectAccess 배포 (U) 를선택한후, 다음을 진행합니다. 7. DirectAccess 클라이언트설정부분의그룹선택페이지에서, DirectAccessClients 및 DirectAccessClientsWindows7 그룹을선택하여 DirectAccess 클라이언트로적용될 클라이언트를선택합니다. 나머지옵션은선택하지않고다음을진행합니다. 페이지 74 / 89

76 8. DirectAccess 클라이언트설정부분의네트워크연결길잡이페이지에서, 기본설정을변경하지않고, 마침을진행합니다. DirectAccess 연결이름 부분에서, 작업공간연결 이라는이름은추후 DirectAccess 클라이언트가 DirectAccess 연결할때, 클라이언트의네트워크연결부분에표시되는이름입니다. 페이지 75 / 89

77 9. 원격액세스설정부분의단계 2 의 구성 버튼을클릭합니다. 10. Remote Access 서버설정부분의네트워크토폴로지페이지에서, 에지 (E) 를선택한후, 클라이언트가원격액세스서버에연결하는데사용할공개이름또는 IPv4 주소입력 (T): 부분에 EDGE1.CONTOSO.com 을입력한후, 다음을진행합니다. 실제환경에서는 EDGE1.CONTOSO.com FQDN 과해당공인 IP 를공인 DNS 에등록해야합니다. 11. Remote Access 서버설정부분의네트워크어댑터페이지에서, 기본적으로구성된사항을확인한후, 다음을진행합니다. 외부네트워크및내부네트워크에연결된어댑터가정상적인확인한후, 앞서구성한 EDGE1.CONTOSO.com 외부공개 FQDN 에서사용될인증서가정상적인지확인합니다. 페이지 76 / 89

78 12. Remote Access 서버설정부분의인증페이지에서, Windows 7 클라이언트컴퓨터에서 DirectAccess 를통한연결사용 (A) 를선택하게되면, 자동적으로 컴퓨터인증서사용 부분이선택이되고, 찾아보기 버튼을클릭하여, DirectAccess 클라이언트가사용하는인증서를발급했던 CA 루트인증서 (CORP-DC1-CA) 를선택한후, 마침을진행합니다. 페이지 77 / 89

79 13. 원격액세스설정부분의단계 3 의 구성 버튼을클릭합니다. 14. 인프라서버설정부분의네트워크위치서버페이지에서, 원격액세스서버에네트워크위치서버배포 (D) 를선택하게되면, 자동적으로 네트워크위치서버인증에사용할인증서선택 (S): 부분에 CN=EDGE1.CORP.CONTOSO.com 이라는서버인증서가할당됩니다. 즉, 본테스트환경에서는 DirectAccess 를위한네트워크위치서버를별도서버에구성하지않고, DirectAccess 서버에구성합니다. 실제환경에서는, 네트워크위치서버를다른별도에위치시킬수도있습니다. 다음을진행합니다. 15. 인프라서버설정부분의 DNS 페이지에서, 기본설정사항을변경하지않고, 다음을진행합니다. 페이지 78 / 89

80 16. 인프라서버설정부분의 DNS 접미사검색목록페이지에서, 기본설정사항을변경하지않고, 다음을진행합니다. 17. 인프라서버설정부분의관리페이지에서, 기본설정사항을변경하지않고, 마침을진행합니다. 페이지 79 / 89

81 18. 원격액세스설정부분의단계 4 의별도구성을하지않습니다. 19. 원격액세스설정부분의하단에서 마침 버튼을클릭합니다. 20. 원격액세스검토부분에서, 적용 버튼을클릭하여, DirectAccess 서버구성을완료합니다. 페이지 80 / 89

82 페이지 81 / 89

83 21. Remote Access 설정마법사설정적용부분에서, DirectAccess 부하분산을위한대표인증서 부분에경고가발생하지만, 이부분은무시하고 닫기 버튼을클릭하여, 구성을완료합니다. 22. 원격액세스관리콘솔의 작동상태 부분에서 EDGE1.CORP.CONTOSO.com 의 DirectAccess 서비스가정상적으로작동함을확인합니다. 페이지 82 / 89

84 페이지 83 / 89

85 Step 8 : Windows 7 및 Windows 8 DirectAccess 클라이언트테스트 일반적인테스트는앞서 DirectAccess 테스트랩구성절차 (for Windows 8 Client) 부분의 Step 4 : CLIENT1 구성 의절차를그대로진행합니다. 이단계에서는, 인터넷영역및 Homenet 영역에 클라이언트가연결되었을때, 각클라이언트컴퓨터의 IPCONFIG 부분만확인해봅니다. 인터넷영역의 CLIENT2W7.CORP.CONTOSO.com 의 IPCONFIG Iphttpsinterface 터널어댑터부분에정상적으로 IPv6 주소가할당되어있음을알수있습니다. Homenet 영역의 CLIENT2W7.CORP.CONTOSO.com 의 IPCONFIG Iphttpsinterface 터널어댑터부분에정상적으로 IPv6 주소가할당되어있음을알수있습니다. 페이지 84 / 89

86 인터넷영역의 CLIENT1.CORP.CONTOSO.com 의 IPCONFIG Iphttpsinterface 터널어댑터부분에정상적으로 IPv6 주소가할당되어있음을알수있습니다. 페이지 85 / 89

87 Homenet 영역의 CLIENT1.CORP.CONTOSO.com 의 IPCONFIG Iphttpsinterface 터널어댑터부분에정상적으로 IPv6 주소가할당되어있음을알수있습니다. 페이지 86 / 89

88 DirectAccess 서버의원격클라이언트상태확인 원격액세스관리콘솔의원격클라이언트상태부분에서아래와같이정상적으로연결된 Windows 8 및 Windows 7 클라이언트를확인할수있습니다. 페이지 87 / 89

89 페이지 88 / 89

90 참조자료 Deploy Remote Access in an Enterprise ( ) 'Real World' Direct Access installation using Windows Server 2012 ( ) 페이지 89 / 89