Escape From The Troubles

시스템 부팅 과정에 Activity를 보기 위한 Boot logging

2009-11-09T20:40:34Z

실시간 파일 시스템 동작, 레지스트리, Process 나 Thread 들의 동작 등을 모니터링 하는데 사용하는 Process Monitor 툴 (기존 File monitor, Registry monitor, Process monitor 의 기능이 합쳐진 툴) 은 잘 알고 계실 것입니다. 가끔, 이 프로그램을 실행할 수 없는 부팅 과정에서 부팅이 완료된 시점 또는 그 이후 특정 시점까지의 Activity들에 대한 동작을 보기 위해서는 어떻게 할까요? 바로 이 툴 안에 해당 기능이 포함되어 있습니다.

사용 시나리오: Boot 과정에 성능 이슈가 발생할 경우 로그 수집

1. Process Monitor 툴 실행 후 Options – Enable Boot Logging 을 선택합니다.

2. Enable Boot Logging 을 선택하면 다음 부팅 동안 로그가 수집됨을 알리는 창이 표시됩니다.

3. 시스템이 재 시작되면 이 과정에는 Process Monitor 툴에 의한 로그가 수행되고 있습니다.

4. 부팅 이후 수집된 로그를 확인/저장하기 위해 Process Monitor 툴을 다시 실행합니다. 이 때, 아래와 같은 메시지 창이 뜹니다. “예”를 눌러 저장합니다.

저장 형식은 .PML 이며, Process Monitor 툴에서 로그를 확인합니다.

Windows Server 2008 core 도메인 컨트롤러 강제로 내리기

2009-11-06T05:42:00Z

원문주소 : Forced Demotion of a Windows Server 2008 Core Domain Controller

http://blogs.technet.com/askds/archive/2008/11/14/forced-demotion-of-a-windows-server-2008-core-domain-controller.aspx

네드(Ned)입니다. 오늘의 글은 짧지만 유용합니다. 이 글이 필요한 상황에서 빠르게 작업할 수 있습니다. 관련된 내용은 TechNet에 아직 없습니다(작성중입니다).

Windows 2000 SP4 이후에, DCPROMO /FORCEREMOVAL 명령어를 사용하여 도메인 컨트롤러를 내리는 것이 가능해졌습니다. 다음과 같은 경우에 이 스위치를 사용할 수 있었습니다.

l 중간의 자식 도메인에 있는 가장 마지막 도메인 컨트롤러를 내릴 때 부모 도메인에 현재 가용한 도메인 컨트롤러가 없을 경우

l 세부적인 트러블슈팅을 진행한 이후에 이름 해석, 인증, 복제 엔진, 또는 해석할 수 없는 Active Directory 객체 의존성이 있기 때문에 Active Directory 설치 마법사를 완료할 수 없는 경우

l 도메인 컨트롤러가 하나 또는 그 이상의 네이밍 컨텍스트를 위한 날짜의 Tombstone Lifetime 번호(기본 60일) 에서 들어오는 Active Directory 변경을 복제하지 못했을 경우(KB216993)

l 도메인 컨트롤러 서비스를 즉시 시작해야 하기 때문에 더 이상 자세한 문제해결이 어려울 경우

자연스럽게 항상 다른 DC들에서 Metadata Cleanup을 수행하게 됩니다.

하지만, 코어 모드(GUI없음)에서 동작하는 Windows Server 2008 DC에서 이 명령어를 수행하려고 하면, 다음과 결과를 반환할 것입니다.

Answer file이나 무인 설치 명령줄 매개변수는 반드시 기술해야 합니다.

Answer file을 제공했더라도, 도메인을 내리는 것을 확인하는 여러가지 프롬프트와 공지가 나타납니다.

그렇다면 어떻게 이 작업을 할 수 있을까요? 다음 명령어를 사용하면 됩니다.

dcpromo /forceremoval /demotefsmo:yes /administratorpassword:<the new password>

예제 :

dcpromo /forceremoval /demotefsmo:yes /administratorpassword:Password1

다음과 같은 질문들이 있었습니다 "하지만 이 서버는 FSMO 역할을 가지고 있지 않습니다. 왜 제가 스위치를 추가해야 하나요? 그 이유는 내리는 것을 강요할 때 FSMO 역할을 함께 주면, FSMO 경고 프롬프트를 막을 수 있기 때문입니다.

이 글에 대해 강력한 제목을 붙이려고 했지만, 실제로 이것이 필요한 대부분의 독자는 굉장히 바빠서 그것을 원하지 않는 것을 알았습니다.

- Ned Pyle

기본 도메인 정책에서 보안 설정이 기록되는 것이 실패

2009-10-29T04:41:00Z

원문주소 : Fail to log Security Settings from Default Domain Policy

http://blogs.technet.com/askds/archive/2008/09/22/fail-to-log-security-settings-from-default-domain-policy.aspx

안녕하세요? 여러분. 스캇(Scott Goad)입니다. 오늘은 기본 도메인 정책에서 보안 설정을 기록하는 것을 실패한 최근 사례에 대해 이야기를 잠시 나눠볼까 합니다. 이 경우에, 2대의 도메인 컨트롤러를 가지고 있는 작은 환경이었고, 모두 FSMO 역할을 가지고 있었으며, 다른 하나는 복제대상 도메인 컨트롤러였습니다.

이슈는 내부 감사를 하는 동안 알려졌고, 고객은 특정 보안 설정이 GPRESULT /v를 실행할때 기록되지 않는 것을 알게되었습니다. 여기서 GPRESULT /v는 특정 사용자와 컴퓨터에 대한 세부적인 정책 결과를 표시합니다. 이슈를 해결하기 위하여 자료를 충분히 수집했는데, 일부 아이템은 기본 도메인 정책에서 생략되었고, 오류는 기록되지 않았습니다

도메인 컨트롤러를 멤버서버로 내리고나서, 정책이 적용되고 정확히 리포트되었습니다.

다음은 각 도메인 컨트롤러의 일부입니다.

...DC1의 GPRESULT 중 일부(FSMO 아님)...

Account Policies

----------------

GPO: Default Domain Policy

Policy: MaxServiceAge

Computer Setting: 600

GPO: Default Domain Policy

Policy: MaxTicketAge

Computer Setting: 10

GPO: Default Domain Policy

Policy: MaxClockSkew

Computer Setting: 5

GPO: Default Domain Policy

Policy: MaxRenewAge

Computer Setting: 7

...DC2의 GPRESULT 중 일부(FSMO임)...

Account Policies

----------------

GPO: Default Domain Policy

Policy: MaxServiceAge

Computer Setting: 600

GPO: Default Domain Policy

Policy: MaxTicketAge

Computer Setting: 10

GPO: Default Domain Policy

Policy: MinimumPasswordAge

Computer Setting: 1

GPO: Default Domain Policy

Policy: PasswordHistorySize

Computer Setting: 6

GPO: Default Domain Policy

Policy: LockoutDuration

Computer Setting: 4294967295

GPO: Default Domain Policy

Policy: ResetLockoutCount

Computer Setting: 30

GPO: Default Domain Policy

Policy: MaxClockSkew

Computer Setting: 5

GPO: Default Domain Policy

Policy: MinimumPasswordLength

Computer Setting: 8

GPO: Default Domain Policy

Policy: LockoutBadCount

Computer Setting: 3

GPO: Default Domain Policy

Policy: MaximumPasswordAge

Computer Setting: 90

GPO: Default Domain Policy

Policy: MaxRenewAge

Computer Setting: 7

또한, 두대의 도메인 컨트롤러에서, 이벤트 ID 1704가 기록되었습니다.

여기서, 기본 도메인 정책을 살펴봤는데, 설정은 다음과 같습니다.

이슈를 조사한 이후에, 로컬 보안 정책을 살펴보고, 실제로 무엇이 적용되었는지 보았습니다. 다음은 GPRESULT에서 나타난 실패한 부분입니다.

이 화면은 정책에 변경을 준 후에 다른 서버에서 찍은 것입니다. 여기에서, 설정이 적용된 것을 알았지만, 어디에도 기록되지 않았습니다. 그래서 GES(Global Escalation Services) 팀에 살펴보도록 요청했습니다. PDC 에뮬레이터를 다른 DC에 옮겼는지 확인을 요청했고, 변경을 발견했습니다. 그렇습니다! GPRESULT의 이 정책 설정은 PDC 에뮬레이터 역할을 따라갑니다.

GES는 코드를 리뷰하고 이것은 설계된 동작이라고 했습니다. PDC 에뮬레이터에서, 멤버 서버와 도메인에 조인된 워크스테이션은 그룹정책을 통해 이 정책을 적용합니다. 도메인의 복제대상 도메인 컨트롤러는 도메인 네임 컨텍스트 앞부분에 있는 것을 모니터링하여 이 설정을 적용합니다. 이 설정은 포레스트의 각 도메인의 도메인 컨트롤러간에 Active Directory 복제를 통해 복제됩니다. 이 설정은 도메인 컨트롤러가 살펴서 동작방식을 제어하는 것을 도와줍니다. 이 설정이 변경되면, DC는 즉시 알게되고 새로운 동작을 시작합니다.

