터미널서비스를 단순히 관리 용도로만 사용한다면 특별한 설정이 필요없다. 몇가지 추가기능들을 고려해 보고자 한다. 원격제어기능, 어플리케이션 서버기능 등이 그것이다.

(1)원격 제어

당신이 회사의 고객지원부서에 근무하는 담당자라고 가정해 보자. 회사의 사용자는 오피스2000의 새로운 기능에 대해서 묻고 싶어한다. 당신은 전화상으로 사용방법에 대해서 설명할 것이다. "도구메뉴에 보면 옵션이 있죠? 그걸 열고.. 어쩌고 저쩌고... " 기껏 설명을 했더니 잘 모르겠다고 한다. 또 다시 설명하고, 스트레스는 있는 대로 받고.. 이럴 때 터미널 서비스의 원격제어 기능은 아주 유용하다. 한가지 예제일 뿐이다. 이것을 효율적으로 응용하는 것은 여러분에게 달려있다.

예제에서는 192.168.2.200 IP Address를 사용하는 터미널서버가 있다. 당신은 tsuser2 계정을 사용한다. tsuser1이라는 계정을 사용하는 사용자가 회사에서 새롭게 도입한 프로그램의 기능을 묻고 있는데 직접 프로그램을 띄운 상태에서 설명하고 싶다. 다음과 같은 절차를 통해서 원격제어로 접근해 보자.

① tsuser1에게 터미널 서버로 접속하도록 요청한다.

<화면1. tsuser1 클라이언트 접속>

② 자신도 tsuser1이 접속한 터미널 서버에 tsuser2계정으로 접속한다.

<화면2. tsuser2 클라이언트 접속>

아래의 <화면3>에서는 이해를 돕기 위해 한 컴퓨터에서 두 개의 터미널 서비스 클라이언트 창을 띄워서 각각 tsuser1, tsuser2로서 로그온한 화면을 보여준다. 화면에서 아래의 창은 tsuser1, 위의 창은 당신이 로그온한 tsuser2이다.

③ 터미널 서비스 클라이언트를 이용해 접속한 상태에서 터미널 창안에서 "시작-관리도구-터미널 서비스 관리자"를 연다. 관리콘솔의 오른쪽을 보면 현재 서버에 로그온 한 사용자의 리스트를 볼 수 있다. tsuser1과 tsuser2, wssong이 보인다. 여기서 wssong은 현재 터미널서버에 로컬로 로그온한 사용자를 보여준다. 터미널 클라이언트는 tsuser1과 tsuser2 두명이 있다. 원격제어를 원하는 tsuser1을 클릭하고 마우스 오른쪽 단추를 눌러 "원격제어"를 클릭한다.

<화면3. 원격제어 요청 >

④ 원격제어 세션을 끝낼 때 사용할 단축키를 선택한다. 예제에서는 [Ctrl]+[Tab]을 선택했다.

<화면4.원격제어 단축키 선택>

⑤ 확인버튼을 누르면 tsuser1이 로그온한 화면에서는 <화면5>의 아래창에서 보는 것처럼 "원격 제어 요청"메시지를 받게 된다. 읽어보니 tsuser2이 원격제어 요청을 하고 있으니 수락하겠느냐?는 메시지이다. 당연히 클라이언트쪽에서 [예]를 선택해야 한다.

<화면5. 원격제어 요청 메시지>

⑥ 상대방이 '원격제어요청'을 허용해 주면 아래의 <화면6>에서 볼 수 있듯이 양쪽의 터미널 창에 동일한 화면을 보여주게 된다. tsuser1이 터미널 서버에 로그온한 세션을 공통으로 사용하도록 설정이 되었다.

<화면6. 원격제어 연결 >

⑦ 한쪽에서 프로그램을 띄운다거나, 텍스트를 입력하는 등의 모든 작업은 다른 터미널 창에서도 반영이 된다. 결국 하나의 세션이 양쪽의 터미널 창을 통해서 보여지도록 허용이 되는 것을 의미한다.

<화면7. 원격제어 테스트>

지금까지 한가지 예제를 들어서 원격제어를 구현해 보았다. 응용하는 것은 각자의 할 일이다. 만일 터미널 서비스 사용자의 동의없이 사용자의 세션에 참여하고 싶다면 어떻게 할까? 그렇다면 그 사용자가 터미널 서버에 접속해서 무슨 일을 하는지를 들여다 볼 수 있을텐데, 역시 옵션이 제공된다. "관리도구-터미널 서비스 구성"을 열어서 "연결- RDP-TCP"의 등록정보를 클릭한다.<화면8>

<화면8. 터미널 서비스 구성>

원격제어 탭에서 "사용자의 허가 필요"체크박스의 체크를 해제하고 나면 상대방의 동의 없이 원격제어가 가능해진다. 어떤 용도로 사용할 수 있을까?

<화면9. 터미널 서비스 구성 - 등록정보 수정>

(2)어플리케이션 서버 구현

또 다른 용도를 고려해 보자. 회사에서 업무상 필요한 어플리케이션이 Windows2000환경에서만 작동한다면 어떻게 할까? 당연히 모든 클라이언트들은 Windows2000으로 업그레이드를 해야 할 것이다. 또, 모든 사용자가 그 어플리케이션을 사용해야 한다면 사용자들의 시스템마다 해당 어플리케이션을 설치해야 할 것이고, 당연히 회사는 적절한 라이센스를 확보해야만 법적인 대항력을 확보할 수 있게 된다. 다른 방법은 없을까? 이런 경우에 Windows2000 터미널 서비스는 역시 해결책이 될 수 있다. 터미널서버에 어플리케이션을 설치하고 사용자들이 그 어플리케이션을 쓰기 위해서 터미널서버로 로그인을 하면 된다. 하지만 터미널 클라이언트들에게 주어진 어플리케이션 이외의 프로그램에는 접근하지 못하도록 제한을 두고 싶다면 다음과 같은 방법을 고려한다.

먼저 클라이언트 연결관리자를 통해서 터미널 클라이언트 연결을 하나 만들어보자. "시작-프로그램-터미널 서비스 클라이언트-클라이언트 연결관리자"를 실행한다.<화면10>

< 화면10. 터미널 서비스 클라이언트 연결 관리자 >

파일메뉴 아래의 버튼을 이용하여 마법사를 시작한다.<화면11>

< 화면11. 클라이언트 연결 관리자 마법사 >

연결 이름을 적절히 입력하고 서버이름 항목에는 터미널 서버의 FQDN형태의 호스트이름이나 IP Address를 입력하고 [다음]을 누른다.<화면12>

< 화면12. 연결 만들기 >

로그온 정보를 입력한다. 터미널서버에 접속할 때 제시할 사용자이름과 암호, 그리고 도메인 이름을 입력한다. <화면13> "이 정보를 사용하여 자동으로 로그온"옵션을 체크하였다.

< 화면13. 로그온 정보 입력 >

화면옵션에서 터미널 서버에 연결했을 때의 해상도를 설정한다. 전체화면 모드에서 보기를 원한다면 "전체화면"옵션에도 체크해 준다.<화면14>

< 화면14. 해상도 설정 >

연결등록정보 항목에서는 느린 네트워크에서의 효율적인 전송을 위해서 "데이터 압축 사용"을 하거나  "비트맵 캐싱" 옵션을 사용하여 성능을 향상시킬 수도 있다.<화면15>

< 화면15. 클라이언트 연결 관리자 마법사 - 연결 등록 정보 >

지금 생성하는 연결이 실행할 프로그램을 지정한다. 서버에서 실행될 것이므로 서버에서 해당 프로그램을 실행하기 위한 경로를 입력한다. 단축아이콘을 생성하면 경로를 쉽게 알 수 있다. 예제에서는 인터넷 익스플로러를 실행할 경로를 입력하였다. <화면16>

< 화면16. 프로그램 시작 경로 등록 >

아이콘을 적절히 변경하고 이 연결을 등록할 프로그램 그룹을 등록한다.<화면17>

< 화면17. 아이콘 변경 >

연결 관리자 마법사를 완료한다.<화면18>

< 화면18. 클라이언트 연결 관리자 마법사 완료 >

클라이언트 연결관리자에 "터미널 서버 엑셀"이라는 아이콘이 생성되었다. 프로그램은 인터넷 익스플로러를 실행할 건데 왜 이름이 "엑셀"이냐구? 내맘이다.<화면19>

< 화면19. 클라이언트 연결 관리자에 추가된 형태 >

이제 클라이언트는 준비가 되었다. <화면13>에서 클라이언트가 로그온 할 때 사용할 정보를 제공하였지만 실제로 테스트를 해 보면 여전히 터미널 서버는 클라이언트에게 계정정보를 새롭게 요구하게 된다. 서버의 기본설정이 항상 로그온 정보를 묻도록 되어 있기 때문이다. 터미널 서버에서 이것을 해제해 보자.

관리도구-터미널 서비스 구성을 열고 연결-RDP-Tcp의 등록정보를 연다.<화면20>

< 화면20. 터미널 서비스 구성 관리도구 >

로그온 설정 탭을 열면 "항상 암호 묻기"라는 옵션이 체크되어 있음을 알 수 있다. 해제한다. "항상 다음 로그온 정보 사용"이라는 옵션을 활성화시키면 이 터미널 서버에 접근하는 사용자는 서버가 설정한 계정으로서 터미널 서버에 연결을 하는 형태가 된다. 터미널 클라이언트에게 계정정보를 요구하지 않도록 할 때 사용되는 옵션이다. <화면21>

< 화면21. RDP-Tcp 등록정보 >

이제 설정을 마쳤다. 터미널 서버에 연결해서 결과를 테스틑 해보자. 터미널 연결 관리자를 통해서 만든 연결을 클릭하면 아래의 <화면22>의 결과를 얻을 수 있다. 로그온이 됨과 동시에 터미널 클라이언트는 인터넷 익스플로러가 실행되는 것을 볼 수 있다. 그 외에 어떠한 작업도 할 수가 없다. 만일 클라이언트가 인터넷 익스플로러를 마친다면 터미널 연결까지 끊기게 된다. 터미널 서버를 어플리케이션 서버 용도로 제대로 구현할 수 있는 방법이라고 하겠다.

<화면22. 터미널 서버에 연결된 화면 >

Exchange Server 2000은 이전의 5.5버전과는 달리 Active Directory와 완전한 통합을 이루었다. Exchange Server자신이 별도의 디렉터리 데이터베이스를 가지지 않는다는 것을 의미한다. 예제의 상황을 가정하여 하나의 Exchange Server에서 여러개의 도메인의 메일서비스를 하도록 구성해 보도록 한다. Exchange Server 2000을 이용해서 여러개의 도메인에 대한 메일호스팅을 한다고 가정하면 맞겠다.

<시나리오> Secure.pe.kr 이라는 회사는 Secure.pe.kr 이라는 이름의 Windows 2000 Domain을 구성하였으며 Exchange Server 2000을 사용하여 메일서비스를 하고 있다. 이 하나의 Exchange Server 를 이용해서 mscs.co.kr 이라는 도메인의 메일서비스를 제공하도록 구성하기를 원한다. 어떻게 구성해야 할까?

<해결>

다음과 같은 순서로 구성한다.
1.DNS Zone 구성 - MX레코드 생성
2.Active Directory에서 OU생성
3.ADSI Edit를 이용하여 UPN Suffix 추가
4.Exchange Server - Recipient Policy생성
5.사용자 계정 생성

구성과정이 꽤 까다롭게 느껴질수 있지만 차근차근 제대로 구현을 해 보자.

DNS구성에 대해서는 여기에서 설명하지 않는다. 당연히 구성이 되었다고 가정하고 다음 작업부터 진행한다. DNS구성에 대해서 알고 싶다면 강의실의 'DNS'섹션을 참고하라. 먼저 Secure.pe.kr의 Active Directory에 mscs.co.kr의 사용자를 구분하여 별도로 관리하도록 OU를 하나 생성해 보자. 'Active Directory 사용자 및 컴퓨터'관리도구를 열고 왼쪽패널에서 도메인이름을 마우스 오른쪽 클릭한후 '새로 만들기'에서 '조직단위(OU)'를 선택한다.


<그림1> 새로운 OU 생성

<그림1>에서는 mscs.co.kr이라는 도메인의 사용자를 관리하기 위해 'MSCS'라는 이름의 OU를 생성하고 있다.

다음에 해야 할 작업은 Secure.pe.kr 도메인에서 mscs.co.kr 도메인 이름을 사용할 수 있도록 User Principal Name (UPN) 접미사를 추가하는 작업을 한다. 'Active Directory 사용자 및 컴퓨터'관리콘솔을 이용할 수도 있지만 그것은 도메인의 모든 사용자들에게 해당되는 작업이 되니 그것보다는 새로 생성한 'MSCS' OU에만 적용될 수 있도록 구성하는 것이 바람직하다. 이 작업은 ADSI에디터를 통해서 접근해야 한다.

Win2K 원본CD의 support-tools 폴더에 있는 셋업파일을 이용해서 Windows 2000 Support tools를 설치한다. 설치를 마치면 프로그램메뉴에 등록된 Support tool을 찾을 수 있고 거기에서 adsiedit 라는 관리도구를 확인할 수 있다. 못 찾겠으면 시작-실행 창에서 "adsiedit.msc"라고 입력해 본다.

ADSI에디터를 실행한 다음, Domain NC를 확장하고 "OU=MSCS"라는 폴더를 클릭한다음 등록정보를 연다.

<그림2> ADSI Editor


<그림3> ADSI Editor - 속성편집

Attributes 탭을 열고, 'Select a property to view' 항목에서 'uPNSuffixes'를 선택한다. 'Attribute Values'에서 Edit Attribute박스에 'mscs.co.kr'이라고 입력하고 [Add]버튼을 클릭한다. 아래의 <그림4>와 같이 구성하였다.


<그림4> ADSI Editor - uPN접미사 추가

다음에 Exchange Server를 구성하기 위해 Exchange System Manager 관리도구를 연다.

<그림5> Exchange System Manager - Recipient Policy 추가 1

Recipients를 확장하고 Recipient Policies를 마우스 오른쪽 클릭하여 '새로 만들기'를 선택하고 'Recipient Policy'를 클릭한다. New Policy 화면이 나오면 'E-Mail Address'를 선택하고 [OK]를 누른다.


<그림6> Exchange System Manager - Recipient Policy 추가 2

정책을 구성해야 한다. Name에 "MSCS사용자"라고 입력하고 [Modify]버튼을 클릭한다.


<그림7> Exchange System Manager - Recipient Policy 추가 3

<그림7>에서 '고급'탭을 연다.


<그림8> Exchange System Manager - Recipient Policy 추가 4

'필드'를 선택하고 '사용자'를 클릭한후 '로그온 이름'을 찾아서 선택한다.


<그림9> Exchange System Manager - Recipient Policy 추가 5

선택이 되면 '값'항목에는 'mscs.co.kr'이라고 입력한후 [추가]버튼을 누른다. 그렇게 해서 아래의 <그림10>과 같이 구성을 마친다.


<그림10> Exchange System Manager - Recipient Policy 추가 6

[확인]버튼을 누르면 기존에 있던 사용자에 대해서 새로운 정책을 적용시킬 수 있도록 'Apply this policy now'를 이용하라는 메시지를 보여준다. [확인]버튼을 누른다.


<그림11> Exchange System Manager - Recipient Policy 추가 7

Filter Rules를 보면 -_- 복잡한 필터가 생긴것을 확인할 수 있다. 자세히 보면 볼 수록 머리가 아프다. 넘어가자.


<그림12> Exchange System Manager - Recipient Policy 추가 8

