14-4.Active Directory 클라이언트 되기

14-2-8. 사용자들을 도메인으로 로그온하도록 구성

 

도메인이 생성되었으면 사용자들이 도메인으로 로그온을 할 수 있도록 모든 컴퓨터들의 설정을 바꿔줘야 한다. 사용자들의 시스템을 새롭게 설치하면서 도메인으로 참여하도록 구성할 수도 있다. 설치와는 별도로 사용자들의 시스템을 어떻게 도메인에 참여시켜서 도메인으로 로그온 할 수 있도록 구성할 것인지 접근해 보자.

 

사용자들이 어떠한 OS를 사용하는지에 따라 다르다. Windows XP는 그 설정에 있어서 Windows 2000 과 동일하다. 하지만 Windows 9x 계열의 OS는 조금 다르다. Windows 9x 계열의 OS는 기업네트워킹 환경에서는 사용할만하지 않다고 생각한다. Active Directory를 구축하는 많은 기업들이 Windows 9x의 경우 Active Directory에 포함하지 않고 있다. 도메인에 참여시켜서 얻을 수 있는 특별한 장점이 없다는 이유에서이다. 장점보다는 보안을 고려한다면 단점이 더 많다고도 볼 수 있다. 하지만 Windows 9x도 도메인에 참여시키는 방법을 잠깐 다루어보도록 하겠다.

 

먼저 총 4대의 서버중 2대를 도메인 컨트롤러로 구성하였고, 나머지 2대의 서버 역시 도메인으로 합류시켜야 한다. 이것은 클라이언트의 설정과 다를바가 없다.

 

14-2-8-1. 멤버서버 구성 (Windows 2000, 2003, NT, XP)

 

‘멤버서버’라는 용어는 도메인 컨트롤러는 아니지만 도메인에 멤버로 참여한 서버를 지칭한다. ‘독립실행형 서버’로 설치된 컴퓨터가 멤버서버가 됨으로써 도메인의 Active Directory에 접근이 가능하고, Active Directory의 사용자계정이나 그룹계정들에게 자신의 공유폴더, 공유프린터 등의 자원을 사용할 수 있도록 권한설정을 할 수 있는 환경이 갖춰진다. 그렇지 않으면 도메인을 구축한다는 것이 무의미해 질 것이다.

 

서버차원이 아니라 클라이언트 입장에서는 도메인에서 도메인 컨트롤러에 생성된 자신의 계정으로 네트워크에 로그온을 할 수 있어야 한다. 그래야만 도메인의 계정정보를 통해서 여러 서버에 접근이 가능해 지기 때문이다. 그러기 위해서는 먼저 클라이언트가 사용하는 컴퓨터는 도메인의 멤버가 되어야 한다.

IT관리자 입장에서는 사용자계정은 Active Directory에 생성을 했고, 그룹정책에서는 다양한 설정을 구성해 두었지만 관리대상인 컴퓨터가 도메인에 가입하지 않는다면 무용지물이다. 그런 이유로 Active Directory 인프라가 구축되는 과정은 ŒActive Directory서버구축 계정관리 Ž클라이언트의 도메인 참여를 포함한다.

 

도메인에 참여하고자 하는 모든 클라이언트 컴퓨터는 내부DNS서버(정확히 말하면 Active Directory의정보를 담고 있는 DNS서버, 일반적으로는 Active Directory서버)의 IP Address를 사용하도록 TCP/IP설정이 되어야 한다. DHCP를 사용하고 있다면 DHCP서버에서는 사용자들이 내부DNS서버를 사용할 수 있도록 옵션을 구성해 준다.