다음은 속성의 전체 리스트입니다.

l minPwdAge

l pwdHistoryLength

l lockoutDuration

l lockOutObservationWindow

l minPwdLength

l lockoutThreshold

l maxPwdAge

l pwdProperties (this is complexity on/off)

이 설정은 아래와 같이 LDP로 볼 수 있습니다.

Expanding base 'DC=adatum,DC=com'...

Result <0>: (null)

Matched DNs:

Getting 1 entries:

>> Dn: DC=adatum,DC=com

3> objectClass: top; domain; domainDNS;

1> distinguishedName: DC=adatum,DC=com;

1> instanceType: 0x5 = ( DS_INSTANCETYPE_IS_NC_HEAD | IT_WRITE );

1> lockoutDuration: 1800;

1> lockOutObservationWindow: 1800;

1> lockoutThreshold: 0;

1> maxPwdAge: 3710851;

1> minPwdAge: 86400;

1> minPwdLength: 7;

1> modifiedCountAtLastProm: 0;

1> nextRid: 1006;

1> pwdProperties: 1;

1> pwdHistoryLength: 24;

다음에 뵙겠습니다.

- Scott “Scooter” Goad

Windows 오류 코드 확인 툴

2009-10-28T14:47:31Z

Windows 상의 오류 코드가 무엇을 의미하는가?

Header 없이도 해당 코드의 의미를 알 수 있도록 외부에 Freeware 툴로 제공된 것이 있어서 소개합니다.

http://www.easyfreeware.com/files/hr_plus.zip/14336

Hyper-V 의 Snapshot 기능

2009-10-27T13:52:10Z

Windows Server 2008 / 2008 R2 의 Hyper-V 에는 Snapshot 기능을 포함하고 있습니다.

Snapshot 은 어느 시점 상태로 되돌아 갈 수 있는 VM의 Point in time 이미지들을 말하는 것입니다. 이것은 현재의 VM 상태 (VHD)를 보존하는 상태에서 별도의 Differencing disk file인 .AVHD 파일을 생성하므로서, 현재 Snapshot 상태에서 Windows작업 중에 어떠한 문제가 있을지라도 이 작업을 무시하고 이전으로 되돌아 갈 수 있는 이전 VM 파일의 안전성을 보장합니다.

즉, 번거로운 프로그램을 테스트 작업을 자주 진행하는 개발자 또는 예기치 않은 문제를 야기시킬 수 있는 Hotfixes, Updates 설치 등을 담당하는 시스템 관리자들에게는 유용한 기능입니다.

Snapshot 은 Online 또는 Offline VM 의 Snapshots 을 생성할 수 있습니다. Online VMs 의 경우 Snapshots 은 VM의 Worker process 에 의해 처리되며, Offline VMs의 경우 Snapshot 은 VMMS 내의 Snapshot manager 에 의해 처리됩니다. Snapshot 이 만들어 질 때 아래의 과정이 수행됩니다.

1. 지정된 위치에 현재 .퐁 파일의 Differencing hard disk 이미지인 .avhd 파일이 생성됩니다.

2. 새로운 Snapshot configuration (<GUID.xml) 이 생성됩니다.

3. VM configuration을 Snapshot configuration 파일에 복사합니다.

4. Saved state file (<GUID>.vsv) 을 복사하고 이것을 Snapshot configuration 에 Attach 합니다.

5. 새로운 <GUID>.bin 파일을 생성하고, 메모리의 내용을 이 파일에 복사합니다.

그럼 Snapshot 을 만들어질 경우 VM 파일과 Snapshot 파일이 어떻게 생성되는지 보겠습니다.

Snapshot 이 없는 상태

Snapshot #1생성

Snapshot #2 생성

Snapshot #3 생성

VM의 .bin, .vsv 파일들은 변경되지 않고 있습니다.

VM Client 를 시스템 종료 후 10여분 후 다시 켰을 때는 마지막 AVHD 파일만 변경되고 있습니다.

Snapshot #1으로 이동

Snapshot #1삭제 (Snapshots 폴더 하위 11C6C089-… 가 제거됨)

“Delete Snapshot Subtree” 로 모두 삭제

BitLocker와 Active Directory

2009-10-26T01:52:00Z

원문주소 : BitLocker and Active Directory

http://blogs.technet.com/askds/archive/2009/08/18/bitlocker-and-active-directory.aspx

안녕하세요? 디지털 세상의 폴(Paul Fragale)입니다. 오늘은, BitLocker에 대한 정보와 Active Directory (AD)에 키를 저장하고 복구하는 방법을 공유하겠습니다. 실제로 AD에는 무엇이 만들어질까요? 드라이브를 암호화하고 복호화할 때 어떤 일이 발생할까요? 추가 드라이브는 무엇일까요? AD에 복구 정보를 복사하려고 그룹정책을 적용하기 전에 드라이브가 암호화되면 어떻게 할까요?

시작해보죠. 이 글에서는 Windows Vista와 2008에 초점을 맞추겠습니다. 그룹 정책은 클라이언트가 BitLocker 복구 정보를 Active Directory에 보내는 데 필요합니다. 이것을 설정하려면 Active Directory를 Windows BitLocker 드라이브 암호화에 백업하도록 구성하기와 TPM(Trusted Platform Module) 복구 정보를 살펴보세요. 기억할 점은, 드라이브가 암호화되기 전에 필요하다는 것입니다. 정책이 컴퓨터에 적용되기 전에 드라이브가 암호화되면, BitLocker 복구 정보가 AD에 업로드되지 않습니다. 유일한 해결방법은 복호화하고 정책이 적용된 이후 다시 암호화하는 것입니다.

그룹 정책이 한번 구성되면, 컴퓨터에서 암호화 프로세스를 수행할 수 있습니다. 복구 정보가 Active Directory에 저장되는 것을 보증하기를 원한다면, 수동으로 확인할 필요가 있습니다. Active Directory의 컴퓨터 객체 아래에서 자식 객체로 드라이브 암호화가 만들어집니다. BitLocker 복구 객체의 이름은 고정된 63글자로 GUID(globally unique identifier)와 날짜/시간 정보를 가지고 있습니다. BitLocker 복구 객체의 클래스는 ms-FVE-RecoveryInformation 입니다. 이 객체 내부에는 bitlocker 복구에 필요한 속성이 있습니다. 다음은 드라이브를 암호화하면 컴퓨터 객체 아래에서 볼 수 있는 내용입니다.

LDP를 사용하여 무엇이 포함되어 있는지 다음과 같이 볼 수 있습니다.

이 속성의 설명은 Active Directory에서 Windows BitLocker 드라이브 암호화에 백업하는 것을 구성하기와 TPM(Trusted Platform Module) 복구 정보에서 찾을 수 있습니다.

자 그럼, BitLocker를 구현한 후에 Active Directory에서 무엇을 봐야하는지 알 것입니다. 관리자 관점에서 논의를 해보죠. 드라이브를 암호화하면 어떻게 될까요? 무엇보다도, AD는 저장 컨테이너입니다. 이 정보를 업데이트하고, 검증하고, 관리하는 것을 수행할 기능은 하나도 없습니다. 이것은 완전히 BitLocker에 의해 다뤄집니다. BitLocke는 AD에 드라이브 암호화를 알려주지 않고 ms-FVE-RecoveryInformation 객체는 지워지지 않습니다. 사용자가 다시 드라이브를 암호화하면, Bitlocker는 AD에 새로운 정보를 동기화시킵니다. 따라서 같은 드라이브에 대한 두 개의 엔터티를 볼 수 있습니다. 더 나아가 시스템에 암호화된 각 드라이브의 새로운 엔트리를 볼 수 있습니다.

기억할 점은 다음과 같습니다.

1. 모든 암호화된 드라이브는 새로운 자식 객체를 만듭니다. 이것은 추가 드라이브를 포함합니다.

2. Active Directory에 복구 정보를 저장하는 그룹정책은 첫번째 드라이브가 암호화되기 전에 컴퓨터에 구성되고 적용되어야 합니다.

3. 드라이브를 복호화하면 Active Directory에 Bitlocker 복구 정보는 그대로 남게 됩니다. 업데이트되지 않습니다. 드라이브가 나중에 다시 암호화되면, 새로운 자식 객체가 생성됩니다. 현재의 ms-FVE-RecoveryInformation 객체는 삭제되거나 수정되지 않습니다.

4. Active Directory는 단지 Bitlocker 복구 정보를 저장하는 장소입니다. 모든 기능은 암호화된 드라이브가 있는 컴퓨터에 Bitlocker 응용 프로그램에 의해서 다뤄집니다.

