달력

4

« 2024/4 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
2008. 11. 23. 03:07

14장 맺음말 Windows Networking2008. 11. 23. 03:07

Active Directory에 대해 컨설팅과 강의를 하면서 Active Directory를 도입하려는 기업들과 수강생들의 고민과 관리상의 현실적인 어려움들을 반영하려고 노력했지만 턱없이 부족하다. 이번 장을 통해서 기능적인 측면보다는 Active Directory 구축과 관련하여 전체적인 흐름을 이해하고 감을 잡았으면 하는 바램이다. 이글을 읽은 독자가 도메인 환경 구축을 하기 위해 어떻게 접근해야 할 것인지 전혀 감이 오지 않는다면 필자의 부족함 때문일 것이다. 하지만 한번 해 봐야겠다는 생각을 가지는 독자가 있었으면 좋겠다. 회사에서 Active Directory를 도입하면서 어려운점, 잘 안풀리는 부분, 도입을 완료한 후 관리상 문제점들, 이러한 사항들은 필자와 함께 고민해 보았으면 한다. 다른 페이지도 마찬가지겠지만 도메인 구축에 관련된 이번 장은 계속 업데이트 될 것이다. 거기에 여러분들의 회사환경을 추가하여 조금씩 완성도가 높아지는 모습이었으면 하는 것이 필자의 욕심이다.


:
Posted by 새벽예찬

그룹정책을 통한 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 패키지 생성을 완료하였다.


:
Posted by 새벽예찬
2008. 11. 23. 02:58

14-4.Active Directory 클라이언트 되기 Windows Networking2008. 11. 23. 02:58

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 그룹에 대해서는 접근하지 못하도록 제한을 할 필요가 있다. 추가로 그룹정책을 이용하여 사용자의 작업을 적정 수준에서 제한하는 것은 꼭 필요한 작업이다.


:
Posted by 새벽예찬
2008. 11. 23. 02:51

14-3.그룹 정책 구현 (Group Policy) Windows Networking2008. 11. 23. 02:51

NT시절의 시스템정책에서 한층 향상된 기능을 제공하는 Active Directory의 그룹정책은 참으로 대단한 능력을 보여준다. 도메인환경에서 다수의 컴퓨터, 다수의 사용자들에 대한 대부분의 관리 및 지원기능을 그룹정책 하나를 가지고 자동화시키고 있는 것이다. 이러한 그룹 정책을 잘 사용하는 것은 관리자의 업무부담을 상당부분 줄여줄 수 있다.

 

그룹정책을 적용할 수 있는 Active Directory 구조단위는 사이트, 도메인, OU이다. OU(조직단위)는 그룹정책을 적용할 수 있는 최소단위이다. 만일 당신이 특별한 부서에 대해서 제어판에 접근을 제한한다거나 바탕화면에 특정 그림을 넣어준다거나 하는 등의 작업을 하고자 한다면 이들 특별한 부서의 구성원들을 하나의 OU에 저장하고 이 OU에 대해서 그룹정책을 정의해 주는 것으로 해결할 수 있다.

 

그룹정책이 어떻게 구성되는지 기본적인 용어를 먼저 정리해 보자.


<그림14-19. 도메인 수준의 그룹정책 열기 1>

 

도메인 수준의 그룹정책을 열어보기 위해 Active Directory 사용자 및 컴퓨터 관리콘솔을 열고 도메인 이름을 마우스 오른쪽 클릭하여 속성을 클릭했다.


<그림14-20. 도메인 수준의 그룹정책 열기 2>

 

그룹정책 탭을 열었다.  기본적으로 Default Domain Policy 라는 이름의 그룹정책이 보인다. 아래의 2가지는 필자가 추가한 그룹정책이다. 이 그룹정책을 설정하는 인터페이스를 유심히 들여다 보자. 상속성 및 충돌을 명확히 이해하는데 꼭 필요하다. 아래의 <그림14-21>에 구체적인 사항을 그림으로 정리해 보았다.

 


<그림14-21. 그룹정책의 구성 이해>

 

그룹정책을 구성하는 요소는 그룹정책개체(GPO), 그룹정책 컨테이너(GPC), 그룹정책 템플릿(GPT)로 나뉜다. 먼저 그룹정책개체(GPO)는 사용자, 컴퓨터 계정등과 같이 Active Directory에 하나의 개체로 저장된다. <그림14-21>의 예제에서는 Default Domain Policy, 사용자들 대상 그룹정책, 컴퓨터 대상 그룹정책 이라는 이름의 세개의 그룹정책 개체가 Active Directory에 저장되어 있는 것을 보여준다. 그룹정책 컨테이너는 그룹정책 관리 인터페이스에 해당하며, 이것은 도메인, OU, 사이트 등에 그룹정책 개체를 연결하는 인터페이스 역할을 한다. 이렇듯 그룹정책 개체와 컨테이너는 별개로 봐야한다. 여기서 생성하는 그룹정책 개체는 다른 OU에서도 자신의 컨테이너에 링크시키는 작업을 통해서 가져다 쓸 수도 있다.

 

마지막으로, 각 그룹정책 개체들에 대한 실제구현에 관련된 정보는 Active Directory가 아닌 Sysvol 이라는 폴더에 저장한다. 이것을 가리켜서 그룹정책 템플릿(GPT)라고 한다. Active Directory를 설치할 때 Sysvol 폴더의 위치를 지정했던 것을 기억할 것이다. 그곳은 그룹정책에 관련된 스크립트 파일 등 물리적인 저장소 역할을 하게 된다.

 

도메인에 두 대 이상의 도메인 컨트롤러가 있다면 그룹정책 개체는 Active Directory복제를 통해서 전파가 되고, Sysvol 폴더의 그룹정책 템플릿은 NTFRS (NT파일 복제 서비스)를 통해서 전파가 된다.

 

또한 그룹정책은 기본적으로 상속성을 가지고 있다. 도메인의 그룹정책은 OU에 속한 모든 사용자 및 컴퓨터에 적용되고, 상위OU에 설정된 그룹정책은 하위OU에 상속된다.

 

<참고> 그룹정책의 충돌 및 상속성의 수정

 

그룹정책의 충돌 및 상속성을 이해하기 위한 한가지 예제를 들어 보았다.


<그림14-22. 충돌 및 상속성의 이해를 위한 예제>

 

임직원OU에 속한 사용자가 도메인으로 로그온 했을 때 어떠한 정책이 반영될 것인지 생각해 보자. 기본적으로 그룹정책은 상속성이 있으므로 GPO1, GPO2, GPO3, GPO5 가 반영된다. 그룹정책의 세부항목으로 보자면 ⑥번을 제외한 ① ② ③ ④ ⑤ ⑦ 정책이 반영되게 된다. 그런데 정책을 들여다 보면 정책간에 일부 항목이 충돌이 발생한 것을 알 수 있다. 먼저 윈도우네트웍스OU의 그룹정책 컨테이너에는 GPO2, GPO3 이렇게 2개의 그룹정책 개체가 링크되어 있다. 이 두 정책의 항목 중에서는 시작 메뉴에 실행메뉴 제거라는 항목이 상충되고 있다. GPO2에서는 시작메뉴에 실행메뉴를 제거하도록 설정해 놓고서 GPO3에서는 시작메뉴에 실행메뉴를 제거하지 않도록 설정하고 있다는 것이다. 이렇듯 하나의 컨테이너에 있는 여러 그룹정책이 특별한 항목에서 충돌이 생겼을때에는 우선순위가 있다. 기본적으로 위쪽에 있는 정책이 보다 우선시된다. 그룹정책 메뉴에서 [위로], [아래로] 버튼을 이용하여 우선순위를 바꿀 수도 있다. 그래서 이 경우 임직원OU의 직원이 로그온 했을때는 GPO3의 정책보다는 GPO2의 정책이 우선순위가 있어서 시작메뉴에서 실행창은 제거된다. GPO2의 항목이 반영되는 것이다.

 

또 다른 하나의 충돌도 발생하고 있다. GPO1제어판 접근 허용않음항목과 GPO5제어판 접근 허용항목이다. 이 경우 사용자는 기본적으로는 자신이 속한 OU에 가장 가까운 쪽 정책을 적용받는다. GPO1이 비록 도메인 수준에서 설정된 그룹정책이지만 GPO5의 항목이 최종적으로 적용되는 것이다. GPO1 그룹정책 자체가 적용되지 않는 것이 아니라 GPO1의 그룹정책중 충돌이 발생하는 항목만 적용이 안 되고 나머지 모든 항목은 상속이 된다. 결국 실제로 임직원OU에 속한 사용자가 로그온 했을 때 최종적으로 적용받는 항목들은 ① ③ ④ ⑦ 정책이 반영된다. 이것이 상속성과 충돌이 발생했을때의 기본동작이다.

 

다음에는 이러한 상속성과 충돌발생을 몇가지 옵션을 통해 수정이 되는 것을 알아보자. 예제에서 임직원OU에서는 상위로부터 상속되는 그룹정책을 더 이상 상속받고 싶지 않다면 상속을 거부할 수 있다. 이 설정은 그룹정책 컨테이너 차원에서 이루어진다. <그림14-21. 그룹정책의 구성 이해>에서 정책의 상속을 금지옵션이 그것이다. 임직원OU의 그룹정책 컨테이너에서 이 옵션이 체크되어 있다면 임직원OU에 속한 사용자가 로그온했을 때 받게 되는 정책은 ⑦번 항목인 제어판 사용뿐이다. 도메인 수준의 정책이나 상위OU의 정책은 상속거부되어 적용이 되지 않는다. (Block Inheritance)

 

지금까지 보면 결국 도메인에서 설정한 정책보다 오히려 하위OU수준에서 설정한 정책이 반영이 되었는데, 어떻게 보면 우스운 일이 아닐 수 없다. 하부조직에서 상부의 명령에 불복하는 꼴이 되었으니 말이다. 그런 이유로 무시안함(No Override)’이라는 또다른 옵션이 제공된다. <그림14-32>에서 보면 이 무시안함옵션은 그룹정책 컨테이너 차원에서의 설정이 아니라 그룹정책 개체별 설정이라는 것을 알 수 있다. 아래와 같이 설정되었다고 가정하자.


<그림14-23. 상속성의 수정>

 

결론부터 말하자면 이 경우 임직원OU에 속한 사용자가 로그온했을 때 적용받는 정책은 ① ② ⑤ 번 정책 항목이다. ‘무시안함옵션은 정책간에 같은 항목에서 충돌이 발생했을때는 사용자 측에서 보다 가까운 쪽 정책을 적용한다는 기본설정도 무시한다. 그것보다는 무시안함옵션이 설정된 정책이 우선시 되는 것이다. 윈도우네트웍스OU에서 GPO2는 임직원OU의 그룹정책 컨테이너에 상속금지가 설정되어 있기 때문에 상속이 되지 않지만, GPO3무시안함옵션이 활성화 되어 있기 때문에 역시 상속이 된다.

 

