중소기업진흥공단 중소기업연수원은 마이크로소프트 최고의 컨설팅 서비스 파트너인 필라넷과 2011년 새로운 키워드로 급부상하고 있는 스마트워크(Smart Work)을 주제로 하는 1박2일간의 Smart Work 컨퍼런스를 개최합니다.

금번 Smart Work 컨퍼런스는 약 120개사의 중소기업 IT담당자를 모집하여 개최될 것이며 Smart work의 개념부터 시작해서 사례발표 및 Microsoft의 Exchange 2010, Lync 2010, Sharepoint 2010 기반의 Smart work 구현기술과 구축을 위한 하드웨어, 통신 기술 등에 이르기까지 Smart Work에 대한 모든 것을 다루기 위해 준비되었습니다.

컨퍼런스는 2011.5.3(화)~5.4(수)까지 1박2일로 진행되며 연수원의 기숙사 시설을 제공합니다.
상세한 안내는  http://www.fa.or.kr/conf/10th/index.html 를 통해 확인하실 수 있습니다.

 

늘 행복하시고, 건승하시길 바랍니다.
행복하세요..!!!

내 자리의 데스크탑은 Windows 2000 advanced server가 인스톨되어 있고, 그 서버는 도메인 컨트롤러로 셋업되어 하나의 도메인을 만들어 내고 있다. 노트북은 그 도메인의 멤버로 설정된 Windows 2000 professional이다.

어느날 문득 노트북의 시계를 확인하니 핸드폰의 시간보다 6분 정도 느린 것을 발견했다. 컴퓨터로 작업을 하다 보면 무의식적으로 모니터의 트레이에 위치한 시계를 통해서 시간을 체크하는 것이 일반적이다.

핸드폰의 시간을 기준으로 시계를 맞추고 나서 작업을 계속했다. 다음날 또 다시 시간이 6분 정도 느려진 것을 알게 됬다.

"왜일까??

노트북 제조회사의 서비스센터에 전화를 하니 아마도 CMOS보조 배터리의 상태가 좋지 않은 듯하다고 기사를 보내겠다고 했다. "아니요.. 오실 필요까지는 없는데.."라고 했지만 극구 직접 방문해서 확인을 해 주겠단다. '음.. 서비스 많이 좋아졌군..^^' 하는 생각을 하고 기다렸다.

제조회사의 기사가 와서 노트북을 분해하기 시작했다. 잠시후.. 어?? 당황하는 빛이 역력했다. 키보드를 뜯어냈는데 있어야 할 배터리가 나오질 않는거다. 잠시후~ 시스템을 분해하지 않았어도 될 위치에서 배터리를 발견했다. 노트북 바닥면의 메모리 확장 슬롯을 장착하는 공간에 배터리가 있었던 것이다. 으흐흐..~ (속으로 ..)
배터리를 빼내고 전압체크를 하더니 뭔가 갸우뚱하는 듯한 인상을 주었고, 어찌됬건 배터리를 교체하고 나서 1시간쯤 지났을까? 이런.. 또 다시 시계가 6분 정도 느려져 있었다. 왜 이럴까?? 하는 순간에

아차.. 하고 스치고 지나가는 생각. 부리나케 데스크탑에서 관리자로 로그온을 했다.

데스크탑의 시계를 확인하니 역시 6분 정도 느린, 지금의 노트북과 일치하는 시간을 확인할 수 있었다. 그랬구나.. 바보였어. 배터리 문제가 아니라 시스템이 정상적으로 동작하고 있었던 결과였던 것을...

노트북 담당기사가 배터리를 교체하고, 꺼낸 배터리의 전압을 체크하고 갸우뚱... 하던 모습이 이해가 되는 순간이었다.

Windows2000의 도메인컨트롤러는 SNTP (Simpel Network Time Protocol)을 이용하여 시스템들의 시간을 동기화시켜주는 기능을 제공한다. Windows2000에서 로그온 하는 클라이언트가 타임스탬프를 이용한 암호화를 통해서 도메인컨트롤러에 사용자정보를 제공하기 때문에 상대적으로 시간정보가 중요하기 때문이다.