이것이 전부입니다. 이것이 여러분의 Active Directory에 BitLocker를 구현할 때 필요한 일반적인 질문에 대한 답이 되기를 바랍니다.

다음에 뵙겠습니다.

Paul ‘Fragale

드라이브 및 폴더 이름 포함 파일 이름 전체 경로 길이 확인 툴

2009-10-22T14:59:06Z

내 컴퓨터에서 드라이브, 폴더를 포함한 파일 이름의 전체 길이를 알고 싶으신가요?

인터넷에 Path Scan 이란 툴이 있어서 소개합니다. 이 툴은 Scan 할 드라이브 경로, 전체 경로 Character 길이, 찾고자 하는 최소 Character 길이 등을 지정할 수 있고, 결과에 대해 Text 형식으로 저장하여 목록을 뽑아 볼 수도 있습니다.

다운로드: http://www.registrytweaker.net/files/pathscan.zip

느린 로그온이 발생하는 경우(Part 2)

2009-10-21T04:20:00Z

원문주소 : So you have a slow logon…? (Part 2)

http://blogs.technet.com/askds/archive/2009/09/24/so-you-have-a-slow-logon-part-2.aspx

밥 드레이커(Bob Drake)입니다. 느린 로그온 시리즈의 두번째 부분에 오신 것을 환영합니다. 이 부분에서는 느린 로그온 문제를 확인하는 것을 도와주는 몇 가지 간단한 문제해결 기술을 다루도록 하겠습니다.

어디에서 느린 현상이 발생하는지 구분하는 것은 어렵지 않습니다...

l 전원 버튼을 누르고 로그온 화면이 나타날 때까지 느린가?

l 로그온 화면까지 빠르고 데스크탑이 나타날 때까지 느린가?

l 모두 사용자이고, 관리자가 아닌가?

l 위의 사항 모두

문제해결을 위해서는 위의 질문에 답해야 합니다. 파워버튼을 누르고 로그온 화면에 도달하지 못하는 경우부터 시작하겠습니다(느린 부팅은 느린 로그온이 아닙니다). 만약 처음 부팅을 시작하고 로그온 화면에 도달하기 전에 느린 현상이 발생하면, 일반적으로 운영체제 자체에 문제가 있던지, 설치된 응용 프로그램에 있던지, 아니면 둘 모두에 있을 수 있습니다. KB 325376처럼 시작, 종료, 로그온, 로그오프시에 상태 메시지를 표시하는 것은 문제해결을 위해 좋은 방법입니다. 이렇게하면 부팅/로그온 프로세스 중에 자세한 정보를 받을 수 있습니다.

정책 위치(XP와 2003)

추가적인 메시지 표시(XP와 2003)

정책 위치(Windows 7, Windows 2008)

추가적인 메시지 보기(Windows 7, Windows 2008)

처음으로 확인해야 할 것은 "클린 부팅(Windows XP/2003)(Vista/2008/Win7)" 될 때 지연이 발생하는지 여부입니다. MSCONFIG를 통해 로딩될 때 선택적으로 모든 타사 서비스와 응용 프로그램을 중지할 수 있습니다. 머신에서 응용 프로그램이 필요해서 문제가 생길 수 있는데, 이 단계는 운영체제가 이슈가 되거나 운영체제에 설치된 응용 프로그램이 이슈가 되는 것을 알기 위해 필수적입니다. 다음에 방법이 있습니다.

1. 시작을 클릭하고 실행에서 "MSCONFIG"를 입력합니다.

2. "서비스" 탭을 선택하고 "Hide all Microsoft Services"를 체크하고 "Disable All"을 클릭합니다.

참고 : "Hide all Microsoft Services"를 클릭할 때 시스템에 설치된 응용 프로그램을 볼 수 있습니다. 때때로 머신에 더 많은 문제를 야기하는(드라이브 암호화 소프트웨어같은) 중요한 부팅/로그온 프로세스가 있습니다. 그런 응용 프로그램은 검토하고 중지할 필요가 있습니다.

"Startup" 탭을 선택하고 "Disable All"을 다시 한번 클릭합니다. 모든 타사의 응용 프로그램을 중지하는 것은 더 큰 이슈를 야기할 수 있는데, 시작시 F8을 누르고 "Last Known Good"이나 "Safe mode"를 통해 "msconfig"에서 변경사항을 되돌려 놓을 수 있습니다.

3. 타사 서비스가 중지되면 재부팅이 필요하다는 메시지가 표시되고 재부팅을 해야 합니다. 다른 창이 화면에서 나타나면, "OK"를 클릭하세요.

4. 부팅 시간이 같은지 아닌지 테스트합니다.

타사 서비스를 중지하면 컴퓨터가 부팅되고 로그온하는게 빠르거나 정상적입니까? 답이 '네'라면 지연을 만드는 소프트웨어를 찾은 것입니다. 어떤 것이 더 많이 걸리는지 찾으려면 빠른 방법은 서비스의 반을 시작하고(시작할 수 있는 서비스 목록을 확인하세요) 지연이 발생하는지 보는 것입니다. 그렇지 않으면, 남은 절반의 서비스를 시작해서 이슈가 반복될 때까지 시도합니다. 어떤 것이 문제인지 확인하면, 그 응용 프로그램이나 구성요소의 업데이트를 시도합니다. 만약 특정 응용 프로그램이 이슈가 된다고 생각되면 확인 차원에서 간단히 그것을 중지시키는 것이 빠른 접근 방법입니다. 원인을 밝혀내는 동안 재부팅을 여러번해야 합니다. 지연을 초래하는 응용 프로그램을 발견하면, 다시 시작해서 지연이 발생하는지 확인합니다. 문제가 되는 응용 프로그램을 확인하면 벤더를 부르고 문제가 발생한 이유를 확인한 다음 해결책을 얻습니다. 때때로 그런 충돌을 해결하는 업데이트나 핫픽스가 있습니다.

참고 : 일부 안티바이러스 응용 프로그램은 MSCONFIG에서 중지해도 그 서비스를 필터 수준 드라이버를 로드합니다. 느린 로그온의 원인이 되는 것이 안티바이러스라는 것을 발견하는 방법은 테스트하는 동안 제거하는 것입니다.

여전히 느리다면?

여전히 부팅이 느리다면 클라이언트의 DNS 구성을 살펴봅니다. 다른 하드웨어(스위치, 라우터같은) 사이에 있는 DNS 서버는 문제의 원인이 될 수 있습니다. 네트워크의 한 부분이 문제가 되고 다른 부분은 그렇지 않다면, 네트워크 이슈를 발견할 기회입니다. 네트워크와 DNS 형태의 이슈를 발견하는 좋은 방법은 NetMon같은 패킷 캡쳐 응용 프로그램을 사용하여 네트워크를 추적하는 것입니다. 어려운 점은 머신이 시작할 때 추적을 캡쳐하는 것입니다. 같은 허브나 스위치에 있는(포트 미러링) 다른 컴퓨터를 통해 모니터링 할 수 있습니다. 네트워크 캡쳐 유틸리티를 시작하고 다른 IP 주소를 필터링합니다.

이 추적에서 볼 수 있는 것은 다음과 같습니다.

l 올바른 DNS 응답(쿼리한 쿼리 응답인가?)

l 지연되거나 응답하지 않는 응답(DNS 서버에서 도메인 컨트롤러까지 모두)

l Kerberos 실패

l SMB 실패

l 다양한 TCP 리셋이나 재전송

l 이슈가 발생하는 특정 도메인 컨트롤러의 일치(도메인 컨트롤러 자체에서 발생하는 가능한 이슈)

네트워크에 관련된 이슈가 있다면 특이점을 봐야합니다.

만약 위의 방법으로 모든 타사 소프트웨어를 중지하고도 부팅 지연이 발생하면, 다음 단계는 머신에 어떤 정책이 적용되는지 확인하는 것입니다. 그룹 정책의 문제를 해결하는 좋은 시작점은 기술 문서입니다.

대부분의 환경에서 다양한 정책이 적용되는데, 이슈가 되는 것을 어떻게 찾아낼까요? 가장 빠른 방법은 Active Directory 사용자 및 컴퓨터 스냅인에서 "TEST" OU를 새로 만들고 OU에 정책 상속을 막는 것입니다. 그렇게 하고, 문제가 되는 컴퓨터를 그 OU에 옮깁니다. 어떤 정책도 "enforced" 또는 "no override" 되지 않게 합니다. 그러한 설정을 가진 정책이 있으면, 상속이 차단된 OU에 여전히 적용됩니다.

컴퓨터를 옮기기 전에 다음 명령어를 통해 어떤 그룹 정책 객체가 링크되었는지 확인해야 한다.

"gp.txt"를 열 때 다음과 같은 정책을 볼 수 있습니다.

머신에 적용되는 "Default Domain Policy"와 "Local Group Policy"를 봐야합니다.