같은 화면에서 이번엔 두번째 탭인 'E-Mail Addresses (Policy)'를 클릭한다.


<그림13> Exchange System Manager - Recipient Policy 추가 9

New E-mail Address 화면에서 'SMTP Address'를 선택하고 [OK]를 누른다.


<그림14> Exchange System Manager - Recipient Policy 추가 10

Address Editbox에 "@mscs.co.kr"이라고 입력했다. [확인]을 눌러서 창을 닫으면 'Generation rules'항목에 @mscs.co.kr이라는 SMTP주소가 추가된 것을 볼 수 있다. @secure.pe.kr의 SMTP를 [Remove]버튼을 이용하여 제거하고 아래의 <그림15>와 같이 보이도록 구성한다.


<그림15> Exchange System Manager - Recipient Policy 추가 11

[확인]버튼을 누르면 아래의 메시지가 팝업된다. [예]를 선택한다.

회사에서 웹서버를 한대 운영하고 있다고 가정하자. 동시접속자들의 계속적인 증가로 인한 서버의 응답력의 저하로 서버의 업그레이드를 고려하고 있다. 서버의 업그레이드만이 최선의 방법일까? CPU가 너무 느려서 사용자들의 요청을 제대로 처리할 수 없다거나 메모리의 부족으로 혹은 하드디스크의 느린 속도로 인해서 고민중이라면 서버의 업그레이드가 고민의 일부분은 해소할 수 있겠지만, 한대의 서버로만 완전한 해결책을 제시하기는 한계가 있기 마련이다.

다른 방법은 무엇일까? 당연히 서버를 중복해서 배치하는 것을 고려할 수 있다. 한대보다는 두대가 있어서 사용자들의 요청을 처리한다면 서버의 분산을 통해서 서버의 응답력은 분명히 향상을 가져올 수 있을 것이기 때문이다.

당신은 결국 웹서버 한대를 더 설치하기로 결정했다. 2대의 웹서버. 이들을 어떻게 구성하여야 최선의 선택이 될까? 이제 새로운 고민이 시작된다. 지금 현재 당신이 웹서버를 한대 더 추가하고자 하는데 정확한 필요성을 먼저 판단해 보라. 웹서버의 성능을 높여주기 위함인지, 아니면 한대의 서버가 다운되었을때 또 다른 웹서버를 통해서 계속 서비스를 할 수 있도록 하기 위함인지..

몇가지 방법이 있다. 막연하게 생각할 수 있는 한가지는 요즘 주변에서 심심찮게 들리는 "클러스터"를 생각할 지도 모르겠다. 클러스터는 훌륭한 솔루션인 것임에는 틀림없다. 하지만 좋은 솔루션인 만큼 요구조건도 상대적으로 까다로운 편인데, 몇가지 살펴본다면 Windows 2000에서 제공하는 클러스터로 구현하기 위해서는 OS가 Windows 2000 Advanced Server이상이어야 한다는 것이고, 물리적인 환경으로 보자면 같은 네트워크에 위치해 있어야 한다는 점 등의 제약사항을 들 수 있겠다. 또 다른 솔루션을 찾아보면 "로드밸런싱" 디바이스들을 들 수가 있겠지만 무엇보다 만만치 않은 비용이 들어가야 한다.

간단하게 구현할 수 있는 방법은 없을까? 그러한 관리자라면 DNS에서 한가지 방법을 찾을 수 있다. DNS로써 구현하는 방법은 완전한 솔루션은 아니지만 가장 손쉽고 경제적으로 클라이언트의 웹서버로의 요청을 분산시킬수 있는 방법을 제공한다.

DNS가 어떻게? 개념은 너무 단순하다. 웹서버가 아무리 잘 셋팅되어 있어도 DNS가 웹서버의 위치(IP Address)를 가르쳐 주지 않으면 클라이언트들은 웹서버에 접근할 수 없다. 웹서버가 두대라면? DNS가 클라이언트의 웹서버의 IP를 요청하는 쿼리를 받을때마다 2대의 웹서버를 번갈아가면서 가르쳐줄 수 있다면 당연히 클라이언트의 요청은 분산이 되지 않을까?

이러한 기능을 DNS의 라운드로빈(Round robin)기능이라고 하고 Windows 2000의 DNS서버는 기본적으로 라운드 로빈이 활성화되어 있다. 관리자는 적절하게 관리영역에 호스트레코드만 생성하여 주면 된다.

아래의 예제를 통해서 접근해 본다. <그림1>에서는 mscs.co.kr이라는 도메인에 www 레코드가 2개 생성되어 있고 각각 192.168.0.2와 192.168.0.3 이라는 IP Address가 설정되어 있음을 보여준다.


< 그림1. DNS호스트 레코드 생성 >

두대의 웹서버를 <그림1>과 같이 DNS레코드를 구성한다. 반드시 A레코드를 사용해야 한다. CNAME은 동일한 이름의 레코드를 여러개 구성할 수 없다.

이제 구성은 끝났다.
에게?? 벌써?? 위에서 얘기한바 있다. 가장 간단하게 구성할 수 있는 방법이라고. 기본적으로 Windows 2000의 DNS는 라운드 로빈이 활성화 되어 있다. 이제 이 DNS서버는 외부의 다른 DNS서버로부터 www.mscs.co.kr 레코드에 대한 요청을 받으면 192.168.0.2와 192.168.0.3 레코드를 동시에 응답하게 된다. 하지만 이 응답이 순서가 있어서 첫번째 DNS쿼리가 오면 192.168.0.2 192.168.0.3의 순서로 응답하고 두번째 DNS쿼리가 오면 이번에는 192.168.0.3 192.168.0.2의 순서로 응답해 준다. 결국 사용자들의 웹서버에 대한 요청은 2대의 서버로 분산되는 효과를 가지게 되는 것이다.

DNS서버의 등록정보를 살펴서 라운드 로빈 구성을 살펴보자.

<그림2. DNS서버 등록정보>

DNS관리콘솔의 왼쪽패널에서 DNS서버 이름을 마우스 오른쪽 클릭하여 '등록정보'를 연다.


< 그림3. DNS서버 등록정보 - 고급옵션>

등록정보의 고급옵션을 살펴보니 여러가지 옵션이 보이는데 '라운드 로빈 사용'이 체크되어 있는 것을 확인할 수 있다.

이러한 DNS라운드 로빈을 이용하여 사용자들의 웹서버로의 요청을 분산시키는 작업은 얼마든지 가능하지만 간단한 구현만큼 한가지 맹점을 가지고 있다.

당신이 관리하는 두대의 웹서버중에서 한대의 웹서버가 문제가 생겨서 다운되었다고 가정을 해 보자. 당연히 당신은 DNS서버의 레코드중에서 문제가 생긴 웹서버의 레코드를 삭제할 것이다. 그러고 나면 당신의 웹서버에 연결하고자 하는 사용자들중 일부는 웹서버를 찾지 못한다는 에러를 만나게 될 수 있다. 원인을 살펴보니 사용자들이 여전히 문제가 생겨서 DNS에서 제거한 레코드에 해당하는 웹서버를 찾아가고 있다는 것을 발견하게 되었다. 당연히 사용자들의 요청은 웹서버로 전달될 수가 없다.

무엇이 문제인가?

DNS서버는 기본적으로 '캐쉬'를 가지는데 한번 DNS서버간의 쿼리를 통해서 원하는 레코드의 정보를 얻으면 이것을 캐쉬에 저장하고 캐쉬의 TTL이 만료되기 전에는 다른 DNS서버로 새로운 쿼리를 던지지 않는다는데서 문제가 생기는 것이다.

예를 들어서 외부의 한 사용자가 천리안의 DNS를 사용하고 있다고 가정해 보겠다. 그 사용자는 웹브라우저를 실행시키고 http://www.mscs.co.kr 이라는 사이트에 접근을 시도했다. 당연히 천리안의 DNS에게 www.mscs.co.kr의 IP Address를 요청했을 것이고 천리안의 DNS서버는 mscs.co.kr의 DNS서버에게 www레코드를 요청하게 된다. mscs.co.kr의 DNS는 192.168.0.2와 192.168.0.3 이라는 2개의 레코드를 응답하게 되고 천리안의 DNS서버는 그 정보를 캐쉬에 저장한 다음 사용자에게 응답해 주게 된다. 그렇게 해서 사용자와 웹서버와의 통신은 잘 이루어지게 되는데...

mscs.co.kr의 웹서버중 192.168.0.2 IP Address를 가진 웹서버가 다운이 되었고 mscs.co.kr 관리자는 DNS서버의 192.168.0.2 레코드를 제거하게 된다.

하지만 천리안의 DNS를 사용하는 외부의 사용자가 다시 http://www.mscs.co.kr 에 접근을 시도하게 되면 천리안의 DNS서버는 사용자가 원하는 정보를 자신의 캐쉬에서 찾아서 응답하게 되고 결국 사용자는 현재 다운이 되어 네트워크에서 사라진 192.168.0.2 웹서버에 연결을 시도한다. 웹서버를 찾을 수 없다는 에러메시지를 받게 된다.

이러한 경우는 DNS의 성능을 위해서 제공되는 '캐쉬'가 거꾸로 좋지 않은 영향을 주는 결과를 낳고 말았다. www 레코드의 TTL값을 조정하여 캐쉬로 인한 문제를 최소화해 보자.

DNS서버에서 mscs.co.kr 영역의 SOA레코드를 편집하여 전체적인 TTL을 조정할 수도 있지만 예제에서는 특별히 www 레코드의 TTL만을 바꿔보도록 한다.


< 그림4. DNS관리콘솔 - 고급옵션>

DNS관리콘솔에서 보기-고급을 선택한다. 캐쉬된 레코드나 레코드별 TTL관리 등 추가작업을 할 수가 있게 된다.


< 그림5. www 레코드 TTL조정>

www레코드의 등록정보를 열고 TTL값을 기본값인 1시간을 지우고 0시간으로 바꿨다. 이제 이 DNS서버로부터 www 레코드를 얻은 상대방 DNS서버에서는 www.mscs.co.kr 레코드의 TTL이 0이므로 캐쉬를 하지 않고 항상 필요할 때마다 새롭게 DNS서버에 쿼리하게 될 것이다.

거듭 이야기하지만 DNS를 이용한 방법으로는 당신이 원하는 완벽한 솔루션이 될 수는 없다. TTL을 바꿔서 문제를 최소화시켜도 상대방 DNS서버에서 임의로 캐쉬값을 조절하는 경우도 있고 이 문제로 몇몇 ISP의 DNS같은 경우 24시간 길게는 며칠씩 캐쉬에 정보를 가지는 경우가 있어서 당신의 회사에서 DNS서버의 레코드를 변경했어도 그것이 전체 인터넷의 DNS서버까지 완전하게 반영되기까지는 수일이 걸리는 경우도 허다하기 때문이다.

그러한 문제로 인한 피해가 회사의 손실로 영향을 미칠수 있는 경우라면 당연히 NLBS를 구현하는 것이 올바른 선택일 것이다.

마이크로소프트는 Windows NT에 이어서 Windows 2000을 발표하면서, 기존의 NTLM 인증을 대체하는 Kerberos라는 보안인증 프로토콜을 사용하여 사용자 인증을 처리하고 있다. Kerberos는 NTLM과 방식은 다르지만, 엄격히 따지면 NTLM을 업그레이드시킨 프로토콜이라고 할 수 있다. Unix나 기타 Kerberos와는 호환성은 유지되지만, 몇가지 차이점을 보인다. 그 차이점에 대해서는 다음번에 다루어 보도록 하자. 왜? 모르니까..

먼저 사용자를 인증(Authentication)한다는 것과 권한부여(Authorization)라는 것에 대한 기본개념을 살펴보자. 네트워크 상에서 자원을 가진 수많은 컴퓨터들(Server)과 이들 자원을 이용하는 다수의 사용자(client)가 있기 때문에 허락된 사용자만이 자원에 접근하도록 하는 작업이 반드시 필요하다. 이러한 작업이 안정적으로 동작하기 위해서는 사용자는 자신의 신원확인을 위한 데이터를 인증서버(Domain Controller)에 전송해 주어야 하고, 인증서버는 이 데이터를 받고 자신이 인정해 준 사용자라는 확인절차를 거치고 확인의 증표로서 사용자의 신원정보(SID)를 제공한다. 이 과정이 인증(Authentication)이다.

자원을 가진 서버는 인증받은 사용자의 신원증명을 기준으로 자원들에게 할당된 ACL(Access Control List)와 비교하여 사용자에게 자원에 대한 접근을 제어할 수 있게 된다. 이 과정이 Authorization이다.

 
<그림1> ACL(Access Control List) User Interface

이 과정에서 한가지 짚고 가야 할 것이 있다. 클라이언트 입장에서는 서버에게 사용자정보를 제시해야 하고, 서버 역시 인증받은 사용자를 위해서 인증데이타를 전송해 주어야 할 것이다. 이러한 정보를 전달함에 있어서바로 보안이라는 것이 필요하게 되고, 보안을 제공하는 방법으로 Kerberos라는 프로토콜이 사용되게 되는 것이다. 이제부터 Kerberos프로토콜이 어떻게 클라이언트와 서버간에 안정된 통신이 가능하게 해 주는지 살펴 볼 것이다.

Kerberos라는 용어는 그리스신화에서 지옥을 지키는 머리 셋 달린 개의 이름에서 유래되었다고 한다. 이 개의 역할은 산자와 죽은자를 구분하여 산자는 지옥으로 가지 못하게 막고, 역시 죽은자는 지옥에서 나오지 못하게 막는 일이었다고 하는데, Kerberos라는 프로토콜이 네트워크 상에서 클라이언트,서버,KDC 세 통신주체간에 인증받은 사용자만이 적절한 통신을 할 수 있게 하는 일인 것에 비교하면 참 적절한 이름이 아닌가 생각한다. Kerberos는 Authentication(인증), Identity(무결성),Privacy(데이타보안)을 제공한다. 이러한 서비스들을 제공하기 위해 보안에 있어서 가장 기본적인 키(key)를 이용한 암호화 방법을 이용한다.

흔히들 주변에서 접할 수 있는 PKI, DES, Symmetric Key, Public Key등이 Key를 이용한 암호화 알고리즘에서 나오는 용어이다. Key를 이용한 암호화 알고리즘의 기본개념은 암호를 거는(Encryption) Key를 가지고 암호화를 했다면, 반대로 암호를 푸는(Decryption) Key를 가지고 암호화된 데이터를 꺼낼 수 있다는 것이다. 이 때 사용되는 키 종류에 따라서, 대칭키(Symmetric Key) 혹은 공용키(Public Key, pair Key)등으로 구분할 수 있다. 대칭키는 잠그는 키와 푸는키가 하나임을 의미하는 것이고, 공용키는 잠그는 키와 푸는 키가 별개로써 한쌍을 이루고 있음을 의미한다. Kerberos는 약간의 차이는 있지만, 대칭키 알고리즘이라고 정리를 할 수가 있다. 그렇다면 Kerberos에서 사용하는 암호화 Key는 어떻게 생성되는 것일까?  

