한 울타리 안의 친구들~

시나리오 2
이번 시나리오에서, TS 게이트웨이는 다른 서버에 있는 NPS 중앙 정책을 이용할 것 입니다. 우리는 원격에서 TS 게이트웨이를 통해 연결하는 클라이언트들에 대해 NAP 정책을 적용할것 입니다. 시나리오 1에서 사용했던 구성요소와 같은 구성요소가 사용됩니다. 오직 NPS 서버만 추가되었습니다. 그러나 NAP 적용하기 위해 그림 7에서 보여지는것 과 같이 클라이언트에 추가적인 구성요소가 사용됩니다.
 
그림 7. 시나리오 2 토폴로지의 주요 구성요소들

각각의 개별적인 구성요소에 대해 설명해 드리겠습니다.Windows Vista 클라이언트에서 SHA(System Health Agent)는 모니터링과 클라이언트 건강 상태를 보고하기 위한 클라이언트쪽 구성요소입니다. Windows Vista는 Windows SHA를 가지고 있습니다. 그러나, 그들의 SHAs를 만들어서 동작하게하는 다른 업체들이 있습니다. 클라이언트에 있는 NAP 에이전트는 NAP 서버와 커뮤니케이션 확립을 위해 응답할 수 있습니다. 클라이언트가 네트워크에 연결을 시도할 때 NAP 에이전트는 클라이언트의 SoH(Statement of Health)를 서버로 보냅니다.

TS RAP(Resource Authorization Policy)은 TS 게이트웨이의 구성요소입니다. 그것은 들어오는 RDP 요청에 대해 어떤 컴퓨터가 가능한지를 결정하게 합니다. TS RAP는 또한 어떤 사용자가 특정 서버로 RDP 연결을 맺을 수 있는지에 대해서도 결정합니다.

중앙 NPS는 상태 제어, 구속(constraints), 그리고 내부 컴퓨터에 접근을 통제하는 설정에 대해 응답할 수 있습니다. 중앙 NPS의 SHVs(System Health Validators)는 클라이언트가 제출한 SoH가 관리자가 설정한 정책에 적합한지 아닌지에 대한 평가에 대해 응답할 수 있습니다.

이제 TS 게이트웨이가 NPS 중앙 서버를 가리키게 하겠습니다. TS Gateway Manager 콘솔을 실행합니다. 서버이름에서 마우스 오른쪽 버튼을 클릭합니다. 그리고 속성을 선택합니다. 서버 속성 창에서 TS CAP 저장소를 탭을 클릭한 후 중앙 NPS 서버를 선택합니다. NPS 서버의 IP 주소를 입력합니다. 그리고 추가 버튼을 클릭합니다. 공유 암호 창이 나타납니다. 암호를 입력하고 마침을 클릭합니다. 그리고 마침을 클릭해서 창을 닫습니다. 이 암호는 NPS 서버에서 사용되기 때문에 기억해야합니다.

NPS가 이미 다른 서버에 설치되었다는 가정하에 다음 순서를 진행하십시오.