적용된 정책이 확인되면 새로 만든 테스트 OU에 옮기면 됩니다. OU를 만드는 단계와 상속을 막는 단계는 다음과 같습니다.

1. "Test" OU를 만들고 컴퓨터를 그곳으로 옮깁니다.

2. 그룹 정책 관리 콘솔을 열고 TEST OU에 상속을 차단합니다.

참고 : 상속을 차단하면 OU 아이콘이 파란색 느낌표로 바뀝니다.

3. 상속을 차단하고 컴퓨터를 테스트 OU로 옮기고, 이전 정책을 없애기 위해 컴퓨터를 두 번정도 재부팅합니다.

강제하지 않으면 모든 정책이 제거될 때까지 시간이 걸립니다. 적어도 이 시간에 정책의 일부가 남아있게 됩니다. 테스트를 다시 해야합니다...

컴퓨터가 빠르게 부팅되면 지연의 원인이 되는 것이 그룹정책입니다(또는 그룹정책의 조합입니다)어떤 정책이 문제를 야기하는지 찾으려면 한번에 하나씩 링크를 하고 지연이 발생하는지 재부팅을 해야합니다. 이것은 그림처럼 "Link an Existing GPO"를 선택하여 할 수 있습니다. 감사를 통해 정책을 확인하면, 어떤 정책이 지연의 원인이 되는지 알 수 있습니다.

그래도 느리다면...!?!

위의 단계를 다 진행하고 모든 소프트웨어나 정책을 중지해도 부팅이 느려진 원인을 찾을 수 없다면 다음 단계는 디버그 로깅입니다. 사용하는 시스템에 따라 로깅을 시작하는 방법이 조금 다릅니다.

2000, XP, 2003에서는 다음 문서를 통해 로깅을 시작할 수 있습니다. "How to enable user environment debug logging in retail builds of Windows" http://support.microsoft.com/default.aspx/kb/221833. 운좋게도 제 동료 중에 한 명이 이미 결과물을 해석하는 블로그를 썼습니다(두 부분에서 찾을 수 있습니다. 1절과 2절) Vista, 2008 그리고 Windows 7에서는 마이크로소프트는 "Event Tracing"이라고 불리는 것으로 디버그 로깅 포맷을 변경했습니다. 기본적으로 결과 데이터는 KB문서의 결과물과 같지만 2진 출력물에서 변환된 것입니다. 소스 코드를 포함하고 있기 때문에 변환하는데 마이크로소프트의 도움이 필요할 것입니다(프로필없이 정책 부분을 보려면 gpsvcdebug 로깅을 사용하세요).

다른 훌륭한 도구는 "Autoruns"입니다. 이 유틸리티는 시스템이 시작하거나 로그인되는 동안 실행되도록 구성하는 프로그램을 보여줍니다. 이 도구의 가장 훌륭한 기능 중 하나는 "Hide Microsoft Entries"입니다.

또한 사용자별로 autoruns을 선택할 수 있도록 합니다.

Autoruns는 다른 응용 프로그램에서는 일반적으로 볼 수 없는 아이템을 찾을 것입니다.

정리하면, 대부분의 경우의 경우에 느린 부팅이나 느린 로그온은 응용 프로그램 충돌이나 그룹정책의 제약 또는 구성 이슈로 발생합니다. 위의 문제해결방법과 약간의 노력으로 느린 로그온 문제가 발생하는 곳과 원인을 찾아서 최소의 시간으로 해결할 수 있을 것입니다.

- Bob ‘Quasi-Manager’ Drake

느린 로그온이 발생하는 경우(Part 1)

2009-10-16T05:57:00Z

원문주소 : So you have a slow logon…? (Part 1)

http://blogs.technet.com/askds/archive/2009/09/23/so-you-have-a-slow-logon-part-1.aspx

안녕하세요? 밥 드레이크(Bob Drake)입니다. 오늘은 느린 로그온 문제를 해결하는 처방과 소중한 시간을 절약할 수 있는 두 개의 글을 올리도록 하겠습니다. 여러가지 느린 로그온 사례를 경험했었지만, 대부분의 경우 매우 다루기 힘들었습니다. 접근방법과 가지고 있는 정보에 따라 달라집니다. 느린 로그온이 발생하는 원인은 다양한 이유가 있는데, 가끔은 다양한 이유가 하나로 표시되기도 합니다.

첫번째 글에서는 느린 로그온에 대한 잘 알려진 사례를 다루겠습니다. 여러분의 환경에 최적화된 로그온 상태와 느린 로그온 이슈가 있을 때 기준점을 문서화할 수 있도록 도와드리겠습니다.

"로그온 프로세스"(이 용어는 워크스테이션을 부팅하고 데스크탑을 사용하기 위해 사용자 로그온을 마친 상태로 사용합니다)는 많은 부분으로 구성되어 있습니다. 가장 중요한 질문은 "감내할 수 있는 로그온 시간이 어느 정도인지 입니다" 컴퓨터를 켜고 데스크탑을 사용할 수 있을 때까지 3~5분만이 소요되기를 바란다면, 모든 작업을 수행하는 간단한 창을 볼 것입니다. 비즈니스 요구사항에 따라 로그온 동안 무엇을 수행해야 하는지 문서화하는 것이 필요하고 다음으로 넘어가기 전에 필요한 목표를 이해해야 합니다.

로그온 작업 리스트를 만들면, 로그온 시간 프레임을 테스트할 수 있습니다. 모든 것을 구성하고 원하는 시간범위를 넘으면, 작업을 제한하든지 원하는 시간범위를 늘리든지 조정작업을 해야 합니다. 너무 적은 시간에 너무 많은 일을 수행해야 할 때 포화점에 도달하게 됩니다.

그러면 로그온 프로세스를 느리게 하는 상위 아이템들을 어떻게 알 수 있을까요? 로그온 시간에 영향을 주는 구성은 다음과 같습니다.

l 오래된 드라이버 : 네트워크 인터페이스 카드(NIC)는 최신 드라이버를 사용해야 합니다.

l 오래된 운영체제 패치 수준 : 윈도 업데이트를 통해 운영체제에 최신 서비스팩을 설치해야 합니다.

l 로밍 사용자 프로필 : 로밍 프로필은 그룹 정책을 수행하는 방법을 변경합니다. 로밍 프로필이 "비동기"(백그라운드로 동작하거나 특정 시간에 다수가 동작)에서 "동기"(포그라운드로 동작하거나 특정시간에 하나만 동작)로 동작하도록 구성합니다. 네트워크가 초기화될때까지 기다리는 "Fast logon Optimization"을 비활성화합니다.

참고 : 로밍 프로필이 구성되었을 때 이것은 정말 중요한데, 소프트웨어 설치와 폴더 리디렉션 그룹 정책은 네트워크가 초기화될 때까지 사용자가 로그온되지 않도록 하는 것을 요구하고 정책을 동기화로 수행합니다. 이것은 기본값이고 변경을 하게되면 로그온의 불일치를 야기합니다.

l 홈 폴더 : 이것은 로그온 시간에 영향을 주는데 시스템 DLL을 위한 로컬 위치를 대신 찾기 때문입니다. 클라이언트 머신은 홈 폴더를 대신할 것을 찾게 됩니다. 매핑된 네트워크 공유가 WAN에 걸쳐있다면 로그온 시간은 더욱 오래 걸릴 수 있습니다.

참고 : 로밍 프로필에서 홈 폴더가 필요하면 동작을 바꿀 수 있는 차단 레지스트리 키가 있습니다(SafeDllSearchMode). 만약 여러분의 환경에서 이것이 이슈가 되지 않는다면, 로그온시 네트워크 추적을 하고 DLL이 네트워크를 통해 홈 폴더에 쿼리하는지 확인합니다. 또한 (StartRunNoHOMEPATH)와 같은 방법이 있는데 응용프로그램이 쿼리하는지 확인하는 것을 도와줄 것입니다.

l 시작 응용 프로그램 : 시작할 때 자동으로 시작하도록 구성된 응용 프로그램은 느린 로그온의 원인이 될 수 있습니다.

l 프로필 스캐닝 : 로그온시 프로필(로밍이라면 홈 지역)을 스캔하는 많은 안티바이러스 프로그램이 있습니다. 안티바이러스뿐만 아니라 다른 응용 프로그램도 마찬가지입니다(문제해결 부분에서 어떻게 이것을 발견하는지 다룰 것입니다).

l 과도한 그룹 정책 : 여러가지 작업과 구성(소프트제한 정책같은)을 수행하는 수많은 그룹 정책은 로그온 시간을 증가시킬 수 있습니다. 모든 것을 수행하는 몇 가지 정책이 각각을 수행하는 많은 정책보다 좋습니다. 그룹 정책을 통합하는게 가능하다면 말입니다.

l 과도한 시작/로그온 스크립트 : 로그온시 동작하는 시작/스크립트는 비효율적인 코드를 사용하여 많은 작업을 수행하면 프로세스를 지연시킬 수 있습니다.