대칭키를 사용하는데 있어서 가장 큰 문제점은 통신의 2주체(sender와 receiver)간에 하나의 키를 교환하여 가지고 있어야만 통신이 가능하다는 데 있다. 하나의 서버는 수많은 클라이언트에게 서비스를 제공한다. 이러한 통신마다 별도의 키를 사용해야 한다면 키를 교환하는 작업자체가 보통 일이 아닐 수밖에 없다. 이 키를 교환하는 작업은 어떻게 보호를 할 수가 있겠는가.  효율적인 방법이 있다. 사용자가 로그온을 할 때 사용하는 password를 바로 Kerberos의 키로써 사용하게 되는 것이다. 이 키는 처음 작업에만 사용되며 데이터 통신에는 별도의 키가 사용이 된다. 간단하게 말하자면 사용자는 로그온할 때 password를 입력하고, 로그온을 받아들이는 서버 역시 사용자의 패스워드를 알고 있기 때문에 그 패스워드를 암호화 Key로 사용을 하게 된다면 이미 2주체간에는 대칭키를 가지고 있기 때문에 암호화된 인증을 사용할 수가 있게 되는 것이다.

서버에서는 로그온을 처리하는 서비스만 있는 것이 아니다. 수많은 서버서비스를 가지고 있기 때문에 단순히 패스워드를 이용한 키방식만을 사용한다면 모든 서비스마다 동일한 키를 사용하는 결과를 가지게 될 것이다. 그렇다면 그때마다 서로 다른 키를 사용해야 한다는 얘기인데, 클라이언트 입장에서는 각종 서비스들과 통신을 하기 위해서 그때마다 서로 다른 키를 유지하여야 할 것이기 때문에 이것 역시 번거로운 일일 수밖에 없다. 어떻게 하면 좋을 것인가? 내가 하기 싫다면 남을 시키면 된다. 물론 실제로는 쉬운 일이 아니겠지만. 이것을 해결할 수 있는 방법으로 Kerberos는 "티켓(ticket)"이라는 것을 사용하여 사용자의 신원을 증명하는 방법을 사용하고 있다. Kerberos를 이루고 있는 구성요소 중에 KDC(Key distribution Center)는 티켓을 발행하는 TGS(Ticket Granting Service)를 맡고 있다. 결국 하나의 KDC라는 구성요소가 네트워크 상의 전반적인 키를 발행하는 서비스를 하고 있고, 그것에 접근하는 최초의 통신에만 사용자의 패스워드가 사용이 되고 있는 것이다.

이제부터 Windows2000의 Kerberos가 어떻게 동작하고 있는지를 보도록 하자. 아래의 그림을 예로 들어서 설명한다. Windows2000 Kerberos의 특징이라면 실제 인증작업을 하기 위해서 Pre-Authentication 절차가 있음을 상기하자. 특정service를 하고 있는 서버에 승인을 얻기 위해서는 그 서비스에 접근할 수 있는 ticket을 제시해야 하는데, ticket을 얻기 위해서는 TGT(Ticket Granting Ticket)를 먼저 얻어야만 한다. TGT는 TGS에 ticket 발행요청을 하기 위한 ticket이다. 이 TGT를 얻는 과정을 Pre-Authentication 절차라고 한다.


<그림2> Kerberos Process sample / 클라이언트의 파일서버 접근인증

<그림2>에서 사용자는 파일서버의 자원에 접근하고자 한다. 이 과정에서 클라이언트 인증을 위하여 발생되는 과정을 도식화 해 보았다. ①과 ②가 Pre-Authentication과정이다. ③과 ④는 파일서버의 서버서비스에 접근하기 위한 티켓을 얻기 위한 과정이고, ⑤와 ⑥이 ④에서 얻은 티켓을 가지고 파일서버에 접근하고, 서버로부터 권한부여(Authorization)를 받아서 자원에 접근하게 되는 예제이다. 이러한 6가지 절차에 대해서 구체적으로 진행과정을 살펴보도록 하자. 이 과정을 통해서 Kerberos의 동작원리를 알 수가 있게 될 것이다. 다소 복잡하고 어려운 개념이 될 수도 있지만, 차근차근 접근하면 이해할 수 있으리라 생각된다.

사용자가 Windows2000환경에서 도메인으로 로그온을 할 때 최초로 Kerberos를 이용한 티켓이 필요하게 된다. 도메인 컨트롤러에 접근해야 로그온을 할 수 있을 것이고, 그러기 위해서는 도메인컨트롤러의 인증서비스에 접근할 수 있는 티켓을 발급받아야 할 것이기 때문이다. 이 티켓을 발급받기 위한 과정이 최초의 과정이다.사용자 입장에서는 아주 단순한 작업을 하면 그뿐이다. 로그온대화상자가 뜨면 사용자계정, 패스워드, 도메인지정 등의 내용만 입력하면 나머지는 Windows 2000 시스템이 처리하니 말이다. 쉽게 생각하면 사용자 계정과 패스워드 정보가 네트워크 상에 전송이 되면 되겠구나 라고 생각할 수도 있겠지만, 그렇게 패스워드를 네트워크에 패킷으로 발송한다면 누군가 도청의 위험이 있을 수밖에 없다.

패스워드 하니까 생각나는 우화(?)가 있다. 동생이 즐겨찾는 성인사이트에 접근하기 위해서 동생이 패스워드를 입력할 때 몰래 훔쳐보고, 나중에 그 사이트에 접근해서 asterisk(*)만 6개를 입력하고는 인터넷이 문제있다며 죄없는 모ADSL통신사 도우미 언니들만 붙잡고 시비를 걸었다는 어느 누나의 비애.. 갈길이 먼데 이야기가 삼천포로 빠지고 있다.

결론은 이러한 패스워드를 제시해서 합법적인 사용자라는 사실을 서버에 제공하고 인증을 얻어내야 할 것인데 이 과정을 패스워드를 직접 전송하지 않고도 사용자를 확인할 수 있는 방법으로써 Kerberos는 잘 맞춰진 톱니바퀴처럼 한치의 어긋남이 없이 처리해 주고 있다는 것이다. 기본원칙은 어긋날 수 없다. 두 시스템간의 데이타는 오직 두 시스템에서만 이해할 수 있어야 한다는 것이다.중간에 누군가가 데이터를 훔쳤다고 하더라도 승인받지 못한 제 3자는 그 데이터를 읽을 수 있어서는 안된다.계속 이야기가 되는 도중에 이 기본원칙은 상기할 수 있길 바란다.


<그림3> Authentication Service Exchange

최초의 통신부터 살펴보자. Pre-Authentication과정을 그림으로 표현한 것이다. 사용자가 처음 로그온을 할 때, 사용자 시스템의 Kerberos는 KDC (Key Distribution Center)에 첫 번째 메시지를 보내게 된다. 그 메시지에는 username, pre-authentication data, TGT요청 등이 담겨 있다. 이 메시지를받은 KDC는 적절한 응답을 해야 할 것이다. KDC는 이 메시지를 기반으로 로그온을 요청하는 사용자가 정상적인 사용자라는 사실을 판단할 수 있어야 하는데, 그것은 단순히 사용자가 제시한 username만 가지고는 판단 할 수 없는 일이다. 그렇기 때문에 패스워드가 필요한 것이지만, 이 패스워드는 네트워크 상에서 적법한 사용자라는 것을 판단하는 유일한 기준이라고 할 수 있기 때문에 암호화되지 않은 상태로 네트워크에서 전송되는 일이 있어서는 안 된다. 그래서 패스워드를 암호화해서 전송하는 방법을 생각할 수 있지만, 패스워드를 암호화하자면 이 암호화 작업에 필요한 Key를 만들어야 하는 작업이 선행되어야 할 것이기 때문에 그다지 바람직하지 않은 방법이 될 것이다. 그래서 선택한 방법이 패스워드를 Key로써 암호화작업을 진행하는 방법이 나오게 된다. 기본개념은 그렇지만,정확히 말하자면 패스워드를 Key로써 사용하는 것이 아닌, 패스워드를 해시(hash)라는 함수를 이용해서 산출된 값(다이제스트)을 Key로써 사용하는 것이다. Windows2000은 기본적으로 Message Digest 5 (MD5)알고리즘을 사용하며, RC4로써 암호화를 제공하고 있다.

정리하면 클라이언트의 Kerberos는 pre-authentication data (time stamp)를 패스워드의 hash(그림3.에서 "Kc"에 해당함)로써 암호화한 데이터를 전송하게 되는 것이다.

당연히 KDC에서는 사용자의 패스워드의 hash값을 저장해 두고 있기 때문에 KDC에서 가지고 있던 사용자의 패스워드에 해당하는 hash로써 사용자의 pre-authentication data가 풀린다면 정상적인 사용자의 로그온이라는 판단을 할 수가 있게 되는 것이다. 이렇듯 사용자와 패스워드가 확인이 된다면 KDC는 사용자가 TGS(Ticket Granting Service)에 접근하여 티켓발행 요청을 할 수 있도록 TGT(Ticket Granting Ticket)을 발행한다. 이 때 TGT를 다른 사용자는 열어볼 수 없도록 KDC자신의 비밀키(long-term key)로써 암호화를 하게 된다. 그리고, 다음에 Client가 Server의 TGS와 통신할 때 사용을 하게 될 둘만의 session Key(그림3.에서 'Kc,k'에 해당된다)를 발행하고, 이 키 역시 사용자의 비밀키(Kc)로써 암호화하여 전송하게 되는 것이다.

TGT는 분명히 클라이언트가 제시해야 할 티켓이지만, 클라이언트가 직접 확인할 필요는 없는 값이다. 왜냐면 이 티켓의 쓰임새는 서버 입장에서 이 티켓을 가지고 접근하는 클라이언트만 받아들이면 되는 것이기 때문에 결국 서버에서 확인해야 할 값인 것이다. 자신이 발행하고 자신이 확인하는 셈이 된다. 우리가 극장에 들어갈 때 사용하는 혹은 차를 탈 때 사용하는 티켓과 개념이 같다고 볼 수 있다. 사실 KDC가 제공하는 TGT는 클라이언트와 통신에서 사용할 Session key와 같은 값이다. 이 값이 일치하도록 만든 것은 KDC의 부담을 덜어 줄 수 있는 좋은 해결책이다.

클라이언트가 세션키를 가지고 자신의 서비스에 요청을 보낼 때, TGT라는 티켓을 제시를 할 것이고, 그 TGT는 KDC자신의 비밀키로 암호화 된 티켓이기 때문에 오직 자신만이 확인할 수 있게 된다. 결국 KDC입장에서는 수많은 사용자들에게 발행한 티켓을 일일이 기억하고 있을 필요는 없다는 얘기가 된다. 개인적으로는 입이 떡 벌어질 만큼 잘 만들어 놓은 알고리즘이 아닌가 싶다.


<그림4> Ticket Granting Service Exchange & Client Server Exchange

위의 첫 번째 과정을 이해한다면 다음과정은 크게 차이가 없다. 첫 번째 과정을 통해서 사용자는 로그인을 하게 된 것이고, 자원을 가지고 있는 서버에 접근하기 위하여 먼저 자원을 가진 서버에 접근할 수 있는 티켓을 얻기 위한 작업을 진행해야 한다. TGT를 받았기 때문에 이 TGT를 가지고, 자원을 가진 서버에 접근할 수 있는티켓을 발급받기 위하여 TGS에 서비스 티켓 발급 요청을 보낼 수가 있다. 이 메시지에는 TGT, TGS와의 세션키로 암호화된 Authenticator (user,time), 티켓발급이 필요한 서버의 서비스(application) 등의 요청이 담겨 있다.  이 요청을 받은 KDC의 TGS는 TGT를 자신의 비밀키(Kk)로 해독하고 (TGT와 session key가 같다는 걸 상기하자), session key로써 암호화된 Authenticator를 해독하여 사용자의 신원과 타임스탬프를 확인한다.

사용자 인증이 되었다면, 해당 서비스와 통신할 수 있도록 티켓을 발행해 주어야 한다. Client가 Server의 서비스와 통신할 때 사용을 하게 될 둘만의 session Key(그림4.에서 'Kc,s'에 해당된다)를 발행하고, 이 키 역시 사용자와의 세션키(Kc,k)로써 암호화하여 전송하게 되는 것이다. 더불어 서비스에 접근할 수 있는 티켓을 발행하는데 이 티켓은 Server의 비밀키(Ks)를 가지고 암호화를 하여 전송한다. 이렇듯 비밀키를 통해서 전송함으로써 Privacy를 유지해 줄 수 있게 된다. 클라이언트는 이 과정을 통해서 얻은 서버와의 세션키를 이용해서 서버에 서비스를 요청할 수 있다. 예를 들어서 파일서버라면 파일서비스에 요청을 하게 되는 것이고, 서버는 사용자가 유용한 티켓을 가지고 접근을 했기 때문에 이 티켓을 가지고 있는 사용자를 믿고 서비스를 제공할 수가 있게 되는 것이다. 이것이 바로 인증(Authentication)이다.

Kerberos는 서비스 티켓을 발행해서 사용자의 신원을 증명하는 것이 목표이다. 그 다음과정에 해당하는 Authorization(권한부여)은 Kerberos의 몫이 아니다. 자원을 가진 서버의 Security Decriptor라는 프로세스는사용자가 제공한 티켓의 SID를 기준으로 자원이 가지고 있는 ACL (Access Control List)와 비교를 하여 사용자의 접근여부를 결정하게 된다.

Kerberos는 Windows2000에서 사용하는 "사용자와 서비스(Security Principal)를 인증하기 위한 "보안인증 프로토콜" 이다.

단원	장	구분
단원1. 윈도우 네트워크의 기초	1장. TCP/IP Network	1-1. TCP/IP Protocol의 개요
		1-2. TCP/IP Protocol Suite
		1-3. TCP/IP 통신의 기본흐름
		1-4. Microsoft Network Monitor
	2장. IP Address	2-1. IP Address의 이해
		2-2. IP Addressing
		2-3. Subnet Mask, Default Gateway
		2-4. CIDR (Subnetting,Supernetting), VLSM
	3장. Public Key Infrastructure (PKI)	3-1. 암호화의 역할
		3-2. Symmetric Key (대칭키)
		3-3. Public Key (공용키)
		3-4. Certificate Authority(인증기관)
단원2. 네트워크 서비스의 이해	4장. DHCP (Dynamic Host Configuration Protocol)	4-1. DHCP의 이해
		4-2. DHCP서버의 구현
		4-3. DHCP Client 구성
		4-4. DHCP의 임대 갱신 과정
		4-5. DHCP의 추가기능
		4-6. DHCP의 확장구현
	5장.DNS (Domain Name System)	5-1. DNS의 이해
		5-2. DNS의 구조 및 프로세스
		5-3. DNS 설치 및 구성
		5-4. DNS Server관리
		5-5. DNS Server 문제해결
		5-6. DNS 기타
	6장. 네트워크에서 컴퓨터 찾기(WINS)	6-1. NetBIOS Network
		6-2. NetBIOS Name 등록, 해제, 요청
		6-3. WINS 설치 및 구성
		6-4. Non- WINS 클라이언트를 위한 설정
		6-5. 최적화된 WINS 서버 구현 방법
		6-6. Lmhosts 파일
	7장. RAS & IAS서버	7-1. 전화접속 서버 (Dial-up Server)
		7-2. VPN (Virtual Private Network)
		7-3. RAS정책 및 IAS서버
	8장. 인터넷연결공유와 개인네트워크 구축	8-1. 사설 네트워크의 필요성
		8-2. 인터넷 연결 공유 (ICS)
		8-3. Network Address Translation (NAT)
		8-4. NAT 고급기능
		8-5. 안전을 고려한 네트워크 환경
	9장. 인증기관과 전자메일응용	10-1. 인증기관(CA) 서비스
		10-2. 전자메일 응용
	10장. 인터넷 서비스	9-1. Internet Information Server (IIS)
		9-2. Web server 구현 (SSL서버)
		9-3. FTP Server 구현
		9-4. 안전한 웹서버 운영을 위한 보안지침
