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

(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)를 인증하기 위한 "보안인증 프로토콜" 이다.

위의 백업을 예약한다거나 하는 작업은 백업프로그램이 독자적으로 지원하는 기능이 아니다. OS에서 지원하는 스케쥴 서비스와 연결되어야만 구현이 가능한 방법이다. 추가로 스케쥴 서비스에 대해서 알아볼 필요가 있다. 시스템에서 예약된 작업이 동작하기 위해서는 반드시 스케쥴 서비스가 동작하고 있어야 한다.

<그림11-119. 스케쥴 서비스 확인>

 

관리도구-서비스 스냅인을 열어보면 Task Scheduler 라는 이름이 보인다. 이것이 스케쥴 서비스이다. 백업을 위한 예약작업은 백업프로그램을 통해서 접근이 가능하지만 그밖의 예약작업은 ‘시작à프로그램à보조프로그램à시스템도구à예약된 작업’을 통해서 구현할 수 있다. 사용법은 아주 간단하다. 그것보다는 명령프롬프트에서 구현할 수 있는 방법을 살펴보도록 하겠다.

 

마이크로소프트는 시스템에서의 예약작업을 위하여 at.exe 라는 도구를 제공한다. 아래의 박스는 명령프롬프트에서 진행된 작업이다.

D:\>at (기본제공되는 명령어인 at을 입력했다.) 서비스가 시작되지 않았습니다. (스케쥴 서비스가 시작되지 않았음을 보여준다.)   D:\>net start schedule (net 유틸을 이용해서 스케쥴 서비스를 시작시켰다.) Task Scheduler 서비스를 시작합니다.. Task Scheduler 서비스가 잘 시작되었습니다.   D:\>at 목록에 항목이 없습니다. (이번엔 다른 메시지를 보여준다. 예약된 작업이 하나도 없음을 알려준다.)   D:\>at /? (at 에 대한 자세한 사용법을 알기 위해 도움말을 열었다.) AT 명령은 프로그램과 명령이 지정된 시간과 날짜에 실행되도록 일정을 만듭니다. AT 명령을 사용하려면 일정 서비스를 실행하고 있어야 합니다.   AT [\\\\컴퓨터이름] [ [id] [/DELETE] | /DELETE [/YES]] AT [\\\\컴퓨터이름] 시간 [/INTERACTIVE]     [ /EVERY:날짜[,...] | /NEXT:날짜[,...]] "명령"   \\\\컴퓨터이름       원격 시스템을 지정합니다. 이 매개 변수를 생략하면,                    로컬 컴퓨터에 대한 일정이 됩니다. id                 예약된 명령에 지정된 식별 번호입니다. /delete            예약된 명령을 취소합니다. id를 생략하면,                    해당 컴퓨터에 예약되어 있는 모든 명령이 취소됩니다. /yes               예약된 모든 작업을 취소할 때, 더 이상 확인하지 않을 경우                    yes로 지정합니다. 시간               명령을 실행할 시간입니다. /interactive       작업이 실행될 때 로그온한 사용자의 데스크톱과                    대화할 수 있도록 합니다. /every:날짜[,...]  매주 또는 매달 지정된 날짜에 명령을 실행합니다.                    날짜를 생략하면, 현재 날짜로 가정합니다. /next:날짜[,...]   돌아오는 지정 요일에(예들 들어, 다음 목요일),                    지정된 명령을 실행합니다.                    날짜를 생략하면, 현재 날짜로 가정합니다. "명령"           실행될 Windows NT 명령이나 일괄 프로그램입니다.     D:\>at 16:40 /i notepad.exe (금일 오후 4시 40분에 메모장을 실행하라는 명령이다. /i 스위치는 포그라운드에서 실행하라는 옵션이다. /i 를 주지 않으면 메모장은 기본적으로 백그라운드에서 실행될 것이다. 데스크탑의 화면에 보이지는 않지만 작업관리자의 프로세스탭에서 실행되는 것을 확인할 수 있다.) 새 작업을 추가했습니다. 작업 ID = 1   D:\>at (예약된 작업을 확인하고 있다.) 상태 ID   요일                     시간          명령 줄      1   오늘                    오후 4:40     notepad.exe   D:\>at 1 /d (예약된 작업 ID 1번을 삭제하라는 명령이다.)   D:\>at 목록에 항목이 없습니다.   D:\>

 

그룹정책을 통한 Office 2003 배포를 위해 패키지 만들기

 

요건에서 구현해야 할 Office 2003을 Active Directory 의 그룹정책을 통해 배포하려면 Office 2003 원본CD가 있어야 한다. 원본CD에는 pro11.msi 파일이 있어서 그룹정책에서 그대로 링크를 해도 되겠지만 그렇게 그대로 사용자에게 배포시에는 제품Key, 회사 정보 등 다양한 정보를 수동으로 요구하기 때문에 사용자의 간섭이 필요해 진다. 궁극적으로 자동으로 사용자에게 패키지를 배포하는 것이 목적인 만큼 Office 2003을 그룹정책으로 배포하기 위해서는 약간의 작업이 필요하다.

 

이러한 경우 msi패키지가 아닌 mst 확장자를 가진 사용자 정의 패키지를 만들 수 있다. Office 2003을 예로 들어서 패키지를 만들어 보도록 한다.

 

Œ 패키지 배포서버에서 Office 2003 원본CD를 넣고 명령프롬프트에서 “msiexec /a e:\pro11.msi”를 실행한다. (e:는 CD-Rom드라이브를 의미함) 조직정보를 입력하고, 패키지가 생성될 폴더를 지정했다. 그룹정책 구성시 이 배포서버의 공유폴더를 사용하게 될 것이다.

