Включить ntlmv2 windows 7

Обновлено: 04.07.2024

Безопасное использование протоколов семейства Lan Manager (NTLMv2 в частности)

Прощаемся с LM
Возможные побочные следствия отключения LM
Полное отключение LM
Выключаем хранение LM-хэшей
Удаление хранящихся LM-хэшей
Выключение отправки LM-запроса и LM-ответа по сети
Препятствование генерации LM-хэшей
Прощаемся с NTLMv1
То, что будет иметь потенциальные проблемы от отключения NTLMv1
PPP-соединения и NTLMv1
Защита RPC-запросов
Защита RDP Gateway от использования NTLMv1
Включаем Extended Protection for Authentication
Используем группу Protected Users
Настраиваем NTLMv2

Прощаемся с LM

Поэтому всё плохо и LM мы будем выключать.

Возможные побочные следствия отключения LM

Полное отключение LM

Отключение будет состоять из выключения отправки/приёма протокола LM аутентифицирующими системами, а также выключения хранения LM-хэшей. Да, и ещё мы почистим домен от них.

Выключаем хранение LM-хэшей

Удаление хранящихся LM-хэшей

Вкратце это будет выглядеть так (я опишу сие крайне рамочно, т.к. reverse engineering Windows Server официально считается делом неправильным).

Данный метод, конечно, не рекомендуется к выполнению, и приводится исключительно как демонстрация того, что всё же очистить LM-хэши можно.

Теперь перейдём к сетевой части.

Выключение отправки LM-запроса и LM-ответа по сети

Данный параметр будет нужен, чтобы в сетевом трафике никогда не появлялись значения LM-хэшей. Для этого есть стандартная и древняя (с Windows 2000 Server) настройка, которая в общем-то будет содержать в себе достаточно интересную логику использования (по разному обрабатываться на обычных системах и на DC), но в нашем случае, чтобы сэкономить время изложения, мы сразу включим её на самый максимум:

Такая настройка (она, если что, лежит в Computer Configuration \ Windows Settings \ Security Settings \ Local Policies \ Security Options ) будет гарантировать то, что LM-хэши не будут ни отправляться, ни приниматься ни одной системой, подпадающей под эту политику.

Препятствование генерации LM-хэшей

Прощаемся с NTLMv1

То, что будет иметь потенциальные проблемы от отключения NTLMv1

В остальном, если проблема наблюдается у устройств, которые умеют подключаться к shares (различные принтеры-сканеры), обычно она решается обновлением ПО.

ОК, теперь выключим NTLMv1 везде, где ещё не выключили.

PPP-соединения и NTLMv1

Защита RPC-запросов

В этом поле на самом деле 4 настройки, но нам показывают две, а настроить надо для достижения нашей цели вообще одну.

Очень важно, чтобы данная настройка применялась на все хосты, потому что до NT 6.0 она не является дефолтной, т.е. надо, чтобы XP и 2003и системы явно поняли, что надо использовать NTLMv2 для RPC.

Защита RDP Gateway от использования NTLMv1

Включаем Extended Protection for Authentication

Механизм появляется в Windows 7 / Windows Server 2008 R2, но патч, реализующий его, есть и для XP / 2003.

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

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

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

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

Используем группу Protected Users

Начиная с Windows Server 2012 R2, появляется дополнительная возможность по решению проблем с NTLM. Эта возможность реализуется через новую группу с названием Protected Users.

Вы можете научить LSASS старых версий Windows работать с Protected Users, установив обновление KB 2871997.

Что же добавляет членство учётной записи пользователя в Protected Users?

Настраиваем NTLMv2

Данные настройки, применившись, начнут записывать в журналы операций ситуации, когда доменные учётные записи зачем-то аутентифицировались по NTLM, а не по Kerberos, что даст пищу для размышлений и траблшутинга работы Kerberos.

Напоследок

Надеюсь, что данная статья поможет вам в задаче улучшения безопасности корпоративной сети.

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