단원3. 윈도우 서버 관리	11장. Windows Server 2003	11-1. Account (계정)
		11-2. 파일시스템과 보안
		11-3. 자원관리
		11-4. 백업과 복구
		11-5. 문제해결(troubleshooting)
		11-6. 시스템 유지를 위한 업데이트
		11-7. 시스템 관리를 위한 도구
	12장. 파일, 프린트 서버관리	12-1. 파일서버 구축하기
		12-2. 파일서버의 보안
		12-3. DFS (분산파일시스템)
		12-4. Disk 할당량 관리
		12-5. 프린트서버 구축 및 관리
단원4. 기업네트워크와 Active Directory	13장. Active Directory	13-1. Directory Service (Workgroup과 Domain)
		13-2. Active Directory의 개요
		13-3. Active Directory의 구조 및 이름
		13-4. Active Directory 설치
		13-5. Active Directory 관리
	14장. Active Directory 인프라 구축	14-1. 도메인의 설계
		14-2. 도메인 환경 구축
		14-3. 그룹정책(Group Policy) 구성
		14-4. 도메인 환경에서의 서버 및 클라이언트
		14-5. Active Directory 에 공유자원 등록

다시 한번 말하지만 사용자들이 네트워크에 공유자원을 손쉽게 찾아다니는 것은 쉬운 일은 아니다. 관리자들은 그러한 사용자들의 입장을 파악해야 할 것이며 최대한 사용자들이 손쉽게 네트워크에 공유자원을 사용하고, 또 사용자들이 만들어 내는 회사의 데이터를 공유지점에 저장하도록 유도해야 할 것이다. 사용자들이 회사의 방침에도 불구하고 네트워크의 파일서버에 접근하는 방법이 어려워서, 혹은 귀찮아서 자신들의 컴퓨터의 하드디스크에 데이터를 저장하고 있다면 그것은 관리자의 무신경함 때문이다.

 

14장에서 다루는 그룹정책에서의 폴더재지정, 사용자 홈폴더 설정, 로그온 스크립트를 통한 드라이브 매핑 등의 방법을 고려해 봐야 할 것이며, 이번 장에서는 공유자원을 Active Directory에 포함시킴으로써 검색에 대한 효율성을 높여주는 방법을 살펴보도록 하자.

 

Active Directory는 회사 전체의 자원들의 정보를 담고 있는 글로벌 디렉터리 서비스이다. 사용자 계정, 컴퓨터 계정뿐만 아니라 공유폴더나 공유프린터 등도 Active Directory에 저장해 둠으로써 사용자들은 Active Directory에 질의를 통해서 찾고자 하는 자원들을 검색해 낼 수 있다. 예제를 통해서 방법을 알아보자. 예제에서는 blueapple 이라는 이름의 파일서버가 가진 Public 이라는 공유자원을 Active Directory에 등록(Publishing)하는 과정을 설명하였다.

<그림12-57. Active Directory 공유폴더 게시 1>	Active Directory 사용자 및 컴퓨터 관리콘솔을 연다음, 공유폴더를 등록하고자 하는 위치에서 마우스 오른쪽 클릭하여 ‘새로 만들기-공유폴더’를 선택한다.
<그림12-58. Active Directory 공유폴더 게시 2>	먼저 공유폴더의 이름을 입력한다. 이것은 파일서버의 실제폴더의 이름과 같을 필요는 없다. 이것은 Active Directory에서 공유폴더라는 하나의 개체를 구별하기 위한 식별자 역할을 하는 것이다.   네트워크 경로 항목에는 실제 공유폴더에 접근하기 위한 UNC Path를 입력한다. \\blueapple\public 이라고 입력했다.
<그림12-59. Active Directory 공유폴더 게시 3>	오른쪽 패널에서 test1 이라는 개체가 생성된 것이 보인다. 이 개체의 등록정보를 연다.
<그림12-60. Active Directory 공유폴더 게시 4>	등록정보에서 ‘키워드’를 할당해 보자. 이 키워드를 이용해서 사용자들은 Active Directory에 쿼리가 가능하다.
<그림12-61. Active Directory 공유폴더 게시 5>	키워드에 ‘오피스2000’과 ‘Windows2000’을 추가했다. 아마도 blueapple의 public 공유폴더에는 오피스2000 과 Windows 2000의 자료가 저장되어 있을 것이다.
<그림12-62. Active Directory 공유폴더 게시 6>	이제 사용자들은 디렉터리 검색을 할 수 있다. 네트워크 환경을 클릭하여 ‘디렉터리’까지 접근한 다음 마우스 오른쪽 클릭하여 ‘찾기’를 선택한다.
<그림12-63. Active Directory 공유폴더 게시 7>	찾기항목을 ‘공유폴더’로 지정하고, 키워드 항목에 ‘오피스’라고 입력하여 [지금찾기]를 시도했더니 <그림12-63>과 같이 자원을 찾아주고 있다. 이 결과값을 클릭하면 실제 자원을 가진 서버인 \\blueapple\public 까지 접근할 수 있다.   사용자들은 더 이상 파일서버의 이름, 공유폴더의 이름 등을 기억할 필요가 없다. 자신이 찾고자 하는 자료를 검색하는 것만으로 그것을 가진 서버까지 접근이 가능해 졌기 때문이다.
<그림12-64. Active Directory 공유폴더 게시 8>	공유프린터도 마찬가지이다. 다만 차이가 있다면, 공유폴더와는 달리 프린터의 경우는 기본적으로 네트워크에 프린터가 공유되는 순간 자동적으로 Active Directory에 등록(게시)이 되도록 설정되어 있다.   프린터의 등록정보를 열어보면 <그림12-64>에서 보여지는 것처럼 ‘디렉터리에 나열’이라는 항목이 보이고 이것이 활성화되어 있음을 확인할 수 있다. 이 디렉터리가 의미하는 것은 바로 Active Directory이다.

회사의 네트워크에 프린트 서버를 구현하는 것은 가장 기본적인 관리작업중의 하나이다. 프린터 자체를 설치하지 못해서 사용하지 못하는 경우는 드물 것이다. 다만 프린터를 사용할 수 있는 적절한 권한설정의 미비로 인한 접근이 되지 않는 것, 또 그보다 앞서 클라이언트로부터 프린트 서버까지의 네트워크 연결문제, 이러한 것들이 프린트서버가 제대로 동작하지 않는다고 판단하게 만드는 요인들이 된다.

 

기본적인 프린터 설치와 같은 내용은 언급하지 않는다. 다만 추가로 회사 네트워크 환경에서 구현해 볼만한 유용한 몇가지 기능을 살펴보도록 하겠다. 두가지 기능을 살펴볼 것이다. 첫째는 하나의 물리적인 프린트 디바이스에 대해서 2개의 ‘프린터’를 설치하여 우선순위, 일정 등이 다른 프린터를 추가해 본다. 둘째는 하나의 프린트 디바이스가 문제가 생겼을 때 다른 프린트 서버의 프린터로 인쇄를 전환(Redirection)하는 방법에 대해서 알아보자.

 

상황은 다음과 같다. 회사의 프린트 서버에 프린터 한대가 물려있고, 이것을 전체 직원들이 공통적으로 사용하도록 네트워크에 공유(프린터)했다. 영업담당 이사가 거래처로 급하게 팩스전송해야 하는 문서를 한장 출력했는데 먼저 프린터에 인쇄명령을 보낸 사용자들이 많아서 프린트 서버의 프린터큐에는 많은 문서가 쌓여 있다. 영업담당이사가 당신에게 “나는 직급도 높고 급하게 문서를 출력해야 하는 경우가 많은데 이렇게 프린터 사용량이 많아서 업무에 지장이 있다. 다른 사용자보다는 내가 보낸 문서가 보다 빨리 프린팅 되도록 조치해 달라”라고 요청했다.

 

이에 대해 당신은 “이사님~ 이사님방에 별도로 프린터 한대 도입하면 됩니다” 라고 말할 것인가? 물론 그럴 수 있지만 처리해 줘야 할 일이다. 어떻게 할 수 있을까? 그러한 경우 하나의 물리적인 프린트 디바이스에 대해 추가로 ‘프린터’를 만들어 냄으로써 해결할 수 있다.

<그림12-40. 우선순위가 다른 프린터 구성 1>	해당 프린트 디바이스를 가진 프린트 서버에서 ‘프린터’관리콘솔을 연 다음 ‘프린터 추가’를 클릭한다. 예제의 프린트 서버는 HP Laser 4000과 HP Laser 5000 2대의 프린터를 가진 서버이다. 이 서버의 LPT1 포트에 물린 HP Laser 4000프린트 디바이스에 대한 또 하나의 ‘논리적인’ 프린터를 설치하고자 한다. ‘프린터 추가’아이콘을 누른다.
<그림12-41. 우선순위가 다른 프린터 구성 2>	서버에서 프린터를 관리할 때는 ‘로컬 프린터’를 선택한다. ‘네트워크 프린터’는 프린트 서버에 클라이언트로서 연결하고자 할 때 사용하는 메뉴이다.
<그림12-42. 우선순위가 다른 프린터 구성 3>	LPT1 포트에 HP Laser 4000 시리즈 프린트 디바이스가 설치되어 있는 것이 보인다. 지금 하고자 하는 작업은 물리적인 프린트 디바이스를 추가하고자 하는 것이 아니라, 이미 존재하는 프린트 디바이스에 대한 복사본을 만들고자 하는 것이기 때문에 동일한 포트를 선택해야 한다. LPT1 포트를 선택하고 [다음]을 누른다.
<그림12-43. 우선순위가 다른 프린터 구성 4>	기존에 이미 프린터가 설치되어 있기 때문에 ‘이미 있는 드라이버 사용’이라는 메시지가 나왔다. ‘현재 드라이버를 사용함’을 선택하고 [다음]으로 진행한다.
<그림12-44. 우선순위가 다른 프린터 구성 5>	프린터 이름을 지정한다. 어떠한 프린터인지 구별할 수 있는 이름을 사용한다.
<그림12-45. 우선순위가 다른 프린터 구성 6>	추가하는 프린터를 공유하고 있다. HPLaserJ.2 라는 공유이름을 그대로 사용했다.
<그림12-46. 우선순위가 다른 프린터 구성 7>	프린터 추가가 완료되었다.
<그림12-47. 우선순위가 다른 프린터 구성 8>	다시 프린터 관리콘솔을 열어보니 새로운 프린터가 하나 추가된 것이 보인다. <그림12-47>에서 하이라이트된 2개의 프린터 아이콘은 실제로는 하나의 물리적인 프린트 디바이스를 가리키고 있는 것이다.
<그림12-48. 우선순위가 다른 프린터 구성 9>	기본적으로 이 두 프린터는 동일한 설정을 가지고 있다. 하나의 프린터를 선택하고 ‘등록정보’를 연다.
<그림12-49. 우선순위가 다른 프린터 구성 10>	등록정보의 ‘고급’탭을 열면 ‘우선순위’를 설정할 수 있는 항목이 보인다. ‘우선순위’의 기본값은 1이다. 우선순위를 99로 높였다. 이제 이 프린터를 통해서 인쇄를 시도하는 사용자는 우선순위가 1인 프린터를 통해서 인쇄하는 사용자보다 높은 우선순위를 가지기 때문에 보다 빠른 문서출력이 가능해 진다.   위의 예제상황에서 영업담당 이사에게 새로운 프린터를 쓰도록 설정해 주면 된다. 하지만 현재 설정으로는 영업담당이사가 아닌 다른 사용자라고 하더라도 이 프린터를 쓸 수 있다. 막아줄 필요가 있다. 공유프린터 권한설정을 통해서 해결한다.
<그림12-50. 우선순위가 다른 프린터 구성 11>	새로운 프린터의 등록정보에서 ‘보안’탭을 열고 Users그룹을 제거하고 특별히 이 프린터에 대해서 인쇄권한을 주기를 원하는 사용자 그룹만 추가해야 한다.

이렇듯 하나의 물리적인 프린트 디바이스에 대해 논리적으로 여러 개의 프린터를 만들 수 있고 이 각각의 논리적인 프린터들에는 서로 다른 권한설정이나 우선순위등을 설정하는 것이 가능하다. <그림12-49>를 보면 또 다른 옵션들도 있다. 기본적으로 프린터는 24시간 동안 개방되어 있는데 여기서 일정변경을 통해서 “밤12시부터 오전6시까지만 동작하는 프린터”등으로 일정조정도 가능하다. 급하진 않지만 대용량 프린팅을 원하는 사용자가 있다면 이러한 일정의 프린터를 하나 설치하고서 사용자에게 이 프린터를 쓰도록 해 준다면 사용자가 낮에 프린터에 출력명령을 보내도 이 프린터는 출력을 하지 않고 ‘스풀러’에 저장해 두었다가 밤 12시가 되면 프린팅을 시작하게 된다. 하나의 프린트 디바이스를 여러목적으로 공유해서 사용하고 있을 때 효율적인 방법이라고 하겠다.

 

이번에는 다른 상황을 하나 고려해 보자. 회사에서는 프린트 디바이스 2대를 구입하여 영업부서용, 관리부서용으로 구분하여 사용하고 있다. 어느날 관리부서용으로 사용하던 프린트 디바이스가 고장이 발생했다. 프린트 서버에서 프린트 큐를 열어보니 <그림12-51>과 같이 5개의 문서가 인쇄대기중인 것을 확인했다. 이 경우 관리자는 관리부서가 사용하던 프린트 디바이스가 당분간 사용할 수 없는 상태가 되었으니 관리부서 사용자들의 컴퓨터에 영업부서용 프린터를 사용할 수 있도록 프린터 설치를 해 주고, 현재 관리부서의 프린터 큐에 대기중인 문서는 사용자들이 새롭게 영업부서용 프린터로 출력하도록 가르쳐 줘야 할 것이다. 그러다가 관리부서용 프린트 디바이스의 수리가 완료되어 다시 네트워크에 복귀하고 나면 관리부서 직원들이 다시 예전의 부서용 프린터를 사용하도록 설정을 바꿔 주어야 한다. 충분히 그럴 수 있다. 문제는 번거롭다는 것이다.

 

이러한 경우에 프린터 포트 재지정(Redirection)은 도움을 준다. 이러한 내용을 구현할 수 있는 기본전제는 관리부서와 영업부서의 프린트 디바이스가 동일하거나, 같은 프린트 디바이스 드라이버로써 호환성이 있어야 한다는 것이다. 구현해 보도록 하자.

<그림12-51. 프린터 포트 재지정 1>	고장난 프린터를 가진 프린트 서버에서 해당 프린터의 등록정보를 연다.
<그림12-52. 프린터 포트 재지정 2>	등록정보의 ‘포트’탭을 연다. LPT1에 프린트 디바이스가 물려있음을 보여준다. 상황은 간단하다. LPT1에 연결된 프린터가 고장이 나서 출력이 되지 않으니 다른 포트의 프린터로 출력되도록 포트를 바꿔주면 되는 것이다. 새로운 포트의 위치는 같은 프린트 서버의 다른 포트일 수도 있고, 다른 서버의 포트일 수도 있다. 개의치 않는다.   [포트추가]를 클릭한다.
<그림12-53. 프린터 포트 재지정 3>	‘프린터 포트’화면에서 ‘Local Port’를 선택하고 [새 포트]를 클릭한다.
<그림12-54. 프린터 포트 재지정 4>	포트 이름 창에는 고장난 프린터를 대체할 프린터를 가진 서버로 접근할 수 있는 UNC Path를 입력한다. 예제에서는 \\msz001\hplaserj 를 입력했다. [확인]을 눌러서 마친다.
<그림12-55. 프린터 포트 재지정 5>	<그림12-55>을 보면 포트가 LPT1에서 변경된 것을 볼 수 있다.
<그림12-56. 프린터 포트 재지정 6>	잠시 후 <그림12-56>화면과 같은 작업이 일어났다. 고장난 프린터에 있던 모든 대기중인 인쇄파일이 대체시킨 다른 서버로 넘어간 것을 확인할 수 있다.   이 작업은 관리자에게 상당히 효율적인 관리방법을 제공한다. 관리부서의 프린트 디바이스가 고장나 있는 동안 새롭게 사용자들에게 프린터를 설치해 줄 필요가 없다. 관리부서의 사용자들은 부서의 프린터가 고장나기 전과 동일하게 자신의 프린터에 출력을 하는 것이고, 다만 프린터 결과물은 영업부서의 프린트 디바이스로 출력이 되니 거기서 찾으면 될 것이다.  관리부서의 프린트 디바이스가 다시 복귀했다면 관리자는 다시 프린터 포트를 LPT1으로 돌려주는 것으로 관리작업은 끝난다.