<그림14-32. Office 2003 패키지 생성>

 

 Office 2003 리소스킷을 설치한 후 실행한다. 리소스킷은 마이크로소프트 다운로드 사이트에서 구할 수 있다. (http://www.microsoft.com/downloads/details.aspx?FamilyID=4bb7cb10-a6e5-4334-8925-3bcf308cfbaf&DisplayLang=en)

<그림14-33. 그룹 정책 구현 10>	설치한 Office 2003 리소스킷 프로그램중 “Custom Installation Wizard”를 실행한다.
<그림14-34. 그룹 정책 구현 10>	원본CD에서 찾을 수 있었던 msi 파일의 위치를 묻고 있다. Œ에서 지정한 C:\Packages\office2003 폴더를 지정하고 pro11.msi 파일을 지정했다.
<그림14-35. 그룹 정책 구현 10>	mst 파일을 생성해야 한다. 이미 만들었다면 수정할 수도 있다.
<그림14-36. 그룹 정책 구현 10>	작업이 끝나면 생성될 mst 파일의 저장위치를 묻고 있다.
<그림14-37. 그룹 정책 구현 10>	클라이언트에 배포되었을 때 설치될 기본위치를 묻고 있다.
<그림14-38. 그룹 정책 구현 10>	이미 Office가 설치되어 있는 경우 어떻게 할 것인지를 입력한다. 기본값은 사용자에게 프롬프트를 띄우는 것이다.
<그림14-39. 그룹 정책 구현 10>	오피스 설치 옵션을 입력한다. 설치과정에서 많이 보던 화면이다.
<그림14-40. 그룹 정책 구현 10>	Production Key, License 동의 등을 미리 입력하는 화면이다.
<그림14-41. 그룹 정책 구현 10>	이 단계에서 더 이상 진행하지 말고 [Finish]를 누른다.
<그림14-42. 그룹 정책 구현 10>	Mst 파일이 생성되었음을 보여준다. 배포서버의 C:\Packages\Office2003 폴더를 확인하면 <그림14-36>에서 입력한 windowsnetwork.msft.office2003.mst 파일을 찾을 수 있을 것이다. 이렇게 office 2003 패키지 생성을 완료하였다.

어떤 회사라도 회사직원들의 인명부나 주소록 정도는 가지고 있을 것이다. 또한 회사에서 사용하는 인사프로그램들의 경우 요즈음 프로그램의 대부분은 출력포맷으로 마이크로소프트의 오피스제품인 엑셀(Excel) 프로그램과 호환되는 파일포맷을 지원해 주고 있다. 이렇듯 회사의 직원명부를 엑셀 형태의 데이터로 가지고 있는 경우라면 간단하게 사용자 계정을 생성하는 것이 가능하다.

 

Windows Server 2003의 Active Directory에서 기본제공되는 dsadd 유틸리티는 대량계정생성작업에 아주 유용한 도구이다. 명령프롬프트에서 “dsadd /?”를 입력하여 도움말을 열어보았다.

설명: 이 도구는 디렉터리에 특정 개체 유형을 추가할 수 있도록 합니다. dsadd 명령: dsadd computer - 디렉터리에 컴퓨터를 추가합니다. dsadd contact - 디렉터리에 연락처를 추가합니다. dsadd group - 디렉터리에 그룹을 추가합니다. dsadd ou - 디렉터리에 조직 구성 단위를 추가합니다. dsadd user - 디렉터리에 사용자를 추가합니다. dsadd quota - 디렉터리 파티션에 할당량 지정을 추가합니다.   특정 명령의 도움말을 보려면 "dsadd <개체 유형> /?"를 입력하십시오. <개체 유형>은 위에 표시되어 있는 지원된 개체 유형입니다. 예, dsadd ou /? 참고: 고유 이름에 구분 기호로 사용되지 않는 쉼표는 백슬래시("\")로 이스케이프되어야 합니다. (예, "CN=Company\, Inc.,CN=Users,DC=microsoft,DC=com") 고유 이름에 사용되는 백슬래시는 백슬래시로 이스케이프되어야 합니다. (예, "CN=Sales\\ Latin America,OU=Distribution Lists,DC=microsoft,DC=com") 디렉터리 서비스 명령줄 도구 도움말: dsadd /? - 개체 추가에 대한 도움말 dsget /? - 개체 표시에 대한 도움말 dsmod /? - 개체 수정에 대한 도움말 dsmove /? - 개체 이동에 대한 도움말 dsquery /? - 검색 조건에 해당되는 개체 찾기에 대한 도움말 dsrm /? - 개체 삭제에 대한 도움말

 

도움말에서 볼 수 있듯이 다양한 개체를 생성할 수 있는 것을 알 수 있다. 사용자 계정 만드는 것은 “dsadd user”라는 명령이라는 것을 알았다. 이번에는 dsadd user /? 를 입력해 보면 다음과 같은 결과를 얻을 수 있다.

설명:  디렉터리에 사용자를 추가합니다. 구문:  dsadd user <사용자 DN> [-samid <SAM 이름>] [-upn <UPN>] [-fn <이름>]         [-mi <이니셜>] [-ln <성>] [-display <표시 이름>]         [-empid <직원 ID>] [-pwd {<암호> | *}] [-desc <설명>]         [-memberof <그룹 ...>] [-office <사무실>] [-tel <전화 번호>]         [-email <전자 메일>] [-hometel <집 전화 번호>] [-pager <호출기 번호>]         [-mobile <휴대폰 번호>] [-fax <팩스 번호>] [-iptel <IP 전화 번호>]         [-webpg <웹 페이지>] [-title <직함>] [-dept <부서>]         [-company <회사>] [-mgr <관리자>] [-hmdir <홈 디렉터리>]         [-hmdrv <드라이브 문자:>] [-profile <프로필 경로>]         [-loscr <스크립트 경로>] [-mustchpwd {yes | no}] [-canchpwd {yes | no}]           [-reversiblepwd {yes | no}] [-pwdneverexpires {yes | no}]         [-acctexpires <일 수>] [-disabled {yes | no}]         [{-s <서버> | -d <도메인>}] [-u <사용자 이름>]         [-p {<암호> | *}] [-q] [{-uc | -uco | -uci}]   매개 변수:   값                      설명 <사용자 DN>             필수. 추가할 사용자의 고유 이름(DN)입니다.                         대상 개체가 생략되면 표준 입력(stdin)으로부터                         얻습니다. -samid <SAM 이름>       사용자의 SAM 계정 이름을 <SAM 이름>으로 설정합니다.                                 <SAM 이름>이 생략되면 <사용자 DN>에 대한                                 일반 이름(CN)의 첫 20문자를 사용하여 SAM 계정                                 이름을 만듭니다.   -upn <UPN>              upn 값을 <UPN>으로 설정합니다. -fn <이름>              사용자 이름을 <사용자 이름>으로 설정합니다. -mi <이니셜>            사용자 중간 이니셜을 <이니셜>로 설정합니다. -ln <성>                사용자 성을 <성>으로 설정합니다. -display <표시 이름>    사용자 표시 이름을 <표시 이름>으로 설정합니다. -empid <직원 ID>        사용자 직원 ID를 <직원 ID>로 설정합니다. -pwd {<암호> | *}       사용자 암호를 <암호>로 설정합니다. *를 지정하면                         암호를 묻습니다. -desc <설명>            사용자 설명을 <설명>으로 설정합니다. -memberof <그룹 ...>    사용자를 <그룹 ...> 구성원으로 등록합니다. -office <사무실>        사용자 사무실 위치를 <사무실>로 설정합니다. -tel <전화 번호>        사용자 전화 번호를 <전화 번호>로 설정합니다. -email <전자 메일>      사용자 전자 메일 주소를 <전자 메일>로 설정합니다. -hometel <집 전화 번호> 사용자 집 전화 번호를 <집 전화 번호>로 설정합니다. -pager <호출기 번호>    사용자 호출기 번호를 <호출기 번호>로 설정합니다. -mobile <휴대폰 번호>   사용자 휴대폰 번호를 <휴대폰 번호>로 설정합니다. -fax <팩스 번호>        사용자 팩스 번호를 <팩스 번호>로 설정합니다. -iptel <IP 전화 번호>   사용자 IP 전화 번호를 <IP 전화 번호>로 설정합니다. -webpg <웹 페이지>      사용자 웹 페이지 URL을 <웹 페이지>로 설정합니다. -title <직함>           사용자 직함을 <직함>으로 설정합니다. -dept <부서>            사용자 부서를 <부서>로 설정합니다. -company <회사>         사용자 회사 정보를 <회사>로 설정합니다. -mgr <관리자>           사용자 관리자를 <관리자>로 설정합니다(DN 형식). -hmdir <홈 디렉터리>    사용자 홈 디렉터리를 <홈 디렉터리>로 설정합니다.                         UNC 경로인 경우 이 경로에 매핑될 드라이브 문자를                         -hmdrv로도 지정해야 합니다. -hmdrv <드라이브 문자:> 사용자 홈 드라이브 문자를 <드라이브 문자:>로                         설정합니다. -profile <프로필 경로>  사용자 프로필 경로를 <프로필 경로>로 설정합니다. -loscr <스크립트 경로>  사용자 로그온 스크립트 경로를 <스크립트 경로>로                         설정합니다. -mustchpwd {yes | no}   사용자가 다음 로그온 시 암호를 변경해야 하는지                         지정합니다. 기본값: no -canchpwd {yes | no}    사용자가 암호를 변경할 수 있는지 지정합니다.                         -mustchpwd 값이 "yes"인 경우 "yes"여야 합니다.                         기본값: yes -reversiblepwd {yes | no}                         사용자 암호를 해독 가능한 암호화로 저장할 것인지                         지정합니다. 기본값: no -pwdneverexpires {yes | no}                         사용자 암호가 만료될 수 있는지 지정합니다. 기본값: no -acctexpires <일 수>    사용자 계정이 오늘부터 <일 수> 후에 만료되도록                         설정합니다. 0 값은 계정이 오늘 만료될 것을 의미합니다.                         양수는 계정이 미래에 만료될 것을 의미합니다.                         음수는 계정이 이미 만료된 것을 의미하며                         만료 날짜를 지난 날짜로 설정합니다.                         "never" 문자열은 계정이 만료되지 않는 것을                         의미합니다. -disabled {yes | no}    사용자 계정을 사용 불가능 또는 사용 가능하게                         설정합니다. 기본값: no {-s <서버> | -d <도메인>}                         -s <서버>는 <서버> 이름을 가진 도메인 컨트롤러(DC)에                         연결하도록 합니다.                         -d <도메인>은 <도메인> 도메인에 있는 DC에 연결하도록                         합니다. 기본값: 로그온 도메인에 있는 DC -u <사용자 이름>        <사용자 이름>으로 연결합니다. 기본값: 로그인된 사용자                         <사용자 이름>은 사용자 이름, 도메인\사용자 이름 또는                         UPN이 될 수 있습니다. -p {<암호> | *}         <사용자 이름> 사용자의 암호입니다. *를 입력하면                         암호를 묻습니다. -q                      자동 모드: 화면에 출력을 표시하지 않습니다. {-uc | -uco | -uci}     -uc 파이프로부터 입력 또는 파이프로의 출력이 유니코드로                         인코딩되도록 지정합니다.                         -uco 파이프 또는 파일로의 출력이 유니코드로                         인코딩되도록 지정합니다.                         -uci 파이프 또는 파일로부터의 입력이 유니코드로                         인코딩되도록 지정합니다.

 

대략 짐작이 갈 것이다. 기본적인 사용법은 다음과 같다.

dsadd user CN=송용하,OU=사용자,OU=임직원,OU=윈도우네트웍스,DC=windowsnetwork,DC=msft -samid yhsong -upn yhsong@windowsnetwork.msft -fn 송용하 -pwd 패스워드

 

이것을 제대로 사용하기 위해서는 dsadd user 뒤에 따라오는 매개별수들을 잘 이해해야 한다. 위의 도움말을 참고하여 이해하도록 하자.

 

위의 내용을 근거로 윈도우네트웍스사에서 사용할 파일을 생성하고 있다.<그림14-12>

<그림14-12. 엑셀프로그램을 이용한 사용자 계정 생성 파일 준비>

 

파일을 저장할 때 파일형식을 “텍스트(탭으로 분리)(*.txt)”를 선택하고, 파일이름은 상관없지만 bat 확장자를 가진 배치파일로 저장한다. 파일이름을 큰 따옴표로 묶어서 txt확장자가 붙지 않도록 주의한다. 그 다음 명령프롬프트에서 이 배치파일을 실행했다.

<그림14-13. dsadd를 이용한 사용자 계정 대량생성>

 

작업이 완료되었다. 결과는?

<그림14-14. dsadd를 이용해서 생성한 사용자 계정>

 

사용자OU에 19개의 사용자계정이 생성된 것을 확인할 수 있다.

이것은 맨처음 Active Directory를 구축하고서 초기작업에는 유용하지만 인사이동에 따른 지속적인 변경관리를 하기에는 역부족이다. 단순히 사용자 계정만 생성하면 될 것이 아니라 인사이동에 따라 사용자들의 그룹멤버쉽 추가 및 제거, OU의 이동, 입사/퇴사/휴직/복직 등의 인사발령에 따른 계정의 변동 등 사용자/그룹 계정관리를 지속적으로 유지하는 것은 Active Directory의 안정성과 신뢰성을 유지하는데 매우 중요한 작업이다. 이러한 작업을 위해서는 인사시스템과 연동하여 자동으로 AD계정을 관리해 주는 솔루션 [1]도입이 검토되어야 할 것이다. 이러한 이유로 많은 기업들이 Active Directory 인프라 구축의 범위에 인사연동 계정관리시스템 구축까지 포함하고 있다.

<그림13-90. 로그온 에러 메시지 1>

 

처음 Active Directory를 셋업한 후 테스트를 하다 보면 만나게 되는 황당한 메시지이다. 기껏 Active Directory를 셋업하고 Active Directory 관리도구를 이용하여 사용자 계정을 추가했는데 로그온이 안 된다. 이런~ 계정을 잘못 만들었나? 패스워드가 틀렸나?? 다시 관리자로 들어가서 사용자 암호를 바꾸고, 다른 사용자도 만들어 보고 고민을 해 봐도 역시 답이 나오지 않는다.

 

메시지를 읽어보니 ‘사용자는 대화형으로 로그온’할 수 없단다? 왜? 로컬정책이라는 녀석이 허용을 안 해준단다. 와~ 로컬정책이 뭐길래 로그온을 안 시켜줘?? 기분 나쁘다. 내가 셋업한 시스템인데 내가 만든 계정을 로그온을 안 시켜주다니... 아무튼 메시지를 잘 읽어보니 적어도 사용자 계정이 틀렸거나 패스워드가 틀린 것은 아닌 듯 하다.

 

패스워드가 틀렸을 때는 어떤 메시지가 뜨는지 비교해 보자.

<그림13-91. 로그온 에러 메시지 2>

 

언뜻 봐도 많이 다르다. 하지만 너무도 친절한 메시지이다. 처음 시작할 때는 사실 메시지를 보고 원인을 찾는 것은 너무나 힘들다. 다만 조금씩 관심을 가지는 연습을 하자. 무작정 이것저것 눌러보는 수고를 조금이라도 덜 수 있는 방법이 될 것이다.

 

에러 메시지를 토대로 차근 차근 접근해 보자. 먼저 '대화형 로그온'이라는 것이 무엇일까? 시스템을 켜게 되면 우리는 로그온 하기 위해서는 [Ctrl+Alt+Delete]를 입력할 것을 요구받는다. 시키는 대로 키조합을 입력하면 아래와 같은 화면이 제공된다.

<그림13-92. 로그온 대화 상자>

 

이 화면을 가리켜서 ‘로그온 대화 상자 (Logon Dialog Box)’ 라고 부른다. 그리고 이렇게 로그온 하는 방법을 가리켜서 에러 메시지에서는 '대화형 로그온'이라고 표현하였다. 결국 이러한 형태의 로그온을 하지 못하도록 시스템의 로컬정책에서 설정이 되어 있다는 얘기다. 그럼 이렇게 로그온 하는 것이 아닌 다른 방법도 있나? 네트워크 로그온을 예를 들 수 있다. 대화 상자를 통해서 접근하는 것이 아니라 네트워크에 파일서버에 연결한다거나, 익스체인지 서버에 메일확인을 위해서 연결을 하는 등의 과정에서 네트워크 로그온이 이루어진다.

 

네트워크로 로그온을 했을 때 사용자는 네트워크상의 서버에 접근하는 방법은 서버에서 공유되어 있는 자원에 접근을 하게 된다. 접근할 때는 "공유자원"에 부여되어 있는 접근권한의 영향을 받게 되고, 할 수 있는 일이 상당히 제한적이다. 하지만, 해당 시스템에서 직접 로컬로 로그온을 했을 때는 그러한 권한 설정은 무시되고 심지어는 공유되어 있지 않은 리소스까지도 직접 액세스가 가능하기 때문에 보안에 치명적인 문제가 발생 할 수 있다. 도메인 컨트롤러의 경우에는 더 심각하다. 도메인 환경의 전체 자원에 대한 정보가 Active Directory에 담겨있기 때문에 누군가 로컬로 도메인 컨트롤러에 접근한다면 회사의 중요한 정보를 누출시킬 위험에 노출되기 마련인 것이다.

 

이러한 이유로 상대적으로 더 중요한 역할을 담당하는 도메인 컨트롤러에서는 로컬로 로그온 할 수 있는 권한에서 일반사용자들을 제거하고, 관리자 그룹에 속한 사용자들만 로그온 할 수 있도록 기본 로컬정책을 가지고 있다.

 

에러메시지는 그러한 상황을 보여주고 있는 것이다.

 

그렇다면 기본설정을 그대로 두는 것이 좋겠다. 하지만, 테스트 환경이라면 로컬정책을 바꿔서 접근할 수 있게 할 수 있다. 또, 도메인 컨트롤러에서 FTP서비스를 구현했을 때, 익명사용자의 연결을 허용하지 않고 계정이 있는 사용자만 접근하도록 권한 설정을 하고 싶다면 로컬정책을 수정해 주어야 한다. 권장되지는 않는 방법이다. 실제 회사 환경에서 이러한 작업을 해서는 안 될 일이다. 또, FTP서비스는 기본적으로 계정 로그인시 암호화 인증 방법을 사용하지 않기 때문에 누군가 사용자 로그인 트래픽을 캡춰해서 분석한다면 사용자의 계정과 암호는 암호화되지 않은 평문으로 전송되기 때문에 더더욱 위험하다.

<그림13-93. FTP 사이트 등록정보 >

 

시스템의 정책을 수정하여 "대화형 로그온"이 가능하도록 설정을 해 보자. 먼저 시스템의 관리자로 로그온을 한 다음, 관리도구à도메인 컨트롤러 보안정책을 클릭하여 '보안설정à로컬정책à사용자권한 할당'을 찾아가면 관리콘솔의 오른쪽 패널에서 "로컬 로그온 허용"을 찾을 수 있다. 마우스 오른쪽을 눌러 '속성'을 클릭한다.

<그림13-94. 도메인 컨트롤러 보안 정책 관리콘솔>

 

'로컬로그온 허용 등록정보'창에서 로컬로 로그온(대화형 로그온)을 허용할 사용자 또는 그룹을 추가하고 [확인]을 누른다. Active Directory에 계정이 있는 모든 사용자들에게 '로컬 로그온'을 허용하려면 'Users"그룹을 추가하면 된다.

<그림13-95. 로컬 로그온 권한 설정>

 

관리콘솔을 닫는다. 이러한 시스템 정책이 즉시 반영되지는 않는다. 시스템을 재시작하거나 5분 정도의 시간을 기다리면 된다. 명령프롬프트에서 "gpupdate" 유틸리티[1]를 이용하여 바뀐 보안정책을 즉시 반영시킬 수도 있다. 다음과 같이 입력한다.

 

Gpupdate /force

 

화면과 같은 메시지가 나온다면 반영된 것이다. 확인을 하고 싶다면 관리도구-로컬 보안 정책을 확인해 보라.

<그림13-96. gpupdate를 이용한 그룹정책 수동으로 갱신하기>

 

이제 다시 로그온을 해 보면 에러메시지 없이 로그온을 할 수 있을 것이다.

국내외 수많은 기업들이 여러가지 이유로 Active Directory를 기업의 인프라로 도입하고 있다. 오히려 왜 이제서야 바람이 불기 시작한 것일까? 라는 생각도 들지만 Active Directory 관련분야의 기술을 교육하고, 컨설팅을 하고 있는 필자로서는 참으로 반가운 일이 아닐 수 없다.

아이러니하게도 AD를 도입하는 회사들을 보면 분야별로 포인트 솔루션들을 가지고 있지 않은 회사가 드물다. 그러한 포인트 솔루션들의 한계를 보완할 수 있는 방안은 더 이상 추가솔루션 도입이 아닌 ‘인프라’라는 것은 고객과 컨설턴트들이 한결같이 입을 모으는 깨달음이다.

시기적으로는 참 적절한 시점이라고 보인다. 여러분들보다 한발짝 먼저 Active Directory를 검토하고 도입한 선배들로 인해 다양한 구축사례들이 나와 있고, 국내의 AD분야 기술컨설팅 회사들도 많은 사이트에 대한 다양한 경험과 도구들을 보유하고 있다.

여러분들의 기업네트워크의 안전하고 효율적인 관리를 위해 불씨를 지필 수 있는 사람은 어느 누구도 아닌 바로 여러분들 자신이다. 아무리 뛰어난 컨설턴트라고 하더라도 고객의 협력없이는 고민에 대해100% 정답을 내려주지는 못한다. 가장 큰 노력은 관리자의 의지에 달려 있다고 생각한다.

Active Directory ! 참 멋진 녀석이다. Active Directory에 대해 깊게 고민해 본다면 분명히 무엇인가 변화가 있을 것이라 생각한다.

여러분들이 관리하는 Active Directory가 이름그대로 Active Directory가 될지 Passive Directory가 될 것인지는 여러분들의 판단에 달려있다.

마이크로소프트의 Windows 뿐만이 아니라 다른 벤더의 OS도 마찬가지고, 회사 내부의 인트라넷 어플리케이션, 우리가 사용하는 E-mail서버 등, 수많은 어플리케이션이 디렉터리를 요구한다. 이러한 디렉터리를 보다 효율적으로 사용하기 위한 노력이 존재하고 마이크로소프트 역시 효율적인 디렉터리 관리를 위해서 상당한 노력을 기울이고 있다. 디렉터리가 어떻게 관리되는지에 따라서 네트워크 관리모델을 결정할 수가 있게 된다. 마이크로소프트는 관리모델로써 Workgroup과 Domain이라고 하는 두가지 모델을 제공한다.

 

두 모델의 가장 큰 차이점이라면 디렉터리 데이터베이스의 위치라고 할 수 있다. 먼저 첫번째 그림을 보자. 네트워크에 Windows 2000 server, professional, NT4.0 Server, Workstation 의 서로 다른 4개의 컴퓨터가 있고, 각각의 시스템이 고유한 디렉터리 데이터 베이스를 유지하고 있는 모델이다. 

< 그림13-3. Workgroup 모델 >

 

이러한 형태로 네트워크를 운영할 때 어떤 일이 발생할 것인지를 생각해 보자.

 

‘홍길동’이라는 사용자가 특정 서버의 공유자원에 접속을 원한다면 해당 서버의 디렉터리 데이터베이스에 사용자 계정이 존재해야 한다. 만일 홍길동이 4대의 서버에 각각 접속을 원한다면 홍길동은 4대의 서버마다 자신의 사용자 계정을 가지고 있어야 하고 또한 그 계정과 각각의 암호를 기억하고 있어야 전체 서버의 자원을 이용할 수 있게 될 것이다.

 

서버 입장에서는 어떤가? 만일 홍길동이 자신의 공유자원에 접속하기를 원한다면 서버의 관리자는 홍길동을 위해 공유자원에 대한 접근허가를 주기 위해서 자신의 디렉터리 데이터베이스 안에 홍길동이 사용할 계정을 생성해 주어야 한다. 서버가 추가된다면 역시 홍길동의 계정은 추가된 서버의 디렉터리 데이터베이스에 새롭게 생성이 되어야만 한다.

 

결과적으로는 하나의 사용자가 서버들의 자원에 접근하도록 하기 위해서 각 서버에는 사용자 계정이 생성되어야 하는 번거로움을 감수해야 할 것이다. 이들 4대의 서버를 관리하는 관리자도 마찬가지이다. 관리자 역시 각각의 서버를 관리하기 위해서는 각 서버에서 관리권한을 가진 사용자 계정과 암호를 알고 있어야만 관리가 가능해 지는 것이다. Workgroup을 사용하는데 있어서 불편한 점을 정리해 보면 다음과 같다.

 

  ① 한 사용자가 자원을 가진 서버마다 별도의 사용자 계정을 가지고 있어야 한다.

  ② 하나의 사용자를 위해서 서버마다 계정을 만들어야 하는 번거로움

  ③ 중앙집중적인 관리의 어려움

 

서버의 수도 많아지고 사용자의 숫자도 증가하여 네트워크에서 관리해야 할 자원들이 늘어간다면 워크그룹 모델은 분명히 한계가 있다. 제대로 관리를 한다는 것은 너무나 많은 노력을 필요로 하는 일이다.

 

이것을 해결할 방법은 없는가? 마이크로소프트는 도메인이라는 모델을 제시하고 있다. 생각을 조금만 바꾸면 된다. 회사에 있는 모든 서버들이 자신의 디렉터리 데이터베이스에 사용자 계정을 각각 관리할 것이 아니라, 하나의 마스터 디렉터리 데이터베이스를 두고 모든 서버들은 그 디렉터리 데이터베이스에 접근하여 사용자 계정을 공유한다면 될 것이 아닌가?

 

이것을 가능하도록 하기 위하여 마이크로소프트는 네트워크 환경에서 특별한 서버를 지정하여 마스터 디렉터리 데이터베이스를 관리하도록 하였고, 이 서버를 도메인 컨트롤러 (Domain Controller, DC)라고 부른다. 그리고 이 도메인 컨트롤러의 마스터 디렉터리를 사용할 수 있는 서버나 클라이언트들을 묶어서 '도메인(Domain)'이라는 논리적인 관리단위를 만들었다. 정리하자면 워크그룹이 가졌던 단점을 해결하고자 한다면 도메인이라는 그룹을 만들고 모든 서버들을 이 도메인의 멤버로 만들고, 클라이언트 역시 도메인으로 로그온하도록 구성을 하면 되는 것이다. 그렇게 하면 도메인의 모든 멤버들은 디렉터리 서비스에 적용을 받고 각각의 계정이 아니라 도메인의 마스터 디렉터리 계정으로서 자원관리를 할 수가 있게 된다.

 

아래의 그림에서는 디렉터리 데이터베이스가 DC에 집중되어 있는 것을 볼 수 있다.

<그림13-4. 도메인 모델>

 

도메인 환경에서는 앞에서 홍길동의 계정이 서버마다 생성될 필요가 없다. 도메인 컨트롤러의 마스터 디렉터리 데이터베이스에서 한번만 생성이 되면 그뿐이다. 다른 모든 멤버서버들은 도메인 컨트롤러에 접근하여 마스터 디렉터리 데이터베이스에 저장된 홍길동에게 직접 자원에 대한 접근허가를 줄 수 있다.

 

사용자 입장에서도 자원에 접근하기가 수월해졌다. 자원을 가진 모든 서버마다 별도의 사용자계정과 암호를 기억할 필요가 없이 도메인 컨트롤러의 마스터 디렉터리 데이터베이스에 저장된 사용자 계정과 암호만 기억한다면 그 정보를 이용해서 모든 서버에 접근을 할 수 있다.

 

도메인 환경에서 새로운 서버가 추가되고 그 서버의 자원에 모든 사용자들이 접근할 수 있게 하려면? 간단해 진다. 새로운 서버를 도메인의 멤버서버로 설정하기만 하면 된다. 그러면 그 서버는 기존에 이미 존재하는 도메인의 디렉터리 데이터베이스에 접근하여 사용자 정보를 사용하는 것이 가능해 지기 때문이다.

 

관리적인 측면으로 본다면 워크그룹모델은 컴퓨터와 컴퓨터 즉, 자원과 자원간에 아무런 연관성이 없는 개별적인 관리모델이고, 도메인 모델은 도메인에 참여하여 도메인을 구성하고 있는 서버 및 PC들이 도메인이라는 범위내에서 관리정책, 보안정책 등을 서로간에 공유할 수 있는 모델을 말한다.

도메인 모델의 장점을 굳이 언급할 필요는 없다. 워크그룹 모델을 사용하는데 불편했던 점들을 고려한다면 그것들 중의 대부분은 도메인 모델을 채택함으로써 해결될 수 있는 단점이 될 것이다.

 

사설 네트워크 ? 공용 네트워크 ? (Private Network vs. Public Network)

주변에서 많이들 듣는 용어일 것이다. 뚜렷하게 이들 용어를 구분짓기는 어려운 일일지도 모른다. 하지만 각각의 어떠한 상황에서, 어떠한 구조에서 쓰이는 용어인지는 알아두어야 한다. 당신이 운영하는 네트워크가 어떠한 모습인지도 모르고 있다면, 그리고 현재 구현하고자 하는 것이 어떠한 네트워크 환경인지를 모른다면 안될 말이다.

 

이들 용어는 다분히 주관적이기도 하고, 조금은 혼돈되어 사용되기도 한다. 필자가 생각하는 이들 네트워크의 분류에 대해서 설명하고자 한다. 사설네트워크와 공용네트워크를 2가지 분류로 구분해 볼 수 있다.

 

<그림8-1. 개인네트워크와 공용네트워크의 첫번째 분류>

 

먼저 첫번째 분류는 회사와 회사간의 연결하는 방법을 놓고 사설 네트워크와 공용네트워크로 나눠볼 수 있다. 서울에 본사가 있고, 여수와 부산에 지사를 둔 회사가 있다고 가정하자. 서울에서는 ISP를 통해서 인터넷에 접근하도록 구성되어 있다. 서울과 여수, 서울과 부산을 각각 연결하는 방법으로는 2가지를 이용할 수 있는데, 첫번째 방법은 전용회선을 사용하는 것이다. 서울과 여수간에 전용회선을 사용하도록 네트워크가 구성되었다면 이 전용회선은 다른 회사와는 무관해진다. 두 지점간에만 전용으로(Dedicated, Leased) 할당된 회선을 사용하기 때문에 보다 안전하고, 보다 빠르다는 장점이 있다. 하지만 단점이라면 상대적으로 비싼 고정비용을 부담해야 한다는 것이다. 이러한 네트워크를 가리켜서 사설네트워크, 혹은 전용 네트워크라고 부른다.

 

본사와 지사를 연결할 수 있는 두번째 방법은 인터넷을 사용하는 것이다. 부산에 있는 지사의 환경이 부산에 있는 로컬 ISP를 통해서 인터넷으로의 연결이 가능한 상태라면, 인터넷을 통해서 서울의 본사로 연결이 가능하다. 이러한 네트워크는 ‘공용 네트워크’라고 부른다.

 

두번째 분류는, 비슷하지만 다른 측면으로의 접근이다.  단순히 생각하면 “TCP/IP기반의 모든 컴퓨터들은 IP Address라는 것으로써 구분을 하게 되는데 이때 네트워크ID를 사설 네트워크를 위해 예약된 네트워크 ID[1]를 사용하면 사설네트워크이고, 그 밖의 네트워크ID를 사용하면 공용(공인) 네트워크이다.”라고 정리할 수도 있다.

 

이것은 대부분의 경우는 올바른 답이라고 할 수도 있다. 그렇지만 어떤 컴퓨터가 공용IP주소를 사용하고 있다고 해서 그것이 반드시 공용네트워크에 있는 컴퓨터라고 볼 수는 없다. 보다 명확히 정리할 필요가 있다. 그것은 사용자 입장에서 봤을 때 자신의 컴퓨터와 인터넷 사이에 있는 중간 매개체 (라우터 등) 의 역할에 따라서 달라질 수 있다. 즉, ‘사용자가 인터넷에 접근하기 위해서 거치는 중간 인터페이스에 해당하는 장비에서 어떤 작업을 해 주는가?’ 이것이 바로 사설(개인) 네트워크와 공용네트워크를 구분지을 수 있는 기준점이라고 보는 것이다.

 

사용자들은 인터넷에 접근하기 위하여 로컬 라우터를 통과해야 한다. 라우터가 하는 일중 ‘라우팅’은 사용자로부터 받은 패킷을 목적지 컴퓨터가 있는 곳으로 갈 수 있는 네트워크로 포워딩하는 일이다. IP패킷의 흐름에 대해서는 이 책의 1장.TCP/IP <그림1-16>과 관련된 설명을 참고하라. 거기서 MAC Address는 계속 변하지만 원본 컴퓨터가 목적지 컴퓨터를 찾아가지 위해 생성한 IP Packet의 목적지, 원본 IP Address 부분은 라우터를 거치는 동안에 변화가 없었음을 알아야 한다.

<그림8-2. 공용 네트워크>

 

<그림8-2>를 보면서 설명한다. 예를 들어서 211.234.93.250 IP의 클라이언트가 211.232.71.131을 사용하는 외부의 웹서버와 통신을 하고자 한다. 클라이언트 컴퓨터는 211.232.71.131를 목적지로 하는 IP패킷을 생성하고 전송할 것이다. 이때 기본게이트웨이로 설정된 211.234.93.1을 경유하게 되고 결국 211.232.71.131 웹서버까지 패킷은 도달하게 된다. 웹서버는 클라이언트의 요청에 응답을 해야 할 것인데, 그때 웹서버는 거꾸로 211.234.93.250을 목적지로 하는 IP패킷을 생성하여 인터넷을 통해 전달을 하게 된다. 이러한 통신은 잘 이루어진다. 이 경우 211.234.93.250 IP의 클라이언트는 ‘공용 네트워크’에 있다고 할 수 있다.

 

다른 경우를 들여다 보자. 이번에는 클라이언트의 IP Address를 192.168.0.2로 할당해 보았다.<그림8-3>

<그림8-3. 개인(사설) 네트워크>

 

예제의 그림에서는 192.168.0.2 IP의 클라이언트가 211.232.71.131을 사용하는 외부의 웹서버와 통신을 하고자 한다. 클라이언트 컴퓨터는 211.232.71.131를 목적지로 하는 IP패킷을 생성하고 전송할 것이다. 이때 기본게이트웨이로 설정된 192.168.0.1을 경유하게 되고 결국 218.55.9.37 웹서버까지 패킷은 도달하게 된다. 웹서버는 클라이언트의 요청에 응답을 해야 할 것인데, 그때 웹서버는 거꾸로 192.168.0.2를 목적지로 하는 IP패킷을 생성하여 인터넷을 통해 전달을 하려는 시도를 할 것이다. 이 때 웹서버로부터의 응답이 클라이언트에게까지 전달될 수 있을까?

 

이것은 통신실패라는 결과를 가져온다. 192.168.0.1이라는 호스트가 어디에 있는지를 인터넷에서는 알지 못한다. 다시 말하면 인터넷상의 라우터의 라우팅 테이블에서는 192.168.0.0, 이러한 개인네트워크를 위해 예약된 IP Address들은 라우팅 경로에서 찾아볼 수 없다. 결국 개인네트워크에 해당하는 IP Address를 가지고서는 인터넷의 공용네트워크에 있는 컴퓨터들과의 통신이 이루어지지 않는다는 것을 의미한다.

 

그렇다면 어떻게 해야 할까? 이 경우 클라이언트가 속한 네트워크에서 외부 인터넷으로의 접근을 위해서는 중간에 NAT(Network Address Translation, 네트워크 주소 변환)작업이 필요하다. 클라이언트는 처음에 송신자(192.168.0.1), 수신자(211.232.71.131)를 담은 IP패킷을 생성하지만 인터넷으로 나가기 전에 다시 NAT의 외부 인터페이스, 즉 211.234.94.1의 IP주소로 주소변환이 된다. 송신자(211.234.94.1), 수신자(211.232.71.131)의 형태로 IP주소가 변환되어 웹서버에게 패킷이 전송되는 것이다. 요청을 받은 웹서버는 실제 송신자인 192.168.0.2로 패킷을 보내는 것이 아니라, 211.234.94.1을 목적지로 하는 IP패킷을 생성하여 응답하기 때문에 인터넷에서 통신이 잘 이루어 진다.

 

이 경우 192.168.0.2 클라이언트의 존재는 인터넷상에서 감춰지게 된다. 클라이언트가 속한 네트워크에 30대의 컴퓨터가 있다고 가정하고 이들이 동시에 인터넷을 사용하고 있다고 하더라도 인터넷에서는 오직 하나, 211.234.94.1의 IP패킷만이 발견될 뿐이다. 이러한 형태로 클라이언트가 인터넷에 접근할 수 있다면 그 클라이언트는 ‘개인(사설) 네트워크’에 있고 회사의 네트워크는 개인(사설) 네트워크로 구성되었다고 말한다.