1. NPS 콘솔을 실행합니다. 왼쪽에 NPS(Loacl)을 클릭합니다.
2. 오른쪽 창에서 NAP 구성을 클릭합니다. "네트워크 연결 방법"이 나타납니다.
3. 네트워크 연결 방법 아래에서 "TS 게이트웨이(터미널 서비스 게이트웨이)"를 선택합니다.
4. "TS 게이트웨이를 실행하는 NAP 적용 서버 지정"에서 "추가"버튼을 클릭합니다.
5. "새 TS 게이트웨이 서버"에서 TS 게이트웨이 서버의 IP나 이름을 입력합니다. 그리고 아래에 공유 암호를 입력합니다. 그리고 "확인"을 클릭합니다.
6. "클라이언트 장치 리디렉션 및 인증 방법 구성"페이지에서 리디렉션할 장치를 지정하고 허용할 인증 방법(암호 허용 또는 스마트 카드 허용)을 선택할 수 있습니다.
7. "사용자 그룹 및 컴퓨터 그룹 구성" 페이지에서 연결을 맺을 사용자 그룹을 추가합니다. 예를들어 "사용자 그룹" 아래의 "사용자 추가"버튼을 클릭합니다. 그리고 "Domain Admins"를 추가합니다. 그리고 "확인"을 누른 후 "다음"을 클릭합니다.
8. "NAP 상태 정책 정의"페이지에서 기본적으로 SHV가 이미 선택되어진 것을 확인할 수 있습니다. 이 페이지 아래에 적합하지 않은 컴퓨터덜은 액세스가 거부된 것도 확인할 수 있습니다. 기본설정대로 놔둔후 "다음"버튼을 클릭합니다.
9. "NAP 적용 정책 및 RADIUS 클라이언트 구성 완료"페이지는 앞에서 선택한 옵션들을 확인 할 수 있습니다. 그리고 "구성 세부 정보" 링크를 클릭하면 선택한 것 들이 요약된 HTML 페이지가 나타날 것 입니다. "마침"을 눌러 구성을 마칩니다.

이 마법사를 통한 작업은 많은 중요한 정책들의 설정을 구성하는데 도움이 됩니다.(연결 요청 정책, 네트워크 정잭 그리고, 성태 정책), 이 시나리오에 대한 NAP을 구성하는데 필요한 작업을 눈에띄게 줄여줍니다.

클라이언트에 대해서
서버가 이제 모두 설치가 되고 설정이 되었습니다. 이제 클라이언트에 대해선 어떤 것을 해야 할까요?

NAP 적용 정책의 이점을 위해 클라이언트는 Windows Server 2008 또는 Windows Vista이어야 합니다. Windows XP는 NAP 클라이언트를 포함하기 위해 SP3가 설치되어야 합니다. 그리고 아래는 몇 개의 관계되는 서비스와 설정입니다.

• 클라이언트에서 신뢰할 수 있는 서버 목록에 TS 게이트웨이 서버의 이름을 추가합니다.
• NAP 에이전트 서비스를 시작합니다. 그리고 서비스 시작 유형을 "자동"으로 설정합니다.
• TS 게이트웨이 격리 적용 클라이언트를 활성화 합니다.

이 솔루션을 쉽게 배포하기 위해서 Microsoft는 터미널 서비스 NAP 클라이언트 설정 명령을 만들었습니다.(Tsgqecclientconfig.cmd) 이것은 여기에서 다운로드 하실 수 있습니다. 명령어를 실행한 후에는 클라이언트는 TS 게이트웨이를 사용하는 NAP 적용 클라이언트로 설정될 것입니다. 명령어는 관리자 권한으로 실행되어야만 합니다.

[원문 Article]
http://technet.microsoft.com/en-us/magazine/cc742827.aspx

외부 RDP 사용자는 연결을 초기화 합니다. 첫 번째로 클라이언트는 TS 게이트웨이의 외부 이름을 풀이할 수 있어야 합니다(여기에서는 tsg.contoso.com). 외부 DNS는 이 이름을 ISA Server의 외부 IP로 이름풀이를 합니다.
SSL 터널은 RDP 클라이언트와 ISA 서버의 외부 인터페이스와의 협상입니다. ISA 서버는 포트 443에 대한 웹 게시 규칙을 가지고 있습니다. 이 포트는 tsg.contoso.com에 발급된 인증서를 사용합니다.
규칙을 평가하고 허용된 트래픽인지 체크한 후 ISA 서버는 웹 게시 규칙에서 지정한 서버의 이름을 풀기 위해 DNS 쿼리를 내부 DNS 서버로 전송합니다.(여기에서는 DC에 설치된 DNS). TS 게이트웨이로 SSL 터널이 열린 다음 ISA 서버는 인증 요청을 TS 게이트웨이로 전달합니다.