l 과도한 WMI 필터 : 과도한 WMI 필터는 그룹 정책 적용을 느려지게 만들 수 있습니다.

l 로컬 도메인 컨트롤러가 없는 경우 : 로컬 도메인 컨트롤러가 없다면 로그인 지연이 발생할 수 있습니다(사용자가 WAN을 통해 인증하는 경우)

느린 로그온 증상에 대해 문제를 해결하기 전에 느린 로그온이 무엇이고 어디에서 느리게 되는지 확인할 필요가 있습니다. 로그온이나 부팅 시간이 느리다고 말하려면 무엇이 정상적인 로그온이나 부팅시간인지 알아야 합니다. 위의 기대치를 가지고 다음 단계로 정상적인 상태에서 로그온을 수행하는데 걸리는 시간을 기록합니다. 기업환경에는 다양한 운영체제가 있을 수 있는데(데스크탑, 노트북, 서버, XP, 비스타, Win 7, 2003, 2008, 2008 R2) 각각에 대해 기준선을 가지고 있어야 합니다.

다음은 기준선을 문서화할 때 포함할 목록입니다.

l 네트워크 토폴로지

l Active Directory 토폴로지

l 사용자 및 컴퓨터 그룹 멤버쉽

l 운영체제와 서비스팩 수준

l 설치된 응용 프로그램

l 네트워크 대역폭와 지연

l NIC 드라이버 정보

l XP 또는 2003에서 "UserEnv" 로그(다른 보안 그룹의 구성원인 여러 사용자), 비스타와 Win7에서 ETL 로그

l 네트워크 추적

l 그룹정책 정보(컴퓨터와 사용자 모두)

평균 시간에 대한 명료한 기준선이 있으면, 로그온 시간이 증가하는 것에 대해 명확해지고 어떤것이 문제인지 범위를 좁힐 수 있습니다. 위의 문서가 있다면 이슈는 훨씬 빨리 해결될 것입니다. 문서가 없다면 설정하는데 많은 시간과 노력을 해야 합니다. 다음 글에서는 실제로 문제를 해결하는 방법을 다루겠습니다.

다음에 뵙겠습니다...

- Bob “My idea of a short hiatus is 18 months” Drake

파일 및 폴더의 ACL 정보 및 네트워크 공유 권한을 백업/복원

2009-10-15T00:44:24Z

파일 서버 용도의 구형 서버를 새로운 서버로 옮겨야 될 경우는 어떻게 할까요?

그렇다면 파일/폴더들에 대한 ACL 및 네트워크 공유 권한도 같이 옮겨야 할 경우가 있습니다.

파일/폴더들에 대한 ACL 정보 또는 NTFS 파일 시스템 권한은 보통 Xcacls, Xcacls.vbs 또는 Cacls 와 같은 툴을 사용할 수 있었으며, Windows Vista 에서는 Icacls 라는 툴을 개발되어 백업/복원 작업을 하실 수 있습니다.

이후 이 툴은 Windows 2003 SP2 와 Windows Server 2008, Windows 7 에 포함되었습니다.

이 툴을 이용하여 위의 두 가지 정보를 백업 및 복원하는 방법을 알아 보겠습니다.

<NTFS 파일 시스템 권한 정보를 백업/복원하는 방법>

예를 들어, d: 드라이브 상에 database 라는 폴더가 있다고 가정하면, 아래의 명령으로 백업합니다.

Icacls.exe d:\database /save acl.txt /t /c

참고! 자세한 스위치 정보를 보기 위해서는 Icacls.exe 를 실행합니다.

Sids may be in either numerical or friendly name form. If a numerical

form is given, affix a * to the start of the SID.

/T indicates that this operation is performed on all matching

files/directories below the directories specified in the name.

/C indicates that this operation will continue on all file errors.

Error messages will still be displayed.

/L indicates that this operation is performed on a symbolic link

itself versus its target.

/Q indicates that icacls should supress success messages.

그리고, 복원을 위해서는 아래의 명령을 실행합니다.

Icacls.exe d:\ /restore acl.txt

여기에서 하나 눈여겨 봐야 할 것이 있습니다. 복원 시에는 백업 당시 사용되었던 절대 경로인 D:\database 를 사용하지 않은 d:\ 가 사용되었습니다. 이것은 저장된 파일이 상대 경로를사용하기 때문입니다.

<acl.txt 파일 내용>

database

D:(A;ID;FA;;;BA)(A;OICIIOID;GA;;;BA)(A;ID;FA;;;SY)(A;OICIIOID;GA;;;SY)(A;ID;0x1301bf;;;AU)(A;OICIIOID;SDGXGWGR;;;AU)(A;ID;0x1200a9;;;BU)(A;OICIIOID;GXGR;;;BU)

database\New Text Document.txt

D:(A;ID;FA;;;BA)(A;ID;FA;;;SY)(A;ID;0x1301bf;;;AU)(A;ID;0x1200a9;;;BU)

database\perfctrl.dll

D:(A;ID;FA;;;BA)(A;ID;FA;;;SY)(A;ID;0x1301bf;;;AU)(A;ID;0x1200a9;;;BU)

database\xperf.exe

D:(A;ID;FA;;;BA)(A;ID;FA;;;SY)(A;ID;0x1301bf;;;AU)(A;ID;0x1200a9;;;BU)

database\XperfHighCPU.cmd

D:(A;ID;FA;;;BA)(A;ID;FA;;;SY)(A;ID;0x1301bf;;;AU)(A;ID;0x1200a9;;;BU)

< 네트워크 공유 권한을 백업/복원하는 방법 >

네트워크 공유 권한을 백업하기 위해 아래 네트워크 공유에 대한 레지스트리 키를 “내보내기” 후 적당한 이름 Networkshare.reg 로 저장합니다.

HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares

이후 네트워크 공유 권한을 복원하기 위해서는 위의 내보내기 파일 Networkshare.reg를 실행하여 가져오기 작업을 진행하면 됩니다.

Saving and restoring existing Windows shares

http://support.microsoft.com/kb/125996/en-us

기타 관련 문서:

How to use Xcacls.vbs to modify NTFS permissions

http://support.microsoft.com/kb/825751/en-us

Cacls

http://technet.microsoft.com/en-us/library/bb490872.aspx

Windows 7/2008 R2 : Remote Desktop Services 의 변경

2009-10-13T19:06:31Z

Windows 7/2008 R2 에서는 이전에 Terminal Services 가 어떻게 변했는지 알아보려고 합니다.

우선 Windows 2008 R2에서는 Terminal Services 이름이 Remote Desktop Services 로 완전히 바뀌었습니다.

구제적으로, Windows Server 2008 R2 에서 Terminal Services 와 관련된 모든 서비스 이름이 Remote Desktop Services 관련 이름으로 완전히 바뀌었습니다. 아래 테이블에서 이전 이름과 새로운 이름이 설명되어 있습니다.

이전 이름	새로운 이름 (Windows Server 2008 R2)
Terminal Services	Remote Desktop Services
Terminal Server	Remote Desktop Session Host
Terminal Services Licensing (TS Licensing)	Remote Desktop Licensing (RD Licensing)
Terminal Services Gateway (TS Gateway)	Remote Desktop Gateway (RD Gateway)
Terminal Services Session Broker (TS Session Broker)	Remote Desktop Connection Broker (RD Connection Broker)
Terminal Services Web Access (TS Web Access)	Remote Desktop Web Access (RD Web Access)

또한, 위의 서비스들을 관리할 관리 툴들의 이름들도 바뀌었습니다.

이전 이름	새로운 이름 (Windows Server 2008 R2)
Terminal Services Manager	Remote Desktop Server Manager
Terminal Services Configuration	Remote Desktop Server Configuration
TS Licensing Manager	Remote Desktop Licensing Manager
TS Gateway Manager	Remote Desktop Gateway Manager
TS RemoteApp Manager	RemoteApp Manager

Windows Server 2008 R2 에 Remote Desktop Services 는 Windows Server 2008 에 Terminal Services 에 의해 제공된 Feature set 을 포함하여 다음 항목들에 대한 새로운 Features 를 제공하고 있습니다.

Remote Desktop Services Administration
Client Experience
Remote Desktop Protocol
RemoteApp and Desktop Connection
Remote Desktop Connection Broker
Remote Desktop Virtualization (RDS-V)
IP Virtualization

여기에서는 위의 상위 두 가지에 대해서만 확인해 보겠습니다.

Remote Desktop Service Administration 에 새로운 개선으로서 PowerShell provider, Windows Installer Compatibility, 그리고, Dynamic Fair Share Scheduling (DFSS) 등을 포함한 상당히 많은 새로운 Features 가 있습니다. 그리고,

Remote Desktop Licensing mechanism 에 대한 몇몇 변경 사항이 있습니다.