마이크로소프트의 네트워킹 운영체제(NOS)인 NT는 4.0버전까지 파일시스템에 대한 디스크할당량 기능을 지원하지 않았다. 그런 이유로 특정 사용자에 의해 파일서버가 독점된다거나, 사용자에게 FTP계정서비스 등을 하고자 할 때 용량제한을 한다거나 하는 등의 기능을 사용하기 위해서는 3^rd Party 유틸리티들의 도움을 받아야만 했다.

 

마이크로소프트는 Windows 2000부터 디스크 할당량 관리 기능을 지원하고 있다. 이것은 C: D: 등의 볼륨단위로 처리되며, 로컬, 원격, FTP등 사용자 계정으로 접근해서 저장하는 모든 데이터에 대해서 적용된다. 디스크 할당량 관리 기능을 구현해 보자.

 

디스크 할당량 기능을 사용하기 위해서는 서버의 볼륨은 반드시 NTFS파일 시스템으로 포맷되어 있어야 한다.

<그림12-32. 디스크 할당량 관리 1>	디스크할당량 관리는 볼륨 단위로 별도로 이루어진다. E: 의 등록정보를 열었다. ‘할당량’탭을 열었다. NTFS파일시스템이 아니라면 ‘할당량’탭이 보이지 않을 것이다. 기본적으로 ‘할당량 관리 사용’은 비활성화되어 있는 상태이다. 디스크 할당량을 사용하기 위해서 ‘할당량 관리 사용’의 체크박스에 체크했다. 그리고 얼마만큼 제한할 것인지를 결정해 준다. 예제에서는 200MB의 공간으로 제한을 했고, 180MB에 이르렀을 때 경고를 남기도록 설정하고 [확인]을 눌렀다.
<그림12-33. 디스크 할당량 관리 2>	디스크 할당량 관리를 사용하겠다는 메시지가 나온다. [확인]을 누른다. 디스크 할당량은 활성화하면 현재 드라이브의 파일 Ownership을 확인하여 할당량 체크를 시작한다. 즉시 적용되는 것이다. 위와 같은 설정을 했을 때 기본적으로는 사용자가 200MB를 넘게 사용하는 것이 가능하다. 단지 경고를 남길 뿐이다.
<그림12-34. 디스크 할당량 관리 3>	만일 할당량 제한을 넘은 사용자에게 더 이상 공간을 주지 않겠다고 결정하였다면 ‘할당량’탭의 ‘할당량 한도를 넘은 사용자에게 디스크 공간 주지 않음’옵션을 활성화 시킨다. 이렇게 서버쪽의 디스크할당량이 설정되어 있으면 네트워크를 통해서 서버로 접근하는 사용자는 서버의 하드디스크가 마치 200MB인것으로 인식된다. 자신의 계정이 200MB를 이상 넘어가는 데이터를 기록하고자 했을때는 디스크공간이 부족하다는 에러메시지를 만나게 된다. 가장 확실하게 디스크 공간을 제약하는 방법이 된다.   위와 같이 기본설정만 그대로 둔 상태에서는 관리자 그룹에게는 무제한, 다른 모든 사용자들에게는 일괄적으로 200MB라는 공간제약을 하게 되는데 경우에 따라서는 사용자별로 차별적인 공간할당을 해야 할 필요가 있다. [할당량 항목]버튼을 클릭해서 추가구성을 할 수 있다.
<그림12-35. 디스크 할당량 관리 4>	할당량 항목 화면에서 할당량메뉴-새 할당량 항목을 선택한다.
<그림12-36. 디스크 할당량 관리 5>	할당량을 특별하게 지정하고자 하는 사용자의 목록을 추가한다.
<그림12-37. 디스크 할당량 관리 6>	100MB로 제한했다. 이것은 앞에서 전체사용자에게 기본할당량 한도보다 우선한다. 기본할당량이 200MB로 되어 있더라도 이곳의 할당량이 100MB로 지정되어 있으면 100MB 라는 공간제한을 따른다. 만일 300MB로 지정되었다면 기본할당량인 200MB보다 더 많은 공간을 사용하게 되는 것이다.
<그림12-38. 디스크 할당량 관리 7>	서버 한대가 여러 개의 볼륨으로 구성되었거나, 또한 사용자들이 여러대의 파일서버에 접근해야 하는 경우, 볼륨마다 혹은 서버마다 사용자들에게 동일한 설정을 해야 하는 경우가 있다. 이때는 서버마다 새롭게 사용자 할당량을 설정할 것이 아니라 <그림12-38>과 같이 하나의 볼륨에서 할당량을 잘 설정한 다음, 할당량 항목 ‘내보내기’를 통해서 파일로 저장할 수 있다.
<그림12-39. 디스크 할당량 관리 8>	F:에 diskquotaexport 라는 이름으로 할당량 목록을 저장한 파일을 생성했다. 확장자도 필요없다. 이 파일을 이 서버의 다른 볼륨이나 다른 서버의 볼륨에서 ‘가져오기’메뉴를 이용해서 동일한 할당량 항목을 설정할 수 있다.

클라이언트들이 네트워크에 있는 서버에 간단하게 접근한다는 것은 쉬운 일이 아니다. 실제로 관리자가 생각하는 것보다 훨씬 클라이언트들은 네트워크를 이용하는 것에 익숙하지 못한 경우가 많다. 회사에서 사용자들이 사용하는 파일서버가 여러 대 라면 더더욱 그러하다. 이러한 경우에 분산파일시스템은 유용한 기능이다. 분산파일시스템이 제공하는 또 다른 측면의 기능은 ‘컨텐츠 복제’가 가능하다는 것이다. 파일서버 2대를 복제하고자 한다면, 예를 들어 1대의 서버에 새로운 폴더나 파일이 생기거나 기존의 파일의 내용이 변경되었다면 복제로 구성된 다른 서버로 그 변경사항이 그대로 반영되도록 구성되고자 할 때 역시 분산파일시스템을 고려할 수 있다. 이것의 응용범위는 많다. 또 웹서버 2대를 NLBS (네트워크 로드 밸런싱 서비스)를 구현했을때도 분산파일시스템을 이용해서 웹사이트 컨텐츠 복제를 구성할 수 있다.

 

분산파일시스템은 2가지가 제공된다. 독립실행형DFS와 도메인 DFS가 있다. 독립실행형 DFS는 단일서버이고, 도메인 DFS는 복수서버를 지원한다.

 

회사에 여러대의 파일서버가 있다. 사용자들이 각각의 파일서버에 접근해서 자원을 이용하고 있는데 번거로운 일이 아닐 수 없다. 독립실행형 DFS를 구현해 보자. 독립실행형 DFS는 여러 파일서버의 흩어져 있는 여러 개의 공유자원들에 대해 사용자들에게 단일공유지점을 제공함으로써 사용자들의 접근에 있어서 편의성을 제공한다.

<그림12-19. DFS사용전 환경>

 

<그림12-19>는 DFS사용전의 공유환경이다. 클라이언트가 접근해야 할 지점이 4군데라면 사용자는 각각 4개의 지점에 접근하는 방법을 알고 있어야 한다.

 

 

<그림12-20. DFS사용후 환경>

 

DFS를 사용하면 환경이 달라진다. DFS서버를 설치하고 흩어진 서버의 자원을 DFS서버의 DFS루트에 연결(link)시킨다. 그러면 사용자는 DFS서버의 DFS루트 공유폴더에 연결함으로써 전체 자원의 리스트를 확인할 수 있게 된다. 자원의 활용을 극대화시킬 수 있는 좋은 방법이다. 독립실행형 DFS를 구현해 보도록 하자.

<그림12-21. 독립실행형 DFS 구현 1>	DFS서버로 구현할 서버에서 관리도구-분산파일시스템을 실행한다. 분산파일시스템 관리콘솔에서 마우스 오른쪽 클릭하여 ‘새 DFS 루트’를 선택한다.
<그림12-22. 독립실행형 DFS 구현 2>	마법사가 실행된다.
<그림12-23. 독립실행형 DFS 구현 3>	‘도메인 DFS’와 ‘독립실행형 DFS’를 생성할 수 있다. 도메인DFS를 구현하려면 Active Directory가 필수적이다. 예제에서는 독립실행형 DFS를 구현해 보자.
<그림12-24. 독립실행형 DFS 구현 4>	DFS루트를 서비스할 서버의 호스트이름을 입력했다. Blueapple.mscs.co.kr 을 입력하고 [다음]으로 진행한다.
<그림12-25. 독립실행형 DFS 구현 5>	DFS서버에 DFS루트를 지정해야 한다. DFS루트도 하나의 공유폴더라고 생각하면 편하다. 다만 여러 개의 다른 공유폴더를 링크시킬수 있는 대표공유폴더일뿐이다. 이미 만들어져 있는 공유폴더를 사용하거나, 새롭게 DFS루트로 사용할 공유폴더를 만들 수 있다. 예제에서는 F:\data\Public 폴더를 public 이라는 공유이름으로 새로운 공유를 추가했다.
<그림12-26. 독립실행형 DFS 구현 6>	DFS루트 이름을 눈여겨 본다. \\blueapple.mscs.co.kr\public 이라는 UNC Path 형태를 그대로 보여준다. 사용자들은 이 UNC Path를 이용해서 DFS서버에 접근하게 된다.
<그림12-27. 독립실행형 DFS 구현 7>	작업을 마쳤다.
<그림12-28. 독립실행형 DFS 구현 8>	<그림12-28>을 보면 DFS루트가 추가된 것을 확인할 수 있다. 추가로 이제는 흩어져 있는 공유자원들을 링크시키는 작업을 한다. 왼쪽패널에서  DFS루트를 마우스 오른쪽 클릭하여 ‘새 DFS 연결’을 선택한다.
<그림12-29. 독립실행형 DFS 구현 9>	연결이름에는 사용자가 알기 쉬운 이름을 입력해 주고, 두번째의 ‘사용자를 이 공유폴더로 보냄’에는 실제로 공유폴더를 가진 서버의 공유이름을 입력해 준다. 예제에서는 \\salesserver\sales$ 를 입력했는데 이것은 saleserver의 sales$ 공유폴더를 의미한다. Salesserver 의 공유폴더를 Sales$ 와 같이 마지막 문자열에 $(달러표시)를 함으로써 salesserver 서버가 가진 공유자원을 숨기는 형태를 취했다. 이것은 사용자들에게 실제 공유폴더가 어디에 위치해 있는지는 감추겠다는 것을 의미한다. 사용자 입장에서는 서버가 어디에 있는지, 어떠한 공유폴더가 있는지를 알 필요가 없다. 네트워크의 자원에 접근하고자 한다면 ,DFS서버에 연결하면 그뿐이다.
<그림12-30. 독립실행형 DFS 구현 10>	같은과정을 거쳐서 각 부서별 공유자원을 하나의 DFS루트 폴더에 링크시켰다.
<그림12-31. 독립실행형 DFS 구현 11>	사용자들은 더 이상 서버들을 찾아다닐 필요가 없다. 공유자원이 필요하면 DFS서버의 DFS루트를 찾아오면 된다. 예제에서는 \\blueapple\public 으로써 DFS서버에 접근한 화면을 보여준다. 개발팀, 관리부.. 등 4개의 폴더가 보이는데, 이것은 실제로 폴더가 아니라 각각 흩어져 있는 서버들의 공유자원이 링크된 인터페이스 역할을 하는 것이다. 사용자가 만일 ‘개발팀’폴더를 클릭한다면 그것은 실제로 <그림12-29>에서 설정한 \\salesserver\sales$ 로 연결되어 다른 서버의 공유자원을 보여주게 된다.

 

이렇듯 독립실행형 DFS 기능은 흩어진 서버의 공유자원을 하나의 서버에 집중시킴으로써 사용자들의 편의성을 극대화시킬 수 있다는 장점이 있다. 하지만 독립실행형 DFS서버가 다운되는 상황이 생겼다면 사용자들은 접속지점을 잃어버리는 것이 되기 때문에 주의해야 할 것이다.

 

반면에 도메인 DFS는 DFS루트를 여러 개의 서버에 복제로 구현할 수 있어서 하나의 DFS 루트가 손상되었더라도 계속해서 사용자들이 공유폴더에 접근할 수 있다는 장점이 있다. 내결함성(Falut Tolerance)을 제공한다. 도메인DFC를 구현하기 위해서는 Active Directory가 구축되어야 한다.

‘파일서버’라는 이름은 우리에게 너무나 친숙하다. 네트워크라는 것의 필요성이 여기서부터라고 해도 틀린 말은 아닐 것이다. 옆자리에 있는 동료의 컴퓨터에 저장된 파일을 ‘공유’하고 싶다는 데서부터 파일서버의 필요성은 출발된다.

 

파일서버를 구축하는 것은 간단하지만 제대로 관리하는 것은 쉽지 않다. 처음에는 잘 준비하지만 공유해야 할 데이터가 하나 둘 늘어가면서 금새 어수선한 공유폴더를 만들어 내는 경우가 많기 때문이다. 폴더를 구성할때는 계층구조를 사용하도록 하자. 앞으로의 확장을 고려한다면 좋은 구조이다. 예제로 만든 폴더구조를 보도록 하자.

<그림12-1. 파일서버의 계층적인 폴더관리>

 

<그림12-1>의 예제에서는 F: 루트에 “데이터”라는 이름의 폴더를 만들고, 그 아래에는 “공용데이터”, “사용자데이터”를 생성했다. “공용데이터”에는 부서별 공통 데이터를 저장하며, “사용자데이터”는 회사의 사용자별 홈폴더를 설정해 주기 위한 공간이다. 이런 형태로 파일서버를 계층적 폴더구조를 만들어서 관리하면 늘어나는 사용자에 따른 폴더생성, 백업 등이 용이해진다.

 

위와 같이 구성하면 회사에서 부서별로 공유할 데이터를 저장할 ‘공용데이터’폴더를 공유하고, 사용자별 데이터를 저장할 ‘사용자데이터’를 공유하는 두가지 작업만으로 기본적인 요구사항은 해결될 수 있는 구조가 마련된다. 상위의 폴더 하나만 공유하면서 어떻게 하위에 있는 폴더들의 권한통제가 가능할 것인가? 그것은 바로 Windows NT기반의 OS에서 지원하는 NTFS파일시스템의 NTFS 퍼미션관리를 통해서 가능한 작업이다.

 

