Включить EPA для NTLM - нужно или нет ? - Компьютерный форум OSzone.net

Доброе время суток. Наткнулся на 1 статью про усиление безопасности LM, NTLM, NTLMv2 в WinSRV.
Там есть такоие пункты:

Цитата:

Включаем EPA для NTLM

Если речь про NTLMv2-аутентификацию в домене, то включается так:

Ключ реестра HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ LSA \ дополняется DWORD32-значением SuppressExtendedProtection, которое ставится в ноль. Логика простая – это значение указывает, при работе каких протоколов подавлять генерацию CBT. Если в единицу поставить первый бит (т.е. SuppressExtendedProtection = 1), то CBT не будут генериться при работе NTLMv2, если второй – то при работе Kerberos. Соответственно, установка SuppressExtendedProtection в тройку выключает механизм и для NTLM, и для Kerberos, а в нуль – включает.

Включаем EPA для Telnet Server

Да, даже для такой некрофилии есть способ улучшить проверку подлинности. Telnet server в Windows Server умеет использовать NTLM изначально (чтобы не передавать учётные данные открытым текстом), и в нём тоже можно закрутить гайки, чтобы использовался именно NTLMv2 и с EPA. Это несложно – надо взять ключ реестра HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ TelnetServer \ 1.0 \, создать в нём DWORD32 ExtendedProtection и поставить туда единицу, если хочется, чтобы CBT анализировались, и двойку – если хочется, чтобы требовались.

Включаем EPA для SMB-хранилищ

Для того, чтобы при доступе к обычной “файловой шаре” использовался исключительно NTLMv2, нам надо будет чуток поправить настройки сервиса LanmanServer. Мы зайдём в ключ реестра HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ LanmanServer \ Parameters \ и создадим там DWORD32-параметр SmbServerNameHardeningLevel. Нам надо будет выставить этот параметр как минимум в единицу – чтобы данный сервер принимал от клиентов EPA-запросы, и в двойку, если мы хотим жёстко ограничить работу с данным сервером только протоколом NTLMv2 (безусловно, из Lan Manager – семейства – в случае работы с Kerberos CBT будут присылаться без доп.настроек).

В случае включения этой настройки гарантированно станут недоступны общие папки, расположенные на не-доменных хостах Windows XP – но, думается, это не то чтобы минус, а даже скорее плюс – крайне сомнительно, что в современном домене на подобный сценарий может быть что-то завязано.

Включаем EPA для HTTP

Для включения проверки CBT у входящих аутентификаций поверх HTTP (это может быть и digest, и NTLM), нужно будет взять IIS версии 7.5 или старше, найти в его конфигурации ( system.webServer / security / authentication / windowsAuthentication ) параметр < extendedProtection >, в котором будет элемент tokenChecking, который надо установить в единицу.

Учтите, данный параметр весьма сильно влияет на вопросы совместимости. Убедитесь, что для начала на всех ваших серверных системах есть его поддержка и включен приём/обработка данного параметра, а после – что все сторонние продукты, использующие, например, NTLM-аутентификацию для прокси, поддерживают именно NTLMv2 и умеют создавать/читать CBT. Включение EPA с гарантией похоронит NTLMv1.

Убедитесь, что подключающиеся клиенты отправляют CBT – данная настройка реально улучшит безопасность, но повлияет на множество механизмов – например, на подключения Outlook с использованием RPC over HTTPS и модификаций данного механизма (который до сих пор использует NTLM). Если поставить у IIS вышеупомянутый параметр tokenChecking в двойку, а не единицу, CBT будут не accepted, а required, что приведёт, допустим, к гарантированному отбою для обычной Windows XP, где не установлен нужный патч, не включён механизм EPA в явном виде, и не включена отправка NTLMv2 (см. настройку LM Compatibility в части статьи про LM).

В общем, теперь перейдём к настройке NTLMv2 – который мы будем закапывать уже в следующей статье про Kerberos. Ещё раз подчеркну – упомянутые выше техники позволяют практически полностью исключить работу NTLMv1 в домене даже на базе XP / 2003 (за исключением разве что работы поверх HTTP – всё ж IIS 7.5 будет только с Windows Server 2008 R2) и перейти на более безопасный NTLMv2.

- Не могу понять насколько будет польза или вред от этой рекомендации (4 позиции, ну telnet можно не в счет), если кому не сложно, объясните пожалуйста.