<그림14-70. 멤버 서버 설정 1>	예제의 화면은 Windows XP Professional에서 접근한 것이다. 바탕화면의 ‘내 컴퓨터’를 마우스 오른쪽 클릭하여 ‘등록정보’로 접근하였다. 제어판의 ‘시스템’을 열어도 같은 화면이다. 전체 컴퓨터이름이 raincoat 로 되어 있고 workgroup이라는 작업그룹에 속해 있다. 도메인으로 가입시키기 위해 [변경]을 누른다.
<그림14-71. 멤버 서버 설정 2>	소속그룹 항목에서 ‘도메인’을 선택하고 도메인 이름인 windowsnetwork.msft 을 입력한다. 이 컴퓨터를 도메인에 가입시킬 권한이 이는 사용자의 이름과 암호를 묻는다. 정보를 입력해 주면 잠시후 화면과 같이 ‘Windowsnetwork.msft 도메인 시작’이라는 메시지가 나온다. 이제 raincoat 는 도메인에 가입되었고 시스템을 재시작하면 도메인 로그온이 가능한 변경된 로그온 화면을 만나게 될 것이다. (만일 도메인이 없거나 연결할 수 없다는 에러메시지를 만난다면 DNS서버를 확인해야 한다. DNS서버에 도메인 컨트롤러의 SRV레코드와 A레코드가 등록되어 있지 않다면, 혹은 사용자의 컴퓨터가 엉뚱한 DNS서버를 사용하고 있다면 도메인으로의 변경작업을 진행될 수 없다.
<그림14-72. 멤버 서버 설정 3>	Active Directory를 확인하면 도메인에 참여하는 컴퓨터의 기본컨테이너에 해당하는 Computers에서 raincoat의 정보를 찾을 수 있다. 드래그앤드롭을 이용하여 윈도우네트웍스/임직원/컴퓨터OU로 개체를 이동시켰다.
<그림14-73. 멤버 서버 설정 4>	간혹 멤버로 구성작업이 완료되고 나서도 사용자 컴퓨터의 정보가 DNS서버에 동적업데이트가 되지 않는 경우가 있는데, 그 때는 DNS서버가 문제가 없다면 클라이언트 컴퓨터에서 <그림14-73>과 같이 ‘도메인 구성원 자격이 변경되면 주DNS접미사 변경’옵션이 선택되어 있는지를 확인한다.
기본적으로 독립실행형 서버는 FQDN을 사용하지 않는다. Raincoat 등과 같은 평면적인 이름을 사용하고 있는데, 도메인의 멤버로 참여하게 되면 자동적으로 도메인의 이름을 주DNS접미사로 사용하도록 구성된다. 그래서 전체이름이 raincoat.windowsnetwork.msft 의 형태가 되는 것이다. 그러면 이 정보는 DNS서버의 windowsnetwork.msft 영역에 업데이트가 되게 되는데, 만일 위의 체크상자가 해제되어 있다면 예전이름 형태로만 남아 있게 되고 DNS서버에서는 raincoat의 정보를 찾을 수 없다.
<그림14-74. 멤버 서버 설정 5>	DNS관리콘솔을 통해서 Bluepro 의 정보가 DNS에 업데이트 된 것을 확인해 보았다.
위의 작업이 완료되면 이 컴퓨터는 도메인의 사용자계정으로 로그온 할 수 있다. 하지만 사용자가 도메인의 사용자 계정으로 자신의 컴퓨터에서 로그온을 하고 나서는 자신의 컴퓨터에서 할 수 있는 작업이 그리 많지 않다는 것을 알고 의아해 할 것이다. 그것은 도메인의 사용자계정이 자신의 컴퓨터에서 가지는 지위가 ‘일반 사용자’에 해당하기 때문이다. <그림14-75. 클라이언트 도메인 참여후 로컬 그룹멤버쉽 수정>

 

클라이언트 PC의 컴퓨터 관리도구를 이용하여 로컬 Admininstrators 또는 Power Users 그룹에 도메인의 사용자 계정을 추가해 주어야 한다. 만일 Power Users그룹의 멤버로 추가하였다면 사용자는 자신의 컴퓨터에서 로컬 Administrators 그룹을 관리하는 작업, 가입한 도메인에 탈퇴 등을 제외한 대부분의 작업을 할 수 있게 된다. Administrators 그룹에 추가하였다면? 두말할 필요가 없다. 말 그대로 도메인의 사용자 계정은 클라이언트PC에서 로그온하여 관리자로 취급된다.

 

이상으로 도메인 참여작업을 진행해 보았다. 도메인으로 가입하는 과정에서 도메인 참여, AD에서 개체의 이동, 로컬 그룹멤버쉽 수정 등 몇가지 작업이 진행됨을 알 수 있다. 많은 수의 PC에 대해 동일한 작업을 수행해야 하는 관리자로서는 부담스러울 수 밖에 없다. 더불어 한가지 고려할 사항이 있다. 사용자가 도메인에 가입하기 전 사용하던 프로파일 (바탕화면, 즐겨찾기, 단축아이콘, 환경변수, 내문서의 위치, Outlook 설정 등)이 있었을 텐데, 도메인에 가입하고 도메인의 계정으로 로그온을 하면 새로운 사용자의 프로파일이 생성되는 만큼 사용자에게는 당연히 약간의(?) 거부감과 불편함이 따르게 됨이 일반적이다. 그런 이유로 Active Directory인프라를 구축하는 많은 기업들은 클라이언트 컴퓨터를 도메인에 참여시키기 위해 써드파티 ‘도메인 이행 전용도구’를 이용하여 작업을 진행하고 있다. 이들 도메인 이행 도구들은 도메인 참여, 관리자가 희망하는 OU에 컴퓨터 개체 생성, 로컬 그룹멤버쉽 자동설정, 사용자의 기존 프로파일을 도메인 계정으로 마이그레이션 등의 클라이언트PC를 도메인에 참여시키면서 필요한 서버측과 클라이언트측의 이행관련 업무 자동화를 지원하고 있다.

 

14-2-9. Windows 9x – 도메인으로 로그온하도록 구성

 

Windows 9x에서 도메인으로 로그온을 하도록 구성해 보자.

<그림14-76. Windows 9x 계열 컴퓨터 구성 1>	<그림14-76>은 Windows ME에서의 로그온 화면이다. 예제에서는 blue라는 계정으로서 로그온을 하고 있다. Windows 9x OS에서는 로그온이 필수적인 것은 아니다. [취소]버튼을 누르면 로그온 하지 않고도 시스템의 바탕화면으로 접근하는 것이 가능하다. 하지만 그렇게 했을 경우에는 클라이언트 서비스(workstation Service)가 시작되지 않기 때문에 네트워크 상에 자원에 접근하는 작업은 할 수 없게 된다. Windows NT 기반의 시스템을 사용하기 위해서는 반드시 로그온을 해야 하는 것에 비하면 커다란 차이점이다.
<그림14-77. Windows 9x 계열 컴퓨터 구성 2>	바탕화면의 네트워크 환경을 마우스 오른쪽 클릭하여 등록정보로 접근한다. 바탕화면에 네트워크 환경 아이콘이 나오지 않는다면 제어판의 네트워크 아이콘을 눌러서 접근할 수도 있다. 등록정보를 열면 <그림14-77>의 화면이 열린다. 설치된 네트워크 구성요소 창에서 'Microsoft 네트워크 클라이언트'를 확인한다. 만일 보이지 않는다면 [추가]버튼을 이용하여 설치를 해야 한다.   Microsoft 네트워크 클라이언트를 클릭하고 [등록정보]를 누른다.
<그림14-78. Windows 9x 계열 컴퓨터 구성 3>	클라이언트 등록정보 창이 열렸다. '로그온 확인'항목이 있고, 기본적으로는 'Windows NT 도메인으로 로그온'항목의 체크상자가 비워져 있다. 체크를 하고 아래쪽의 Windows NT 도메인 란에 도메인의 NetBIOS 이름을 입력한다.
<그림14-79. Windows 9x 계열 컴퓨터 구성 4>	시스템을 재시작하고 나면 <그림14-79>와 같은 로그온 화면을 볼 수가 있다. 사용자 이름과 암호 뿐만 아니라 '도메인'명을 입력할 수 있는 박스가 추가되었다. Windows 9x계열에서의 도메인 이름 입력상자는 Edit Box이다. 기본적으로는 위에서 입력한 도메인명이 나오지만 다른 이름으로 수정도 가능하다는 것을 의미한다.

이 책에서 Windows 9x의 설정에 대해서는 거의 다루지 않았다. 만일 회사에서 Windows 9x OS를 도메인 환경에서 사용해야 하는 경우라면 필자의 홈페이지 (http://www.secure.pe.kr ‘강의실’의 기타 섹션에서 ‘도메인환경에서 Windows 9x 클라이언트 관리’) 를 참고하라.

 

14-3. 도메인 환경에서의 서버

 

독립실행형 서버로 설치된 컴퓨터가 멤버서버로서 도메인에 참여하고 나면 어떤 것이 바뀌었을까? 가장 큰 차이점은 Active Directory로의 접근이 가능해 졌다는데 있다. 이들 서버들도 도메인 컨트롤러는 아니지만 분명히 자신의 디렉터리 데이터베이스를 가지고 있다. 이것을 특별히 ‘로컬 디렉터리 데이터베이스’라고 부른다. 도메인컨트롤러의 그것을 ‘글로벌 디렉터리 데이터베이스’라고 구분한다면 차이점을 이해할 수 있을 것이다.

 

도메인의 도메인 컨트롤러가 가지는 디렉터리 데이터베이스의 사용범위는 도메인내의 어떠한 서버라도 사용이 가능하지만, 도메인의 멤버서버가 가지는 디렉터리 데이터베이스의 사용범위는 오직 자신의 서버에서만 사용이 가능하다. 이렇듯 ‘로컬’이라는 용어는 항상 제한적으로 사용된다.

 

도메인에 참여한 서버는 네트워크에서 파일, 프린트 서버, 데이터베이스 서버, 메일서버 등 여러가지 용도로 사용된다. 중요한 것은 더 이상 이들 서버에서는 로컬 사용자 계정을 만들지 말아야 한다는 것이다. 도메인의 A라는 사용자에게 프린팅을 할 수 있는 권한을 주기 위해 ‘컴퓨터 관리’도구를 열고 자신의 로컬 디렉터리 데이터베이스에 A라는 사용자 계정을 생성할 것이 아니라 도메인의 Active Directory에 접근하여 A라는 사용자를 찾아서 자신의 자원을 쓸 수 있게 권한만 주면 된다. 물론 이것은 한가지 예제일 뿐이다. 실제로 서버의 자원에 권한설정을 할때는 사용자 단위보다는 그룹 단위로 권한설정을 하는 것이 좋다.

 

이렇듯 계정관리는 중앙에서 집중적으로 (도메인 컨트롤러에서만) 이루어져야만 제대로 된 도메인 모델을 유지하는 것이 가능하다.

 

14-4. 도메인 환경에서의 클라이언트

 

클라이언트들은 Windows 9x계열 (95,98,ME)인지 아니면 Windows NT계열(NT, 2000, XP)인지에 따라서 환경이 달라진다. 하지만 그러한 기본적인 물리적인 문제보다도 현실에서 가장 관건이 되는 부분은 클라이언트 컴퓨터의 관리주체가 시스템 관리자인지, 아니면 컴퓨터 사용자인지의 문제이다. 관리자 입장에서 시스템을 잘 관리할 수 있는 가장 좋은 방법은 사용자들에게 최소한의 권한만 부여하는 것이다. 사용자들이 자신의 컴퓨터에서 제어판에 접근하지 못하도록 제한하는 것만으로도 네트워크에, 그리고 사용자 컴퓨터에 있어서 상당부분의 문제점을 줄여줄 수 있다. 이를테면, 사용자 임의로 소프트웨어를 설치한다거나, 웹브라우저의 보안설정을 임의로 바꾸거나, IP Address 설정을 바꿔서 통신상의 문제점을 일으킨다거나 하는 문제는 원론적으로 통제할 수 있다.

 

하지만 현실적으로 사용자들의 요구는 너무나 다양하며 또한 그들은 이미 시스템에 대해서 상당한 지식을 가진 사용자도 많기 때문에 위와 같이 구성을 한다면 거부반응이 만만치 않을 것이다. 회사가 정책적으로 회사에서는 사용자들이 임의로 아무런 소프트웨어도 추가할 수 없으며 오직 업무를 위해서만 컴퓨터를 사용하도록 완전한 통제가 되지 않는 이상 관리자가 시스템을 제한하는 것은 한계가 있기 마련이다. 직원규모 100명 이내의 중, 소규모 회사라면 더더욱 그러할 거라는 생각이다. 사용자들은 옆자리의 동료에게 자신의 컴퓨터에 있는 파일을 함께 쓰기를 즐겨하며, 여전히 인터넷으로부터 새로운 프로그램을 다운받아서 설치하고자 시도할 것이다.

 

이러한 회사실정을 고려하여 먼저 생각해야 할 것은 회사의 물리적인 네트워크 환경을 바꾸는 작업이다. 공용네트워크와 개인네트워크를 분리하여 기본적으로 외부 인터넷에서 내부 네트워크에 접근이 어렵도록 막는 것이다. 그리고 사용자 시스템에 대한 관리자 계정은 회사의 시스템 관리자만이 가져야 한다. 다만 사용자에게는 도메인의 사용자 계정에 대해서 로컬 컴퓨터의 Power Users 그룹의 멤버가 되게 함으로써 대부분의 작업을 할 수 있게 하지만, 사용자가 자신의 시스템의 Administrators 그룹에 대해서는 접근하지 못하도록 제한을 할 필요가 있다. 추가로 그룹정책을 이용하여 사용자의 작업을 적정 수준에서 제한하는 것은 꼭 필요한 작업이다.