В рамках данного материала мы будем рассматривать сознательно упрощенное представление процедур аутентификации, достаточное для понимания базового принципа работы, впоследствии данные знания могут быть углублены путем изучения специализированной литературы.

Для начала внесем ясность в термины. Многие путают понятия аутентификации и авторизации, хотя это различные процедуры.

Аутентификация - происходит от английского слова authentication, которое можно перевести как идентификация или проверка подлинности. Это полностью отражает суть процесса - проверка подлинности пользователя, т.е. мы должны удостовериться, что пользователь, пытающийся получить доступ к системе именно тот, за кого себя выдает.
Авторизация - перевод слова authorization означает разрешение, т.е. проверка прав доступа к какому-либо объекту. Процесс авторизации может быть применен только к аутентифицированному пользователю, так как перед тем, как проверять права доступа, мы должны выяснить личность объекта, которому мы собираемся предоставить какие-либо права.

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

Точно также, сотрудник полиции, остановив трудового мигранта и проверив его паспорт, просит разрешение на работу, если разрешения нет, то зарубежный гость успешно прошел аутентификацию, но провалил авторизацию. Если аутентификация не пройдена, то до авторизации дело не дойдет.

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

Локальная аутентификация

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

Затем служба LSA обращается к диспетчеру учетных записей безопасности (SAM) и сообщает ему имя пользователя. Диспетчер обращается в базу SAM и извлекает оттуда хэш пароля указанного пользователя, сгенерированный при создании учетной записи (или в процессе смены пароля).

Затем LSA сравнивает хэш введенного пароля и хэш из базы SAM, в случае их совпадения аутентификация считается успешной, а хэш введенного пароля помещается в хранилище службы LSA и находится там до окончания сеанса пользователя.

В случае входа пользователя в домен, для аутентификации используются иные механизмы, прежде всего протокол Kerberos, однако, если одна из сторон не может его использовать, по согласованию могут быть использованы протоколы NTLM и даже устаревший LM. Работу этих протоколов мы будем рассматривать ниже.

LAN Manager (LM)

Протокол LAN Manager возник на заре зарождения локальных сетей под управлением Windows и впервые был представлен в Windows 3.11 для рабочих групп, откуда перекочевал в семейство Windows 9.х. Мы не будем рассматривать этот протокол, так как в естественной среде он уже давно не встречается, однако его поддержка, в целях совместимости, присутствует до сих пор. И если современной системе поступит запрос на аутентификацию по протоколу LM, то, при наличии соответствующих разрешений, он будет обработан.

Что в этом плохого? Попробуем разобраться. Прежде всего разберемся, каким образом создается хэш пароля для работы с протоколом LM, не вдаваясь в подробности обратим ваше внимание на основные ограничения:

Пароль регистронезависимый и приводится к верхнему регистру.
Длина пароля - 14 символов, более короткие пароли дополняются при создании хэша нулями.
Пароль делится пополам и для каждой части создается свой хэш по алгоритму DES.

Исходя из современных требований к безопасности можно сказать, что LM-хэш практически не защищен и будучи перехвачен очень быстро расшифровывается. Сразу оговоримся, прямое восстановление хэша невозможно, однако в силу простоты алгоритма шифрования возможен подбор соответствующей паролю комбинации за предельно короткое время.

А теперь самое интересное, LM-хэш, в целях совместимости, создается при вводе пароля и хранится в системах по Windows XP включительно. Это делает возможной атаку, когда системе целенаправленно присылают LM-запрос и она его обрабатывает. Избежать создания LM-хэша можно изменив политику безопасности или используя пароли длиннее 14 символов. В системах, начиная с Windows Vista и Server 2008, LM-хэш по умолчанию не создается.

NT LAN Manager (NTLM)

Новый протокол аутентификации появился в Windows NT и благополучно, с некоторыми изменениями, дожил до наших дней. А до появления Kerberos в Windows 2000 был единственным протоколом аутентификации в домене NT.