마지막으로 알아볼 것은 그룹정책의 필터링이다. 도메인의 모든 사용자에게 같은 정책을 할당하고 싶지만 특별한 사용자나 그룹에게는 반영하고 싶지 않다면 2가지 방법이 있다. 그러한 사용자나 그룹만 모아서 새로운 OU를 만든다음 이 OU에는 정책을 할당하지 않는 것이 첫번째이고, 두번째 방법은 해당 그룹과 사용자에게만 그룹정책이 적용되지 않도록 퍼미션 설정을 하는 것이다. 후자가 보다 유용한 방법이다. 이것을 그룹정책의 필터링이라고 부른다. 이것 역시 그룹정책 개체단위로 설정할 수 있다. 하나의 예제를 보자. 그룹정책 컨테이너를 열고 필터링 하고자 하는 정책을 클릭한 다음 [속성]을 눌러서 보안탭을 연다.

 

<그림14-24. 그룹정책 필터링>

 

기본적으로 그룹정책은 Authenticated Users 그룹에게 그룹정책 적용이라는 사용권한이 허용되어 있다. <그림14-24>에서 보는 바와 같이 그룹정책이 적용되지 않게 하고 싶은 사용자나 그룹을 추가한 다음 그룹정책 적용사용권한을 거부에 체크해 주면 된다. 예제에서는 송용하라는 사용자가 그룹정책을 받지 않도록 하고 있다. 마이크로소프트의 보안설정구조에서는 항상 허용보다는 거부가 우선한다. 비록 송용하라는 사용자는 Authenticated Users 그룹에 속해 있기 때문에 그룹정책을 허용받게 되지만 명시적으로 자신의 계정에게 거부가 주어져 있기 때문에 그룹정책을 적용받을 수 없다. ‘송용하를 제외한 모든 사용자들은 여전히 그룹정책에 적용받게 된다. 이러한 필터링은 당연히 그룹에게도 적용할 수 있다.

 

<그림14-23>에서 만일 GPO1 그룹정책에서 임직원OU송용하에게 <그림14-24>와 같은 설정을 하였다면 결과적으로 이 사용자가 로그온 했을때는 ⑤,⑦ 정책항목이 적용된다.

 

이제 윈도우네트웍스㈜ 회사의 그룹정책을 구현해 보자. 이 회사에서 구현해야 하는 그룹정책은 다음과 같다.


-
도메인 그룹정책 : 암호정책(8자리), 계정잠금정책(5), 감사정책 구현

- 전사 표준 정책 : Office 2003 배포정책, 무선 네트워크 설정, 인터넷옵션 설정

- 임직원OU 정책 : My document구성, 부서별 공유폴더 매핑 로그온 스크립트

* IT관리OU는 정책상속 거부

 

먼저 도메인 수준의 그룹정책부터 구현해 보도록 하자. 마이크로소프트는 관리자가 그룹정책 구성을 보다 수월하게 할 수 있도록 GPMC (Group Policy Management Console)이라는 관리도구를 별도로 제공해 주고 있다. 그룹정책 관리에 아주 유용한 도구이다. 하지만 GPMC가 아닌 기본 그룹정책 관리 인터페이스도 알아두어야 하니 도메인 수준 그룹정책은 기본 메뉴를 이용해서 구현해 보고, GPMC에 대한 것은 잠시 후에 다루어 보도록 한다.


<그림14-26. 그룹 정책 구현 2>

기본적으로 생성되어 있는 Default Domain Policy가 있다. 여기서 [편집]버튼을 열어서 그룹정책을 설정한다.


<그림14-27. 그룹 정책 구현 3>

그룹정책을 열면 컴퓨터구성사용자구성으로 구분되어 있다. ‘컴퓨터구성àWindows설정à보안설정à암호정책을 열고 오른쪽 패널에서 최소 암호 길이 8문자로 지정하고 최대 암호 사용기간은 60일로 지정했다. 이제 앞으로 사용자가 생성되거나 암호를 변경할 때는 반드시 8자리 이상의 암호를 생성해야만 처리가 된다. 또한 60일이 경과하기 전에 사용자는 암호를 변경해야만 한다.


<그림14-28. 그룹 정책 구현 4>

이번에는 컴퓨터구성àWindows설정à보안설정à계정정책à계정 잠금 정책을 클릭했다. 계정 잠금 임계값을 ‘5’로 지정했다. 추가사항이 나온다. 계정잠금기간은 5번 틀린 암호를 시도했을 때 계정을 잠그고 30분이 지나면 다시 풀어주겠다는 것이고, ‘다음 시간후… ‘ 옵션은 암호를 틀렸을 때 다음번 암호를 틀릴때까지의 카운터를 갱신하는 값이다. 이 값이 30분일 때 어떤 사용자가 한번 암호를 잘못 입력해서 틀리고, 30분이 지나서 또 틀렸다면 그것은 두번째 틀린 것이 아니라 한번 틀린것으로 처리된다.


<그림14-29. 그룹 정책 구현 5>

이번엔 그룹정책에서 감사정책을 구성한다. 정책을 더블클릭하면 이 정책 설정 정의체크상자가 있고, 성공과 실패의 시도가 있다. 계정로그온 이벤트 감사의 경우 사용자가 계정과 암호를 제대로 입력해서 로그온을 성공했다면 성공한 이벤트로 감사가 되고, 암호를 틀려서 로그온을 실패했다면 실패한 이벤트가 된다.

감사정책을 구현하였다. 이 감사정책에 걸려든(?) 이벤트들을 관리자는 관리도구-이벤트 뷰어를 통해서 확인할 수 있다. 기본적으로 사용할 몇가지 감사정책을 설정했다. 창을 닫는다.


<그림14-30. 그룹 정책 구현 8>

Default Domain Policy 그룹정책을 거부하지 못하도록 무시안함옵션을 사용한다. Default Domain Policy를 클릭하고 [옵션]버튼을 눌러서 무시안함을 선택해 준다.


<그림14-31. 그룹 정책 구현 9>

무시안함이 선택된 화면이다. 이 옵션은 OU수준에서 상속을 거부하거나, 동일한 항목의 정책상 충돌이 발생했을때에도 항상 Default Domain Policy는 적용되게 한다.


OU수준의 그룹정책을 설정하기 전에 앞서 언급한 GPMC (Group Policy Management Console)을 설치하자. GPMC는 마이크로소프트 다운로드 사이트에서 찾을 수 있다. GPMC로 검색해서 찾도록 한다.


<그림14-43. GPMC 관리콘솔>

  


<그림14-44. 그룹 정책 구현 1>

이번에는 OU수준의 그룹정책을 설정하자. GPMC에서 그룹정책을 적용할 윈도우네트웍스OU를 마우스 오른쪽 클릭하여 ‘Create and Link a GPO Here’ 선택했다.


<그림14-45. 그룹 정책 구현 2>

GPO의 이름을 전사 표준 정책이라고 입력했다.


<그림14-46. 그룹 정책 구현 3>

전사 표준 정책 GPO가 생성된 것이 보인다. GPMC의 오른쪽 패널을 보면 정책에 대한 권한, 설정 등을 확인할 수 있다. Settings 탭을 선택했다.


<그림14-47. 그룹 정책 구현 4>

Settings 탭을 확인하니 현재 전사 표준 정책’GPC에는 아무런 설정이 되어 있지 않는 것을 알 수 있다. 그룹정책을 설정하기 위해 그림과 같이 마우스 오른쪽 클릭하여 “Edit”를 선택한다.

 


<그림14-48. 그룹 정책 구현 5>

그룹정책 개체 편집기가 열린다. 이것은 앞서서 도메인 수준의 그룹정책을 적용했던 것과 동일한 그림이다. Group Policy Template에서 불러온 것이기 때문이다. 먼저 이 회사의 표준 소프트웨어인 Office 2003을 배포해 보자. ‘사용자구성à소프트웨어 설정à소프트웨어 설치를 마우스 오른쪽 클릭하고 새로 만들기à패키지를 선택한다.


<그림14-49. 그룹 정책 구현 6>
 

배포할 패키지의 위치를 찾고 있다. <그림14-32>에서 c:\packages\office2003폴더에 패키지를 저장했다. 예제에서는 \\blueapple\packages$\office2000 라고 입력했다. 배포서버인 blueapple에는 packsoftware$ 라는 이름의 공유폴더가 있어야 하고 이 곳에는 소프트웨어를 설치하기 위한 패키지가 저장되어야 한다. Packages$라는 이름을 사용하여 공유이름을 감춤으로써 사용자들이 네트워크에서 직접 이 공유폴더를 찾아가는 것을 막을 수 있다. 그룹정책에 의해서만 소프트웨어 원본을 분배해 주기 위한 조치이다.


<그림14-50. 그룹 정책 구현 7>

Office2003 패키지 설치파일인 pro11.msi를 선택하고 나니 소프트웨어 방법을 묻는다. 수정된 mst 파일을 배포하기 위해서는 고급을 선택해야 한다. 게시나 할당을 선택하면 Office 2003이 기본설치되고 사용자들에게 프롬프트를 보여줄 것이다.


<그림14-51. 그룹 정책 구현 8>

<그림14-51>을 보면 고급옵션이 나타난다. [수정]탭을 눌러서 [추가]버튼을 클릭한 후 사용자정의된 .mst 파일을 추가했다.


<그림14-52. 그룹 정책 구현 9>

계속해서 [배포]탭을 선택한 후 배포형식 및 옵션을 결정한다. ‘게시할당은 사용자가 로그온 했을 때의 설치방법의 차이를 보여준다. ‘게시로 배포하면 제어판의 프로그램추가/제거에서 프로그램 추가 항목에 접근하면 Office 2003 설치가 대기중인 것을 확인할 수 있고, ‘할당으로 배포하면 <시작à모든 프로그램> Office2003 관련 실행메뉴가 보이는 것을 확인할 수 있다. 실제 설치가 된 것은 아니다. 배포옵션중 로그온시 이 응용프로그램 설치를 선택하면 사용자가 도메인 로그온을 하면 제일 먼저 Office 2003이 설치된다.


<그림14-53. 그룹 정책 구현 10>

다음엔 인터넷 옵션의 프록시 설정을 구성해 보자. 그룹정책 개체 편집기에서 <사용자구성àWindows설정àInternet Explorer유지à연결>을 찾아가면 오른쪽 패널에서 프록시 설정을 찾을 수 있다. ISA Server 2004로 구성된 웹캐싱서버의 IP주소를 입력하고 구성된 포트번호를 기록한다.


<그림14-54. 그룹 정책 구현 11>

무선랜 클라이언트를 지원하기 위해 사용자의 무선랜 연결설정을 구성하자. <컴퓨터구성àWindows설정à보안설정à무선 네트워크>를 선택하고 무선 네트워크 정책 만들기를 시작한다.


<그림14-55. 그룹 정책 구현 12>

무선 네트워크 정책 이름을 입력한다. 예제에서는 WindowsNetwork WirelessLAN이라고 입력했다.


<그림14-56. 그룹 정책 구현 13>

무선랜 연결의 등록정보를 입력한다. 기본 네트워크탭을 열었다. 회사에 구축된 무선네트워크 연결을 하기 위해 [추가]를 누른다.


<그림14-57. 그룹 정책 구현 14>

네트워크 속성에 무선AP SSID를 입력하고, 계속해서 [IEEE 802.1x]탭을 선택한다.


<그림14-58. 그룹 정책 구현 15>

EAP종류에서는 보호된 EAP”를 선택하고 [설정]탭을 누른다.