TS 게이트웨이 서버는 사용자의 자격 증명을 검증하고 증명합니다. 사용자는 연결할 수 있는 권한을 부여 받습니다. 사용자가 연결 협상에 대한 권한을 부여 받은 후에 TS 게이트웨이 서비스는 TCP 443 포트의 요청들을 받습니다. 그리고 TCP 3389포트를 통해 RDP 패킷을 응용프로그램(CRM 프로그램등) 을 가지고 있는 내부 터미널 서버로 전달합니다.(기본설정) 이 시점에서부터 RDP 클라이언트는 패킷들을 ISA 서버를 통해서 TS 게이트웨이 서비스로 보냅니다. RDP 클라이언트는 이 패킷들을 내부 터미널 서버로 보내고, 내부 터미널 서버는 RDP 클라이언트로 보냅니다.

이 상황이 일어나기 전에 RDP Over HTTPS는 RDP/RPC/HTTPS 그 이상의 무엇도 아니라는 게 중요합니다. RDP 클라이언트는 RPC 헤더안에 RDP 통신을 캡슐화합니다. RPC 헤더는 바로 SSL을 사용해 보안이 적용된(또는 TLS – Transport Level Security) HTTP 헤더로 캡슐화 됩니다. 모든 컴포넌트는 RPC Over HTTPS 솔루션을 위해 필요합니다. 이것은 TS 게이트웨이 역할 서비스를 설치할 때 RCP Over HTTP 프록시가 자동으로 설치되는 이유입니다. 보다 자세하게 프로토콜이 어떻게 동작하는지에 대해 이해하고 싶으시면 "Testing RPC over HTTP Through ISA Server 2006 Part1 : Protocols, Authentication and Processing"을 읽어보십시오. ISA Server Team Blog에서 찾아보실 수 있습니다.
이 방법은 TS 게이트웨이가 설치된 Windows Server 2008이 필요합니다. TS 게이트웨이는 RPC Over HTTP 프록시에 종속됩니다. RDP Over RPC over HTTP 프록시 기능은 꼭 IIS 7.0이 설치되고 실행 되고 있어야 합니다.

그리고 NPA(Network Policy and Access)서비스도 필요합니다. 그리고 만약 원한다면 TS 게이트웨이에 저장소, 관리 그리고 TS-CAPs(Terminal Services Connection Authorization Policies) 검증을 중앙에서 하기 위해 NPS서버를 IAS(Internet Authentication Services)로 사용할 수 있습니다. 마지막으로 TS 게이트웨이 서버용 SSL 인증서가 없다면 발급받아야 합니다. 꼭, ISA Server 2006이 인증서를 발급하는 CA(Certificate Authority)를 신뢰하고 있어야 합니다. 신뢰하기 위해서는 인증서 가져오기를 이용해서 신뢰된 인증 기관 저장소에 인증서를 저장합니다.
TS 게이트웨이 인증 정책이 설정한다면 TS 게이트웨이 인증액티브 디렉터리 도메인 서비스는 필수입니다. TS 게이트웨이 서버에 연결하기 위해서 이 인증 정책은 액티브 디렉터리 보안 그룹의 멤버의 사용자를 필요로합니다.이 특별한 설치는 Windows Server 2003 SP2가 실행되는 액티브 디렉터리를 사용할 수 있습니다.
TS 게이트웨이 서비스 설치가 끝나면 설치된 컴포넌트들을 볼 수 있는 그림 2와 같은 화면이 나타납니다. TS 게이트웨이에 연결하기 위해 클라이언트는 Windows Vista, Windows XP with SP2 와 RDP 6.0 또는 그 이상, Windows Server 2008, Windows Server 2003 with SP1 또는 그 이상, RDP 6.0 이상의 환경이어야만 합니다. TS 게이트웨이 설정의 보다 자세한 정보는 Windows Server 2008 TS 게이트웨이 Server Step-by-Step 가이드를 확인해주시기 바랍니다. 자 이제 ISA Server 2006 설정 방법을 확인해 보겠습니다.
 