앞에서는 파일서버의 기본적인 구성에 대해서만 설명하였다. 이번장에서는 기본구성을 근거로 하여 구체적인 서버의 보안설정을 어떻게 하여야 할 것인지를 살펴본다. 예제는 다음과 같다. 부서별 공용데이터와 사용자별 개인폴더를 저장하는 blueapple 이라는 이름의 파일서버가 있다. 이 파일서버에서는 F:에 data라는 최상위 폴더를 생성했으며 부서별 폴더와 사용자별 폴더를 각각 public, user로 생성했다. 이 때 파일서버의 기본보안은 어떻게 유지되어야 하는지 접근해 보자.

 

<그림12-2. 파일서버의 권한설정 1>	먼저 부서별 데이터폴더인 Public폴더를 공유한다. Public에서 마우스 오른쪽 버튼을 이용하여 ‘공유’를 선택한다.
<그림12-3. 파일서버의 권한설정 2>	공유이름으로 public 이라는 기본값을 사용했다. 공유폴더에 대한 사용권한을 설정하기 위해 [사용권한]을 클릭했다.
<그림12-4. 파일서버의 권한설정 3>	기본적으로 모든 공유폴더의 사용권한은 Everyone에게 ‘모든 권한’이 부여되어 있다. 좋지 않은 권한설정이다. [제거]를 클릭했다.
<그림12-5. 파일서버의 권한설정 4>	Public공유폴더에 대해서 [추가]를 이용하여 Administrators 그룹을 추가했다. 또한 Users 그룹을 추가하고 ‘변경’,’읽기’권한을 주었다.
<그림12-6. 파일서버의 권한설정 5>	이렇게 공유설정을 마쳤다. <그림12-6>을 보면 \\blueapple\public UNC Path를 이용하여 네트워클를 통해 blueapple서버의 public공유폴더에 접근해 본 화면이다. Public 폴더 아래에는 개발팀, 관리부, 마케팅, 영업부라는 4개의 서브폴더가 있다. 현재 상태로는 각 부서에 속한 사용자들이 자기 부서의 폴더에만 접근하는 것이 아니라 public 공유폴더를 통해서 접근하기 때문에 4개의 모든 폴더에 대해서 ‘변경’권한까지 가지도록 설정되어 있다. 4개의 서브폴더를 포함하는 상위폴더를 공유했기 때문에 4개의 서브폴더는 상위폴더에 주어진 공유폴더에 대한 권한을 그대로 동일하게 적용받는 것이다.
이것을 공유폴더만 가지고 해결하기 위해서는 Public이라는 상위폴더를 공유하는 것이 아니라 4개의 서브폴더를 각각 공유해야 한다. 예를 들어 ‘개발팀’폴더를 ‘개발팀’이라는 이름으로 공유하고 ‘개발팀’그룹에게만 사용권한을 할당해야 하는 것이다. 하지만 그렇게 접근하는 것이 아니라 공유폴더 사용권한과 NTFS 폴더 퍼미션을 같이 사용함으로써 해결할 수 있다.
<그림12-7. 파일서버의 권한설정 6>	NTFS퍼미션을 할당해 보자. 먼저 Public아래의 서브폴더인 ‘개발팀’을 마우스 오른쪽 클릭하여 ‘등록정보’를 선택했다.
<그림12-8. 파일서버의 권한설정 7>	기본적으로 할당되어 있는 퍼미션이 보인다. 기본 퍼미션을 변경하기 위해 먼저 아래쪽에 ‘부모로부터 상속 가능한 사용권한을 이 개체로 전파할 수 있음’체크상자를 해제한다.
<그림12-9. 파일서버의 권한설정 8>	<그림12-9>와 같은 메시지가 팝업된다. ‘복사’를 누른다.
<그림12-10. 파일서버의 권한설정 9>	이제 기본설정된 NTFS퍼미션을 변경할 수 있도록 활성화 되었다. Everyone 그룹을 제거한다.
<그림12-11. 파일서버의 권한설정 10>	CREATOR OWNER그룹을 추가한다. 이것은 개발팀에 이 폴더내에 새로운 폴더나 파일을 생성한 사용자가 파일이나 폴더에 대해 ‘모든 권한’을 가지도록 해 준다.
<그림12-12. 파일서버의 권한설정 11>	추가로 ‘개발팀’을 위해 미리 생성해둔 도메인 로컬 그룹인 DL_rnd 를 추가하고 ‘읽기 및 실행’, ‘폴더 내용 보기’, ‘읽기’ 사용권한을 할당했다. 여기까지만 할당하면 ‘개발팀’에 권한을 할당하기 위한 그룹인 DL_rnd 그룹의 구성원들은 ‘개발팀’폴더에 대해서 읽기 권한 밖에 가지지 못한다. 추가작업이 필요하다.
<그림12-13. 파일서버의 권한설정 12>	계속 이어서 [고급]버튼을 클릭한다.
<그림12-14. 파일서버의 권한설정 13>	고급옵션의 ‘사용권한’탭에서 [추가]를 누른다.
<그림12-15. 파일서버의 권한설정 14>	‘개발팀 권한 항목’화면에서 이름은 ‘DL_rnd’를 선택하고 적용대상은 ‘이 폴더만’ 사용권한은 하위폴더 및 파일 삭제, 삭제 권한을 제외한 모든 권한을 허용시킨 다음 [확인]을 누른다.
<그림12-16. 파일서버의 권한설정 15>	DL_rnd 그룹을 위한 특별한 권한이 구성되었다. [확인]을 눌러서 구성을 마친다.
다른 부서의 공용폴더도 같은 방법으로 구성해 준다. 이것에 대한 결과로서 각 부서별 폴더는 부서의 구성원들만 접근이 가능하며, 부서의 구성원이라고 할지라도 다른 사용자들이 만든 폴더나 파일에 대해서는 읽기만 가능하고, 자신이 만든 파일에 대해서는 자신이 모든 권한을 가지게 된다. 부서별 데이터를 파일서버에서 처리하는 좋은 구조이다. ‘자신의 파일은 자신이 관리하고, 같은 부서의 다른 사용자가 만든 파일은 읽기만 가능한 구조’가 되었다는 것이다.   부서별 공용데이터 폴더의 권한설정을 마치고 이번에는 사용자별 개인 데이터 폴더를 구성해 보자. 먼저 공용데이터를 저장하기 위한 상위폴더인 Public을 공유하였던 것과 마찬가지로 사용자 데이터를 저장하기 위한 상위폴더인 user 폴더를 공유하고 권한설정을 마친다.
<그림12-17. 파일서버의 권한설정 16>	다음 사용자의 폴더에 대한 NTFS퍼미션을 구성한다. 예제에서는 ‘김수용’이라는 사용자의 홈폴더를 구성하고 있다. 해당폴더를 마우스 오른쪽 클릭하여 ‘등록정보’를 선택한다.
<그림12-18. 파일서버의 권한설정 17>	아래쪽에 ‘부모로부터 상속 가능한 사용권한을 이 개체로 전파할 수 있음’체크상자를 해제하고 Everyone 그룹에게 부여된 퍼미션을 제거한 다음, 김수용(sykim@mscs.co.kr) 사용자에게 ‘모든 권한’을 할당했다. 이 결과로 ‘김수용’ 사용자는 자신의 폴더에 대해서 모든 권한을 가지며, 관리자 그룹이 아닌 다른 어떤 사용자도 ‘김수용’ 폴더에 접근조차 불가능하게 되었다. 사용자의 개인 데이터를 보호하기 위한 좋은 방법이다. 여기서 관리자가 폴더를 들여다 봐야할 특별한 사유가 없다면 Administrators 역시 제거해도 무방하다.

사용자가 많아질수록 일일이 수작업으로 사용자의 폴더마다 권한설정을 하는 것은 상당히 번거로운 작업이다. 도메인의 사용자 계정을 생성할 때 ‘홈폴더’를 할당하면 자동적으로 사용자별 폴더도 생성되고 동시에 이러한 권한설정이 이루어지게 된다. 이것에 대해서는 이 책의 14장을 참고한다.

 

이상으로 파일서버에서 부서별 공용데이터와 사용자별 개인데이터를 관리하기 위한 권한설정을 하는 방법에 대해서 알아보았다.

시스템 관리를 위해 제공되는 몇가지 도구에 대한 소개를 하고자 한다. MMC, 보안구성 도구, 서버 지원도구, 리소스 킷 등에 대해서 알아본다.

 

11-7-1. MMC (Microsoft Management Console)

 

MMC는 한마디로 컨테이너라고 부를수 있다. 컨테이너는 그 자체만으로는 보잘 것이 없다. 제대로 사용이 되려면 컨테이너 안에 화물이 들어차야 유용하게 쓰일수 있을 것이다. MMC도 그런것이다. MMC라는 컨테이너만으로 할 수 있는 작업은 없다. 하지만 이 MMC라는 껍데기에 관리를 위한 구성요소들을 하나씩 하나씩 추가하여 비로소 “관리도구”가 되는 것이다. 이렇듯이 MMC에 집어넣어서 관리도구가 될 수 있는 구성요소들을 가리켜서 “스냅인 개체 (Snap-in Object)”라고 부른다.

 

이렇듯 관리도구가 개체화되어 MMC라는 커다란 컨테이너를 통해서 관리될 수 있도록 한 것에는 상당한 장점이 제공된다. 관리도구의 관리인터페이스가 하나로 통일된다는 것을 의미한다. 더 이상 이전버전의 관리도구들처럼 각각 저마다의 인터페이스를 가지는 것이 아니라 MMC라는 하나의 인터페이스에 통합되어 있기 때문에 관리자들이 보다 쉽게 관리업무를 할 수 있는 환경을 제공한다. 또한 관리자는 자신만의 관리도구를 커스터마이징할 수 있어서 편리하며 개발자적 관점에서 보자면 관리도구를 만드는데 크게 시간낭비를 하지 않고 스냅인개체로 만드는 작업으로써 관리도구를 만드는 작업을 마무리하게 된다. SQL Server 2000, Exchange Server 2000, ISA Server 2004 등 각종 서버제품군들의 관리인터페이스 역시 이 MMC를 채택하고 있어서 통합된 관리환경을 제공하고 있다.

MMC를 실행하기 위해 시작à실행창에 “mmc”라고 입력하였다.	<그림11-163. MMC 실행>
mmc.exe는 MMC를 실행하는 실행파일이다. mmc를 실행하니 하나의 컨테이너가 열렸다. 콘솔메뉴à스냅인 추가/제거를 누른다.	<그림11-164. MMC – 스냅인 추가/제거>
‘독립 실행형 스냅인 추가’화면이 열리면 눈에 익숙한 메뉴들이 펼쳐진다. 시작à프로그램à관리도구에서 찾아볼 수 있는 메뉴들이다. 자주 사용하는 몇가지 스냅인을 [추가]버튼을 이용하여 추가하였다.	<그림11-165. MMC-독립실행형 스냅인 추가>
다섯가지의 스냅인이 추가된 관리콘솔을 보여준다. 이제 당신만의 관리도구가 만들어진 것이다.	<그림11-166. MMC에 스냅인이 추가된 화면>
우리가 ‘시작à프로그램à관리도구’를 통해서 접근할 수 있는 많은 관리도구들도 이러한 MMC콘솔을 통해서 미리 만들어진 관리도구의 단축아이콘일 따름이다.	<그림11-167. 제어판-관리도구>
콘솔메뉴에서 ‘저장’을 누른다.	<그림11-168. 사용자정의된 MMC저장>
방금 당신이 정의한 관리도구를 저장할 수 있다. 확장자가 .msc 인것을 기억하자.	<그림11-169. 관리도구 폴더에 MMC저장
Msc (Microsoft Management Console)확장자는 MMC 를 필요로 하는 확장자이다. 많이 접근하는 관리도구인 ‘컴퓨터 관리’도구를 명령줄에서 불러오기 위해서는 compmgmt.msc 를 입력하면 된다. 시작à프로그램à관리도구à컴퓨터관리를 눌렀을때와 동일한 결과를 볼 수 있다.	<그림11-170. 컴퓨터 관리도구 실행>

 

11-7-2. 보안 분석 구성 도구

 

서버에서 ‘보안’을 고려하는 것은 매우 중요한 작업이다. 보안이라고 하면 사실 그 범위는 너무나 광범위하다. 하지만 서버에서 기본 제공되는 보안정책을 구성하기 위해서 ‘시작à프로그램à관리도구à로컬 보안 정책’을 실행하여 접근할 수 있다.

<그림11-171. 로컬 보안 정책 메뉴>

 

<그림11-171>을 보면 왼쪽 패널에서 계정정책, 로컬정책, 공개키 정책, 로컬컴퓨터의 IP보안 정책등 몇가지 큰 항목들을 보여주고, 오른쪽 패널에서는 세세히 개별적인 정책들의 리스트를 보여주고 있다. 살펴보니 암호관련한 정책을 보여주고 있는데 로컬 컴퓨터의 디렉터리 데이터베이스에서 생성되는 사용자계정에 대한 암호의 사용기간, 암호의 길이 등 보안관련된 정보중에서도 암호와 관련된 정책을 보여주고 있다. 이것은 하나의 단편적인 항목일 뿐이다.

 

하나하나의 모든 항목들을 열어서 관리자가 원하는 수준의 보안을 구성한다는 것은 상당히 부담스러운 일이 아닐수 없다. 또 여러대의 서버가 있을 때 모든 서버를 이렇게 동일수준의 보안을 구성하는 작업을 하는 것도 번거로운 일일 것이다. 무엇보다도 꽤 많은 항목에서 보안설정을 지원해 주고 있기 때문에 각각의 보안구성 항목에 대해서 완전한 지식이 없으면 현실적으로 제대로 사용하기도 어려울 수 밖에 없다는 것이 문제이다.

 

마이크로소프트는 이러한 보안설정을 보다 쉽고 정확하게 할 수 있도록 몇 개의 보안템플릿을 제공하고 있다. 관리자는 이러한 보안 템플릿의 사용방법을 잘 익혀서 시스템에 반영할 수 있다면 직접 처음부터 작업을 하는 것보다는 만족할 만한 수준의 보안을 구현할 수 있게 된다.

 

‘보안 구성 및 분석’도구는 보안템플릿을 효과적으로 사용할 수 있도록 지원해 주는 관리 스냅인이다. 과정을 단계별로 접근해 보겠다.

 

‘보안구성 및 분석’관리도구는 기본제공되는 관리도구의 메뉴에서 찾을 수 없다. 스냅인 개체만을 제공하고 있다. ‘보안구성 및 분석’스냅인을 추가하기 위해서 mmc를 실행한다.

<그림11-172. 보안 구성 도구 1>

 

콘솔메뉴에서 스냅인 추가/제거를 이용하여 ‘보안 구성 및 분석’스냅인을 추가한다.

<그림11-173. 보안 구성 도구 2>

 

왼쪽패널에서 ‘보안 구성 및 분석’스냅인이 추가된 것을 볼 수 있다. 오른쪽 패널에서는 친절하게도 사용법에 대한 설명을 해 주고 있다.

<그림11-174. 보안 구성 도구 3>

 

보안 구성 데이터베이스를 생성해야 한다. ‘보안 구성 및 분석’에서 마우스 오른쪽 클릭하여 ‘데이터 베이스 열기’를 선택한다.

<그림11-175. 보안 구성 도구 4>

 

인터페이스가 조금 맞지 않는다는 생각이 든다. 새로운 데이터베이스를 만드는 것이기에 ‘파일이름’상자에 원하는 데이터베이스 파일 이름을 직접 입력하고 [열기]를 누른다. 예제에서는 test.sdb 라고 입력했다.

<그림11-176. 보안 구성 도구 5>

 