<그림14-59. 그룹 정책 구현 16>

신뢰할 수 있는 루트인증기관으로 회사에 구축된 루트CA를 선택하고 인증 방법 선택 아래에 있는 빠른 다시 연결 사용을 체크한 다음 [확인]을 눌러서 구성을 마친다.


<그림14-60. 그룹 정책 구현 17>

윈도우네트웍스OU에 링크된 전사 표준 정책의 구성을 마쳤다. 오른쪽 패널에서 구성된 사항을 확인할 수 있다.

이번에는 임직원 대상 그룹정책” GPO를 생성하고 임직원OU에 링크시켜 보자. 사용자들의 내 문서폴더를 파일서버의 개인폴더로 지정하고, 부서공용폴더를 사용자에게 특정 드라이브로 매핑하여 부서공용문서에 접근이 용이하도록 설정해 주고자 한다.


<그림14-61. 그룹 정책 구현 18>

GPMC를 실행하고 임직원OU에서 마우스 오른쪽클릭하여 ‘Create and Link a GPO Here’ 선택한다. “사용자구성àWindows설정à폴더 리디렉션à내 문서의 속성을 열었다.


<그림14-62. 그룹 정책 구현 19>

blueapple서버에는 사용자들의 데이터를 저장하기위한 용도로 userdoc 라는 공유폴더를 생성해 두었다. <그림14-62>에서 설정부분은 기본값으로 설정했다. 다른 설정을 선택하면 Active Directory의 그룹별로 다른 공유폴더를 지정할 수도 있다. ‘대상 폴더위치부분에서 루트경로\\blueapple\userdoc를 지정했다.

이것은 아주 유용한 기능이다. 이 결과 임직원OU에 속한 모든 사용자계정에 해당하는 폴더가 \\blueapple\userdoc 공유폴더에 생성되며 이 폴더는 자동적으로 해당 사용자에게만 모든권한이 부여되고 다른 사용자들은 접근하지 못하도록 권한관리가 이루어진다.

 

이 그룹정책을 적용받는 사용자가 로그온 하게 되면, 예를 들어 wonsuk 이라는 사용자 계정으로 로그온을 했다면 자동적으로 사용자가 사용하는 컴퓨터에서 바탕화면에 있는 ‘내 문서’폴더는 \\blueapple\userdoc\wonsuk 이라는 이름의 폴더로 매핑이 되어 있다. 사용자가 데이터를 만들고 저장할 때 ‘내 문서’를 이용하도록 교육할 필요가 있다. 사용자가 ‘내 문서(My Document)’에 저장을 하게 되면 실제로 그 데이터는 사용자의 로컬 하드디스크의 파일시스템이 아닌 blueapple 파일서버의 개인폴더 안으로 저장된다. 사용자들이 더 이상 네트워크에서 자신의 폴더를 찾기 위해 헤맬 필요가 전혀 없다. 이렇게 모든 사용자들의 데이터가 파일서버 하나에 집중되게 되면 관리자는 이 서버의 폴더를 백업함으로써 전체 사용자들의 개인 데이터를 보호할 수 있다.

 

또 하나의 장점은 이 사용자가 어떤 컴퓨터에 앉아서 로그온을 하더라도 항상 바탕화면의 ‘내 문서’는 \\blueapple\userdoc\wonsuk 에 매핑이 되기 때문에 항상 자신의 데이터에 접근할 수 있다는 것이다. 일반 사용자가 생각할때는 마술에 걸렸다고 생각할 지도 모르겠다. 자기 컴퓨터에서 저장했다고 생각한 데이터에 다른 사람의 컴퓨터에서도 “내 문서”폴더만 열면 접근할 수 있으니 말이다.


<그림14-63. 그룹 정책 구현 22>

이번엔 부서별로 공용데이터 폴더에 접근할 수 있도록 사용자에게 드라이브를 연결해 주는 스크립트를 자동으로 실행하도록 설정하려고 한다. ‘사용자구성àWindows설정à스크립트(로그온/로그오프)à로그온의 등록정보를 열고 있다.

 

이 작업을 하기 전에 미리 네트워크 드라이브 매핑을 수행할 스크립트 (혹은 배치파일)을 생성해야 한다. 메모장을 열고 net use x: \\공유서버이름\공유폴더\해당부서폴더 를 입력한 다음 바탕화면에 배치파일로 저장해 둔다. 사용자 컴퓨터에서 이 배치파일이 실행되면 로컬 X: blueapple의 공유폴더가 매핑된다. 다음에 할 일은 앞에서 만든 배치파일을 사용자가 로그온할 때 자동으로 실행되도록 그룹정책에서 설정하면 되는 것이다.


<그림14-64. 그룹 정책 구현 23>

로그온 등록정보에서 [파일표시]를 선택한 후 앞에서 만든 배치파일을 저장했다.


<그림14-65. 그룹 정책 구현 24>

[추가]버튼을 눌러서 로그온 스크립트로 수행시키고자 하는 파일을 선택한 다음 [확인]을 눌러서 마친다.


<그림14-66. 그룹 정책 구현 25>

임직원 대상 그룹정책의 설정을 마쳤다. GPMC를 통하여 내용을 확인할 수 있다.


<그림14-67. 그룹 정책 구현 28>

마지막으로 IT관리자들은 상위의 그룹정책을 적용받지 않도록 설정하고자 한다. GPMC에서 IT관리자계정을 조직하기 위한 IT관리OU를 마우스 오른쪽 클릭하고 ‘Block Inheritance’를 선택한다. IT관리OU에 파란색 느낌표가 생기는 것을 확인할 수 있을 것이다.


<그림14-68. 클라이언트 로그온 테스트>

Active Directory 도메인에 참여되어 있는 PC에서Windows XP 임직원OU에 속한 사용자의 계정으로 로그온을 해 보았다. 로그온과 동시에 Office 2003이 설치되고 있는 것이 보인다.

이상으로 그룹정책 구성을 마쳤다. 이 그룹정책이 적용되는 클라이언트의 OS는 현재 Windows 2000 Professional, Windows XP Professional 버전이다. Windows NT Windows 9x의 경우는 그룹정책과 무관하다. 위의 모든 설정이 전혀 반영되지 않는다는 것이다. 점차 도입되는 새로운 시스템들은 Windows XP 로 대체가 될 것이다. 도메인 환경을 구축하였다면 가급적이면 네트워크에 모든 클라이언트들도 Windows 2000이나 Windows XP를 사용하는 것이 좋다.

 

하지만 Windows NT, 9x 클라이언트들의 경우에도 로그온 스크립트나 홈폴더 설정등은 아주 간단히 이루어진다. Active Directory 사용자 및 컴퓨터를 이용해서 Windows 9x 컴퓨터를 사용하는 사용자계정의 등록정보로 접근하여 프로필탭에서 설정할 수 있다. 이것은 Windows 계열의 모든 OS에게 적용되는 설정이다.


<그림14-69. 사용자 계정별 홈폴더, 로그온 스크립트 구성>

:
Posted by 새벽예찬