그림 2 TS 게이트웨이 설치 결과


ISA Server 2006 설정
첫번째 순서는 웹 수신기를 만드는 것 입니다. 웹 수신기는 외부 RDP 클라이언트로부터의 요청을 처리할 것 입니다.
웹 수신기를 다음 사항에 맞게 만들어 주십시오.
Authentication: Basic
Authentication Validation: Windows (Active Directory)
Connections: Enable SSL (HTTPS) connections on port 443
Certificates: certificate issued to tsg.contoso.com
Networks: External

다음으로, 웹 게시 규칙을 만듭니다. RDP 클라이언트는 Outlook Anywhere가 사용하는 프로토콜과 같은 프로토콜을 사용할 것 입니다. 따라서 Exchange Server 2007 마법사를 이용해서 다음 순서대로 진행해 주시기 바랍니다.
1. 방화벽 정책에서 마우스 오른쪽 버튼을 클릭합니다. 새로 만들기를 선택합니다. 그리고 Exchange 웹 클라이언트 액세스 게시 규칙을 클릭합니다.
2. 웹 게시 규칙 생성 마법사 첫 페이지에 규칙 이름을 입력하고 다음을 누릅니다.
3. 서비스 선택 페이지에서 Exchange 버전을 선택합니다. 여기에서는 Exchange Server 2007을 선택합니다. 그리고 "외부에서 Outlook 사용(RPC/HTTP(s))"를 선택한 후 다음을 클릭합니다.(참고: Exchange Server for Outlook 2007 클라이언트에 추가 폴더 게시 옵션은 선택하지 않습니다.)
4. 게시 유형 페이지에서 "단일 웹 사이트 또는 부하 분산 장치 게시"를 선택한 후 "다음"을 클릭합니다.
5. 서버 연결 보안 페이지에서 "SSL을 사용하여 게시된 웹 서버 또는 서버 팜에 연결"을 선택 후 다음을 클릭합니다.
6. 내부 게시 정보 페이지에서 내부 사이트 이름 입력 박스에 TS 게이트웨이 서버의 이름을 입력합니다. 그리고 "컴퓨터 이름 또는 IP 주소를 사용하여 게시된 서버에 연결" 옵션의 체크 박스에 체크한 다음서버 이름을 입력합니다. 만약 TS 게이트웨이 서버 이름을 모를 경우 찾아보기 버튼을 이용해서 위치를 탐색합니다. 참고. 이 페이지에서 사용하는 이름은 TS 게이트웨이 웹사이트로 연결되는 웹사이트 인증서의 제목과 꼭 일치해야 합니다.
7. 공개 이름 정보 페이지에서 "이 도메인 이름(아래에 입력)"을 선택 한 다음 공개 이름 박스에 이 URL에 발급된 인증서 이름과 같은 이름을 입력합니다. 여기에서는 tsg.contoso.com 을 입력한 후 다음을 클릭합니다.
8. 웹 수신기 선택 페이지에서 이전에 만들어 놓은 웹 수신기를 선택합니다. 그리고 다음을 클릭합니다.
9. 인증 위임 페이지에서 "위임 안함 – 클라이언트에서 직접 인증"을 선택 후 다음을 클릭합니다.
10. 사용자 집합 페이지에서 "모든 사용자"가 선택되어 있는지 확인 후 다음을 클릭합니다. 그리고 마침을 클릭해서 적용합니다.
규칙을 더블 클릭한 후 "경로"텝에서 오직 패스가 "/rpc/*"만 가지고 있는 것을 확인할 수 있습니다. 이것은 외부에서 Exchange Server 2007 사용 마법사를 사용했기 때문입니다.