- 새로운 PowerShell Provider 를 통해 모든 Remote Desktop Services Role Services및 구성 요소들을 설정하고 관리할 수 있습니다. 또한 PowerShell 의 스크립트를 통해 관리자는 반복적으로 처리해야 하는 복잡한 작업들을 자동화할 수 있게 되었습니다.

- Windows Server 2008 R2 에 RDS 이전에는 단지 한 번에 하나의 Windows Installer 설치가 가능했습니다. Microsoft Word 와 같은 사용자 당 환경 설정이 요구되는 프로그램에 대해서는, 관리자가 해당 프로그램을 미리 설치할 필요가 있었고, 프로그램 개발자는 RD client 와 RD Session Host Server 상에서 이들 프로그램을 테스트할 필요가 있었습니다. 하지만, 새로운 이 Feature는 사용자 당 프로그램 설치가 RD Session host Server 에 의해 Queued 되어 Windows Installer 로 하여금 처리되도록 합니다.

- DSS 는 새로운 CPU 스케쥴링 방법으로서, Processor time 을 모든 Sessions 이 아닌 Active sessions 에 대해서만 분산/로드하는 Feature 입니다. 이것은 동적으로 CPU 스케쥴링을 함으로서 CPU 리소스를 낭비할 수 있었던 이전의 정적 스케쥴링 메카니즘에 대한 향상된 부분입니다.

RD 라이센스 서비스와 관련하여, Windows Server 2008 R2 에서는 더 이상 RDS 에 대한 자동 라이센스 서버 검색 기능이 지원되지 않습니다. 따라서, RD Licensing Role service 를 설치할 때, 해당 서버가 Licenser Server 임을 Active Directory 에 Service Connection Point (SCP) 로 등록해야 합니다. 즉, 라이센스 서버 사용을 위해 관리자는 각각의 RD Session Host server 에 라이센스 서버의 이름을 지정해 줘야 하는데, SCPs 로서 등록된 리스트로 부터 라이센스 서버를 선택하거나 혹은 수동으로 이름을 입력하는 방법을 사용합니다.

Client Experience 에 대한 몇몇 개선된 변경 사항은 다음과 같습니다.

- Desktop Composition

Windows 7 /2008 R2 에는 Remote Desktop Connection 7.0 (RDP 7.0)이 포함되었습니다. 이버전에서는 RD Session 내에서 Aero 로 지원합니다.

- Single Sign-On improvement

웹을 통해 연결이 가능하게 해 주는 RD Gateway 을 통해 요구되었던 여러 번의 Sign-on 창을 줄였습니다.

- True Multiple Monitor support

RDC 7.0 은 최대 16개 모니터를 지원합니다.

- Redirection

오디오 및 비디오 플레이백의 리디렉션을 지원하며, 연결하는 Client 상에 레코드 장치로부터의 입력을 서버에서 저장될 수 있도록 연결된 장치의 입력 데이타에 대한 리디렉션이 지원됩니다.

- 네트워크 창에 존재하는 컴퓨터들을 선택하여 마우스 오른쪽 버튼상의 메뉴에 RD 연결을 통해 쉽게 원격 연결을 실행할 수 있습니다.

- 그 밖의 RemoteApp and Desktop Connection Shell 의 추가 및 개인 가상 데스크탑 연결 등의 기능이 추가되었습니다.

Windows 7 출시가 몇 일을 앞두고 이미 카운트 다운에 들어갔군요. 이미 베타 버전이나 그 이전 빌드로 테스트를 해 보신 분들도 계시겠지만, 이러한 새로운 기들을 직접 경험해 보시길 바랍니다. 추가 Feature 들에 대해서는 차차 다뤄 보겠습니다.

LDAP 보안 프로세싱의 이해

2009-10-13T07:34:00Z

원문주소 : Understanding LDAP Security Processing

http://blogs.technet.com/askds/archive/2009/09/21/understanding-ldap-security-processing.aspx

랜디(Randy)입니다. 오늘은 LDAP 보안을 다루도록 하겠습니다. LDAP(Lightweight Directory Access Protocol)은 Active Directory 데이터베이스를 읽고 쓰는데 사용하는 인터페이스입니다. 따라서 Active Directory 관리도구(AD 사용자 및 컴퓨터, AD 사이트 및 서비스 등)나 타사의 관리도구는 도메인을 관리하기 위해 데이터베이스에 연결하는데 LDAP을 사용합니다. 아시는 것처럼 이 중요한 데이터베이스에 접근할 때 사용자를 인증하는 것은 윈도우 보안에 의존합니다. 이 데이터베이스에 접근하는 것은 도메인 컨트롤러에서 Ntdsa.dll로 나타나는 DSA(Directory System Agent)를 통해 제어합니다. Ntdsa.dll은 Lsass.exe로 동작하는 LSA(Local Security Authority)의 일부분으로 동작합니다.

접근 권한을 얻는 과정은 두 단계로 진행됩니다. 바로 인증과 권한부여입니다. 이 글에서는 인증부분을 자세히 살펴볼 것입니다(사용자의 신원을 확인하는 부분). 인증 절차에 대해 더 알고 싶다면, 보안 토큰에 대한 글을 참조하세요. Active Directory 데이터베이스의 객체는 다른 윈도우 객체와 같이 동일한 규칙을 따릅니다. Active Directory 데이터베이스의 객체는 인증된 사용자가 할 수 있는 권한와 특권을 포함하고 있습니다.

이 글에서는 Windows 2008에 있는 LDP.EXE 유틸리티를 통해 설명하겠습니다. 이 도구는 Active Directory에 연결하고, 바인드하고, 관리를 도와주는 클라이언트 GUI 도구입니다. LDAP 문제를 트러블슈팅하거나 네트워크 추적을 원하면 네트워크 모니터(Network Monitor)를 다운로드할 수 있습니다. LDP를 열고 Connection 메뉴의 "Connect…"를 선택하고 매개변수는 넣지 마세요.

그리고 "bind as currently logged on user"를 선택하세요.

시작을 하면 잘 동작하는 것을 확인할 수 있습니다. DC Locator process를 통해 대상 DC를 지정하지 않고 현재 도메인 컨트롤러에서 실행했고 현재 로그온한 사용자로 연결해서 윈도우에 포함된 보안 패키지를 사용했습니다. 네트워크 추적에서는 무엇을 볼 수 있을까요? Network Monitor 3.3을 열고 LDAP을 필터링해서 볼 수 있습니다.

접속하기 전에 왜 LDP.exe에서 결과를 얻을까요?

처음으로 볼 수 있는 트래픽은 많은 LDAP Search Requests와 Search Responses입니다. 설명은 Description 필드에서 볼 수 있습니다.

그러면 왜 LDAP을 바인드하기 전에 LDAP search request이 나타날까요? 왜냐하면 Active Directory 데이터베이스의 "RootDSE" 파티션에 처음 접근할 때, 이 DSA에 바인드하고 인증하는 규칙에 대한 정보를 쿼리하기 위해 익명으로 연결하기 때문입니다. 이 루트에는 익명 접근을 허용하지만, Windows Server 2003과 이후 버전은 Active Directory의 모든 다른 파티션에 익명 접근을 차단합니다. DSHeuristics 값을 변경하여 이 설정을 바꿀수 있습니다. 그러면 포레스트 전체에 있는 모든 도메인 컨트롤러에 변경됩니다.

LDAP search request의 상세정보를 살펴보면 LDAP request parameters가 "BaseDN: NULL"으로 나타납니다. "LDAP: Search Request"를 확장하고, "Parser: Search Request"를 확장하고, "Search Request"를 확장합니다.

"BaseDN"은 LDAP 쿼리에서 검색을 시작하는 컨테이너입니다. NULL은 도메인 컨트롤러의 RootDSE가 됩니다. 이것이 바인드하기 전에 LDP 유틸리티의 오른쪽 창에서 그런 결과가 나타나는 이유입니다.

"LDAP: Search Result"는 "LDAP: Search Result"를 확장하고, "Parser: Search Result"를 확장하고, "SearchResultEntry" 확장할 때와 같은 데이터를 보여줍니다.

네트워크 추적의 결과는 LDP.exe 결과 창에 나타난 것과 일치합니다. 중요한 정보 중 하나는 "supportedSASLMechanisms"입니다. 이것은 LDAP 바인드에서 사용할 수 있는 보안 매커니즘입니다. 이것은 이 글의 뒷부분에서 다루겠습니다.

왜 자격증명 입력을 선택할 때 "Null"로 로그온 할까요?

바인드를 하고 현재 로그온한 사용자를 기본값으로 선택합니다. LDP 결과 창에서 'NULL'로 로그인한 것을 볼 수 있습니다.

저는 이것이 이 도구의 특징이고, 완벽하게 정확하지 않다고 생각합니다. 바인드를 할 때, 'NULL' 자격증명을 표시하지만, 인증 타입으로 SASL을 지정하기도 합니다. 이 부분에서, SASL 매커니즘으로 인증 절차가 이루어집니다. 네트워크 추적을 통해 그 증거를 볼 수 있습니다.