다음은 템플릿 가져오기 화면이 열린다. 위에서 생성하는 test.sdb 데이터베이스 파일에 연결할 템플릿을 선택해야 한다. 템플릿이 저장된 위치는 %Systemroot%\security\templates 폴더이다. *.inf 확장자를 가진 파일들이 보이는데 이것이 기본제공되는 템플릿 파일들이다.

<그림11-177. 보안 구성 도구 6>

basic으로 시작하는 파일은 Windows Server 2003을 처음 설치했을 때 가지는 기본보안설정을 담은 템플릿이다. 보안을 한단계 올리고 싶다면 secure로 시작하는 파일을, 제공되는 템플릿중의 최상위 보안을 구성하려면 hisec로 시작되는 템플릿 파일을 선택한다. 파일이름의 끝에 있는 dc, sv, ws 등의 이름은 각각 도메인 컨트롤러(dc), 서버(sv), 워크스테이션(ws)등을 나타내는 표기이다. 도메인 컨트롤러라면 dc를 일반서버라면 sv나 ws를 선택한다. 어떤 것을 선택할 것인가보다는 일단 이 툴의 사용법을 잘 익혀두자. 예제에서는 hisecws.inf를 선택했다. [열기]를 누른다.

<그림11-178. 보안 구성 도구 7>

처음 화면과 달라진게 없는 것 처럼 보인다. 다시 ‘보안 구성 및 분석’을 마우스 오른쪽 클릭하면 ‘지금 컴퓨터 분석’과 ‘지금 컴퓨터 구성’이라는 메뉴가 보인다. ‘지금 컴퓨터 구성’을 클릭하여 실행하면 불러온 템플릿 파일인 hisecws.inf 파일의 보안설정을 현재 이 시스템에 적용시키겠다는 것을 의미한다. 그렇게 되면 이 시스템의 로컬 보안정책은 템플릿의 내용대로 바뀌게 된다. 그냥 하기엔 뭔가 미심쩍어 보인다. ‘지금 컴퓨터 분석’을 누르면 현재 이 시스템에 적용되고 있는 보안정책과 템플릿의 보안정책을 비교할 수 있도록 해 준다. 좋은 옵션이다. ‘지금 컴퓨터 분석’을 실행했다.

 

이어서 오류로그를 저장할 파일의 위치를 입력해 준다.

<그림11-179. 보안 구성 도구 8>

 

[확인]을 누르니 7가지 카테고리에 대해서 보안분석을 하고 있는 화면이 나온다. 오래 걸리진 않는다.

<그림11-180. 보안 구성 도구 9>

 

보안분석이 끝나고 나면 각 항목마다 ‘데이터베이스 설정’과 ‘컴퓨터 설정’을 비교해 주는 화면이 보인다. 데이터베이스 설정은 템플릿의 설정을 의미하고 컴퓨터 설정은 이 컴퓨터에 현재 설정된 정책을 의미한다. 각 항목을 더블클릭하여 직접 사용자정의하는 것도 가능하다. 녹색 체크아이콘은 데이터베이스 설정과 컴퓨터설정이 일치하는 것을 보여주고, 빨간색 x 표시는 두 설정이 다른 것을 나타낸다.

<그림11-181. 보안 구성 도구 10>

 

이렇게 각각 항목을 차근차근 살펴서 원하는 설정을 정의한 다음 컴퓨터에 적용시키려면 그때 ‘지금 컴퓨터 구성’메뉴를 이용한다.

<그림11-182. 보안 구성 도구 11>

 

컴퓨터 구성을 마치고 나면 모든 아이콘이 녹색체크 표시로 바뀐 것을 보게 되는데 이것은 데이터베이스의 설정이 컴퓨터설정으로 완전히 반영되었음을 나타낸다.

<그림11-183. 보안 구성 도구 12>

 

이렇게 구성한 컴퓨터설정을 다른 컴퓨터에도 동일하게 적용하길 원하거나 테스트시스템에서 작업을 한 보안설정을 실제 적용시킬 서버로 옮긴다거나 할 경우를 위해서 ‘템플릿 내보내기’메뉴를 이용한다.

<그림11-184. 보안 구성 도구 13>

 

이렇게 해서 *.inf 파일로 저장을 하면 사용자정의된 보안템플릿이 만들어진다. 이 파일을 다른 서버에서 앞의 절차와 같은 방법으로 구성하면 해당 서버는 이 서버와 동일한 보안설정을 가지게 된다.

<그림11-185. 보안 구성 도구 14>

 

11-7-3. Windows Server Support tool

 

Windows Server 에서는 OS와 함께 기본적으로 설치되지는 않지만 관리에 도움이 되는 유용한 도구를 원본CD에서 제공하고 있다. 일반적인 관리작업에는 필요하지 않을 수 있지만 조금 더 깊은 내용을 공부하고자 한다면 설치할 필요가 있다.

 

‘원본CD-Support-Tools-Setup.exe’를 통해서 설치한다.

<그림11-186. Support tools 설치>

 

설치를 하고 나면 ADSI Edit, Replication Monitor, SNMPutil, Netdiag.exe 등 여러가지 유용한 툴들과 그들의 사용법에 대한 도움말을 얻을 수 있다. 기본적인 설치위치는 \Program files\Support Tools이다. 설치후 이 폴더를 열어서 툴들을 살펴보라.

 

11-7-5. Runas 서비스 (Secondary Logon)

 

Windows NT기반의 시스템에서 무엇인가 작업을 하기 위해서는 반드시 “로그온”이라는 과정을 거쳐야만 한다. 로그온을 하면 사용자는 자신의 존재를 시스템으로부터 “인증(Authentication)”을 받게 되고 이 인증받은 자격(Security Context)으로서 시스템의 모든 작업을 진행하게 된다.

 

시스템 관리자들이 흔히 하는 실수가 있다. 서버룸에 서버가 있고 시스템 관리자는 사무실에서 업무를 보고 있다. 서버를 관리해야 하는 경우는 극히 일부분의 업무이고 대부분의 업무는 개인의 일상적인 업무임에도 불구하고 많은 시스템 관리자들은 자신의 데스크탑에서 시스템관리자의 계정으로서 로그온을 해 있다거나 혹은 자신의 계정이 도메인의 관리자그룹의 멤버로 되어 있다거나는 하는 경우가 많다. 이것은 보안상의 허점을 노출하게 된다. 네트워크상에서 다른 사용자들이 관리자계정을 알게 하는 등의 허점을 노출시킬 수 있으며 혹은 우습게도 관리자가 잠깐 자리를 비운 사이에 다른 사용자가 관리자의 시스템을 사용한다면 회사의 네트워크에 심각한 문제를 초래할 수도 있기 때문이다.

 

이것에 대해 RunAs 서비스를 이용하는 것은 관리자에게 매우 유용한 기능이라고 할 수 있다. 기본적으로 관리자라고 하더라도 일상적인 작업을 할때는 일반계정을 사용해야 한다. (관리자가 wssong 이라는 계정을 쓰는 사람이었다면 이 wssong이라는 사용자계정은 Domain Admins나 Administrators 그룹의 멤버로 만들어서는 안된다는 것이다.) 관리업무를 해야 할 필요가 있다면 그때 관리자계정으로써 새롭게 로그온을 할 것이 아니라 RunAs 서비스를 이용하여 다른 사용자계정으로서 해당 작업을 열 수가 있다. 그렇게 되면 그 작업에 한정해서만 관리자로서 작업을 하는 것이기에 보다 편하면서도 안전하게 작업을 할 수 있다.

 

시스템에서 이 기능을 사용하기 위해서는 RunAs서비스가 동작하고 있어야 한다. <그림11-187>에서는 RunAs서비스가 시작되어 있음을 보여준다.

<그림11-187. RunAs Service>

 

RunAs를 이용해서 관리도구를 실행하는 방법은 2가지가 있다. 먼저 마우스를 이용해서 접근해 보자. 예제에서는 ‘Active Directory 사용자 및 컴퓨터’를 실행하고자 한다. 이 관리도구가 있는 곳까지 마우스를 이동한 다음 키보드 [Shift]키를 누르채로 마우스 오른쪽 버튼을 누르면 ‘다음 계정으로 실행’이라는 메뉴가 활성화된다. 이 화면에서 [다음 계정으로 실행]을 누른다.

<그림11-188. GUI 환경에서 RunAs 사용 1>

 

‘다음 사용자 계정으로 실행’창이 열리면 하고자 하는 작업의 권한이 있는 사용자 계정과 암호를 넣어준다.

<그림11-189. GUI 환경에서 RunAs 사용 2>

  

다음은 명령프롬프트에서 RunAs 사용법에 대해서도 익혀보자. <그림11-200>에서 runas /?를 이용하여 사용법을 들여다 보았다. 다음에 아래와 같이 타이핑했다.

 

runas /user:wssong "mmc %windir%\system32\compmgmt.msc"

이것은 wssong 계정의 권한으로써 mmc 로써 compmgmt.msc (컴퓨터 관리도구)를 실행하는 것을 보여준다. 잠시후 관리도구가 실행되고 해당 관리도구를 닫는 순간 RunAs를 이용한 Secondary logon 권한은 없어진다. 

<그림11-190. 명령프롬프트에서 RunAs 사용>

11-7-6. Net.exe

 

Net.exe는 명령프롬프트에서 사용되는 도구로써 둘째가라면 서러워할만큼 자주 사용되는 도구이다. 옵션도 다양하여 상당히 많은 작업을 이 도구를 통해서 해낼수가 있다.

 