Сегодня протокол NTLM, точнее его более современная версия NTLMv2, применяются для аутентификации компьютеров рабочих групп, в доменных сетях Active Directory по умолчанию применяется Kerberos, однако если одна из сторон не может применить этот протокол, то по согласованию могут быть использованы NTLMv2, NTLM и даже LM.

Принцип работы NTLM имеет много общего с LM и эти протоколы обратно совместимы, но есть и существенные отличия. NT-хэш формируется на основе пароля длиной до 128 символов по алгоритму MD4, пароль регистрозависимый и может содержать не только ACSII символы, но и Unicode, что существенно повышает его стойкость по сравнению с LM.

Как происходит работа по протоколу NTLM? Рассмотрим следующую схему:

Допустим локальный компьютер хочет получить доступ к некоторому файловому ресурсу на другом ПК, который мы будем считать сервером, при этом совсем не обязательно наличие на этом ПК северной ОС или серверных ролей. С точки зрения протокола NTLM клиент это тот, кто обращается, сервер - к кому обращаются.

Зашифрованный хэшем пароля запрос сервера называется ответом NTLM и передается обратно серверу, сервер извлекает из хранилища SAM хэш пароля того пользователя, чье имя было ему передано и выполняет аналогичные действия с запросом сервера, после чего сравнивает полученный результат с ответом NTLM. Если результаты совпадают, значит пользователь клиента действительно тот, за кого себя выдает, и аутентификация считается успешной.

В случае доменной аутентификации процесс протекает несколько иначе. В отличие от локальных пользователей, хэши паролей которых хранятся в локальных базах SAM, хэши паролей доменных пользователей хранятся на контроллерах доменов. При входе в систему LSA отправляет доступному контроллеру домена запрос с указанием имени пользователя и имени домена и дальнейший процесс происходит как показано выше.

В случае получения доступа к третьим ресурсам схема также немного изменяется:

Как видим, хэш пароля ни при каких обстоятельствах по сети не передается. Хэш введенного пароля хранит служба LSA, хэши паролей пользователей хранятся либо в локальных хранилищах SAM, либо в хранилищах контроллера домена.

Но несмотря на это, протокол NTLM на сегодняшний день считаться защищенным не может. Слабое шифрование делает возможным достаточно быстро восстановить хэш пароля, а если использовался не только NTLM, а еще и LM-ответ, то и восстановить пароль.

Но и перехваченного хэша может оказаться вполне достаточно, так как NTLM-ответ генерируется на базе пароля пользователя и подлинность клиента сервером никак не проверяется, то возможно использовать перехваченные данные для неавторизованного доступа к ресурсам сети. Отсутствие взаимной проверки подлинности также позволяет использовать атаки плана человек посередине, когда атакующий представляется клиенту сервером и наоборот, устанавливая при этом два канала и перехватывая передаваемые данные.

NTLMv2

Осознавая, что протокол NTLM не соответствует современным требованиям безопасности, с выходом Windows 2000 Microsoft представила вторую версию протокола NTLMv2, который был серьезно доработан в плане улучшений криптографической стойкости и противодействия распространенным типам атак. Начиная с Windows 7 / Server 2008 R2 использование протоколов NTLM и LM по умолчанию выключено.

Сразу рассмотрим схему с контроллером домена, в случае его отсутствия схема взаимодействия не меняется, только вычисления, производимые контроллером домена, выполняются непосредственно на сервере.

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

Запрос сервера объединяется с запросом клиента и от этой последовательности вычисляется HMAC-MD5 хэш. После чего от данного хэша берется еще один HMAC-MD5 хэш, ключом в котором выступает NT-хэш пароля пользователя. Получившийся результат называется NTLMv2-ответом и вместе с запросом клиента пересылается серверу.

Криптостойкость данного алгоритма является актуальной и на сегодняшний день, известно только два случая взлома данного хэша, один из них произведен компанией Symantec в исследовательских целях. Можно с уверенностью сказать, что в настоящий момент нет массовых инструментов для атак на NTLMv2, в отличие от NTLM, взломать который может любой вдумчиво прочитавший инструкцию школьник.