프레임 세부정보 창의 Bind Request를 살펴보면, LDAP 패킷을 확장할 때 흥미로운 정보를 볼 수 있습니다.

NULL 자격증명이 통과된 것을 볼 수 있지만, SASL 인증으로 협상합니다. SASL(Simple Authentication and Security Layer)은 연결기반 프로토콜에 인증을 추가하는 방법입니다. 기본적으로, LDAP은 NULL 자격증명으로 바인드되는데 SASL에 로그온 절차를 넘기고 모든 작업을 하도록 합니다. bind request에서 협상 프로세스의 세부내용을 볼 수 있고 GSS-SPEGNO SASL 매커니즘을 선택하면 Kerberos 세션 티켓이 나타납니다.

그러면 어떻게 SASL이 인증을 제공할까요?

자세한 정보는, SASL에 대한 IETF의 설명을 확인할 수 있습니다. SSPI(Security Support Provider Interface)가 보안 패키지를 사용하는 방법과 비슷하게, SASL은 인증 절차를 완료하기 위해 SASL 매커니즘 등록을 사용합니다. 앞서 기술한 supportedSASLMechanisms의 초기 LDAP 쿼리 동안입니다. 서버와 클라이언트가 선택할 수 있는 모든 매커니즘의 목록을 가져왔습니다. 다음은 Windows Server 2008의 기본 매커니즘입니다.

인증 프로토콜	설명
GSS-SPNEGO	GSS-SPNEGO는 커버로스나 NTLM을 인증 프로토콜의 기초로 사용합니다.
GSSAPI	GSSAPI는 커버로스를 항상 인증 프로토콜의 기초로 사용합니다.
EXTERNAL	LDAP 통신 외부에서 제공되는 정보를 통해 클라이언트가 자체적으로 인증하는 것을 허용하는데 사용합니다. TLS나 IPSec을 통해 인증서를 제출하는데 사용합니다.
DIGEST-MD5	Digest-MD5을 사용하여 인증을 암호화합니다.

LDP 도구는 다양한 매커니즘을 선택할 수 있도록하고 다른 도구를 사용할 수 없을 때 연결을 테스트할 수 있는 훌륭한 도구입니다. 응용 프로그램이 무엇을 수행하는지 적절한 바인드 특성을 선택할 수 있습니다.

응용 프로그램은 어떤 기능을 사용하여 데이터베이스에 연결할지를 결정합니다. (예 : LDAP_Simple_bind, LDAP_Sasl_bind, 등)

LDAP 서명(signing)은 무엇일까요?

그룹 정책에서 보안 설정을 살펴본다면, LDAP에 많이 관련되어 있는 것을 알 수 있습니다.

Domain controller: LDAP server signing requirements

Network security: LDAP client signing requirements

둘 모두 컴퓨터 구성\윈도우 설정\보안 설정\로컬 정책\보안 옵션에 있습니다.

서명된 LDAP 트래픽은 man-in-the-middle 공격을 예방하는 방법입니다. LDAP 트래픽을 서명함으로써, 요청이 만들어진 DC로부터 만들어진 LDAP 응답을 보장합니다. 이 설정을 활성화하면, 컴퓨터는 트래픽을 가로챌 수 없고 유선상에서 데이터를 변경할 수 없습니다. 네트워크 추적에서 디지털 서명 값을 볼 수 있습니다. 이 값은 서명이 완료된 DC의 모든 LDAP 응답에 있습니다.

단순 바인드는 무엇일까요?

LDAP 단순 바인드는 LDAP 서버에 자격증명을 제공하기 위해 사용자이름과 비밀번호를 텍스트로 보냅니다. 이것은 안전하지 않기 때문에, 응용 프로그램에서 단순 바인드를 사용한다면 다시 구성하거나 업데이트 해야합니다. LDP.exe의 이 옵션을 사용하여 단순 바인드를 생성하거나 코드에 LDAP_Simple_bind 기능을 호출하여 만듭니다. 네트워크 추적에서 LDAP BIND 바인드 프레임에서 사용자이름과 비밀번호를 볼 수 있습니다.

도메인에 서명이 필요해서, LDP.exe를 통해 단순 바인드를 수행할 수 없었습니다. "LDAP_Simple_Bind failed: Strong Authentication Required"라는 오류를 받았습니다.

익명 바인드는 무엇일까요?

앞서 기술했듯이, 모든 LDAP 연결은 LDAP 서버의 RootDSE를 쿼리하기 위해 익명 바인드를 수행합니다. 또한 앞서 언급했듯이, AD 포레스트의 DSHueristics 값을 변경하면, 모든 AD 파티션에 대해서 익명 바인드 LDAP 검색을 허용할 수 있습니다. 익명 바인드는 디렉터리 객체의 권한에 의해 여전히 제한됩니다. 익명 바인드를 만들고 도메인의 모든 사용자 객체에 검색을 수행하였는데, 한명의 사용자에만 수동으로 권한을 주었기 때문에 한명의 사용자만 검색되었습니다.

또한 사용자를 포함하고 있는 OU에 권한을 주었는데, 익명 로그온은 권한이 없기 때문에 컨테이너를 검색할 수 없었습니다. 루트 도메인 네이밍 컨텍스트에 접근할 수 있는 권한을 주지 않았습니다. "AD 사용자 및 컴퓨터"에서 "고급 기능"을 통해 권한을 설정할 수 있습니다.

LDAPS은 무엇일까요?

LDAPS은 LDAP 서버와 클라이언트 사이에서 암호화된 터널을 만드는 SSL/TLS 기술을 사용합니다. 터널은 LDAP 서버의 PKI 인증으로 통해 암호화하고, LDAP서버와 클라이언트를 제외한 다른 사람은 이 트래픽을 읽을 수 없기 때문에 클라이언트는 단순 바인드를 수행할 수 있고 텍스트로 자격증명을 안전하게 전달할 수 있습니다. LDAPS는 다른 글로 쓸 수 있는 완전히 다른 주제입니다. 운좋게도 James Carr 가 그것에 대해 기술했습니다. 여기를 확인하세요.

개발자는 Active Directory 데이터베이스에 바인드할 수 있는 다양한 방법이 있습니다. LDAP 클라이언트의 다양한 성향을 지원하지만, AD 관리자가 일부 구성을 해주어야 합니다. 안녕히 계세요...

Randy “Baby Elvis, thank you verah muuuch” Turner

VHD (Virtual Hard Disk)를 생성하고 설정하는데 사용하는 툴

2009-10-13T02:44:00Z

VHD (Virtual Hard Disk)를 생성하고 설정하는 등의 작업 및 관련된 작업들을 수행하는데 사용할 수 있는 Tools 에 대해 정리해 보았습니다.

1. Diskpart

Diskpart 는 별도로 제공되기도 하며, Windows 7/2008R2 에 포함되어, 아래와 같은 VHD 작업들을 지원합니다.

- Create vdisk : 새로운 VHD 생성합니다. 이것은 빈 VHD 파일로 만들 수도 있고 기존 VHD로부터의 이미지를 포함할 수 있습니다.

- Attach vdisk : VHD 를 연결시키고 드라이브 문자를 할당합니다.

- Detach vdisk : VHD를 분리시킵니다.

- Compact vdisk : VHD의 크기를 주립니다. VHD 내의 파일들을 삭제할 경우라도 이 파일 크기는 자동으로 줄어들지 않습니다.

- Expand vdisk : VHD 에서 사용 가능한 최대 크기를 확장합니다.

- Merge vdisk : Child disk 를 Parent disk 와 병합합니다.

- Detail vdisk : VHD에 대한 정보를 표시합니다.

http://technet.microsoft.com/en-us/library/cc766465(WS.10).aspx

2. 디스크 관리자 콘솔

- Create VHD : 새로운 VHD 생성합니다. 이것은 빈 VHD 파일로 만들 수도 있고 기존 VHD로부터의 이미지를 포함할 수 있습니다.

- Attach VHD : VHD 를 연결시키고 드라이브 문자를 할당합니다.

- Detach VHD : VHD를 분리시킵니다.

3. ImageX

ImageX 는 파일 기반의 디스크 이미지를 Capture, Modify 등의 작업에 사용할 수 있는 Command-line 툴로서,

Windows image (.wim) 파일 또는 Windows 설치, Windows Deployment Service, SMS Operating System Feature

Deployment pack 과 같은 .wim 이미지를 사용하는 기술 등과 같이 사용됩니다.

http://technet.microsoft.com/en-us/library/dd744298(WS.10).aspx

Tool Download :

Vista SP1 / Windows Server 2008

http://www.microsoft.com/downloads/details.aspx?familyid=94BB6E34-D890-4932-81A5-5B50C657DE08&displaylang=en

Windows 7