클라이언트 액세스 테스트와 모니터링
테스트 하기 전에 클라이언트는 RDP 6.0 또는 그 이상이 설치되어있어야 합니다. RDP 클라이언트 응용프로그램을 설정하기 위해서 프로그램을 실행시키고 접속하고 싶은 터미널 서버의 이름을 입력합니다. 옵션 버튼을 클릭합니다. 고급 탭에서 설정버튼을 클릭한 후 외부 TS 게이트웨이 서버의 이름을 입력합니다. 그림 3에서 이 이름은 웹 수신기에 등록된 인증서 이름입니다. Windows NTLM을 사용합니다. 입력이 완료 됐으면 확인을 누르고 연결 버튼을 클립합니다.
 
그림 3 RDP 클라이언트 설정

참고. RDP 6.0 클라이언트(Windows XP와 Windows Server 2003)은 그림 3과 같은 화면으로 나타납니다. 인증 프롬프트가 두번 실행이 될 것 입니다. 첫번째 인증은 TS Gatewary 컴퓨터에서 인증을 합니다. 그리고 두번째는 접근하려고 하는 터미널 서버에서 인증을 합니다. 이것은 ISA 서버의 설정 때문에 발생하는 것이라고 생각할 수 있기 때문에 중요합니다. 사실 ISA 서버는 ISA 서버를 통한 익명 연결을 허용하는 "모든 사용자"에 대해 웹 게시 규칙은 어떠한 인증도 처리하지 않습니다.

Windows Server 2008의 RDP 클라이언트는 그림 4에서 보시는 것과 같이 원격 컴퓨터에 TS 게이트웨이 자격증명을 사용합니다. 이 옵션이 선택되어있으면 자격 증명을 두번 입력할 필요가 없습니다. 결과적으로 사용자 경험이 낳습니다. 이 SSO(Single Sign-on)옵션은 Windows Vista SP1에서도 사용 가능합니다.
 
그림 4 Windows Server 2008 RDP 클라이언트

TS 게이트웨이 관리자의 모니터링 옵션을 통해 연결을 모니터링 할 수 있습니다. TS 게이트웨이 서비스는 서버에 연결을 시도한 인증되지 않은 사용자의 자세한 정보도 제공합니다. 그림 5에서 이벤트 뷰어는 TS 게이트웨이를 통해 권한이 없는 사용자로부터 시도된 연결을 볼 수 있습니다.
 
그림 5 TS 게이트웨이 서비에 기록된 이벤트

이 이벤트에는 ISA Server 2006의 IP 주소가 기록되어있습니다. 그 이유는 ISA 서버의 웹 게시 규칙 옵션 중 "요청이 ISA Server 컴퓨터에서 시작된 것으로 표시"가 설정되어있기 때문입니다. 만약 원래 클라이언트 IP 주소가 등록되기를 원한다면 ISA Server 2006의 웹 게시 규칙에서 "요청이 원래 클라이언트에서 시작된 것으로 표시" 옵션을 선택하면 됩니다.


ISA Server에서 모니터링
ISA Server 2006 지원팩의 새로운 기능을 사용합니다. 이것은 보다 자세하게 볼 수 있고 각각에 대한 내부 네트워크로의 연결을 이해할 수 있습니다. 그림 6은 강조된 한 개의 연결을 보여줍니다. 요청 : the RPC_IN_DATA verb indicating the URL for the RPC over HTTP Proxy.
 
그림 6 지원팩을 사용한 ISA Server 2006 로깅

만약 로깅을 계속 지켜본다면 다른 "RPC Over HTTP 동사, RPC_OUT_DATA"를 볼 수 있습니다. 이것은 HTTP 방식이 사용되고 있다는 것을 알아내는데 중요합니다. RDP/HTTP는 "RPC_IN_DATA" 와 "RPC_OUT_DATA"가 나타납니다. 만약 이 방식을 거부하는 HTTP 필터링을 사용한다면 트레픽은 ISA 서버에서 거부될 것 입니다. 만약 당신의 환경을 잠그고 싶다면 RDP/HTTP 웹 게시 규칙을 오직 두 방식만 허용하게 설정할 수 있습니다. 일반적으로 게시할 때 사용되는 HTTP 방식에 대한 보다 자세한 정보는 다음 글을 읽어 보십시오. "HTTP Filtering in ISA Server 2004"