이론으로 정리를 하고, Active Directory강의시 이러한 내용들을 강조해서 강의를 하면서도 막상 이런 실수를 하고 말았다. 모든 상황에서 알고 있는 지식이 바로바로 매칭되어 튀어 나올수 있다면 좋을텐데... 하긴, 어쩌한 그러한 순간순간의 해결을 위해서 수백페이지의 책을 읽어야 하는 지도 모를일이다.

글, 송원석 팀장 "(주)필라넷 정보기술팀”

http://technet.microsoft.com/ko-kr/library/cc700736.aspx

네이버에서 지식검생중에 우연히 발견한 글이다. 비단 오픈마켓 뿐이랴, 시사하는 바가 있는 듯 하여 옮겨 놓는다.

======================================================================================================

 온라인, 특히 오픈마켓에서 판매하고 있거나 판매중인 사람은 누구나가 빅셀러가 되고 싶어한다. 그러나 모두가 빅셀러가 되는 것은 아니다.
성공을 하려면 성공한 사람을 만나야 한다는 말이 있다.
유사 분야의 빅셀러와 안면이 있다면 좋겠으나 그러나 그것이 어디 말처럼 쉬운 일인가? 그리고 또한 자신외 타인은 경쟁상대로 보는 마당에 누가 자신이 쌓아온 노하우를 쉽게 공개해 주겠는가?
하지만 당신은 온라인상에서 판매하는 빅셀러를 벤치마킹하려는 것이다.
다행스럽게도 온라인이라는 특징때문에 당신은 그들의 판매기법을 간접적으로마나 살펴 볼 수 있다.

자 그럼 빅셀러를 직접 만나서 노하우를 듣거나 전수받는 것 외에 온라인을 통해 간접적
으로 빅셀러의 어떤 부분을 벤치마킹 해야 하는지를 살펴보도록 하자.

1. 빅셀러의 아이템 Vs 나의 아이템

당신이 경쟁자가 거의 없는 독특한 아이템을 취급한다면 아래부분을 자세히 볼 필요가 없다. 그러나 그렇지 않다면 아래 글들을 반드시 살펴보기 바란다.
취급하고자 하는 분야의 카테고리에서 잘 팔리고 있는 상품을 보라.
여기서 주의할 점은 당연히 취급상품의 특성도 반드시 포함하여 살펴봐야 한다는 것이다. 계절적 요인이 작용하는 상품이라면 계절적 특수성도 봐야할 것이며 유행이나 트렌드(Trend)에 민감한 상품인지 등을 반드시 검토할 때 염두에 두고 살펴봐야 한다는 의미이다.
또한 해당 아이템을 취급하는 판매자는 어느 정도 수준인지 검토해야 한다.
많이 판매되는 아이템일지라도 취급하는 판매자 또한 많다면 과연 그 시장에 참여하여 경쟁할 것인지 아니면 판매는 적을지라도 경쟁상대가 없는 틈새시장의 아이템을 발굴해서 취급할 것인지를 반드시 검토해야 한다.
저자의 경우라면 빅셀러의 판매보다 경쟁력있는 판매가 가능하다면 전자를 택할 것이고 그렇지 않다면 후자를 택할 것이다.
왜냐하면 오픈마켓은 이미 저렴한 가격을 기준으로 구매하는 고객이 전체의 70%를 차지하고 있기때문이다.

2. 상품의 제목! 글자 토씨 하나도 놓치지 말고 분석하자.

잘되는 판매자는 잘되는 판매자만의 노하우가 분명이 존재한다.
우리가 게시판의 글을 보더라도 다른 제목보다 더 눈길이 가는 제목의 글들이 있다.
즉, 같은 게시판의 글일지라도 분명 그 글들간에는 차별화가 존재한다는 뜻이다.
이는 모방을 통해서는 한계가 있을 것이며 무한하게 창작 가능한 부분이기도 한다.
그리고 부단한 연습과 노력, 시행착오를 통해서만 얻을 수 있는 분분이기도 하다.
하지만 이러한 노력과 시행착오를 통해 얻은 결과는 이제 당신의 것이며 당신의 상품 판매량은 점점 달라지기 시작할 것이다. 온라인 판매에 있어서 제일 중요한 '고객의 눈길을 끌어라'는 아무리 강조해도 지나치지 않기 때문이다.