Сервер, получив NTLMv2-ответ и запрос клиента, объединяет последний с запросом сервера и также вычисляет HMAC-MD5 хэш, затем передает его вместе с ответом контроллеру домена. Тот извлекает из хранилища сохраненный хэш пароля пользователя и производит вычисления над HMAC-MD5 хешем запросов сервера и клиента, сравнивая получившийся результат с переданным ему NTLMv2-ответом. В случае совпадения серверу возвращается ответ об успешной аутентификации.

При этом, как вы могли заметить, NTLMv2, также, как и его предшественник, не осуществляет взаимную проверку подлинности, хотя в некоторых материалах в сети это указывается.

Настройки безопасности

Теперь, когда вы имеете представление о работе протоколов аутентификации самое время поговорить о настройках безопасности. NTLMv2 вполне безопасный протокол, но если система настроена неправильно, то злоумышленник может послать NTLM или LM запрос и получить соответствующий ответ, который позволит успешно осуществить атаку.

За выбор протокола аутентификации отвечает локальная или групповая политика. Откроем редактор политик и перейдем в Конфигурация компьютера - Конфигурация Windows - Политики безопасности - Локальные политики - Параметры безопасности, в этом разделе найдем политику Сетевая безопасность: уровень проверки подлинности LAN Manager.

В этом же разделе находится политика Сетевая безопасность: не хранить хэш-значения LAN Manager при следующей смене пароля, которая запрещает создание LM-хэша, по умолчанию активна начиная с Vista / Server 2008.

В нашей же политике мы видим широкий выбор значений, очевидно, что сегодня безопасными могут считаться политики начиная с Отправлять только NTLMv2-ответ и ниже по списку.

Эти же значения можно задать через реестр, что удобно в сетях уровня рабочей группы, для этого в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lsa нужно создать параметр DWORD с именем LmCompatibilityLevel, который может принимать значения от 0 до 5. Рассмотрим их подробнее:

Наименование настройки	Клиентский компьютер	Контроллер домена	Lm Compatibility Level
Отправлять LM- и NTLM-ответы	Клиентские компьютеры используют LM и NTLM аутентификацию , и никогда не используют сеансовую безопасность NTLMv2.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	0
Отправлять LM- и NTLM- использовать сеансовую безопасность NTLMv2	Клиентские компьютеры используют LM и NTLM аутентификацию, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	1
Отправлять только NTLM-ответ	Клиентские компьютеры используют проверку подлинности NTLMv1, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	2
Отправлять только NTLMv2-ответ	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	3
Отправлять только NTLMv2-ответ. Отказывать LM.	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена отказываются принимать аутентификацию LM, и будут принимать только NTLM и NTLMv2.	4
Отправлять только NTLMv2-ответ. Отказывать LM и NTLM.	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена отказываются принимать аутентификацию LM и NTLM, и будут принимать только NTLMv2.	5

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

После того, как клиент пройдет аутентификацию формируется ключ сеанса, который используется для подтверждения подлинности при дальнейшем взаимодействии. Ключ сеанса NTLM основан только на NT-хэше и будет одинаковым до тех пор, пока клиент не поменяет пароль пользователя. Какие угрозы безопасности это несет пояснять, нам кажется, не надо. Сеансовая безопасность NTLMv2 подразумевает вычисление ключа сеанса с использованием не только NT-хэша, но и запросов сервера и клиента, что делает ключ уникальным и гораздо более стойким к возможным атакам. При этом данная возможность может быть использована совместно с NTLM или LM аутентификацией.

Мы надеемся, что данный материал поможет вам глубже понять процессы аутентификации в системах Windows. В следующей части мы подробно остановимся на устройстве и работе протокола Kerberos.

В этой статье описывается, как включить проверку подлинности NTLM 2.

Применяется к: Windows 10 — все выпуски
Исходный номер КБ: 239869

Сводка