[원문]
Enhance TS Gateway Security with ISA Server 2006

Solution Accelerators Forefront Integration Kit for NAP의 기술적 깊이를 위해 Dan Griffin이 작성한 글을 소개하려합니다.

이 블로그는 두가지의 목적이 있습니다.
첫번째는 간단하게 다음 질문에 대한 답입니다. : NAP이 적합하지 않은(Non-Compliance) 클라이언트들에 대해 어떻게 작동하는가? 다른 말로, 건강한 컴퓨터들과 건강하지 않은 컴퓨터들이 어떻게 구분이 되는가?
두번째는 Solution Accelerators의 새로운 Forefront/NAP 통합 킷을 가지고 무엇을 할 수 있는가? 에 대한 답입니다.

위 두가지를 설명함에 앞서 NAP에 대해 약간 설명을 해드리겠습니다.
NAP에는 5가지 시나리오(802.1X, DHCP, Ipsec, Terminal Server Gateway, VPN)가 있습니다. 이 글에서는 DHCP에 대해서 설명합니다. 그러나 DHCP는 몇가지 보안상 문제가 있습니다.
첫번째로, DHCP 구성에서 적합하지 않은 클라이언트는 제한된 네트워크에 놓여집니다. 그러나 네트워크가 기본 라우터가 있는 정말 간단한 구성으로 되어있을 경우 그리고, 기본 게이트웨이가 몇 개 안될 경우, 컴퓨터를 조금 알고있는 사용자는 제한되지 않는 네트워크로 우회할 수 있습니다.
두번째로, DHCP 표준의 제한된 속성 때문에 서버인증이나 메시지 무결성을 제공하지 않습니다. 이 것은 같은 LAN환경에 있는 누군가가 악의적으로 클라이언트나 서버가 알 수 없게 DHCP 트레픽을 수정할 수 있다는 말입니다.
그러나, 인증서 기반의 Ipsec을 이용해서 NAP을 배포할 때에는 위 두가지에 대한 문제를 해결할 수 있습니다. 예를들어 Ipsec 클라이언트와 서버는 상호간에 인증되고 네트워크 트레픽의 암호화와 암호화된 체크섬에 의해 보호됩니다.

그러나 NAP을 배우기 위한 목적이고, 테스트환경에서 POC(Proof of Concept)를 진행하기 위해서는 DHCP로 구성하는게 덜 복잡하고 보다 빠르게 다른 시나리오들을 진행할 수 있습니다. 방법은 다음 Step-by-Step 가이드를 참고해 주시기 바랍니다.

FCS/NAP 아키텍쳐
자세한 설치 절차는 제외하고 NAP이 DHCP로 구성되어있다고 가정하겠습니다. 클라이언트 컴퓨터는 NAP에 의해 적합하지 않을 경우 사내 네트워크 접근 권한을 박탈당하게 됩니다.
첫번째 단계로, NAP 에이전트가 실행되고있는 클라이언트는 SOH(Statement of Health)신호를 DHCP서버에 전송합니다. 아래 그림에서 클라이언트는 왼쪽 아래의 노트북 그림 둘 중 한 개 일 수 있습니다. 아래 큰 동그라미 그림에서 서버는 DHCP와 NPS 역할을 합니다.
 

DHCP서버는 클라이언트로부터 DHCP 요청을 받습니다. 그리고 SOH신호를 추출해서 NPS서버로 보냅니다. NPS는 이 신호를 분석합니다. 그런데요 한가지 궁금증이 생기네요. 한 서버에서 서비스끼리 통신이 가능할까요? ^^
만약 SOH가 적합하다고 판단되면 DHCP서버는 사용할 수 있는 IP 정보를 보냅니다. 만약 SOH가 적합하지 않다면 DHCP서버는 제한된 네트워크의 IP정보를 보내줍니다.
그러면 FCS/NAP 솔루션은 어떻게 동작할까요? SOH에 어떤 정보가 포함이 될까요? 그리고 NPS에서 어떻게 평가가 되어질까요? FCS/NAP은 두개의 플러그인으로 구성되어있습니다. 그건 SHA(System Health Agent)와 SHV(System Health Validator) 입니다.