3. 상품의 판매방식, 판매기간은 어떻게 하고 있는지 모니터링 하자.

빅셀러들도 처음부터 빅셀러는 아니었다. 빅셀러가 되기까지 여러가지 시행착오를 거쳐서 여기까지 온 것이다.
그러니 그들이 판매하는 판매방식(경매/공동구매/즉시구매설정여부 등등)은 그들의 경험이 녹아져 들어가 반영된 결과인 것이다.
또한 빅셀러들은 오픈마켓에서 제공하는 유/무료 부가서비스는 어떻게 이용하고 있는지살펴보자. 작은 것하나라도 놓치지 말고 꾸준히 모니터링하고 분석하는 습관을기른다면 이미 성공적인 첫발을 뗀 것이라 확신한다.

4. 상품의 소개 페이지를 어떻게 구성하고 관리하고 있는가?

빅셀러들의 상품소개 페이지를 보라.
빅셀러들의 상품소개 페이지를 보면 대부분 상당히 신경을 써서 제작한 흔적이 여기 저기에서 엿보인다.
이유는 간단하다. 온라인이라는 특수성 때문이다.
오프라인 가게라면 전시된 물품을 눈으로 보고 직접 체감을 통해 판단할 수 있지만 온라인에 전시된 상품은 이미지와 글로서 상품의 가치와 구매호소력을 지닌다.
특히나 의류, 패션관련 아이템의 경우 디테일한 부분까지 제품소개 이미지를 제공하는 것을 알 수 있을 것이다. 좀 더 발전된 판매자의 경우 연예인 등 스타를 이용한 상품페이지도
진행중인 것이 현실이다. 그렇다고 반드시 돈을 많이 들어야만 되는 부분은 아닌 것이다.
이 부분은 다른 판매기법 소개시 다시 살펴보도록 하자.
빅셀러의 상품페이지를 보면 대부분 정돈된 이미지, 표와 같은 형식으로 구성된 제품의 특성표시, 거기에다가 판매하는 다른 상품의 추가 간접광고 등의 기법을 이용하고 있음을 알 수 있을 것이다.
자 이제 당신은 판매할 상품을 어떻게 표현할 것인지 감이 오는가?
내가 구매자라면 어떻게 내상품이 표현되어야 구매할 마음이 들지를 생각해보면 될 것이다.

5. 빅셀러의 구매자들의 구매거래평을 참고하라.

구매자들의 글 속에는 진리가 숨겨져 있다.
빅셀러의 무엇이 구매고객들로 하여금 만족감을 주는지, 더 나아가 감동을 주고 있는지 확인하라. 그리고 느꼈다면 당장 할 수 있는 작은 부분부터 실천하라.
이러한 것들이 쌓이고 쌓여서 당신을 정상의 길로 안내하고 있는 것이다.

6. 고객들에게 특별한 인센티브를 제공하고 있는지 확인하라.

빅셀러가 자신의 고객에게 어떤 인센티브를 제공하고 있는지 확인하자.
여기서 말하는 인센티브는 유무형의 모든 것을 말한다.
사은품이 될 수도 있고 무료배송 혜택일 수도 있고 쿠폰이 될수도 있다.
그렇지 않다면 상품배송시 들어가는 구매감사의 표현이 담긴 작은 쪽지 일수도 있다.
빅셀러들은 고객들에게 어떤 인센티브를 제공하여 만족과 감동과 단골을 확보하고 있는지 확인해보라.

7. 직접 물품을 구입해서 해당 빅셀러의 일처리 프로세스(과정)에 대해서 느껴보자.

벤치마킹을 위해 많은 빅셀러들의 물품을 구입해보라는 의미는 아니다.
(물론 할수만 있다면 좋겠으나...)
단, 이 단계에서  대상 빅셀러를 선정하는 방법은 가격으로만 승부하는 빅셀러는 제외한다.
왜냐하면 가격으로 승부하는 빅셀러는 가격 자체가 큰 무기이자 경쟁력을 갖고 있으므로 벤치마킹해서 얻을 부분이 그리 많지 않을 것이기 때문이다.
오픈마켓에서 판매하고 있는 사람이거나 판매를 시작하려는 사람들중 과연 몇 %정도가가격에서 큰 경쟁력을 가지고 있겠는가?

