Назад | Перейти на главную страницу

«Анонимный вход» против «NTLM V1» Что отключить?

Работаем над тем, чтобы полностью избавиться от логинов NTLM V1 в среде AD; обнаружил много событий, почти все они от пользователя «Анонимный вход» (4624 события), другой 1 (4624 события) процент исходил от некоторых пользователей. Итак, у меня есть несколько вопросов.

Пожалуйста, дайте мне знать, если потребуется дополнительная информация.

Вопрос, который вы задали, «Что лучше: отключить« анонимный вход »(через настройки безопасности GPO) или заблокировать« NTLM V1 », не очень хороший вопрос, потому что эти две вещи не исключают друг друга. Вы можете делать и то, и другое, или только одно, и в разной степени. Здесь много оттенков серого, и вы не можете сжать его до черно-белого.

Отключение NTLMv1 - это вообще хорошая идея. Это сделано с LmCompatibilityLevel параметр реестра или через групповую политику. Помните, что один и тот же параметр имеет немного другое поведение в зависимости от того, является ли компьютер контроллером домена или членом домена.

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

Потенциальный риск при отключении NTLMv1 здесь заключается в нарушении обратной совместимости с очень старые клиенты Windows и, что более вероятно, клиенты сторонних производителей, которые не поддерживают NTLMv2. Вам придется их протестировать. Любая достаточно современная версия Windows с исправлениями будет обрабатывать NTLMv2 w / Session Security без каких-либо проблем (мы говорим как что-то вроде Server 2000 или выше).

Отключение анонимного входа в систему - совсем другое дело. Вы можете отключить возможность анонимных пользователей перечислять общие ресурсы, учетные записи SAM, ключи реестра, все или ничего из этих вещей или их комбинации. Чем больше вы ограничиваете анонимный вход, вы гипотетически повышаете свою безопасность, теряя при этом простоту использования и удобство. (например, ваши пользователи могут потерять возможность перечислять общие файлы или принтеры на сервере и т. д.)

Так что вы не можете сказать, какой из них лучше. Это два разных механизма, которые делают две совершенно разные вещи.

Событие 540 специфично для "сетевого" входа в систему, например, когда пользователь подключается к общей папке или принтеру через сеть. Это также идентификатор события в стиле Win 2003. Вы можете сказать, потому что это всего лишь 3 цифры. Соответствующие события в Vista / 2008 были преобразованы в 4-значные идентификаторы:

Эрик Фицджеральд сказал: Я дважды писал (здесь и здесь) о взаимосвязи между «старыми» идентификаторами событий (5xx-6xx) в WS03 и более ранних версиях Windows, а также между «новыми» идентификаторами событий безопасности (4xxx-5xxx). ) в Vista и последующих версиях.

Короче говоря, EventID (WS03) + 4096 = EventID (WS08) почти для всех событий безопасности в WS03.

Исключение составляют события входа в систему. События успешного входа в систему (540, 528) были свернуты в одно событие 4624 (= 528 + 4096). События сбоя входа в систему (529-537, 539) были свернуты в одно событие 4625 (= 529 + 4096).

Помимо этого, есть случаи, когда старые события были объявлены устаревшими (IPsec IIRC), а есть случаи, когда были добавлены новые события (DS Change). Это все новые приборы, и нет возможности «картирования» - например, новые события аудита DS Change дополняют старые события DS Access; они записывают что-то иное, чем старые события, поэтому нельзя сказать, что старое событие xxx = новое событие yyy, потому что они не эквивалентны. Старое событие означает одно, а новое событие означает другое; они представляют различные точки инструментария в ОС, а не только изменения форматирования в представлении событий в журнале.

Конечно, я объяснил ранее, почему мы изменили нумерацию событий и (в том же месте), почему разница составляет «+4096», а не что-то более понятное для человека, например «+1000». Суть в том, что схема событий отличается, поэтому, изменяя идентификаторы событий (и не используя их повторно), мы заставляем обновлять существующую автоматизацию, а не просто неверно интерпретировать события, когда автоматизация не знает версию Windows, которая произвел событие. Мы понимали, что это будет болезненно, но это далеко не так болезненно, как если бы каждый потребитель событий должен был знать и иметь специальный корпус для событий до и после Vista с одинаковыми идентификаторами, но с другой схемой.

Так что, если вам известны события безопасности до Vista, вы можете быстро перенести имеющиеся знания в Vista, добавив 4000, прибавив 100 и вычтя 4. Вы можете сделать это в уме.

Однако, если вы пытаетесь реализовать некоторую автоматизацию, вам следует избегать попыток создать диаграмму со столбцами «= 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