ADSI의 이벤트 추적
Windows Server 2008 및 Windows Vista는 ADSI(Active Directory 서비스 인터페이스)에서 이벤트 추적을 도입했습니다. ADSI LDAP 공급자의 특정 영역에는 복잡하거나 문제를 진단하기 어렵게 만드는 일련의 단계가 포함된 기본 구현이 있습니다. 애플리케이션 개발자의 문제 해결을 돕기 위해 이벤트 추적이 다음 영역에 추가되었습니다.
ADSI의 IADs 인터페이스를 사용하려면 특성이 올바르게 마샬링될 수 있도록 클라이언트에서 LDAP 스키마를 캐시해야 합니다(ADSI 스키마 모델에 설명된 대로). 이를 위해 ADSI는 각 프로세스(및 각 LDAP 서버/도메인)에 대한 스키마를 로컬 디스크에 저장된 스키마(.sch) 파일에서 또는 LDAP 서버에서 다운로드하여 메모리로 로드합니다. 사용 가능하고 적용 가능한 경우 동일한 클라이언트 컴퓨터의 여러 프로세스에서 디스크에 캐시된 스키마를 사용합니다.
디스크 또는 서버에서 스키마를 가져올 수 없는 경우 ADSI는 하드 코딩된 기본 스키마를 사용합니다. 이 경우 이 기본 스키마의 일부가 아닌 특성은 마샬링할 수 없으며 ADSI는 이러한 특성을 검색하는 동안 오류를 반환합니다. 스키마 구문 분석 문제 및 스키마를 다운로드할 수 있는 권한 부족 등 여러 가지 요인으로 인해 이러한 문제가 발생할 수 있습니다. 특정 기본 스키마가 사용되는 이유를 확인하기가 어려운 경우가 많습니다. 이 영역에서 이벤트 추적을 사용하면 문제를 보다 신속하게 진단하고 해결하는 데 도움이 됩니다.
ChangePassword 및 SetPassword는 사용 가능한 구성에 따라 요청된 작업을 수행하기 위해 둘 이상의 메커니즘을 사용합니다(LDAP 공급자를 사용하여 사용자 암호 설정 및 변경에 설명됨). ChangePassword 및 SetPassword가 실패하면 정확한 이유를 확인하기 어려울 수 있으며 이벤트 추적은 이러한 메서드의 문제를 해결하는 데 도움이 됩니다.
ADSI는 가능할 때마다 내부적으로 LDAP 연결을 다시 사용하려고 합니다(연결 캐싱 참조). 문제를 해결할 때 서버와의 통신을 위해 새 연결이 열렸는지 또는 기존 연결이 사용되었는지 여부를 추적하는 것이 유용합니다. 또한 연결 캐시의 수명 주기(바인딩 캐시라고도 함) 및 생성 또는 닫기, 연결 조회가 이루어졌는지 여부를 추적하는 데 유용할 수 있습니다. 서버리스 바인딩의 경우 ADSI는 DC 로케이터를 호출하여 사용자 컨텍스트의 도메인에 대한 서버를 선택합니다. 그런 다음 ADSI는 후속 연결에 대한 도메인 서버 매핑의 캐시를 유지 관리합니다. 이벤트 추적은 DC 선택을 추적하는 데 도움이 되므로 연결 관련 문제를 해결하는 데 유용합니다.
ADSI 추적을 켜려면 다음 레지스트리 키를 만듭니다.
\HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\adsi\추적\ProcessName
ProcessName 은 확장(예: "Svchost.exe")을 포함하여 추적하려는 프로세스의 전체 이름입니다. 또한 이 키에 PID라는 DWORD 형식의 선택적 값을 배치할 수 있습니다. 이 값을 설정하여 특정 프로세스만 추적하는 것이 좋습니다. 그렇지 않으면 ProcessName에서 지정한 애플리케이션의 모든 인스턴스가 추적됩니다.
그런 다음, 다음 명령을 실행합니다.
tracelog.exe -start sessionname **-guid #**provider_guid -f filename -flag traceFlags -level traceLevel
sessionname 은 추적 세션에 레이블을 지정하는 데 사용되는 임의의 식별자일 뿐입니다(추적 세션을 중지할 때 나중에 이 세션 이름을 참조해야 합니다). ADSI 추적 공급자의 GUID는 "7288c9f8-d63c-4932-a345-89d6b060174d"입니다. filename 은 이벤트가 기록될 로그 파일을 지정합니다. traceFlags는 다음 값 중 하나여야 합니다.
플래그 | 값 |
---|---|
DEBUG_SCHEMA |
0x00000001 |
DEBUG_CHANGEPWD |
0x00000002 |
DEBUG_SETPWD |
0x00000004 |
DEBUG_BINDCACHE |
0x00000008 |
다음 표에 따르면 이러한 플래그는 추적할 ADSI 메서드를 결정합니다.
Flag | 메서드 |
---|---|
DEBUG_SCHEMA |
|
DEBUG_CHANGEPWD |
|
DEBUG_SETPWD |
|
DEBUG_BINDCACHE |
|
traceFlags 인수에서 적절한 비트를 결합하여 플래그를 결합할 수 있습니다 . 예를 들어 DEBUG_SCHEMA 및 DEBUG_BINDCACHE 플래그를 지정하려면 적절한 traceFlags 값이 0x00000009.
마지막으로 traceLevel 플래그는 다음 값 중 하나여야 합니다.
플래그 | 값 |
---|---|
TRACE_LEVEL_ERROR |
0x00000002 |
TRACE_LEVEL_INFORMATION |
0x00000004 |
TRACE_LEVEL_INFORMATION 추적 프로세스는 모든 이벤트를 기록하는 반면 TRACE_LEVEL_ERROR 추적 프로세스는 오류 이벤트만 기록합니다.
추적을 종료하려면 다음 명령을 실행합니다.
tracelog.exe -stop 세션 이름
이전 예제 에서 세션 이름은 추적 섹션을 시작한 명령과 함께 제공된 이름과 같습니다.
컴퓨터의 모든 프로세스를 추적하는 것보다 특정 PID를 지정하여 특정 프로세스만 추적하는 것이 더 효과적입니다. 동일한 컴퓨터에서 여러 애플리케이션을 추적해야 하는 경우 성능에 영향을 미칠 수 있습니다. 코드의 성능 지향 섹션에는 상당한 디버깅 출력이 있습니다. 또한 관리자는 여러 프로세스를 추적할 때 로그 파일의 사용 권한을 올바르게 설정하도록 주의해야 합니다. 그렇지 않으면 모든 사용자가 추적 로그를 읽을 수 있고 다른 사용자는 보안 정보를 포함하는 프로세스를 추적할 수 있습니다.
예를 들어 관리자가 애플리케이션 "Test.exe"에 대한 추적을 설정하고 프로세스의 여러 인스턴스를 추적하기 위해 레지스트리에 PID를 지정하지 않는다고 가정합니다. 이제 다른 사용자가 애플리케이션 "Secure.exe"을 추적하려고 합니다. 추적 로그 파일이 제대로 제한되지 않은 경우 사용자가 해야 할 일은 "Secure.exe"의 이름을 "Test.exe"로 바꾸는 것이며 추적됩니다. 일반적으로 문제를 해결하는 동안 특정 프로세스만 추적하고 문제 해결이 완료되는 즉시 추적 레지스트리 키를 제거하는 것이 가장 좋습니다.
이벤트 추적을 사용하도록 설정하면 추가 로그 파일이 생성되므로 관리자는 로그 파일 크기를 주의 깊게 모니터링해야 합니다. 로컬 컴퓨터의 디스크 공간이 부족하면 서비스 거부가 발생할 수 있습니다.
시나리오 1: 관리자가 사용자 계정에 대한 암호를 설정하는 애플리케이션에서 예기치 않은 오류가 표시되므로 다음 단계를 수행하여 이벤트 추적을 사용하여 문제를 해결합니다.
문제를 재현하는 스크립트를 작성하고 레지스트리 키를 만듭니다.
\HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\adsi\추적 cscript.exe\
추적 세션을 시작하고 다음 명령을 사용하여 traceFlags를 0x2(DEBUG_CHANGEPASSWD)로 설정하고 traceLevel을 0x4(TRACE_LEVEL_INFORMATION)로 설정합니다.
tracelog.exe -start scripttrace -guid #7288c9f8-d63c-4932-a345-89d6b060174d -f .\adsi.etl -flag 0x2 -level 0x4
테스트 스크립트로 cscript.exe 실행하여 문제를 재현한 다음 추적 세션을 종료합니다.
tracelog.exe -stop scripttrace
레지스트리 키 삭제
\HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\adsi\추적 cscript.exe\
ETW 도구 Tracerpt.exe 실행하여 로그에서 추적 정보를 구문 분석합니다.
tracelog.exe -start scripttrace -guid #7288c9f8-d63c-4932-a345-89d6b060174d -f .\adsi.etl -flag 0x2 -level 0x4
시나리오 2: 관리자는 이미 실행 중인 w3wp.exe ASP 애플리케이션에서 스키마 구문 분석 및 다운로드 작업을 추적하려고 합니다. 이렇게 하려면 관리자는 다음 단계를 수행합니다.
레지스트리 키 만들기
\HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\adsi\추적 w3wp.exe\
키 내에서 PID라는 DWORD 형식의 값을 만들고 로컬 컴퓨터에서 현재 실행 중인 w3wp.exe 인스턴스의 프로세스 ID로 설정합니다.
그런 다음 추적 세션을 만들고 traceFlags를 0x1(DEBUG_SCHEMA)로 설정하고 traceLevel을 0x4(TRACE_LEVEL_INFORMATION)로 설정합니다.
tracelog.exe -start w3wptrace -guid #7288c9f8-d63c-4932-a345-89d6b060174d -f .\w3wp.etl -flag 0x1 -level 0x4
문제 해결이 필요한 작업을 재현합니다.
추적 세션을 종료합니다.
tracelog.exe -stop w3wptrace
System\CurrentControlSet\Services\adsi\추적\w3wp.exe\HKEY_LOCAL_MACHINE 레지스트리 키를 삭제합니다.
ETW 도구 tracerpt.exe 실행하여 로그에서 추적 정보를 구문 분석합니다.
tracerpt.exe .\w3wp.etl -o -report