실제 생산, 유통을 하지 않는 한 대부분의 판매자는  가격적 부분에서 서로가 경쟁의 Boundary(범위)에 있다고 보는게 맞다.
따라서 지금 말하고자 하는 빅셀러는 자신에 적합한 대표적인 몇 몇 빅셀러를 의미한다.
그럼으로써 그들이 판매과정에서 고객들에게 어떤 반응을 보이고 또 어떤 서비스를 제공하고 있는지 알아볼 수 있으며 해당 빅셀러의 좋은 점을 금방 잡아낼 수 있다.
예를 들자면, 배송시작부터 종료시까지 구매자에게 진행상황에 대한 SMS(단문문자메시지)을 전송해준다거나 상품포장은 어떤 식으로 하는지, 사은품을 제공하고 있는지 등을 파악하여 알 수 있게 해준다. 당연히 좋다고 여겨지는 부분은 응용해야 하지 않을까.

----------------------출처와 저작권에 대한 안내 -------------------------------
 출처 : 대한민국 파워셀러 양성소 프로셀러 www.proseller.co.kr

한 사람은 능력이 뛰어나지만 태도가 나쁘다. 또 다른 한 사람은 태도는 좋지만 능력은 떨어진다. 이 중 한 명을 해고해야 한다면 누구를 선택하겠는가? CEO라면 누구나 이 같은 딜레마 상황에 빠져봤을 것이다.

만약 GE의 잭 웰치(Welch) 전 회장이라면 어떤 선택을 할까? GE는 사람을 평가할 때 두 가지 요소를 감안한다. 하나는 태도(attitude), 또 다른 하나는 능력(ability)이다. 모든 인사 평가는 이 두 가지 요소의 조합을 통해 이뤄진다. 태도와 능력이 모두 우수한 사람에겐 파격적인 연봉 인상과 승진이 주어진다. 일반적으로 이들의 비율은 전체 직원의 20% 정도다. 반면 태도와 능력이 모두 떨어지는 10%에겐 차가운 해고 통지서가 날아든다.

문제는 둘 중 하나가 모자라는 직원을 처리하는 방법이다. 웰치 전 회장의 원칙은 간단하다. 능력이 떨어지는 직원에겐 보직 이동을 통해서 한번 더 기회를 준다. 하지만 태도가 나쁜 직원은 해고의 수순을 밟는다. 지금 당장 성과를 낼지는 몰라도 장기적 관점에서 봤을 때 조직의 문화를 파괴할 위험이 있다는 게 그의 판단이다. 여기서 말하는 태도란 '얼마나 상사의 말을 잘 따르는가' 등과 같은 문제가 아니다. '얼마나 회사가 중요하게 생각하는 가치를 지키느냐','얼마나 열정을 갖고 일하느냐' 등과 같은 조직의 문화와 관련된 것이다. 다시 세계상사의 회의실로 돌아가 보자.

검은 고양이든, 흰 고양이든 쥐만 잘 잡으면 나머지는 관용할 수 있는 것일까? 나 사장은 한 가지를 깊게 생각해 봐야 한다. '혹시 색깔 다른 고양이 한 마리가 우리 조직의 문화와 가치를 흐리거나 망치고 있지는 않는가?' 만약 '예스'라고 생각된다면 이때는 과감한 결단(해고)이 필요하다. 그대로 뒀다간 이 고양이는

쥐만 잘 잡는 게 아니라 우리 조직도 '잡아먹을' 수 있기 때문이다.

 

[출처] 조선일보 土日섹션경제 2008년 6월 14-15일 C3페이지, 최철규 IGM(세계경영연구원)부원장의 글 인용

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