데이터 흐름
클라이언트 SHA는 Forefront관련 정보를 SOH에 추가하고 SHV에 의해 평가가 됩니다. SOH에는 미리 정의된 질문들에 대한 답을 가지고 있습니다. 예를들어 "Forefront Client가 현재 실행 중인가"(아래 그림에서 화살표 2번입니다.) 다른 질문은 "백신 업데이트 버전이 최신인가?"(화살표 1, 3)
 
FCS/NAP의 SHV가 SOH(그림 5)를 받을 때 설정된 Health 정책과 맞는지 검사합니다. 예를 들어 만약 "Forefront가 실행중인가"에 대한 대답이 "아니오"일 경우 SHV는 현재의 정책이 Forefront가 항상 실행 되어야만 하는지 아닌지를 검사합니다.

SOH의 모든 대답에 대해 평가가 끝나면 SHV는 다음 둘 중 한가지 상태를 NPS서버로 보고합니다.
1. 클라이언트가 건강/적합 하다
2. 클라이언트가 건강하지 않음/부적합 하다
후자의 경우 SHV는 사용자에게 부적합한 이유를 설명해줍니다. 예를들어 "Forefront 클라이언트가 실행중이 아닙니다." 또는 "백신 업데이트 버전이 최신이 아닙니다.". 등등. 이런 메시지는 내장된 napstat.exe나 netsh.exe프로그램을 통해서 보여지게 됩니다.

설정시 주의할 점
위 그림에는 나타나있지 않지만, 추가적인 몇가지 NAP 설정 시나리오들이 있습니다.

첫번째는 "보고(Reporting)" 모드 입니다. "보고" 모드에서 NAP은 적합하지 않은 클라이언트들을 격리하진 않습니다. 간단하게 건강상태만 보고하기 때문입니다. 이것은 NAP을 운영하거나 평가중인 고객에게 아주 좋은 설정입니다. "보고"모드는 SHV의 효과가 동작하지 않습니다. 그러나 이것은 위에서 설명한것과 같이 동작합니다.
두번째 시나리오는 NAP "적용(enforcement)" 모드입니다. 부적합한 클라이언트들은 격리됩니다. 그리고 자동 치료(auto-remediation) 옵션이 있습니다. 이것은 어떤 효과가 있고 SHV는 어떻게 동작할까요?
자동치료 옵션이 활성화 되어있지 않다면 SHV는 위에서 설명한 것과 무엇이 잘못 되었는지 알려주기만 합니다.
그러나 자동치료 옵션이 활성화 되어있고 클라이언트가 적합하지 않을 때 SHV는 SOH 응답에 다른 정보를 넣어야만 합니다. 자동치료는 두 가지로 구성된 정보로 응답합니다.
1. 사용자가 수동(Instructive)으로 올바른 행동을 할 수 있는지와 SHA(informative)에 의해 자동으로 올바른 상태로 돌아가게 할 것인지에 대한 시나리오들의 차이를 두기 위해 다른 문자열이 사용됩니다. 후자가 자동치료입니다.
2. SOH응답은 SHV에서 SHA로, 지정된 자동 치료 행동에 관한 프로그램에 의한 명령들이 포함되어야 합니다. 예를들어 정책상 Forefront 서비스가 실행되어있어야 하는데 실행되어있지 않다면, SHV는 SOH에 SHA가 자동으로 서비스를 시작해야한다는 비트마스크를 설정할 것입니다.

[참고 Article]
NAP and FCS
http://blogs.technet.com/clientsecurity/archive/2008/06/18/nap-and-fcs.aspx