Недавние улучшения компьютерного оборудования и алгоритмов программного обеспечения сделали эти протоколы уязвимыми для широко опубликованных атак для получения паролей пользователей. В своих постоянных усилиях по доставке более безопасных продуктов для своих клиентов Корпорация Майкрософт разработала усовершенствование под названием NTLM версии 2, которое значительно улучшает механизмы проверки подлинности и безопасности сеансов. NTLM 2 доступен для Windows NT 4.0 с момента выпуска Пакет обновления 4 (SP4) и поддерживается в Windows 2000 г. Вы можете добавить поддержку NTLM 2 в Windows 98, установив клиентские расширения Active Directory.

После обновления всех компьютеров, основанных на Windows 95, Windows 98, Windows 98 Second Edition и Windows NT 4.0, вы можете значительно повысить безопасность организации, настроив клиентов, серверов и контроллеров домена, чтобы использовать только NTLM 2 (не LM или NTLM).

Дополнительная информация

При установке расширений клиентов Active Directory на компьютере с Windows 98 автоматически устанавливаются системные файлы, которые обеспечивают поддержку NTLM 2. Эти файлы Secur32.dll, Msnp32.dll, Vredir.vxd и Vnetsup.vxd. При удалении клиентского расширения Active Directory системные файлы NTLM 2 не удаляются, так как файлы предоставляют расширенные функции безопасности и исправления, связанные с безопасностью.

Чтобы проверить версию установки:

Прежде чем включить проверку подлинности NTLM 2 для 98 Windows 98 клиентов, убедитесь, что все контроллеры домена для пользователей, которые войдите в сеть из этих клиентов, работают Windows NT 4.0 Пакет обновления 4 или более поздней. (Контроллеры домена могут работать Windows NT 4.0 Пакет обновления 6, если клиент и сервер присоединяются к разным доменам.) Конфигурация контроллера домена не требуется для поддержки NTLM 2. Необходимо настроить контроллеры домена только для отключения поддержки проверки подлинности NTLM 1 или LM.

Включение клиентов NTLM 2 для Windows 95, Windows 98 или Windows 98 Second Edition

В этот раздел, описание метода или задачи включены действия, содержащие указания по изменению параметров реестра. Однако неправильное изменение параметров реестра может привести к возникновению серьезных проблем. Поэтому следует в точности выполнять приведенные инструкции. Для дополнительной защиты создайте резервную копию реестра, прежде чем редактировать его. Так вы сможете восстановить реестр, если возникнет проблема. Дополнительные сведения о том, как создать и восстановить реестр, щелкните следующий номер статьи, чтобы просмотреть статью в базе знаний Майкрософт:
322756 Создание резервной копии и восстановление реестра Windows

Чтобы включить Windows 95, Windows 98 или Windows 98 Second Edition для проверки подлинности NTLM 2, установите клиент служб Directory. Чтобы активировать NTLM 2 для клиента, выполните следующие действия:

Начните редактор реестра (Regedit.exe).

Найдите и щелкните следующий ключ в реестре: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control

Создайте ключ реестра LSA в ключевых реестрах, перечисленных выше.

В меню Изменить нажмите кнопку Добавить значение, а затем добавьте следующее значение реестра:
Имя значения: LMCompatibility
Тип данных: REG_DWORD
Значение: 3
Допустимый диапазон: 0,3
Описание. Этот параметр указывает режим проверки подлинности и безопасности сеансов, которые будут использоваться для сетевых логотипов. Это не влияет на интерактивные логотипы.

Уровень 0 . Отправка ответа LM и NTLM; никогда не используйте безопасность сеанса NTLM 2. Клиенты будут использовать проверку подлинности LM и NTLM и никогда не будут использовать безопасность сеансов NTLM 2; Контроллеры домена принимают проверку подлинности LM, NTLM и NTLM 2.

Чтобы включить NTLM 2 для Windows 95 клиентов, установите клиент распределенной файловой системы (DFS), Обновление WinSock 2.0 и Microsoft DUN 1.3 для Windows 2000 г.

Закройте редактор реестра.

Для справки, полный диапазон значений для значения LMCompatibilityLevel, поддерживаемого Windows NT 4.0 и Windows 2000:

Можно настроить минимальную безопасность, используемую для программ, которые используют поставщика поддержки безопасности NTLM(SSP), изменяя следующий ключ реестра. Эти значения зависят от значения LMCompatibilityLevel:

Начните редактор реестра (Regedit.exe).

Найдите следующий ключ в реестре: HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\LSA\MSV1_0

В меню Изменить нажмите кнопку Добавить значение, а затем добавьте следующее значение реестра:
Имя значения: NtlmMinClientSec
Тип данных: REG_WORD
Значение: одно из значений ниже:

Закройте редактор реестра.

Если клиент/серверная программа использует SSP NTLM (или использует безопасный вызов удаленной процедуры [RPC], который использует SSP NTLM) для обеспечения безопасности сеанса для подключения, тип безопасности сеанса для использования определяется следующим образом:

Вы можете использовать значение NtlmMinClientSec, чтобы вызвать подключение к клиенту или серверу, чтобы договориться о заданном качестве безопасности сеанса или не добиться успеха. Однако следует отметить следующие элементы:

Аутентификация в системах Windows. Часть 1 - NTLM-01

authentication

идентификация

проверка подлинности

Авторизация - перевод слова authorization означает разрешение, т.е. проверка прав доступа к какому-либо объекту. Процесс авторизации может быть применен только к аутентифицированному пользователю, так как перед тем, как проверять права доступа, мы должны выяснить личность объекта, которому мы собираемся предоставить какие-либо права.

Локальная аутентификация

Аутентификация в системах Windows. Часть 1 - NTLM-02

LAN Manager (LM)

Пароль регистронезависимый и приводится к верхнему регистру.
Длина пароля - 14 символов, более короткие пароли дополняются при создании хэша нулями.
Пароль делится пополам и для каждой части создается свой хэш по алгоритму DES.

NT LAN Manager (NTLM)

Как происходит работа по протоколу NTLM? Рассмотрим следующую схему:

Аутентификация в системах Windows. Часть 1 - NTLM-03

В случае получения доступа к третьим ресурсам схема также немного изменяется:

Аутентификация в системах Windows. Часть 1 - NTLM-04

NTLMv2

Аутентификация в системах Windows. Часть 1 - NTLM-05

Настройки безопасности

За выбор протокола аутентификации отвечает локальная или групповая политика. Откроем редактор политик и перейдем в Конфигурация компьютера - Конфигурация Windows - Политики безопасности - Локальные политики - Параметры безопасности, в этом разделе найдем политикуСетевая безопасность: уровень проверки подлинности LAN Manager.

Аутентификация в системах Windows. Часть 1 - NTLM-06

Эти же значения можно задать через реестр, что удобно в сетях уровня рабочей группы, для этого в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lsa нужно создать параметр DWORDс именем LmCompatibilityLevel, который может принимать значения от 0 до 5. Рассмотрим их подробнее:

Наименование настройки	Клиентский компьютер	Контроллер домена	Lm Compatibility Level
Отправлять LM- и NTLM-ответы	Клиентские компьютеры используют LM и NTLMаутентификацию, и никогда не используют сеансовую безопасность NTLMv2.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	0
Отправлять LM- и NTLM- использовать сеансовую безопасность NTLMv2	Клиентские компьютеры используют LM и NTLM аутентификацию, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	1
Отправлять только NTLM-ответ	Клиентские компьютеры используют проверку подлинности NTLMv1, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	2
Отправлять только NTLMv2-ответ	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	3
Отправлять только NTLMv2-ответ. Отказывать LM.	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена отказываются принимать аутентификацию LM, и будут принимать только NTLM и NTLMv2.	4
Отправлять только NTLMv2-ответ. Отказывать LM и NTLM.	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена отказываются приниматьаутентификацию LM иNTLM, и будут принимать только NTLMv2.	5

Я надеюсь, что данный материал поможет вам глубже понять процессы аутентификации в системах Windows. В следующей части мы подробно остановимся на устройстве и работе протокола Kerberos.

Читайте также: