"익명 로그온" 대 "NTLM V1" 무엇을 비활성화해야 합니까?

"익명 로그온" 대 "NTLM V1" 무엇을 비활성화해야 합니까?

AD 환경에서 NTLM V1 로그인을 모두 제거하기 위해 노력하고 있습니다. 많은 이벤트를 발견했는데, 거의 모든 이벤트가 "익명 로그온"(4624 이벤트) 사용자로부터 발생했으며 다른 1(4624 이벤트)%는 일부 사용자로부터 발생했습니다. 그래서 여기에 몇 가지 질문이 있습니다.

  • GPO 보안 설정을 통해 "익명 로그온"을 비활성화하는 것이 더 낫습니까, 아니면 "NTLM V1" 연결을 차단하는 것이 더 낫습니까? 둘 중 하나 또는 둘 다에 어떤 위험이 있습니까? 이러한 로그온 이벤트는 대부분 다른 Microsoft 구성원 서버에서 발생합니다.
  • 익명 로그온은 항상 "NTLM V1"을 사용합니까? 즉, 익명 로그온이 표시되면 확실히 NTLM V1을 사용하고 있다고 가정할 수 있습니까?
  • 익명 로그온 이벤트 540과 4624의 차이점은 정확히 무엇입니까? -> 참고: 기능 수준은 2008 R2입니다.

추가 정보가 필요한 경우 알려주시기 바랍니다.

답변1

당신이 제기한 질문은,"(GPO 보안 설정을 통해) "익명 로그온"을 비활성화하는 것이 더 낫습니까, 아니면 "NTLM V1"을 차단하는 것이 더 낫습니까?, 이 두 가지가 상호 배타적이지 않기 때문에 그다지 좋은 질문은 아닙니다. 둘 다 할 수도 있고, 둘 다 할 수도 있고, 하나만 할 수도 있고, 정도는 다양합니다. 여기에는 회색 음영이 많이 있으며 이를 흑백으로 압축할 수 없습니다.

일반적으로 NTLMv1을 비활성화하는 것이 좋습니다. 이는 LmCompatibilityLevel레지스트리 설정이나 그룹 정책을 통해 수행됩니다 . 동일한 설정이라도 컴퓨터가 도메인 컨트롤러인지 도메인 구성원인지에 따라 동작이 약간씩 다르다는 점에 유의하세요.

Lm호환성수준

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

여기서 NTLMv1을 비활성화할 때 발생할 수 있는 잠재적인 위험은매우오래된 Windows 클라이언트, 그리고 NTLMv2를 사용하지 않는 타사 클라이언트일 가능성이 높습니다. 당신은 그것을 테스트해야 할 것입니다. 합리적으로 최신 패치가 적용된 Windows 버전은 세션 보안이 포함된 NTLMv2를 문제 없이 처리합니다(Server 2000 이상과 비슷하다고 말합니다).

익명 로그온을 비활성화하는 것은 완전히 다른 것입니다. 익명 사용자가 공유, SAM 계정, 레지스트리 키 등을 모두 열거하거나 전혀 열거하지 않거나 조합을 열거하는 기능을 비활성화할 수 있습니다. 익명 로그온을 더 많이 제한할수록 보안 상태가 강화되는 반면 사용 용이성과 편의성은 상실됩니다. (예: 사용자가 서버 등의 파일이나 프린터 공유를 열거하는 능력을 상실할 수 있습니다.)

그래서 당신은 실제로 어느 것이 무엇인지 말할 수 없습니다더 나은.둘 다 완전히 다른 두 가지 작업을 수행하는 두 가지 서로 다른 메커니즘입니다.

이벤트 540은 네트워크를 통해 공유 폴더나 프린터에 연결하는 사용자와 같은 "네트워크" 로그온에만 해당됩니다. 이는 또한 Win 2003 스타일의 이벤트 ID이기도 합니다. 3자리 숫자로 알 수 있습니다. Vista/2008의 해당 이벤트는 4자리 ID로 변환되었습니다.

Eric Fitzgerald는 다음과 같이 말했습니다. 저는 WS03과 이전 Windows 버전의 "이전" 이벤트 ID(5xx-6xx)와 "새" 보안 이벤트 ID(4xxx-5xxx) 간의 관계에 대해 두 번(여기 및 여기) 썼습니다. ) Vista 이상에서.

간단히 말해서 WS03의 거의 모든 보안 이벤트에 대한 EventID(WS03) + 4096 = EventID(WS08)입니다.

예외는 로그온 이벤트입니다. 로그온 성공 이벤트(540, 528)가 단일 이벤트 4624(=528 + 4096)로 축소되었습니다. 로그온 실패 이벤트(529-537, 539)가 단일 이벤트 4625(=529+4096)로 축소되었습니다.

그 외에 기존 이벤트가 더 이상 사용되지 않는 경우(IPsec IIRC)가 있고, 새 이벤트가 추가되는 경우(DS 변경)가 있습니다. 이는 모두 새로운 계측이므로 "매핑"이 불가능합니다. 예를 들어 새로운 DS 변경 감사 이벤트는 이전 DS 액세스 이벤트를 보완합니다. 그들은 이전 이벤트와 다른 것을 기록하므로 동일하지 않기 때문에 이전 이벤트 xxx = 새 이벤트 yyy라고 말할 수 없습니다. 이전 이벤트는 한 가지를 의미하고 새 이벤트는 다른 것을 의미합니다. 이는 로그의 이벤트 표현에 대한 형식 변경뿐만 아니라 OS의 다양한 계측 지점을 나타냅니다.

물론 우리가 이벤트 번호를 다시 매긴 이유와 그 차이가 "+1000"과 같이 좀 더 인간 친화적인 것이 아닌 "+4096"인 이유를 (같은 장소에서) 앞서 설명했습니다. 결론은 이벤트 스키마가 다르기 때문에 이벤트 ID를 변경하고 재사용하지 않음으로써 자동화가 Windows 버전을 알지 못할 때 이벤트를 잘못 해석하는 대신 기존 자동화를 강제로 업데이트한다는 것입니다. 이벤트를 제작했습니다. 우리는 그것이 고통스러울 것이라는 것을 깨달았지만 모든 이벤트 소비자가 ID는 동일하지만 스키마가 다른 Vista 이전 이벤트와 Vista 이후 이벤트를 인식하고 특별한 케이스를 보유해야 하는 것처럼 고통스럽지는 않습니다.

따라서 Vista 이전 보안 이벤트를 알고 있는 경우 4000을 더하고 100을 더하고 4를 빼면 기존 지식을 Vista로 신속하게 변환할 수 있습니다. 이 작업은 머릿속으로 수행할 수 있습니다.

그러나 일부 자동화를 구현하려는 경우 이벤트 ID 번호의 "=Vista" 열을 사용하여 차트를 만드는 것을 피해야 합니다. 이렇게 하면 이벤트 집합 하나를 잘못 구문 분석할 가능성이 높으며 다음과 같은 결과를 얻을 수 있기 때문입니다. 1:1 매핑이 없다는 점은 실망스럽습니다. 어떤 경우에는 매핑이 전혀 없습니다.

에릭

http://blogs.msdn.com/b/ericfitz/archive/2009/06/10/mapping-pre-vista-security-event-ids-to-security-event-ids-in-vista.aspx

관련 정보