(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. 터미널 서버에 연결된 화면 >

앞에서 우리는 TCP Sliding Window 에 대해서 알아 보았다. 그러면, 이러한 TCP Window라고 하는 것의 Size의 크기 여부가 네트워크에서 가지는 영향에 대해서 정리를 해 보도록 한다.먼저 정리를 해 보면, NT는 "Window size"는 8K, "Segment Size"는 1K로 설정이 되어 있다. 물론 NT의 Registry를 편집함으로써 수정은 가능하지만 권장하지는 않는다. 이미 우리의 선배들이 시행착오를 거쳐서 최적의 size로서 설정이 되어 있기 때문에 우리는 그러한 문제를 고민하는 것보다는 효율적으로 운영하는데 초점을 두는 것이 바람직하겠다. window size가 너무 작을 경우와 너무 클 경우 어떠한 일이 생길 것인지 알아보자.

(1) Window size가 작은 경우 [그림1~3]

[그림1]

Window size가 1K라고 가정을 해 보면 어떻게 될까? 이제 앞에서 보았던 전송과 응답과정을 이해했다면 금방 알 수 있는 문제다.송신측의 컴퓨터는 1K의 데이터를 전송하고 그것에 대한 응답을 기다릴 것이다. Ack신호가 오면 그 다음 차례인 2번으로 window를 sliding시켜서 또 전송을 시작할 것이다.

하나를 보내고 하나를 받고, 좋아 보이지만 답답한 방법이 아닐 수 없다.

[그림2]      [그림3]

(2) Window size가 큰 경우

Window size가 크다 혹은 작다는 것은 상대적인 개념이다. 네트워크가 얼마나 안정적이며, 또 LAN에서의 통신인지 WAN에서의 통신인지에 따라서 달라질 것이다. 또, WAN구간이라고 할 지라도 56K의 모뎀을 이용하는지 아니면 T3의 빠른 회선을 이용하는 지에 따라서 달라질 수 있다.예제를 통해서 느린 네트워크에서 window size가 큰 경우의 문제를 알아보도록 하자.[그림4]에서는 8K의 window size를 사용하고 있다. 하지만, 문제는 네트워크가 느리다는 데 있다. 속도가 느려서 혹은 트래픽이 많아서 기대되는 응답시간보다 더 오랜시간이 걸려야만 Ack신호를 받을 수 있다고 한다면, 결국엔 송신측 컴퓨터는 미처 Ack신호를 받지 못하고 "Retransmission Timer"의 시간이 만료되어 같은 데이터를 재전송해야 하는 일이 많아지게 될 것이다. 당연히 비효율적인 네트워크가 운영이 될 것이다..

[그림4]

이런 경우라면 오히려 window size를 보다 작은 size로 줄이는 것이 현명한 방법일 것이다. 위의 2가지 예제의 경우에 TCP는 "Connection Oriented protocol"이라는 가장 큰 장점이 오히려 적절하지 못한 window size로 인해서 비효율적인 Protocol이 될 수도 있다. 적절한 window size를 사용하게 된다면 TCP의 장점을 극대화한 최적의 네트워크를 구성하게 될 것이다.

TCP/IP Protocol Suite중의 하나인 TCP는 TCP Host간에 효율적인 데이터 전송을 위하여 "Window"라고 부르는 Buffer를 이용한다. Window는 TCP/IP통신을 원하는 컴퓨터(일반적으로 Host라고 부른다)가 송신, 혹은 수신할 수 있는 size를 가리켜 준다.

이러한 window라는 것을 이용하여 호스트간에 전송을 하고 받는 과정중에, 네트워크의 트래픽 혹은 호스트의 불안한 요소등 여러 가지 원인에 의하여 전송되는 데이터의 손실이 생길 수 있는 경우가 발생하게 된다. 반대로 안정적인 네트워크 상황하에서 보다 많은 데이터를 전송할 수 있음에도 TCP가 제공하는 가장 큰 특징중의 하나인 "확실한 전송"이라는 책임 때문에 오히려 비효율적인 전송을 하게 되는 경우도 있게 될 것이다. 이러한 요소들을 모두 고려하여 가장 효율적인 데이터 전송방법으로써 "Sliding Windows" 라는 기법을 사용하여 호스트 간의 통신에서 최적의 성능을 제공할 수 있게 된다.

그러면, 실제로 호스트간의 TCP/IP통신 중에서 "TCP Sliding windows"라는 기법이 무엇인지, 어떻게 동작을 하는지 차근차근 접근해 보도록 하자.

[그림1]

TCP/IP를 사용하는 모든 호스트들은 각각 2개의 window를 가지고 있다. 하나는 보내기 위한 window, 또 다른 하나는 받기 위한 Window이다.

[그림2]

호스트들은 실제 데이터를 보내기 전에 먼저 "TCP 3-way handshaking"을 통하여 수신컴퓨터의 receive window size에 자신의 send window size를 맞추게 된다. 상대방이 받을 수 있는 크기에 맞추어 전송을 하겠다는 것이다.

[그림2]의 "A"컴퓨터가 "B"컴퓨터에게 10K byte size의 데이터를 전송하려 한다고 가정을 해 보자.또, 이 컴퓨터의 "window size"는 8K이고, "TCP Segment Size"는 1K라고 가정을 한다. 사실 이것은 우리가 가장 많이 사용하는 Ethernet환경에 최적화된 size이기 때문에 NT는 기본적으로 위와 같은 windows와 segment size를 이용한다."TCP Segment Size"는 Application이 만든 데이터를 TCP가 받아서 IP에게 전달해서 통신을 하려고 할 때, IP에게 전달해 주는 데이터 패킷의 크기이다. 결과적으로는 실제 데이터를 TCP가 보다 작은 크기로 나누게 되는데, 이 때 나누게 되는 크기를 가리켜서 "TCP Segment Size"라고 부른다.예제의 경우와 같을 때, "A"컴퓨터는 "B"컴퓨터에게 데이터를 전송하기 위해서 먼저 10K크기의 데이터를 1K크기로 나누게 된다. 당연히 10개의 패킷으로 데이터가 나뉘게 될 것이다. TCP는 1K로 나눈 데이터마다 순서를 붙이게 된다. 1번부터 10번까지 번호를 붙이고, 1번부터 데이터 전송을 시작하게 된다.

TCP의 특징은 "신뢰성있는 전송"을 보장한다는 데 있다. 1번을 보내고, "A"컴퓨터는 "B"컴퓨터로부터 잘 받았다는 확인 메시지(Acknowledgement)를 받을 때까지 기다리게 된다. 마침내 Acknowledgement 메시지가 오면 "A"컴퓨터는 그 다음 순서인 2번 데이터를 전송한다. 생각하기에는 당연한 이야기고 그런대로 쓸 만한 방법이라고 생각할 수도 있겠지만 지극히 비효율적인 방법이다. "A"컴퓨터는 1번 데이터를 보내고 나서도 충분히 다음 데이터를 보낼 여유가 있지만, 응답을 받을 때까지 기다리고만 있어야 한다는 것이다. 만일 회선상의 문제가 있어서 Ack신호가 더욱 지연된다면 그 결과는 당연히 영 아닌 상태의 네트워크 통신을 지켜 봐야만 할 것이다. 이러한 문제점을 해결하기 위해서 TCP는 데이터를 낱개단위로만 처리하지는 않는다는 것이며, 그때 한꺼번에 전송하는 데이터의 크기를 바로 "Window Size"라고 부르는 것이다.

[그림4]

[그림4]처럼 호스트는 자신이 보내야할 전체 데이터 중에서 사용가능한 Window size만큼 데이터를 전송하기 시작한다. 위의 예제에서 window size는 8K이다. 1번부터 8번까지 순차적으로 계속해서 데이터를 내 보내게 되는 것이다. 그리고 나서 이 호스트는 상대방의 응답을 기다리게 된다. 단순하게 생각해도 일단은 하나씩 보내고 응답을 기다리는 것보다는 효율적인 방법일 것이다. 성공적으로 통신이 되어서 상대방으로부터 응답이 온다면 그때 "A"호스트는 나머지 남은 9번, 10번의 데이터를 전송한다.이것이 "TCP Sliding Windows"라는 기법이다. window size만큼 데이터를 전송하고, 상대방으로부터 Ack신호가 올 때까지 기다렸다가 Ack신호가 오면, window를 이동(Slide)시켜 다음 순서의 TCP데이터를 전송하는 방식을 말한다.

하지만, 역시 이것만으로는 뭔가 비효율적인 면이 여전히 남아있다. 1번부터 8번까지 데이터를 전송하고 상대방으로부터 1번부터 시작하여 자신이 보낸 데이터의 마지막인 8번까지의 데이터에 대한 Ack신호가 올 때까지 기다려야 한다면 어리석은 일이 아닐 수 없다. 우리가 생각하는 정도는 이미 TCP/IP를 개발한 개발자들도 충분히 고려했던 부분이었기에 그것에 대한 생각도 물론 했을 것이다. 그렇기 때문에 보다 효율적인 방법을 채택했다.

[그림 5]

일단 보내는 쪽의 TCP는 window size만큼 한꺼번에 데이터를 전송하고, 받는 쪽에서의 Ack신호가 오면 오는대로 바로바로 window를 Sliding시키는 방법이 그것이다. 다시 말하면 굳이 자신이 발송한 마지막 데이터에 대한 Ack신호가 오지 않더라고 일단 그 전의 데이터에 대한 Ack가 오게 되면 그만큼은 여분의 window size가 생긴 것이기 때문에 추가로 더 전송할 여유가 생겼다는 의미이다.

[그림 5]에서 보면 window가 이동한 그림을 볼 수 있다.예제의 경우는 받는 쪽에서 2번까지의 데이터를 잘 받았다는 Ack신호를 발송해 주게 되면 그때 "A"컴퓨터는 1,2번 데이터는 제대로 전송해야 할 책임을 완수했기 때문에 window를 이동시켜서 그 다음 순서의 데이터인 9번과 10번을 전송할 수가 있게 되었다. 추가로, 받는 측인 "B"컴퓨터는 패킷 하나마다 계속해서 Ack신호를 전송한다는 것은 역시 그것도 하나의 트래픽을 발생시키는 것이기에 약속을 해 두었다. 적어도 2개 이상의 연속된 패킷이 들어왔을 때 Ack신호를 전송하도록 한 것이 그것이다.

[그림6]

[그림6]에서처럼 1번과 3번 패킷이 도착을 했지만, 중간에 이빨이 빠진 채로 2번이 아직 도착을 하지 않았다라고 가정을 해 보자. 그렇게 되면, 받는 측의 TCP는 2개이상의 연속된 패킷이 도착하면 전송을 하자는 약속을 해 두었기에 마냥 기다려야 할 것이다.

그래서 만일의 경우를 대비하여 한가지 해결책을 강구해 두었다. 받는 측의 컴퓨터는 패킷이 도착하였을 때, "Delay Acknowledgement Timer"라고 부르는 Timer를 설치하게 된다. 이 Timer의 시간이 만료될 때까지 2번 패킷이 도착하지 않는다면, 받은 1번 패킷에 대한 Ack신호만이라도 전송을 해 주는 것이 보다 효율적이기 때문이다.

[그림7]에서 보면, 받는 측의 TCP는 1번 패킷에 설치해 둔 Timer가 만료되었고, Ack신호를 전송하고 있다.

[그림 7]

송신컴퓨터는 이렇게 수신컴퓨터의 Ack신호를 받고, window를 sliding시켜서 다음 신호를 전송하는 방식을 쓰고 있지만, 또 한가지 문제가 여전히 남아 있다. 만일 무슨 이유에선지 Ack신호가 전혀 오지 않는 상황이라면 어떻게 해야 할까? 이러한 문제를 해결하기 위해서 송신컴퓨터의 TCP는 자신이 보낼 수 있는 Window Size만큼 데이터를 전송하고 자신이 보낸 데이터에 대해서 각 Segment마다 "Retransmission Timer"라고 불리우는 timer를 설치 해 둔다. 만일 이 timer의 시간이 만료될 때까지 Ack신호가 도착하지 않으면 재전송을 하기 위한 배려이다.

[그림 8]  

결국, TCP는 window size를 이용해서 한꺼번에 일정량의 데이터를 전송하며, 보다 효율을 기하기 위해서 이러한 window를 Sliding시키는 방식을 이용하여 계속적인 데이터 전송을 할 수 있도록 하고 있다. 여기에서 생길 수 있는 문제점들을 "Delay Acknowledgement Timer"와 "Retransmission Timer"를 이용해서 대비책을 마련해 두고 있는 것이다.

이상 TCP Sliding windows에 대해서 정리해 보았다. 다음엔 이어서 TCP Window Size가 네트워크에 미치는 Performance에 대해서 알아보도록 하자.  

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이다.