D:\>net  (net 명령어에 대해서 알아본다.) 이 명령에 대한 구문:     NET [ ACCOUNTS | COMPUTER | CONFIG | CONTINUE | FILE | GROUP | HELP |       HELPMSG | LOCALGROUP | NAME | PAUSE | PRINT | SEND | SESSION |       SHARE | START | STATISTICS | STOP | TIME | USE | USER | VIEW ]     D:\>net help use (net use의 사용법을 물어본다.) 이 명령에 대한 구문:     NET USE [장치이름| *] [\\컴퓨터이름\공유이름[\볼륨] [암호| *]]         [/USER:[도메인이름\]사용자이름]         [/USER:[점있는 도메인이름\]사용자이름]         [/USER:[사용자이름@점있는 도메인이름]         [[/DELETE] | [/PERSISTENT:{YES | NO}]]   NET USE {장치이름 | *} [암호 | *] /HOME   NET USE [/PERSISTENT:{YES | NO}]     NET USE는 컴퓨터를 공유되는 리소스에 연결시키거나 연결을 끊습니다. 옵션 없이 사용될 경우에는 해당 컴퓨터의 연결 상태를 열거해 줍니다.   장치이름    리소스에 연결시킬 이름을 설정하거나 연결을 끊을 장치를                 지정합니다. 장치는 두 종류인데  하나는 디스크 드라이브                 (D: 에서 Z:까지)이고 다른 하나는 프린터(LPT1: 에서 LPT3:까지                 )입니다. 다음 차례의 사용 가능한 장치이름를 지정하고 싶을                 경우 특정 장치이름 대신 *를 치면 됩니다. \\컴퓨터이름    공유 리소스를 제어하는 컴퓨터의 이름입니다.                 컴퓨터이름에 공백이 있을 경우, \\(두개의 백슬래시)와 컴퓨터                 이름을 인용부호(" ") 안에 넣어줍니다. 컴퓨터이름은 1에서 15자                 까지 쓸 수 있습니다. \공유이름       공유되고 있는 리소스의 네트워크이름입니다. \볼륨           서버상의 NetWare 볼륨을 지정합니다.  NetWare 서버에 연결되기                 위해서는 NetWare용 클라이언트 서비스(Windows 워크스테이션)                 혹은 NetWare용 게이트웨이 서비스(Windows 서버)가 설치되어                 실행되고 있어야 합니다. 암호            공유 리소스에 연결하는 데 필요한 암호입니다. *               암호를 칠 수 있는 프롬프트 상태를 만들어줍니다. 암호 프롬프트                 에서는 암호를 쳐도 암호가 보이지 않습니다. /USER           연결에 사용할 다른 사용자 이름을 지정합니다. 도메인이름      다른 도메인을 지정합니다. 도메인을 생략하면 현재 로그온                 되어있는 도메인이 사용됩니다. 사용자이름      로그온할 때 쓸 사용자이름을 지정합니다. /HOME         사용자를 홈 디렉터리에 연결시킵니다. /DELETE        네트워크 연결을 취소시키고 영구 연결 목록에서 연결을 삭제                 합니다. /PERSISTENT     영구적인 네트워크 연결의 사용을 제어합니다. 기본 설정은                 이전에 사용된 설정입니다. YES             이루어진 연결을 저장하여 다음 번 로그온시 연결을 복원합니다. NO              이루어진 연결 혹은 후속 연결을 저장하지 않습니다. 기존의                 연결은 다음번 로그온시 복원됩니다. 영구 연결을 제거하려면                 /DELETE 스위치를 사용합니다. NET HELP 명령 | MORE은 도움말을 한번에 한 화면씩 보여줍니다.     D:\>net help use >>d:\netuse.txt (net use의 사용법을 화면에 디스플레이 하지 말고 d:\netuse.txt파일로 저장하라는 명령이다. >>는 명령을 파일로 Redirection해 주는 역할을 한다.)   D:\>notepad d:\netuse.txt (메모장을 사용해서 저장된 파일을 열어본다.)

 

 

D:\>net use (클라이언트로서 현재 다른 서버에 연결된 정보를 보여준다.) 새 연결 정보가 저장됩니다.   목록에 항목이 없습니다.   D:\>net use \\redapple\ipc$ /user:wssong (redapple 서버에 wssong 이라는 계정을 이용해서 세션을 맺고 있다.) \\redapple\ipc$에 대한 암호나 사용자 이름이 잘못되었습니다.   \\redapple\ipc$에 대한 암호를 입력하십시오: 명령을 잘 실행했습니다.   D:\>net view \\redapple (redapple 이라는 이름의 서버의 공유자원을 보여달라는 명령)   \\redapple의 공유 리소스   공유 이름      종류   다음으로 사용  설명 -------------------------------------------------------------------------- icons     Disk source         Disk 명령을 잘 실행했습니다.   D:\>start \\redapple (blueapple서버로의 연결을 시도하고 있다.)   <그림11-201>   D:\>net use (다시 net use를 실행하니 위에서 연결한 정보를 보여주고 있다.) 새 연결 정보가 저장됩니다.   상태         로컬      원격                      네트워크 --------------------------------------------------------------------------- OK                     \\redapple\ipc$         Microsoft Windows Network 명령을 잘 실행했습니다.   D:\>net use t: \\redapple\icons (로컬 T:에 blueapple의 work 공유폴더를 매핑시키고 있다) 명령을 잘 실행했습니다.   D:\>t:   T:\>dir/w (로컬자원처럼 보이지만 실제로는 blueapple의 work공유폴더의 자원을 보여준다)  T 드라이브의 볼륨: ADserver  볼륨 일련 번호: 649F-4C9B   T:\ 디렉터리   [.]                      [..]                     010100100504SM.zip 100-0019_IMG copy.jpg    100-0020_IMG copy.jpg    100-0030_IMG copy.jpg [2000SETUP]              5.DNS.doc                [ex2000] Image1.psp               Image2.psp               schema.doc [SEcTools]               [terminal]               test.sdb yongha_name.jpg                 14개 파일      15,144,284 바이트                7 디렉터리   3,940,126,720 바이트 남음   T:\>c:   C:\>net use 새 연결 정보가 저장됩니다.   상태         로컬      원격                      네트워크   ---------------------------------------------------------------------------OK           T:        \\redapple\icons         Microsoft Windows Network OK                     \\redapple\ipc$         Microsoft Windows Network 명령을 잘 실행했습니다.   C:\>net use t: /d (로컬 t:의 연결을 끊는 명령) t:이(가) 제거되었습니다.   C:\>net use 새 연결 정보가 저장됩니다.     상태         로컬      원격                      네트워크   --------------------------------------------------------------------------- OK                     \\redapple\ipc$         Microsoft Windows Network 명령을 잘 실행했습니다. C:\>net send bluexp "Send 메시지를 테스트하고 있습니다. 나 누구게?" (네트워크에서 bluexp라는 이름을 찾아서 “  “ 안의 메시지를 전송한다) BLUEXP에 메시지를 보냈습니다.   <그림11-202> (bluexp에서는 위의 화면이 팝업된다. bluexp에서는 Messenger서비스가 동작하고 있어야 한다.)   C:\>net user thkim 1234 /Add (서버의 디렉터리 데이터베이스에 1234라는 암호를 사용하는 thkim계정을 생성하고 있다.) 명령을 잘 실행했습니다.

 

이상으로 Net.exe에 대한 몇가지 사용예를 알아보았다. 위의 예제에 있는 내용 정도는 차근차근 테스트해 보기를 권장한다. 시스템이 두대가 있다면 좋겠지만 한대만 있어도 테스트는 가능하다. 자신의 컴퓨터에 공유폴더를 몇 개 생성하고 테스트를 해 보라. 다른 옵션들은 각각 help를 참고하여 접근해 보라. 잘 안풀리는 명령어가 있다면 필자의 개인홈페이지 Q&A에 글을 올려서 같이 해결해 볼 수 있었으면 한다.

 

지금까지 꽤 많은 지면을 할애하여 Windows Server 의 몇가지 기능들을 알아보았다. 윈도우 서버의 전체기능을 설명하고자 하지는 않았다. 다만 사용될만한 기능들을 위주로 다룬 것이니 독자들이 미처 몰랐던 내용이 있다면 잘 정리해 두길 바란다.

11-6-1. 서비스팩

 

우리가 사용하는 응용프로그램, 즉 소프트웨어는 수많은 코드로써 이루어져 있다. 코드가 많아지면 많아질수록 따라서 늘어가는 것이 있는데 그것이 바로 ‘버그(Bug)’이다. 우리가 ‘서버’로서 사용하는 OS역시 하나의 소프트웨어일 따름이다. 그것도 엄청난 덩지를 차지하는 코드로써 만들어진 대형 소프트웨어라고 할 수 있을 것이다. 그러다 보니 이것 역시 버그의 존재를 무시할 수 없다. 이러한 버그를 패치할 방법이 필요하다.

 

또 한가지 측면은 서버에 새로운 기능을 추가한다거나, 기존에 제공되는 기능의 성능을 강화할 필요성이 생긴다. 혹은 새로운 응용프로그램이 개발되었는데 이것이 기존의 서버의 버전에서 동작을 하지 못한다거나 할 경우이다. 이럴 경우 역시 서버를 버전업 시킬 수 있는 방법이 필요해 진다.

 

다른 소프트웨어에 비해서 마이크로소프트의 Windows 기반의 OS들은 유난히 많은 버그를 가진 것으로 인식이 되고 있는데 다행인 것은 버그가 발견될 때마다 대부분의 경우 마이크로소프트는 그 버그를 해결(패치)할 수 있는 패치프로그램을 제공하고 있다는 것이다.(마케팅 전략과 맞물려 새로운 서비스팩 출시의 논란이 있어왔기는 했지만..) 이러한 패치들을 묶어서 ‘서비스팩’이라는 이름을 제공하고 있다.

 

결론을 말하자면 관리자는 이러한 서비스팩이 출시가 되면 분명히 패치를 해 주어야 한다는 것이다. 그것은 당신의 시스템을 보다 건강하고 안전하게 만들어 주는 방법이 될 것이다. 주의할 점은 서비스팩은 별도의 패키지이다. Windows Server 2003을 설치할 수 있는 원본CD에 담긴 자료는 당연히 패치가 되기 전 상태의 OS를 셋업해 줄 것이다. 서비스팩을 설치한 후 라도 원본CD로부터 새로운 CD를 설치했다면 새롭게 서비스팩을 패치해 주어야 제대로 된 현재의 버전을 유지할 수 있다.

 

11-11-2. 핫픽스(Hotfix)

 

대부분의 경우에는 버그를 패치하기 위해 긴급히 출시되는 패치파일이다. 서비스팩은 1년에 1~2차례 정도 정기적으로 출시된다. 하지만 서비스팩이 출시되고 다음번 서비스팩이 나오기 전까지 심각한 문제점이 발견되었다면 역시 해결해야 할 일이 될 것이다. 특히 ‘보안’상의 위험요소가 존재할 때 더욱 그러하다. 그런 이유로 마이크로소프트는 특별한 보안상의 문제가 될 수 있는 버그가 발견되었을 때 ‘핫픽스’라는 이름으로 보안패치를 제공하고 있다. 이러한 보안패치중의 대부분은 다음 버전 서비스팩에 포함된다. 관리자들은 이러한 핫픽스가 발표되면 회사에서 해당되는 문제인지를 판단하고 관련시스템에 패치하는 작업을 해야만 한다.

 

관련내용은 마이크로소프트 보안 웹사이트(http://www.microsoft.com/korea/security/default.asp)를 참고한다. 보안게시판(http://www.microsoft.com/korea/technet/security/current.asp)을 통해서 대부분의 리스트를 확인할 수 있다.

윈도우 2000 서버부터 마이크로소프트는 복구콘솔이라는 프로그램을 지원한다. 이 복구콘솔을 통해서 관리자는 시스템이 부팅이 되지 않는 등의 문제가 발생했을 때 NTFS파일시스템에 접근이 가능하며 특정 서비스나 디바이스를 중지시키거나 시작시키도록 레지스트리를 수정할 수 있으며 하드디스크를 포맷하는 등 몇가지 작업을 가능하게 만든다.

 

복구콘솔을 사용하는 방법은 두 가지이다. 원본CD롬으로부터 부팅하여 셋업도중 <R>키를 이용한 복구과정에서 복구콘솔을 사용할 수도 있고, 미리 시스템에 복구콘솔을 설치해 둘 수도 있다. 설치를 해 보도록 하겠다.

 

복구콘솔을 서버의 설치프로그램을 통해서 설치할 수 있다. 원본CD의 i386폴더안에는 winnt32.exe라는 설치 프로그램이 들어있다. 이것을 /cmdcons 스위치를 이용해서 설치해 주면 된다.

<그림11-156. 복구 콘솔 설치 방법 >

 

복구콘솔 설치와 관련된 안내메시지를 보여준다. [예]를 누른다.

<그림11-157. 복구 콘솔 설치 안내문>

 

설치가 완료되고 나면 C: 루트에 있는 시스템 파일중의 하나인 boot.ini에는 작은 변화가 있다.

<그림11-158. 복구콘솔 부팅 메뉴가 추가된 Boot.ini 파일>

 

“C:\CMDCONS\BOOTSECT.DAT=”Microsoft Windows 2000 복구콘솔” /cmdcons”라는 메뉴가 추가된 것을 보여주는데 이것을 통해서 복구콘솔로 부팅을 하여 몇가지 작업을 할 수 있게 된다.

 

이렇게 설치한 복구콘솔을 사용하는 방법은 다음과 같다.

<그림11-159. 고급 옵션 메뉴>	시스템을 부팅할 때 “복구콘솔”메뉴를 선택하여 부팅을 시도한다.
<그림11-160. 고급 옵션 메뉴>	복구콘솔은 이 시스템에 설치된 Windows NT 기반의 OS를 찾아내고 해당 OS를 보여주며, 관리자의 암호를 요구한다. 올바른 관리자 암호를 입력해 주었더니 C:\WINNT 에서 명령프롬프트가 시작된 것을 볼 수 있다.
<그림11-161. 고급 옵션 메뉴>	여기서 무슨 작업을 할 수 있을지 “?”를 입력해 보았다. 그랬더니 사용할 수 있는 명령어들이 쏟아진다. DOS명령어들이 대부분이다. 각각의 명령어들에 대한 사용방법을 알고자 한다면 “help 명령어”형태로 도움말 정보를 얻을 수 있다.
<그림11-162. 고급 옵션 메뉴>	필자는 예제에서 “disble dns”를 실행했다. 이 명령은 시스템의 DNS서비스에 대한 시작옵션은 ‘Disable’로 변경하는 효과를 주었다. 이 시스템이 다음번에 부팅할 때는 DNS서비스를 시작하지 않고 부팅한다. 이것은 특정한 서비스 문제로 인한 부팅실패를 간단하게 해결할 수 있게 해준다.

간혹.. 아니 심심찮게.. 솔직히 많은 시스템을 만나게 되면 자주 만나게 되는 화면중의 하나이다. 파란색 화면이라는 뜻으로 “Blue Screen”이라고들 부른다. 혹은 어떤 작업을 하든지 모든 것을 멈추고 갑자기 나오는 화면이기에 “Stop Error”라고도 부른다. 이것은 NTLDR이 이끌어가는 초기 부팅과정과는 상관이 없다. 그 이후에 커널을 초기화하는 과정이나 혹은 정상적으로 부팅후 로그온하여 특정 응용프로그램을 사용하다가 만나게 되는 화면이다.

 

대부분의 경우는 재부팅이 되면서 아무런 문제가 없는 것이 보통의 경우이지만 또 다시 부팅이 되면서 이러한 에러가 발생하면서 더 이상 부팅이 진행되지 않는다면 당황스러운 일이 아닐수 없다.

<그림11-153. Blue Screen 또는 Stop Error>

 

마이크로소프트는 이러한 문제를 “디버깅”이라는 과정을 거쳐서 해결할 수 있는 방법을 제공하고 있지만 조금은 현실성이 떨어지는 방법이다. 또한 대부분의 경우에 재부팅을 통해서 해결이 되는 것이 일반적이기 때문에 디버깅까지 해서 반드시 살려내야 하는 시스템이라면 그전에 이미 문제가 생겼을때를 대비하는 조치를 취했을 노릇이다. 백업이나 서버의 중복 등을 의미한다. 관리자입장에서는 지푸라기라도 잡고 싶은 심정인만큼 최선의 노력을 해 봐야 할 것인데 그럴 때 시스템을 시작시킬 때 [F8]키를 이용해서 접근할 수 있는 고급옵션에서 몇가지를 찾아볼 수 있다.

 

고급옵션은 POST 과정이 끝나고 [F8]키를 이용해서 접근할 수 있다. <그림11-154>을 보면 아래쪽에 고급옵션을 보려면 [F8]을 누르라는 옵션이 보인다.

<그림11-154. 고급 시작 옵션 [F8]키>

 

[F8]키를 눌러 고급옵션 메뉴를 볼 수가 있다. 어떤 메뉴들이 있는지 살펴본다.

<그림11-155. 고급 옵션 메뉴>

 

① 안전모드 : 컴퓨터를 시작하는데 필요한 기본 디바이스만을 사용하여 부팅한다. 새로 추가한 디바이스나 특정 디바이스가 문제가 생겨서 부팅이 되지 않을 때 사용할 수 있는 옵션이다.

② 부팅 로깅 사용 : 부팅과정을 %Systemroot% 폴더에 Ntbtlog.txt 파일에 로깅한다.

③ VGA모드 : 업데이트한 비디오 드라이버가 문제가 생겨서 시스템이 먹통이 된다거나 하는 경우에 유용하다. 기본 VGA드라이버를 로드하여 부팅한다. 부팅후 새롭게 VGA카드 드라이버를 설치하여 해결할 수 있다.

④ 마지막으로 성공한 구성 : Last Known Good Configuration (LKGC)라고 부른다.

⑤ 디렉터리 서비스 복원모드 : 백업받은 Active Directory 데이터베이스를 복구하고자 할 때 이 모드로써 부팅해야 한다.

⑥ 디버그 모드 : 직렬 케이블로 연결된 다른 시스템에서 디버깅 정보를 받을 수 있도록 구성한다.

응급복구디스크(ERD)는 Windows 시스템이 손상되어 부팅이 되지 않을 때 훌륭한 해결책을 제시한다. 이 디스켓을 만들려면 백업프로그램을 이용할 수 있다. 응급복구 디스켓이 없을때도 응급복구를 할 수는 있지만 일부분에 한해서만 가능하다. 미리 응급복구디스크를 만들어 두는 것은 좋은 방법이다.

 

응급복구를 진행하는 방법은 2가지가 있다. 윈도우 서버 설치디스켓으로부터 부팅하여 접근하는 방법과, 윈도우 서버 원본CD롬으로부터 설치과정을 통해서 접근하는 방법이 있다. 부팅디스켓, 셋업디스켓, 응급복구디스켓 이들은 모두 다르다. 필자는 예제에서 Windows 2000 Server의 CD롬 부팅을 통한 셋업과정에서 응급복구를 진행해 보도록 하겠다. 

<그림11-144. 응급 복구 과정 1>	윈도우2000서버 원본CD롬으로부터 시스템에서 부팅을 하여 셋업을 진행하는 것과 동일하게 진행한다. <그림11-144>화면에서 <Enter>키를 누르면 셋업을 하게 되는 것이고 <R>키를 입력하여 복구과정을 진행할 수 있다. 의도한 대로 <R>키를 입력하였다.
<그림11-145. 응급 복구 과정 2>	복구옵션을 선택하는 화면인데 2가지가 나온다. 복구콘솔을 이용할 수도 있고, 응급복구를 진행할 수도 있다. 복구콘솔에 대해서는 다음에 다룬다. 응급복구를 진행하기 위해서 <R>키를 입력한다.
<그림11-146. 응급 복구 과정 3>	응급복구는 수동복구<M>와 빠른복구<F>가 있는데 수동복구를 선택하면 복구하고자 하는 옵션을 체크해서 복구를 진행하게 된다. 빠른복구를 사용하자. <F>키를 입력하였다.
<그림11-147. 응급 복구 과정 4>	시작환경, 시스템파일, 부팅 섹터를 검사하겠다고 한다. [X]표시가 선택이 된 것이다. 우리는 보통 X 표시는 안 하겠다는 뜻인데 우리랑 관념이 다른가 보다. 계속 진행하기 위해서 <Enter>키를 누른다.
<그림11-148. 응급 복구 과정 5>	응급복구디스켓이 있으면 넣고 <Enter>키를 누르고 없으면 <L>키를 누른다. 응급복구디스켓이 있으면 보다 폭넓은 복구가 가능하다. 하지만 부팅프로세스에서 생기는 문제정도는 디스켓이 없어도 잘 복구가 된다. <L>키를 눌렀다.
<그림11-149. 응급 복구 과정 6>	<참고>전 화면에서 <Enter>키를 입력하면 다음과 같은 화면이 보인다.
<그림11-150. 응급 복구 과정 7>	응급복구 프로세스가 시작되었다. 하드디스크를 검색하여 필요로 하는 파일이 손상되었다거나 하는 것을 검색하면 알려줄 것이다.
<그림11-151. 응급 복구 과정 8>	Ntldr이 버전이 다른 것을 발견하고 멈추었다. 복구하려면 <Enter>키를 누르라고 한다. <Enter>키를 입력하면 원본CD로부터 파일을 가져와서 하드디스크의 파일을 대체하는 작업을 한다.
<그림11-152. 응급 복구 과정 9>	응급복구가 완료되었다는 메시지가 나왔다. 시스템을 재시작하면 부팅이 안되었던 문제점이 해결되어 부팅이 성공하는 것을 확인할 수 있다. 부디 확인할 수 있기를…