어떤 회사라도 회사직원들의 인명부나 주소록 정도는 가지고 있을 것이다. 또한 회사에서 사용하는 인사프로그램들의 경우 요즈음 프로그램의 대부분은 출력포맷으로 마이크로소프트의 오피스제품인 엑셀(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 인프라 구축의 범위에 인사연동 계정관리시스템 구축까지 포함하고 있다.



[1] 계정(Identity)관리를 위해 국내에 많이 도입되는 솔루션으로는 Microsoft Identity Integration Server (MIIS), 컨설팅업체인 필라넷의 ArtIDM 등이 있다.

:
Posted by 새벽예찬
2008. 11. 23. 02:26

14-2. 서버설치 및 구성 Windows Networking2008. 11. 23. 02:26

14-2-1. 서버의 역할 결정

 

중소규모 기업네트워크 환경에서 필요한 여러가지 서버의 역할을 각각 고유한 서버가 맡기는 현실적으로 어렵다. 많은 회사들은 최신사양을 갖춘 고가의 전용서버 한대를 들여놓고 회사에서 필요한 모든 서비스를 하나의 서버에 집중시키고 있다. 최소한의 서버대수로써 비교적 원활히 동작할만한 구성을 해 보도록 하자.

 

현재 회사에는 3대의 서버가 동작하고 있다. 아래의 <그림14-6>와 같이 서버를 배치하고 나니 총 4대의 서버가 소요된다. 한대가 부족하다. 새로운 서버 한대를 도입하고 1st 도메인 컨트롤러로 구성할 수 있다. 방화벽 서버가 오래되어 성능이 문제가 되고 있었다면 새로 도입하는 서버를 방화벽 서버로 대체하고 기존 방화벽 서버를 도메인 컨트롤러로 설치하는 것도 좋은 방법이다. 나머지는 기존의 3대의 서버를 가지고 구성하였고, 첫번째 서버에는 802.1x 무선랜 인증을 지원하기 위해 IAS (Internet Authentication Service; 인터넷 인증 서비스)서버를 추가로 구성하였다. ISA Server 2004에는 VPN서비스를 구성하여 출장지에서나 재택근무시 노트북 사용자의 사내자원 접근을 허용하고자 한다. ISA서버와 VPN서버 구성에 대해서는 7장을 참고한다.


<그림14-6. 네트워크에 서버의 기능별 배치>

 

노트북에 설치되어 있던 Windows XP Home edition Active Directory 인프라에 참여할 수 없는 클라이언트이므로 Windows XP Professional버전으로 업그레이드 하였다. Windows 98 3대가 있다는 것이 아쉽긴 하지만 레거시 어플리케이션이 상위버전의 OS에서 지원하지 못한다는 이유로 계속 사용해야 하는 상황이다.

 

네트워크에 서버를 배치할 때는 8장에서 설명한 기업 네트워크에서 네트워크 서버 배치시 고려할 사항을 잘 고려해 보자. 당신이 디자인한 네트워크 구성이 이들 조건에 잘 부합되고 있다면 잘 구성했다고 판단해도 좋다.

 

14-2-2. 첫번째 도메인 컨트롤러 설치

 

다음과 같은 순서로 진행한다.


윈도우 서버 2003 설치 -> 필요한 서비스 설치 -> Active Directory설치 -> 최신 서비스팩 설치


회사의 도메인이름은 위에서 외부적으로 현재 사용하고 있는 windowsnetwork.msft 를 사용하기로 결정했다.



<그림14-7. 첫번째 도메인 컨트롤러 설치 과정 새 도메인 이름 결정>

 

구체적인 설치방법에 대해서는 이 책의 13-3. Active Directory 설치단원을 참고하라.

 

14-2-3. 두번째 도메인 컨트롤러(Replica) 설치

 

같은 방법으로 두번째 도메인 컨트롤러를 설치한다. 설치옵션만 조금 다를 뿐이다.


<그림14-8. 두번째 도메인 컨트롤러 설치 과정 도메인 컨트롤러 종류 결정>

 

역시 구체적인 설치방법에 대해서는 이 책의 13-3. Active Directory 설치단원을 참고하라.

 

Active Directory 도메인 기능수준 (모드)

Windows Server 2003 Active Directory NT4.0과는 다르게 OS의 셋업과 도메인 컨트롤러의 셋업과정이 분리되어 있다. dcpromo 를 이용하여 Active Directory를 셋업하면 도메인 컨트롤러가 되고, 역시 같은 유틸리티를 이용하여 Active Directory를 제거하면 일반서버가 된다.  Windows Server 2003의 도메인은 이전버전인 Windows 2000, NT4.0 도메인컨트롤러와의 호환성을 위하여 기본적으로는 'Windows 2000 혼합모드'를 사용한다. 하지만, Windows 2000 혼합모드는 Active Directory에서 추가된 기능들중 몇 가지를 사용하는데 제약을 주게 된다. Windows NT 4.0 도메인 컨트롤러가 반드시 필요한 상황이 아니라면 그들을 윈도우 서버 2003으로 업그레이드를 고려한다. 회사의 도메인 환경이 Windows Server 2003 도메인 컨트롤러만으로 구성이 완료되었다면 'Windows 2000 혼합모드' 'Windows Server 2003 기능수준으로 전환시켜 주어야 할 것이다. 그렇지 않으면 Universal Group, Group의 중첩적용, RAS서버의 정책관리 등의 기능을 구현할 수가 없다. 보다 자세한 사항은 Windows Server 2003의 도움말에 잘 정리되어 있다.

도메인 기능수준을 확인하기 위해서는 관리도구àActive Directory 사용자 및 컴퓨터를 실행하고, 관리콘솔의 왼쪽패널에서 도메인이름을 클릭하고 마우스 오른쪽 단추를 이용하여 등록정보로 접근한다.<그림14-9>


<그림14-9.  도메인 기능수준 정보>

 <그림14-9>에서는 도메인 기능수준이 'Windows 2000 혼합으로 되어 있음을 보여준다. Active Directory를 설치하고 나면 기본값이다. 화면에서 보이는 것처럼 사용가능한 도메인 기능 수준 선택을 클릭하여 원하는 도메인 기능수준을 선택한 후 [수준 올리기]를 클릭하여 기능수준을 전환할 수 있다. 단방향 작업이니 회사의 도메인에 더 이상 NT 4.0 도메인 컨트롤러나 Windows 2000 도메인 컨트롤러가 없다는 것이 확실했을 때 변경하도록 한다.

이 도메인 기능수준은 클라이언트의 종류와는 무관하다. 도메인 컨트롤러가 아닌 서버나 클라이언트들의 OS Windows 2000이거나 WIndows NT이거나 Windows 98이거나 상관할 바가 아니다. 이전버전의 도메인 컨트롤러가 더 이상 필요하지 않음이 확실하다면 도메인 기능수준을 변경해서 사용하자.

 

14-2-4. OU구조 생성

 

이전단계에서 설계된 OU 구조 디자인에 맞도록 OU를 생성한다. 먼저 최상위 OU윈도우네트웍스부터 만들어 나간다. Active Directory 사용자 및 컴퓨터 관리콘솔의 왼쪽패널에서 도메인이름을 마우스 오른쪽 클릭하여 새로 만들기→조직단위를 선택한다.


<그림14-10. OU생성이 완료된 화면 >

 

OU생성을 완료하였다.

 

14-2-5. 사용자 및 그룹 생성

 

다음 작업으로 OU별 사용자와 그룹을 생성한다. 사실 직원전체 규모 100여명 이내 정도의 회사환경에서는 사용자 계정을 생성하는 초기작업 자체는 귀찮긴 하지만 크게 부담스러운 일은 아니다. 하지만 보다 간단하게 계정을 생성하는 방법에 대해서 정리해 보자. 수동으로 작업을 한다면 일단 부서별로 한명씩만 사용자 계정을 생성하고, 사용자가 속할 그룹을 생성한 다음, 그룹 멤버쉽, 홈폴더, 부서명 등 기본정보를 일단 구성을 마칠 것을 권한다. 그런 다음 사용자 계정을 복사하는 방법을 이용해서 보다 손쉽게 부서별로 동일한 설정을 가진 사용자를 생성하는 작업이 가능하다. 이것은 작업의 속도를 한결 높여줄 것이며 간혹 실수로 사용자계정 정보가 잘못 설정되는 것을 방지해 줄 수 있는 좋은 방법이다.


<그림14-11. 사용자 계정 복사를 통해 새로운 계정을 생성 >


이제 사용자 계정이 제대로 생성되었는지 잘 확인한 다음에 필요한 몇 개의 그룹을 생성하고 사용자를 그룹의 멤버로 참여시킴으로써 계정생성작업을 완료하였다.


<그림14-15. 그룹생성 및 사용자를 구성원에 추가하는 작업>

 

그룹의 이름을 명명할때는 사용자들이 찾기 쉬운 직관적인 이름을 사용할 필요가 있다. 이것은 사용자가 파일공유 등의 작업을 하고자 할 때 그룹단위의 공유작업을 쉽게 할 수 있도록 하는데 유용하다.

*기업에서 많은 수의 계정을 한꺼번에 생성하고자 할 때 사용할 수 있는 유용한 도구가 제공된다. [Note] dsadd 유틸리티를 이용한 대량 사용자 계정 생성방법 (Bulk Import) 참고.

 

14-2-6. 관리권한 위임 구현 (Delegate Control)

 

각각 어떤 작업을 누구에게 위임할 것인지를 시나리오를 통해서 얻어냈다. 그대로 구현하면 될 일이다. ‘14-1-5. 디렉터리 구성 테이블을 참고해서 작업한다. 인사담당자에게 사용자계정 관리권한을 위임하는 것을 구현해야 한다. 어디까지 위임할 것인가의 여부에 따라, 특정OU에서 혹은 전체도메인에 대해 적용하는 것이 가능하다.


<그림14-16. 관리 권한 위임 1>

권한을 위임하고자 하는 대상인 윈도우네트웍스’OU를 마우스 오른쪽 클릭하여 제어위임을 선택했다.


<그림14-17. 관리 권한 위임 2>

관리권한을 위임받을 사용자인 인사담당자인 김태훈사용자계정을 추가했다.


<그림14-18. 관리 권한 위임 3>

어떠한 작업을 위임할 것인지를 결정해야 한다. ‘사용자 계정 작성, 삭제 및 관리권한을 선택하고 [다음]으로 진행하여 제어위임을 마친다.

:
Posted by 새벽예찬
2008. 11. 23. 02:14

14-1. Active Directory 설계 Windows Networking2008. 11. 23. 02:14

14-1-1. 요구분석

안정적인 Active Directory 구축 및 운영을 위한 가장 중요한 단계는 요구분석 단계이다. 요구조건을 최대한 도출하고 분석을 통하여 올바른 설계의 방향을 결정하는 것은 아무리 강조해도 지나치지 않다. Active Directory 설계에 정답이 있는 것은 아니다. AD를 구축하고자 하는 회사의 요구사항이 있고 AD에서 수용할 범위가 결정되었다면 설계된 내용을 토대로 AD를 구축하였을 때 요건이 모두 해결될 수 있다면 최적의 설계를 한 것이라고 하겠다.

No

요구조건

분석 및 접근방향

1

사용자들이 도입되는 무선네트워크에 손쉽게 접근할 수 있도록 해 주어야 한다.

무선네트워크는 Active Directory인프라를 활용하여 별도의 디렉터리를 가지지 않고도 클라이언트들을 지원하도록 한다. 802.1x 무선인증을 지원하는 Wireless Access Point를 구매하여 사용자들이 도메인 로그온을 받을 수 있도록 함. IAS/RRAS서비스를 이용하여 무선AP 802.1x인증 지원, 사용자PC에는 그룹정책을 활용하여 자동을 클라이언트 설정을 구성함

2

보안을 고려하여 내부/외부 DNS는 분리되어야 한다.

ISA Server 2004로부터 퍼블리싱되는 DNS서버는 그대로 유지하고 내부사용자들은 추가되는 도메인 컨트롤러의 DNS서비스를 이용하도록 함

3

전 직원은 파일서버에 자신만 접근할 수 있는 데이터를 저장하도록 한다.

파일서버에 사용자 개인별 홈폴더를 생성하고 홈폴더를 My document에 매핑시켜줌. Windows 98 사용자들은 계정별 홈폴더 매핑적용

4

부서별로 공용폴더를 구성하여 부서원간에 정보를 공유한다. 사용자들이 각 부서별 공유폴더에 쉽게 접근할 수 있도록 네트워크 드라이브 매핑을 설정해 준다.

그룹정책 사용하여 공용폴더를 매핑하는 스크립트 배포, Windows 98사용자들은 사용자별 로그온 스크립트 작성.

5

사용자들은 최소 8자리 이상의 암호를 사용해야 하며, 5번 틀린 암호로 로그온을 시도하면 계정이 잠기도록 설정되어야 한다.

강력한 암호정책 사용으로 사용자들의 도메인 계정 및 로컬PC의 계정에 대한 암호강화

6

하나의 서버가 문제가 되더라도 사용자들은 도메인 로그온에 지장이 없어야 한다.

2대의 도메인 컨트롤러 설치가 필요함

7

관리자들을 제외한 모든 사용자들은 보안을 위해서 Proxy Server를 통해서 인터넷에 접근한다.

그룹정책을 통해 인터넷 옵션 제어. Windows 98 사용자들의 통제어려움으로 Windows 2000, XP로 업그레이드 고려

8

도메인컨트롤러와 서버들을 제외한 회사의 모든 클라이언트 PC들에는 회사의 업무를 위해 표준소프트웨어인 마이크로소프트 오피스 2003이 설치되어야 하며, 부서별로 특화된 프로그램을 배포해야 할 필요가 있다.

그룹정책의 소프트웨어 배포정책 활용, Windows 9x 사용자들의 통제어려움으로 Windows 2000, XP로 업그레이드 고려. 부서별 특화된 프로그램 배포를 위해 OU별 별도의 그룹정책 구현, OU디자인에 반영되어야 함.

9

전체 조직에 걸쳐서 사용자 계정을 관리하는 것은 인사담당자가 직접 처리하도록 하여 신속하고 정확한 계정관리가 가능하도록 하고자 한다.

인사담당자에게 회사 조직에 대한 전체 사용자 계정 생성 작업 위임.

10

보안을 위해서 모든 사용자, 회사내의 모든 서버에 있어서 계정에 대한 감사정책을 구현해야 한다.

도메인 수준, 도메인 컨트롤러 수준의 감사정책 구현

11

시스템 관리자 계정은 회사의 전반적인 정책에 적용받지 않아야 한다.

그룹정책에 대한 관리자계정 필터링을 통해서 해결.

12

노트북을 이용하는 사용자들은 출장지 혹은 재택근무를 할때도 회사자원을 사용할 수 있도록 지원하고자 한다.

VPN서버를 도입함으로써 외부에서 접근시 클라이언트 인증 및 네트워크 보안 지원. ISA Server 2004 VPN기능을 활성화하여 클라이언트 도메인 로그온 지원

 

14-1-2. 도메인 구조 결정

 

일단 도메인구조를 결정할 필요가 있다. 하나, , 아니면 그 이상? 몇 개의 도메인으로 만들것인지를 고려해야 한다. Active Directory Windows NT 4.0 의 도메인 구조와는 분명히 달라질 수 있다. Windows NT 4.0의 도메인은 계층적인 관리구조를 지원하지 못하였다. 그런 이유로 지사, 본사, 부서별 관리 등을 회사가 원하는 대로 지원하기 위해서 복수도메인 구조가 불가피했던 경우가 생겼다. 하지만 Active Directory는 조직단위(OU)라는 관리구조가 도입됨에 따라 계층적인 관리가 가능하고 Windows NT 4.0 이라면 복수도메인(Multiple Domain)으로 구축되어야 할 경우라도, 대부분의 경우 Active Directory은 단일 도메인(Single Domain)으로써 지원할 수 있는 토대가 마련되었다.

 

마이크로소프트는 도메인 모델을 결정할 때 일단 단일 도메인 모델을 검토하고, 회사의 요구사항이 단일 도메인 모델로써 해결될 수 없는 상황일 경우에만 복수 도메인 모델을 도입할 것을 권장하고 있다. 현재 우리가 다루어보고자 하는 시나리오 환경자체는 컴퓨터 100여대 정도의 중소규모 환경이지만 이것보다 훨씬 더 큰 규모의 회사 환경이라도 반드시복수도메인으로 가야 할 이유는 많지 않다고 판단된다.

 

복수도메인이 필요한 경우는 조직간에 보안상의 이유로 계정/암호정책 등이 차별적인 설정을 가져야 하는 경우, 회사의 조직간에 IT관리에 대한 책임과 역할이 명확하게 구분되어야 하는 경우 등이 일반적인 이유이다. 이 회사의 시나리오에서는 어떠한 요구조건에서도 단일도메인을 벗어나야 하는 이유가 없다. ‘단일 도메인을 구축하기로 결정하였다.

 

14-1-3. 도메인 이름 결정

 

도메인의 이름은 회사를 대표할 수 있는 이름을 선택하는 것이 좋다. 이 회사는 이미 windowsnetwork.msft 라는 도메인을 가지고 있다. 이 이름을 그대로 Active Directory 도메인이름으로 사용하기로 한다. 만일 회사가 인터넷에 등록한 도메인 이름이 없는 상태라면 먼저 회사를 대표할 수 있는 이름 하나를 등록할 것을 권장한다. 당장 인터넷에 연결 자체는 할 필요가 없더라도 도메인 이름을 확보해 두는 것이 안정적인 도메인 구축을 할 수 있는 방법이다.

 

이 이름은 두 가지 용도로 사용된다. 하나는 인터넷상의 다수의 클라이언트들이 회사의 웹서버, 메일서버등의 자원에 접근하기 위한 용도이고, 둘째는 회사 내부의 클라이언트가 도메인을 식별하고 디렉터리 서비스를 받기 위한 용도이다. 이들은 사용용도가 다르지만 동일한 이름체계를 사용하고 있기에 하나의 DNS서버를 통해서 얼마든지 서비스될 수 있지만, 보안을 고려한 좋은 모델은 이 두가지 용도별로 DNS서버를 분리시키는 방법이다. 내부 DNS서버와 외부DNS서버로 구분하는 것을 의미한다.

 

이러한 네트워크의 물리적인 환경에 대해서는 8장의 안전을 고려한 네트워크 환경 구축을 참고하라.

 

14-1-4. 관리구조 결정 (OU)

 

Active Directory구조에서 OU는 큰 의미를 가진다. 관리권한의 위임, 그룹정책의 적용의 최소 단위가 OU이기 때문에 IT관리 요구사항을 그대로 반영하여 OU구조를 만들어 낼 필요가 있다. OU의 가장 큰 용도는 그룹정책구성을 위한 최소단위, 관리권한 위임의 최소단위로 사용되어 IT관리자가 개체들을 보다 쉽고 유연하게 관리하도록 한다.

 

그렇지만 OU구조가 조직구조와 같을 필요는 없다. OU라는 단위는 사용자들에게는 투명하다. 사용자들은 자신이 어떤 OU에 속해 있는지 몰라도 되고, 알 필요도 없다는 것이다. 시나리오의 요건중에서 OU의 설계와 연관성이 있는 요건은 3,4,7,8,9 정도가 되겠다. 이중에서도 요건8의 내용을 보면 부서별로 특화된 프로그램을 배포해야 할 필요가 있다는 문구가 있다. 이것은 부서별로 구분되는 프로그램을 정책에서 배포해야 할 필요성을 이야기하는 바, 이러한 정책을 지원하기 위한 OU구조를 고민해 봐야 한다.

 

방법은 2가지가 있다. 첫번째 방법은 부서별로 OU를 구분하여 조직도 형태의 OU를 만드는 것이고, 두번째 방법은 하나의 OU에 개체를 모두 담고 필터링을 통해서 그룹별로 지정된 프로그램을 배포하는 방법이다.

 


<그림14-4. 조직도를 반영한 계층적 OU 구조 디자인>

 

먼저 <그림14-4>의 예제를 보자. 예제의 OU구조는 조직도를 그대로 OU구조에 반영한 것이다. 실제 회사환경은 이보다 훨씬 복잡한 조직구조라는 것을 감안해야 한다. 위와 같이 OU의 계층적인 디자인을 통해서 상속성이 있다는 특징을 그대로 활용할 수 있다. 권한위임이나 그룹정책은 상위OU에서 설정된 내용은 기본적으로 하위OU로 상속성이 있으므로 IT관리구조를 그대로 반영할 수 있다. 최상위OU는 가능한한 회사의 조직개편 등에 재편성을 하는 일이 적도록 신경써야 할 부분이다. OU구조가 틀려지면 관리구조 역시 전체적으로 재정비를 해야 할 것이기 때문이다. 꼭 필요가 없더라도 위와 같은 경우 최상위 OU’를 하나 배치하는 것은 좋은 설정이다. OU에 소속된 모든 사용자들에게 일괄적인 정책이나 권한설정을 하고자 한다면 최상위OU에서의 정책만으로 통제가 가능하기 때문이다.

 

다음의 <그림14-5>OU구조도 살펴보자.


<그림14-5. 기능적 측면을 고려한 계층적 OU 구조 디자인>

 

이 구조는 조직도를 배제하고 기능적인 측면에 중점을 둔 OU구조이다. 이렇게 구성을 하는 것도 현재 윈도우네트웍스사의 요구조건을 모두 만족시킬 수 있을 뿐만 아니라 조직개편 등에 따른  OU간의 이동에 대한 관리부담도 해소할 수 있어 좋은 구조라고 생각한다. 먼저 언급했듯이 설계에는 정답이 있는 것은 아니다. “OU구조가 꼭 조직도 형태로 되어야 한다는 편견은 버려!”(개그맨 정준하님 버전)라고 말해주고 싶다.

 

각각 장단점을 정리해 보면 다음과 같다.

구분

장점

단점

부서별로 OU 생성

l 부서별 다른 설정의 그룹정책을 구성하기가 편하다.

l 조직도 형태로 구성되어 있어서 관리자가 보기에 편하다.

l 사용자의 부서이동에 따라 사용자개체와 컴퓨터개체를 사용자의 이동부서에 따라 OU간 이동을 시켜 줘야 한다. 디렉터리의 일관성이 깨져서 신뢰성이 손상될 우려가 있다.

기능중심의 OU 생성

l 조직개편 등에 따라서 OU의 이동등의 조치가 필요 없어 관리에 따른 부담이 줄어든다.

l 그룹정책 구성시 보다 세심한 설정이 필요하다.

 

14-1-5. 명명규칙


Active Directory
인프라와 관련된 서버/PC/로그온 이름 등 다양한 개체에 대한 명명규칙을 정의한다.

구분

고려사항

비고

서버명

l 도입된 서비스 유형 등이 파악될 수 있는 이름을 고려하는 것이 좋음

l 운영서버/개발서버

l 도입된 시스템 분류

클라이언트

PC

l 효율적인 관리를 위해 단말명은 변경되지 않는 고유값을 설정하는 것이 좋음

l 공유자원에 접근이 용이하도록 단말의 설명항목에 부서명/사용자 이름 등을 표기함으로써 접근이 용이하도록 구성

사용자계정

l 기존 어플리케이션에서 사용하던 로그온 ID와의 편의성 측면을 고려해야 함

l 로그온ID가 보안이 유지되어야 할 대상인지 판단

l 암호정책 고려

l  암호 길이

l  최소암호사용기간

l  최대암호사용기간

l  암호 잘못 입력시 동작 등

그룹계정

l 조직,직무,직군,직급 등의 다양한 그룹이 통합디렉토리에서는 하나의 그룹카테고리로 분류됨

l 사용자가 통합디렉토리에서 검색이 용이하도록 이름 선택

 

 

14-1-6. 디렉터리 구성 테이블 작성


구현을 위해서 필요한 디렉터리의 내용들을 테이블로 정리해 보았다
. 필자는 위의 OU구조중 두번째인 <그림14-5>의 구조를 선택했다.

단위

그룹, 사용자,컴퓨터

권한위임

그룹정책(GPO)

옵션

도메인

 

 

암호정책(8자리)

계정잠금정책(5)

감사정책 구현

무시안함

무시안함

무시안함

Domain Controllers

도메인 컨트롤러 배치

 

 

 

Computers

파일, 프린트, DNS 서버

 

 

 

윈도우네트웍스OU

 

인사담당자에게 사용자계정 생성권한위임

전사적인 업무프로그램배포정책

인터넷옵션 설정

 

IT관리OU

관리자 계정

없음(상속)

 

정책상속거부

임직원OU

 

없음(상속)

My Documents폴더 지정

공유폴더 매핑 로그온스크립트

 

인사외OU

인사시스템에 등재되지 않은 외부사용자

없음(상속)

없음(상속)

 

임직원/사용자OU

회사의 모든 임직원

없음(상속)

없음(상속)

 

임직원/컴퓨터OU

회사의 모든 PC

없음(상속)

없음(상속)

 

 


:
Posted by 새벽예찬
2008. 11. 23. 02:10

<시나리오> 윈도우네트웍스(주) Windows Networking2008. 11. 23. 02:10

이번장에서는 그동안 다루었던 내용들을 토대로 간단하면서도 일반적인 회사 환경 하나를 시나리오로 설정해 보았다. 이 시나리오를 잘 분석하여 하나의 도메인 환경을 구축해 보도록 하겠다.

<회사개요>

윈도우네트웍스㈜(가상의 회사임)’은 윈도우 네트워크 서비스회사이다. 이 회사는 최근 사세가 확장함에 따라 직원수가 대폭 늘어나고 PC대수도 증가하고 있는 추세이다. 추세에 발맞춰 무선네트워크를 도입하고자 검토하고 있으며, 1명의 관리자를 통해 PC를 효율적으로 관리할 수 있는 방안을 검토하고 있다. 사용자들이 메일, 파일, 프린트 등을 위해 각각 서버에 로그온을 해야 하는 것도 불편하여 한번 로그온만 하면 더 이상 인증없이 회사 전체서버에 접근하도록 하기를 원한다. 늘어가는 윈도우PC들의 서비스팩, 보안패치 등을 배포하는 것도 사용자들에게 의존하고 있지만 골칫거리 중의 하나이다.

 

<조직구조>

회사는 관리팀, 영업총괄팀, 마케팅팀으로 나뉘어 있고, 회사의 시스템 관리자인 송창하는 관리팀에 소속되어 있다. 영업팀은 기술영업팀’ ‘컨설팅영업팀으로 세분화된다.

 


<그림14-1. 조직구조도>

 

<현재 네트워크 및 시스템 환경>

회사는 한 ISP의 전용회선을 사용하고 있다. 최근 직원들이 많이 들어와 PC대가 늘어남에 따라 IP Address가 부족한 상황에서 보안을 고려하여 ISA Server 2004를 도입하였고 서버를 제외한 모든 클라이언트들은 개인(사설) IP주소인 192.168.0.2~192.168.0.254 범위의 IP를 사용하고 있다. 클라이언트는 1DNS로 사내에 구축된 DNS서버인 192.168.0.2를 사용하고 있으며, 2 DNS로 외부 ISP DNS서버를 사용하고 있다.


<그림14-2.윈도우네트웍스㈜의 네트워크 및 시스템환경>

 

현재 윈도우 서버 2003 3대 설치되어 있으며 이들은 파일서버, 프린트서버, 웹서버, 방화벽/웹캐쉬서버, DNS서버 등의 역할을 수행하고 있다. 클라이언트들의 시스템중 60대는 Windows XP Professional버전, 30대는 Windows 2000 Professional버전, 신규구매한 노트북 5대에는 Windows XP Home Edition, 3대는 Windows 98이 설치되어 있다. 웹서버는 회사가 등록한 도메인명을 기반으로 www.windowsnetwork.msft 라는 이름을 사용하고 있다.웹서버와 DNS, 메일서버는 클라이언트PC와 마찬가지로 개인IP대역을 사용하고 있으며 ISA Server 2004 로부터 퍼블리싱 되고 있다.

 

<요구조건>

1.사용자들이 도입되는 무선네트워크에 손쉽게 접근할 수 있도록 해 주어야 한다.

2.보안을 고려하여 내부/외부 DNS는 분리되어야 한다.

3.전 직원은 파일서버에 자신만 접근할 수 있는 데이터를 저장하도록 한다.

4.부서별로 공용폴더를 구성하여 부서원간에 정보를 공유한다. 사용자들이 각 부서별 공유폴더에 쉽게 접근할 수 있도록 네트워크 드라이브 매핑을 설정해 준다.

5.사용자들은 최소 8자리 이상의 암호를 사용해야 하며, 5번 틀린 암호로 로그온을 시도하면 계정이 잠기도록 설정되어야 한다.

6.하나의 서버가 문제가 되더라도 사용자들은 도메인 로그온에 지장이 없어야 한다.

7.관리자들을 제외한 모든 사용자들은 보안을 위해서 Proxy Server를 통해서 인터넷에 접근한다.

8.도메인컨트롤러와 서버들을 제외한 회사의 모든 클라이언트 PC들에는 회사의 업무를 위해 표준소프트웨어인 마이크로소프트 오피스 2003이 설치되어야 하며, 부서별로 특화된 프로그램을 배포해야 할 필요가 있다.

9.전체 조직에 걸쳐서 사용자 계정을 관리하는 것은 인사담당자가 직접 처리하도록 하여 신속하고 정확한 계정관리가 가능하도록 하고자 한다.

10.보안을 위해서 모든 사용자, 회사내의 모든 서버에 있어서 계정에 대한 감사정책을 구현해야 한다.

11.시스템 관리자 계정은 회사의 전반적인 정책에 적용받지 않아야 한다.

12.노트북을 이용하는 사용자들은 출장지 혹은 재택근무를 할때도 회사자원을 사용할 수 있도록 지원하고자 한다.

 

윈도우네트웍스㈜의 100여명의 사용자들은 몇대의 서버에 접근하고 있다. <그림14-2>에서 보면 파일서버와 메일서버, 웹캐슁서버 등의 자원을 사용해야 하는데 네트워크에 있는 자원에 접근하기 위해서 먼저 해야 할 일은 자원을 가진 서버로부터 인증(Authentication)을 얻는 일이다. 이 과정을 통해서 자신의 존재를 증명받고 난 다음에 그 다음에 자원에 대한 접근권한이 있는지 없는지를 평가받는 작업(Authorization)을 거치게 되고 최종적으로 자원에 대한 접근허가가 떨어져야만 네트워크의 자원을 사용할 수 있는 것이다. 이에 대해서는 이 책의 13장에서 이미 다룬바 있다.

 

그런 이유로 일단 3대의 서버의 세가지 이상의 자원을 가지고 있는 상황이기 때문에 일단 자원에 접근은 둘째치고 먼저 3대의 서버에 접근할 수 있어야 하는 만큼 이들 3대의 서버에는 자신이 네트워크에서 사용하는 사용자 계정이 있어야 한다. 회사 직원이 100명이므로 3대의 서버에는 각각 100명의 계정정보가 있어야 한다는 것이다.

 

일단 모든 서버마다 전체 사용자들의 계정정보를 가진다는 것은 부담스러운 일이 아닐 수 없다. 사용자 입장에서도 3대의 서버마다 각각 계정과 암호를 알고 있어야 하기 때문에 복잡할 수밖에 없다. 내가 파일서버에 폴더를 읽기 위해서 필요한 계정이 뭐더라? 메일서버에서 내 메일박스의 메일을 확인할때의 계정은 또 뭐지? 이러한 문제들이 결국 사용자들이 서버에 자원을 가지지 않고 각각 자신의 컴퓨터에 로컬로 자원을 가지게 만드는 원인을 제공하는 것이라고 할 수 있다. 첫번째 제공되어야 할 것은 바로 이것이다. “하나의 사용자는 네트워크에서 한번 로그온한 정보를 가지고 전체 자원에 접근할 수 있어야 한다싱글 사인온 (SSO)을 이루고자 하는 것은 대부분의 벤더에서 구현하고자 하는 노력이다. 최근들어 여러 웹사이트들이 서로 연동하여 계정하나만으로 여러 개의 사이트에 접근하도록 구현하고 있는 것을 생각해 보라. 또한 마이크로소프트의 패스포트는 수많은 사이트를 별도의 계정없이 접근할 수 있도록 허용하고 있다.

 

마이크로소프트는 회사의 네트워크 환경에 도메인(Domain)’이라는 논리적인 단위를 도입함으로써 싱글 사인온과 글로벌 디렉터리 서비스를 제공하고 있다. 도메인의 계정 하나만 가지면 네트워크의 모든 자원에 불편없이 접근하여 사용하거나, 관리하는 작업이 가능해 지는 것이다.<그림14-3>


<그림14-3. 마이크로소프트 도메인 모델>


이 회사에는 현재 전체 시스템 및 사용자를 포함할 수 있는 인프라가 필요하다. 마이크로소프트가 제공하는 Active Directory 인프라는 윈도우네트웍스㈜에게 최상의 관리 및 업무환경을 제공할 것이다. 무선네트워크 사용자, 재택근무를 위한 사용자를 지원하는 것도 역시 Active Directory 인프라에 포함할 수 있다. 윈도우네트웍스㈜의 Active Directory를 설계/구현해 보자.

:
Posted by 새벽예찬


<그림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를 이용한 그룹정책 수동으로 갱신하기>

 

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


[1] Windows 2000 Server라면 gpupdate 유틸리티 대신에 secedit을 사용해야 한다. 다음과 같이 입력하면 컴퓨터 정책이 업데이트 된다.  Secedit /refreshpolicy machine_policy /enforce”

 


:
Posted by 새벽예찬
2008. 11. 23. 01:49

Active Directory에 대한 생각 한편 Extra Articles2008. 11. 23. 01:49

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


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


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


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


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


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

:
Posted by 새벽예찬
2008. 11. 23. 01:47

13-5. Active Directory 제거 Windows Networking2008. 11. 23. 01:47

도메인 컨트롤러에서 Active Directory만 제거하면 다시 보통의 서버로 돌아가게 된다. Active Directory를 제거하는 것도 알아 두어야 한다.

 

설치와 마찬가지로 Active Directory를 제거할때도 dcpromo 유틸리티를 이용한다. 시작à실행 창에서 dcpromo를 입력하면 Active Directory 설치마법사가 실행한다. 계속 진행한다.


<그림13-82. Active Directory 제거 1>

경고메시지가 나타난다. 현재 AD제거작업을 하고 있는 서버가 글로벌 카탈로그 서버로 동작하고 있다는 메시지이다. 도메인을 완전히 제거하는 상황이 아니라면 반드시 이 서버를 대신할 다른 도메인 컨트롤러가 글로벌 카탈로그 서버로 설정되어 있어야 한다.


<그림13-83. Active Directory 제거 2>

Active Directory제거 화면이 나왔다. “이 서버가 도메인의 마지막 도메인 컨트롤러입니다  체크박스가 비어있다. 도메인 컨트롤러가 여러대일 때 마지막 도메인 컨트롤러를 제거하는 작업을 할 때는 이 체크박스를 체크해 주어야 한다.


<그림13-84. Active Directory 제거 3>

도메인의 구조에서 이 도메인 컨트롤러를 제거해야 한다. 루트 도메인의 관리자계정과 암호를 제시한다.


<그림13-85. Active Directory 제거 4>

도메인의 구조에서 이 도메인 컨트롤러를 제거해야 한다. 루트 도메인의 관리자계정과 암호를 제시한다.


<그림13-86. Active Directory 제거 5>

Administrator 암호 페이지에서는 AD가 제거되고 난후 로컬 디렉터리 데이터베이스를 사용하게 되므로 그 때의 관리자계정인 Administrator에 대한 암호를 묻고 있다. AD제거후 다시 부팅했을때는 이 암호로써 로그온 할 수 있다.


<그림13-87. Active Directory 제거 6>

요약된 정보를 확인하고 [다음]을 누른다.


<그림13-88. Active Directory 제거 7>

수준을 내리기 위해 디렉터리 서비스를 준비 중이라는 메시지가 보이는데, AD를 제거하고 로컬 디렉터리 데이터베이스를 사용하기 때문이다.


<그림13-89. Active Directory 제거 8>

. 이제 Active Directory제거를 마쳤다. [마침]을 누르고 시스템을 재시작하면 AD는 흔적도 찾아볼 수 없다. 해당 도메인의 멤버서버이거나 마지막 도메인 컨트롤러였다면 독립실행형 서버로 동작하게 된다.


:
Posted by 새벽예찬

Active Directory가 제공하는 도메인 모델은 멀티 마스터 복제 모델이다. 하나의 도메인에 여러 개의 도메인 컨트롤러가 마스터 역할을 한다는 것을 의미이다. NT4.0의 도메인 모델이 싱글 마스터 모델이었던 것과 비교해 볼 필요가 있다. NT4.0의 도메인구조에서 PDC(Primary Domain Controller)라는 하나의 마스터 도메인 컨트롤러가 있었고 나머지 도메인 컨트롤러들은 BDC(Backup Domain Controller)라는 이름을 달고 있어서 마스터의 디렉터리 데이터베이스를 동기화(Synchronization)를 통해서 유지하는 형태로 동작한다.

 

Active Directory에서 도메인 컨트롤러들은 한 도메인에서 NT4.0 PDC, BDC처럼 계층구조를 가지지 않는다. 동등하게 별도의 Active Directory Database를 유지하고 있고, 이들은 복제를 통하여 서로의 디렉터리 데이터베이스를 일치시키는 작업을 하게 된다. 하지만 모든 작업이 이렇게 동작할 수는 없다. 아무리 한 도메인내에서 모든 도메인 컨트롤러가 동등하게 동작한다고 하더라도 그렇게 해서는 문제가 생길 수 있는 작업들이 있기 때문에 Active Directory도메인에서도 특별한 몇몇 작업에 한정해서는 하나의 도메인 컨트롤러를 지정하여 처리를 하고 있고, 이러한 역할을 맡은 도메인 컨트롤러를 가리켜서 작업 마스터(Operation Master)”라고 부른다.

 

작업 마스터 역할을 맡은 도메인 컨트롤러는 다른 도메인 컨트롤러보다는 조금은 더 신경써서 관리해야 할 필요가 있고, 도메인에는 반드시 이 역할을 맡은 도메인 컨트롤러가 1대만 존재하도록 유지를 해 주어야 한다. 또 만일 그러한 역할을 맡고 있던 서버가 네트워크에서 사라져야 할 경우가 생긴다면 다른 서버가 역할을 맡아서 계속 수행할 수 있도록 해 주어야 문제가 없다.

 

이러한 모델을 가리켜서 “FSMO (Flexible Single Master Operations)”라고 부르고 있다. 당신이 회사에서 포리스트 루트 도메인을 생성하였다면 그 도메인에는 5가지의 작업 마스터역할을 하는 서버가 있다. 기본적으로는 도메인에서 첫번째 설치된 도메인 컨트롤러가 이 다섯가지의 작업 마스터 역할을 모두 수행하고 있다.

 

다섯가지 작업 마스터 역할에 대해서 정리해 보자. 포리스트에 도메인 명명 작업 마스터스키마 마스터는 유일하며, 모든 도메인 마다 ‘RID 마스터, PDC 에뮬레이터, 하부 구조 마스터는 하나씩 동작하고 있어야 한다. 대부분의 회사가 그렇듯이 하나의 도메인으로 구성된 회사였다면 아래의 다섯가지 작업마스터가 도메인에 존재해야 하는 것이다.

 

    도메인 명명 작업 마스터 (Domain Naming Master) : 도메인의 이름을 관리하는 역할을 하는 서버이다. Secure.pe.kr이라는 루트 도메인이 있을 때 하부에 jeju.secure.pe.kr 이라는 자식도메인이 생성되려면 이 도메인 명명 작업 마스터의 도움을 받아야 한다. 이 역할을 만일 싱글 마스터로 처리하지 않는다면 같은 이름을 가진 자식도메인이 생기는등 문제의 발생소지가 있다. 이것이 제대로 동작하지 않으면 포리스트에 새로운 도메인을 추가하는 작업이 진행되지 않는다. 도메인 명명 작업마스터는 글로벌 카탈로그 서버와 같은 서버에서 실행되어야 한다.

 

    스키마 마스터 (Schema Master) : 스키마는 Active Directory의 모든 개체들의 속성을 정의한 데이터베이스이다. 이것도 특별히 스키마 마스터라는 작업 마스터를 통해서만 작업이 이루어지도록 되어 있다.

 

    RID 마스터 (RID Master) : Active Directory에서 생성되는 모든 개체에는 SID(Security Identify)가 할당되는데 이 SID는 도메인SID RID(Relative Identify)가 플러스되어 생성된다. SID를 통해서 모든 보안의 평가작업이 이루어지기 때문에 이것은 이름 그대로 보안식별자로써 동작할 수 있어야 하는데, 만일 서로 다른 개체가 같은 SID를 부여받게 된다면 정상적인 동작을 할 수 없게 된다. 그렇기 때문에 Active Directory의 모든 개체들은 고유한 SID를 사용해야 한다. 이것을 RID마스터가 해결해 주고 있다.

 

예를 들어 Forever라는 이름의 도메인에 A B라는 도메인 컨트롤러가 있다고 하자. 이 때  A B는 각각 사용자 계정을 만드는 것이 가능하다.  Forever의 도메인SID 123이라고 가정하면 A는 새로운 사용자를 만들 때 도메인SID 123에 사용자에게 부여할 고유ID RID를 덧붙여서 SID를 할당한다. 만일 B가 사용하는 RID A가 사용하는 RID가 동일한 범위였다면 당연히 한 도메인내에서 같은 SID를 가지는 서로 다른 개체들이 생길 수 있다. RID마스터는 RID(Pool)을 유지하며 도메인 컨트롤러들에게 RID를 할당하는 작업을 한다. SID의 유일성을 보장해 주는 기능을 하는 것이다. Support tool에서 제공하는 dcdiag 툴을 사용하면 도메인 컨트롤러의 RID풀을 확인할 수 있다.

 

    PDC 에뮬레이터 (PDC Emulator) : 이름에서 느껴지는 것처럼 NT4.0 PDC처럼 동작하겠다는 것인데, 이것은 여러가지 작업을 맡아서 처리하고 있다. 먼저, NT4.0 도메인 컨트롤러, BDC들과 혼합된 혼합모드 환경의 도메인에서 PDC에뮬레이터는 BDC들에게 있어서 PDC와 같은 존재가 된다. 또한 Windows 2000 이전버전의 OS를 사용하는 사용자계정의 암호가 변경되었을 때 변경사항을 관리하기도 하며, 도메인에서 타임서버로 동작하여 SNTP(Simple Network Time Protocol)을 이용하여 도메인의 모든 멤버들에게 시간동기화를 처리한다. 도메인의 그룹정책이 저장되는 기본위치도 역시 PDC에뮬레이터이다. Windows 2000 이전버전의 OS를 쓰는 사용자계정에 대한 암호변경작업이 되지 않는다면 PDC에뮬레이터의 작동을 의심해 볼 필요가 있다.

 

    인프라 마스터 (Infrastructure Master) :  복수도메인 환경에서 A도메인의 글로벌 그룹이 B도메인의 로컬 그룹에 포함되었다거나 하는 형태로 서로 다른 도메인간에 그룹멤버쉽이 구성되었을 때, 다른 도메인에 있는 개체들의 일부 복제 데이터를 인프라 마스터가 유지하는 일을 한다. 인프라 마스터는 가능하면 글로벌 카탈로그 서버에 배치하지 않도록 한다. 글로벌 카탈로그 서버에는 이미 포리스트의 모든 도메인의 전체 개체에 대한 부분 복제 데이터가 저장되어 있기 때문에 인프라 마스터는 자신이 가지고 있지 않은 개체에 대한 업데이트의 필요성이 없어서 어떠한 업데이트도 하지 않기 때문이다. 싱글도메인 환경 및 모든 도메인 컨트롤러가 글로벌 카탈로그 서버역할을 하는 경우라면 인프라 마스터를 어디에 두어도 상관없다.

 

현재 도메인에서 작업 마스터 역할을 맡고 있는 서버가 누구인지를 들여다 보자. 이 인터페이스를 통해서 작업마스터 역할을 다른 서버에게 넘기는 작업도 가능하다. 기본적으로 도메인의 첫번째 도메인 컨트롤러가 작업마스터 역할을 맡고 있다고 했다. 이러한 작업마스터로 동작하는 서버를 네트워크에서 제거해야 할때는 먼저 작업마스터 역할을 다른 서버에게 전송해 주어야 한다. 전송작업을 하려면 역할을 전송받을 서버에서 진행되어야 한다. 꼭 물리적으로 해당 서버에 앉아서 해야 한다는 것이 아니다. 각각의 관리콘솔을 열고 해당 서버에 연결한 후 작업을 마치면 될 것이다. 아래의 내용을 살펴보자. 


<그림13-71. FSMO 서버확인 방법>

Active Directory 사용자 및 컴퓨터 관리콘솔을 열고 왼쪽패널에서 도메인이름을 마우스 오른쪽 클릭한 다음 작업 마스터를 선택한다.


<그림13-72. 작업마스터 확인 – RID, PDC, 하부구조>

RID, PDC, 인프라 탭이 보인다. 이 세가지가 도메인마다 필요한 작업마스터 역할들이다. 현재 작업마스터가 누구인지 보여준다. [변경]버튼을 이용하여 다른 컴퓨터로 작업마스터 역할을 전송해 줄 수 있다. 이 작업을 하기 위해서는 역할을 전송받을 서버에서 관리콘솔을 열어야 한다.


<그림13-73. FSMO확인 – Domain Naming Master 확인>

다음엔 Active Directory 도메인 및 트러스트 관리콘솔을 열고, 맨위의 메뉴에서 마우스 오른쪽 클릭하여 작업 마스터를 선택한다.


<그림13-74. FSMO확인 – Domain Naming Master 변경>

도메인 명명 작업 마스터(Domain Naming Master)가 누구인지를 보여준다. 역시 [변경

]을 이용하여 역할을 전송할 수 있다.


<그림13-75. 스키마 관리 스냅인 등록방법>

마지막으로 스키마 마스터 역할을 확인하는데 이를 위한 관리콘솔은 기본적으로는 비활성화되어 있다. 스키마 관리 스냅인을 등록하는 작업을 먼저 한다. 시작-실행창에서 “regsvr32 schmmgmt.dll”을 입력하고 실행하였다.


<그림13-76. 스키마 관리 스냅인 등록 >

Schmmgmt.dll 이 성공적으로 등록되었다는 메시지를 보여준다.


<그림13-77. FSMO확인 – Schema Master 1>

시작à실행 창에서 mmc 를 실행하였다.


<그림13-78. FSMO확인 – Schema Master 2>

스키마 스냅인을 추가하기 위해 스냅인 추가/제거를 클릭했다.


<그림13-79. FSMO확인 – Schema Master 3>

이제 ‘Active Directory 스키마라는 스냅인이 등록된 화면을 보여준다. 마우스 오른쪽 클릭하여 작업 마스터를 선택한다.


<그림13-80. FSMO확인 – Schema Master변경>

현재 스키마 마스터가 bluead.secure.pe.kr 이라는 정보를 보여준다.

 

단일 도메인 환경에서 도메인 컨트롤러가 두 대라면 작업마스터는 어떻게 배치하는 것이 좋을까? 기본설치만 하게 되면 모든 작업 마스터 역할을 처음 설치된 도메인 컨트롤러가 하게 된다. 그래도 두어도 특별한 문제는 발생하지 않지만 분산시키고자 한다면 다음과 같이 배치하는 것이 좋겠다. 앞서 설명한 바와 같이 인프라 마스터는 동작하지 않으므로 어디에 배치해도 상관없다.

 

-          DC1 : 글로벌 카달로그, RID마스터, PDC 에뮬레이터

-          DC2 : 글로벌 카달로그, 도메인 네이밍 마스터, 스키마마스터

 

초기 설치시 위와 같이 구성하려 하거나 관리자가 의도하여 도메인의 작업마스터 역할을 하는 서버를 재설치해야 하는 경우에는 위의 FSMO변경방법을 사용하여 변경이 가능하지만, 불의의 사고로 첫번째 도메인 컨트롤러가 사라져 버렸을 때는 위의 방법을 사용할 수 없다. 그때는 ntdsutil이 유용하다. 아래의 사용법을 참고한다. (명령프롬프트에서 작업한 결과이며, 굵은 글씨체가 필자가 입력한 명령들이다.) 


C:\>ntdsutil

ntdsutil: roles

fsmo maintenance: connections

server connections: connect to server blueapple.windowsnetwork.msft

blueapple.windowsnetwork.msft에 바인딩 중...

로컬에서 로그온된 사용자의 자격 증명을 사용하여 blueapple.windowsnetwork.msft에 연결되

었습니다.

server connections: quit

fsmo maintenance: seize pdc

점유하기 전에 PDC FSMO을 안전하게 전송하도록 시도합니다.


<그림13-81. NTDSUTIL - Seize 확인메시지>

 FSMO을 전송했습니다. 점유할 필요가 없습니다.

"blueapple.windowsnetwork.msft" 서버에서 5 역할이 검색되었습니다.

스키마 - CN=NTDS Settings,CN=GOGUMA,CN=Servers,CN=Default-First-Site-Name,CN=Sit

es,CN=Configuration,DC=windowsnetwork,DC=msft

도메인 - CN=NTDS Settings,CN=GOGUMA,CN=Servers,CN=Default-First-Site-Name,CN=Sit

es,CN=Configuration,DC=windowsnetwork,DC=msft

PDC - CN=NTDS Settings,CN=BLUEAPPLE,CN=Servers,CN=Default-First-Site-Name,CN=Sit

es,CN=Configuration,DC=windowsnetwork,DC=msft

RID - CN=NTDS Settings,CN=GOGUMA,CN=Servers,CN=Default-First-Site-Name,CN=Sites,

CN=Configuration,DC=windowsnetwork,DC=msft

하부 구조 - CN=NTDS Settings,CN=GOGUMA,CN=Servers,CN=Default-First-Site-Name,CN=

Sites,CN=Configuration,DC=windowsnetwork,DC=msft

fsmo maintenance: ?

  ?                             - 이 도움말 정보를 인쇄합니다.

 Connections                   - 특정 도메인 컨트롤러에 연결합니다.

 Help                          - 이 도움말 정보를 인쇄합니다.

 Quit                          - 이전 메뉴로 되돌아갑니다.

 Seize domain naming master    - 연결된 서버의 도메인 역할을 덮어씁니다.

 Seize infrastructure master   - 연결된 서버의 하부 구조 역할을 덮어씁니다.

 Seize PDC                     - 연결된 서버의 PDC 역할을 덮어씁니다.

 Seize RID master              - 연결된 서버의 RID 역할을 덮어씁니다.

 Seize schema master           - 연결된 서버의 스키마 역할을 덮어씁니다.

 Select operation target       - 사이트, 서버, 도메인, 역할 및 명명 컨텍스트를

선택합니다.

 Transfer domain naming master - 연결된 서버를 도메인 이름 마스터로 만듭니다.

 Transfer infrastructure master - 연결된 서버를 하부 구조 마스터로 만듭니다.

 Transfer PDC                  - 연결된 서버를 PDC로 만듭니다.

 Transfer RID master           - 연결된 서버를 RID 마스터로 만듭니다.

 Transfer schema master        - 연결된 서버를 스키마 마스터로 만듭니다.

 


:
Posted by 새벽예찬

글로벌 카탈로그 서버에 대한 설명은 앞에서 한 바 있다. 글로벌 카탈로그 서버를 확인하기 위해서는 Active Directory 사이트 및 서비스 관리콘솔을 이용한다. 네트워크에 있는 서버중의 하나에게 글로벌 카탈로그 서비스를 설정하고자 한다. <그림13-69>에서는 관리콘솔을 열고 Sitesà‘Default-First-Site-NameàServersàBlueappleàNTDS Settings'의 등록정보를 열었다.


<그림13-69. Active Directory 사이트 및 서비스 관리콘솔>

 


<그림13-70. 글로벌 카탈로그 서버 설정>

 

글로벌 카탈로그(G) 라는 체크박스에 체크를 해 주면 이 서버는 글로벌 카탈로그 서버로 동작하게 된다.

:
Posted by 새벽예찬
2008. 11. 23. 01:36

13-4-3. AD관리-사이트(Sites) Windows Networking2008. 11. 23. 01:36

사이트를 관리하기 위해서는 관리도구의 "Active Directory 사이트 및 서비스"를 이용한다. 기본적으로 Forest환경의 모든 도메인 컨트롤러들은 Default-First-Site-Name 이라는 기본사이트에 소속이 된다. 기본적으로는 아무리 도메인 컨트롤러의 수가 많고 이들 도메인 컨트롤러가 지역적으로 각각 배치되어 있다고 하더라도 하나의 사이트에 묶여 있다. 예제에서는 서울과 부산이라는 두 개의 지역으로 나뉜 회사 환경에서 사이트를 생성하는 방법을 다루도록 한다. 이 회사에서는 서울과 부산 2군데의 지역으로 사용자가 배포되어 있고 각 지역에는 별도의 서버센터가 운영되고 있어서 각각 도메인 컨트롤러 1대씩을 지역에 배치했다고 가정한다.


<그림13-61. 새 사이트 만들기>

관리콘솔의 Sites를 클릭하고 "새 사이트"를 선택한다.

 


<그림13-62. 사이트 이름 지정 및 사이트 링크 지정>

이름항목에는 "Busan"이라고 입력하였다. 사이트와 사이트를 연결하기 위한 기본 사이트 링크인 "DEFAULTIPSITELINK"를 선택하고 [확인>을 누른다.


<그림13-63. 알림 메시지>

[확인>을 누르니 앞으로의 절차에 대해서 설명을 해 주는 메시지가 팝업된다. 읽어보자.


<그림13-64. 새로운 서브넷 만들기>

Subnets에 마우스를 두고 "새 서브넷"을 클릭한다. IP Subnet을 생성해 주기 위한 과정이다.


<그림13-65.서브넷 추가>

실제 물리적인 네트워크의 구조를 반영하여 네트워크 ID를 이용하여 서브넷을 추가한다.


<그림13-66.서브넷이 추가된 것을 보여주는 콘솔>

예제에서는 BUSAN사이트가 192.168.101.0192.168.100.0, 192.168.102.0 이라는 3개의 네트워크 ID, 기본사이트가 1개의 네트워크ID를 사용하고 있는 것을 보여준다.

 


<그림13-67. 서버의 이동>

사이트를 설정했으면 기본 사이트에 있는 서버중에서 부산에 있는 서버를 찾아서 "이동"시켜 준다.

 


<그림13-68. 서버를 이동할 사이트 선택 그림>

GOGUMA라는 이름의 서버를 Busan사이트로 이동시키고 있다.

:
Posted by 새벽예찬
2008. 11. 23. 01:32

13-4-2. AD관리-권한 위임 Windows Networking2008. 11. 23. 01:32

Active Directory의 권한위임 기능은 관리작업에 대한 효율성을 극대화 시킬 수 있는 방법이다. 앞에서 OU의 용도에 대해서 언급한 바 있다. 이 하나의 단위 덕분에 NT4.0에서 여러 개의 도메인으로 어쩔수 없이 구성해야만 했던 많은 상황들이 Active Directory에서는 하나의 도메인으로 통합을 할 수도 있는 환경을 제공하게 되었다.

 

상황은 다음과 같다. Windowsnetwork.msft은 미국, 일본 등지에 지사를 가지고 있는데, 미국지사에 인사권이 별도로 있어서 직원의 인사가 직접 이루어지고 있다. 서울의 본사에서는 미국에서 근무하는 사용자들에 대한 계정관리를 미국에 있는 담당자 하나를 임명해서 맡기고자 한다. 새로운 직원이 들어오면 계정을 만들어 주고, 직원이 퇴사하면 계정을 삭제하고, 사용자들이 몇 차례 패스워드를 잘못 입력하여 잠긴 계정을 풀어주는 등의 계정관리를 미국지사에서 처리하도록 하고자 하는 것이다. 이와 같은 작업을 처리하기 위해서 NT4.0때는 미국지사를 위한 별도의 도메인을 생성해야만 했다. 계정관리를 할 수 있도록 미국지사의 사용자 하나를 ‘Account operators’ 그룹의 멤버로 포함시켜 주면 미국의 계정관리를 하게 할 수는 있었지만, 문제는 이 사용자가 관리자가 원하지 않는 일본지사나 본사의 계정까지도 관리가 가능해 지기 때문에 제한적인 권한을 부여하는 것이 불가능했기 때문이다. 계층적인 관리구조가 제공되지 못했기 때문이었다.

 

권한위임의 방법은 이와 같은 경우에 최상의 솔루션이 될 수 있다. 다음과 같은 절차를 거쳐서 접근할 수 있다. <그림13-55>을 보면 전체조직이라는 OU가 있고 하위에는 미국’OU를 포함한 몇 개의 지사별로 구분해 놓은 OU들이 있다. 미국OU를 열어보니 몇 개의 그룹과 사용자계정이 보인다. 예제의 상황에서는 미국OU에 있는 수용이라는 사용자에게 미국지사에 대한 사용자 계정관리를 위임하고자 한다.


<그림13-55. 권한 위임 구성 1>

ADUC관리콘솔을 통해 관리를 위임하고자 하는 곳을 클릭한다.

 


<그림13-56. 권한 위임 구성 2>

미국’OU를 마우스 오른쪽 클릭하여 제어위임메뉴를 선택한다.


<그림13-57. 권한 위임 구성 3>

사용자 또는 그룹화면에서 [추가]버튼을 눌러서 관리를 위임받을 사용자 또는 그룹을 찾아서 추가한다.

 

다음의 위임할 작업화면에서는 다음 일반 작업을 위임위임할 사용자 정의 작업 만들기의 두개의 라디오 버튼을 볼 수 있다. 기본선택된 위의 버튼은 이미 정의된 많이 사용할 만한 관리작업들이 나열되어 있다.


<그림13-58. 권한 위임 구성 4>

위의 작업만으로 만족할만한 관리의 위임을 시키지 못할 경우, 예를 들면 사용자 계정을 생성할 수 있게 하고 싶지만 삭제는 하지 못하게 하기를 원한다거나 하는 경우는 아래의 위임할 사용자 정의 작업 만들기를 클릭하고 [다음]으로 진행하여 직접 보다 제한적인 작업을 결정해 줄 수도 있다. 예제에서는 기본설정을 두고 [다음]버튼을 눌렀다.


<그림13-59. 권한 위임 구성 5>

제어 위임 마법사가 완료되었음을 보여주는 화면이다. 내용을 잘 살펴보면 정보를 잘 요약해 주고 있다.

 

 

위와 같이 권한 위임을 마친다음 테스트를 해 보았다. 권한을 위임받은 김수용이라는 사용자로 로그온을 해서 Active Directory 사용자 및 컴퓨터 관리콘솔을 열어서 미국’ OU를 클릭하고 새로만들기를 누르니 사용자를 생성할 수 있는 메뉴가 나타난다. 위에서 관리자로 로그온했을 때 모든 개체를 생성할 수 있었던 것과 비교해 보라.


<그림13-60. 권한 위임 구성 6>


:
Posted by 새벽예찬