http://www.microsoft.com/downloads/details.aspx?familyid=696DD665-9F76-4177-A811-39C26D3B3B34&displaylang=en

4. Sysprep

System Preparation (Sysprep) 은 여러 대의 컴퓨터에 Windows OS를 구현하는 것을 필요로 하는 시스템 관리자, OEMs,

또는 그 밖의 사람들을 위해 디자인된 툴입니다. 새로운 단일 OS를 설치 후 Sysprep 툴을 실행함으로서 해당 OS상의

사용자와 컴퓨터의 특정 정보를 삭제하여 다른 컴퓨터들에 클론(Clone)을 만들어 마이그레이션할 수 있도록 합니다.

만약 P2V 또는 V2P 를 이용한 물리적인 컴퓨터 사이의 VHD 기반의 OS 를 마이그레이션하고자 한다면, 생성된 이미지에서

Sysprep 을 실행합니다.

http://technet.microsoft.com/en-us/library/dd744263(WS.10).aspx

5. BCDBoot

BCDBoot 는 새로운 BCD stores 와 BCD boot entires 를 생성하고 관리하는데 사용하는 Command-line 툴입니다.

만약 VHD로부터 부팅하도록 컴퓨터를 설정하려면, 이 BCDBoot 를 사용하여 새로운 BCD boot entry를 생성합니다.

http://technet.microsoft.com/en-us/library/dd744347(WS.10).aspx

6. Deployment Image Servicing and Management Tool (DISM)

Deployment Image Servicing and Management Tool (DISM) 은 오프라인 Windows 이미지, 오프라인 Windows PE

이미지, 그리고 VHD 이미지에 Windows features, packages, drivers, 기타 설정들을 설치, 제거, 설정 및 업데이트 등

배포 전에 서비스하는데 사용할 수 있는 Command-line 툴입니다.

http://www.microsoft.com/downloads/details.aspx?familyid=886cd1dd-91aa-4bf4-8557-decedef7fa5d&displaylang=en

http://technet.microsoft.com/en-us/library/dd744256(WS.10).aspx

7. Hyper-V 관리자

Hyper-V관리자는 VHD 이미지 생성을 지원하며, VHD 의 형식, 크기 등을 지정할 수 있습니다. Hyper-V는 Hyper-V

Role 이 설치된 Windows Server 2008/2008 R2 에서 사용할 수 있습니다.

http://technet.microsoft.com/en-us/library/dd446676(WS.10).aspx

8. Windows Deployment Services

Windows Deployment Services 는 VHD 이미지를 물리적인 컴퓨터상에 구현하는데 사용되는 툴입니다.

http://technet.microsoft.com/en-us/library/dd363560(WS.10).aspx

9. Disk2vhd

Disk2vhd 툴은 Microsoft Virtual PC 또는 Hyper-V virtual machines 에서 사용할 수 있는 물리적인 디스크의 VHD를

생성하는 Utility 입니다.

http://technet.microsoft.com/en-us/sysinternals/ee656415.aspx

10. Powershell

Powershell script 인 nstall-WindowsImage.ps1 를 사용합니다.

http://code.msdn.microsoft.com/InstallWindowsImage/Release/ProjectReleases.aspx?ReleaseId=2662

Example)

PS > help .\Install-WindowsImage.ps1 –detailed

NAME

Install-WindowsImage.ps1

SYNOPSIS

Lists or applies Windows Images in .WIM containers.

SYNTAX

C:\Vhd\Install-WindowsImage.ps1 -WIM <String> [<CommonParameters>]

C:\Vhd\Install-WindowsImage.ps1 -WIM <String> -Apply -Index <Int32> -Destination <String> [<CommonParameters>]

DESCRIPTION

PARAMETERS

-WIM <String>

Specifies the .WIM file to examine and/or apply images from.

-Apply [<SwitchParameter>]

Specifies that the specified image index should be applied to the specified Destination.

-Index <Int32>

Specifies the image index of the Windows Image to apply to the specified Destination.

-Destination <String>

The drive or folder to apply the specified Windows Image to.

This cmdlet supports the common parameters: Verbose, Debug, ErrorAction, ErrorVariable, WarningAction,

WarningVariable, OutBuffer and OutVariable. For more information, type, "get-help about_commonparameters".

-------------------------- EXAMPLE 1 --------------------------

C:\PS>This example will list the available images in the D:\Sources\Install.wim container.

.\Install-WindowsImage.ps1 -WIM D:\Sources\Install.wim

-------------------------- EXAMPLE 2 --------------------------

C:\PS>This example will apply image number 8 from D:\Sources\Install.wim to X:\.

.\Install-WindowsImage.ps1 -WIM D:\Sources\Install.wim -Apply -Index 8 -Destination X:\

Windows Vista/2008/2008R2/Win7 에서 이벤트 발생 시 작업을 실행시키는 방법

2009-10-07T21:35:00Z

Trigger된 이벤트를 기반으로 작업을 스케쥴하는 좋은 기능에 대해 소개합니다.

원래는 Vista 에도 추가되어 있었지만, Client 머신이라 잘 사용하지 않았거나 알려지지 않았던 것 같습니다.

만약 서버에서 Event ID 2019, 2020, 15, 55, 등등이 기록되었을 때 적절하게 관리자에게 알리거나 또는,특정 작업을 실행하도록 함으로서, 관리자로 하여금 적절한 대응을 할 수 있도록 하거나 자동으로 어떠한작업을 수행하도록 하는 아주 유용한 기능이 될 것입니다.

Windows Vista 이전 버전에서는 이 기능을 여러 곳에서 제공된 Event monitor 툴을 이용하여 사용할 수 있었습니다.

Windows Vista/2008/2008R2/Win7 에서 이 기능을 사용하기 위해서 아래와 같은 단계를 진행합니다.

1. 관리 도구에 이벤트 뷰어를 실행합니다.

2. 왼쪽 콘솔 트리에서 작업을 연결하고자 하는 이벤트를 포함하는 로그를 선택합니다.

3. 오른쪽 해당 이벤트에서 마우스 오른쪽 버튼을 누른 후 "Attach Task To This Event..."를 선택합니다.

(제 머신이 영문이라서... )

4. Create Basic Task 마법사에서 각 단계를 수행합니다.

Windows Vista/Server2008/ Server2008R2 환경에서 성능 카운터를 Rebuild 하는 방법

2009-10-07T20:43:00Z

가끔 성능 카운터의 일부 또는 전체가 숫자로 보이거나 카운터들이 보이지 않거나 또는 아래와 같은 이벤트 로그가

기록될 경우가 있습니다.

이벤트 형식 : 오류

이벤트 원본 : Perflib

이벤트 ID : 1008 또는 다른 ID

Windows 2000/XP/2003 환경에서는 Base OS의 성능 카운터들을 Rebuild 하기 위해서는 아래 문서를 진행해야 했습니다.

How to manually rebuild Performance Counter Library values
http://support.microsoft.com/?id=300956

또는, exctrlst.exe 툴을 사용해서 카운터들을 Enable/Disable 할 수 있었습니다.

Windows 2000 Resource Kit Tool : Extensible Performance Counter List (exctrlst.exe)
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=7ff99683-b7ec-4da6-92ab-793193604ba4

Windows Vista / Server2008 또는 그 이후 버전에서는 이러한 작업들을 아주 쉬운 Command 를 사용하여 수행할 수 있습니다.

1. 관리자 권한으로 CMD 를 실행합니다.

2. 도스 창에서 “C:\Windows\system32” 디렉토리로 이동합니다.

3. 아래 명령을 수행하여Rebuild 작업을 수행하기 전에 성능 카운터들을Backup_Original.INI로 백업 후 진행합니다.

C:\Windows\System32> LodCtr.exe /S:Backup_Original.INI

C:\Windows\System32> LodCtr.exe /R:PerfStringBackup.INI

4. 성능 로그 툴을 실행하신 후 적절하게 카운터들이 보이는지 확인합니다.

참고: LodCtr.exe 툴의 기타 스위치

C:\>lodctr.exe /?

LODCTR
Updates registry values related to performance counters.

Usage:
    LODCTR <INI-FileName>
        INI-FileName is the name of the initialization file that contains the counter name
           definitions and explain text for an extensible counter DLL.

LODCTR /S:<Backup-FileName>
save the current perf registry strings and info to <Backup-FileName>

LODCTR /R:<Backup-FileName>
restore the perf registry strings and info using <Backup-FileName>

    LODCTR /R
        rebuild the perf registry strings and info from scratch based on the current
            registry settings and backup INI files.

LODCTR /T:<Service-Name>
set the performance counter service as trusted.

LODCTR /E:<Service-Name>
enable the performance counter service.

LODCTR /D:<Service-Name>
disable the performance counter service.

LODCTR /Q

LODCTR /Q:<Service-Name>
query the performance counter service information, either query all or specified one.

LODCTR /M:<Counter-Manifest>
install Windows Vista performance counter provider definition XML file to system repository.