NTLM Overview
Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016
в этой статье для специалистов по ит описывается NTLM, все изменения в работе и ссылки на технические ресурсы для Windows проверки подлинности и NTLM для Windows Server 2012 и предыдущих версий.
Описание компонента
Проверка подлинности NTLM — это семейство протоколов проверки подлинности, включенных в файл Windows Msv1_0.dll. Протоколы проверки подлинности NTLM включают LAN Manager версий 1 и 2, а также NTLM версий 1 и 2. Протоколы проверки подлинности NTLM проверяют подлинность пользователей и компьютеров, основываясь на механизме запроса/подтверждения, доказывающем серверу или контроллеру домена, что пользователю известен пароль, связанный с учетной записью. При использовании протокола NTLM сервер ресурсов должен выполнять одно из следующих действий для проверки удостоверения пользователя или компьютера каждый раз, как возникает необходимость в новом маркере доступа:
Свяжитесь со службой проверки подлинности домена на контроллере домена, чтобы получить домен учетной записи компьютера или пользователя, если эта учетная запись является учетной записью в домене.
Если же учетная запись пользователя или компьютера является локальной учетной записью, то ее можно найти в локальной базе данных учетных записей.
Текущие приложения
Аутентификация NTLM по-прежнему поддерживается и обязательна для использования при выполнении аутентификации Windows с системами, настроенными как элемент рабочей группы. Аутентификация NTLM также используется для аутентификации при локальном входе на контроллеры вне домена. Аутентификация с использованием протокола Kerberos пятой версии является предпочтительным методом аутентификации в средах Active Directory, однако приложения Майкрософт и других поставщиков должны по-прежнему использовать NTLM.
Для того чтобы сократить использование протокола NTLM в ИТ-среде, необходимо знать требования развернутых в NTLM приложений, а также стратегии и шаги, необходимые для настройки вычислительных сред, использующих другие протоколы. Добавлены новые инструменты и параметры, которые помогут вам понять принципы использования NTLM и выборочно ограничить трафик NTLM. Сведения о том, как анализировать и ограничивать использование NTLM в своих средах, см. в разделе Вводные сведения об ограничении аутентификации NTLM (руководство по аудиту и ограничению использования NTLM).
Новые и измененные функции
Нет изменений в функциональных возможностях NTLM для Windows Server 2012.
Удаленные или устаревшие функциональные возможности
Удаленная или устаревшая функциональность для NTLM для Windows Server 2012 отсутствует.
Сведения о диспетчере сервера
NTLM нельзя использовать с диспетчером серверов. Для управления использованием проверки подлинности NTLM между компьютерными системами можно использовать параметры политики безопасности или групповые политики. В доменах протоколом проверки по умолчанию является Kerberos.
См. также раздел
В следующей таблице представлены материалы по NTLM и другим технологиям проверки подлинности Windows.
Отключение NTLM аутентификации в домене Windows
NTLM (NT LAN Manager) – это довольно старый протокол аутентификации Microsoft, который появился еще в Windows NT. Несмотря на то, что еще в Windows 2000 Майкрософт внедрила более безопасный протокол аутентификации Kerberos, NTLM (в основном это NTLMv2) широко используется для аутентификации в Windows сетях до сих пор. В этом статье мы рассмотрим особенности процесс отключения протокола NTLMv1 и NTLMv2, и перехода на Kerberos в домене Active Directory.
Основные проблема NTLMv1 – слабое шифрование, хранение хэша пароля в оперативной памяти в службе LSA, который может извлечь различными утилитами (типа mimikatz) и использовать хэш для дальнейших атак, отсутствие взаимной проверки подлинности клиента и сервера, что делает вполне реальными атаки перехвата данных и неавторизованного доступа к ресурсам сети (утилиты типа Responder могут перехватывать данные NTLM, передаваемые по сети и использовать их для доступа к сетевым ресурсам) и ряд других уязвимостей.
Часть этих недостатков исправлена в более новой версии NTLMv2, который использует более криптостойкие алгоритмы шифрования и позволяет предотвратить популярные атаки на NTLM. Начиная с Windows 7 / Windows Server 2008 R2 использование NTLMv1 и LM для авторизации по умолчанию выключено.
Переключаемся на использование NTLMv2
Если вы задумались полностью отказаться от NTLM в своем домене, сначала нужно убедиться, что у вас не используется его более уязвимая версия- NTLMv1. Вероятно в вашей сети имеется ряд устаревших устройств или служб, которые все еще используют аутентификацию NTLMv1 вместо NTLMv2 (или Kerberos). Поэтому прежде, чем прибегнуть к его полному отключению прочитайте раздел этой статьи по аудиту событий авторизации с помощью NTLM.
В первую очередь администратору домена нужно убедиться, что в его сети запрещено использовать NTLM или LM для авторизации, т.к. в некоторых случаях атакующий может с помощью специальных запросов получить ответ на NTLM/LM запрос.
Network Security: LAN Manager authentication level (Сетевая безопасность: уровень проверки подлинности LAN Manager).
В настройках политики есть 6 опций:
Политики использования NTLM аутентификации расположены в порядке возрастания их безопасности. По умолчанию в Windows 7 и выше используется настройка Send NTLMv2 response only (Отправлять только NTLMv2-ответ). При этой настройке клиентские компьютеры используют NTLMv2 аутентификацию, но контролеры домены принимают LM, NTLM, и NTLMv2 запросы.
Вы можете изменить значение политики на более безопасную 6 опцию — “Send NTLMv2 response only. Refuse LM & NTLM”. При этой политике контролеры домена также будут отвергать запросы LM и NTLM.
Также вы можете отключить NTLMv1 через реестр. Для этого в ветке
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa нужно создать параметр DWORD с именем LmCompatibilityLevel и значением от 0 до 5. Значение 5 соответствует значению политики «Отправлять только NTLMv2-ответ. Отказывать LM и NTLM».
Не забудьте применить эту политику для контроллеров домена.
Если вы убедились, что у вас не используется NTLMv1, вы можете пойти дальше и попытаться отказаться от NTLMv2. NTLMv2 хотя и более защищенный протокол аутентификации, но все равно существенно проигрывает Kerberos в плане безопасности (хотя уязвимостей в NTLMv2 намного меньше, чем в первой версии протокола, все-таки существуют возможности перехвата и повторного использования данных, и отсутствует взаимная аутентификации).
Главная риск отключения NTLM – возможное использование в домене устаревших или некорректно настроенных приложений, которые все еще могут использовать проверку подлинности NTLM, и для перехода на Kerberos их придется обновлять или настраивать особым образом.
Аудит событий NTLM аутентификации в домене
Перед полным отключением NTLM в домене и переходе на Kerberos желательно убедиться, что в домене не осталось приложений, которые требуют и используют NTLM авторизацию.
Аналогичным образом включите политику Network Security: Restrict NTLM: Audit Incoming NTLM Traffic, установив ее значение на Enable auditing for domain accounts.
Можно проанализировать события на каждом сервере, или собрать все события в центральный Event Log.
Вам нужно собрать события от Microsoft-Windows-Security-Auditing c Event ID 4624 – An Account was successfully logged on. Обратите внимание на информацию в секции “Detailed Authentication Information”. Если в строке Authentication Package указано NTLM, значит для аутентификации этого пользователя использовался протокол NTLM.
Теперь обратите внимание на значение Package Name (NTLM only). Здесь должно быть указано какой протокол (LM, NTLMv1 или NTLMv2) использовался для аутентификации. Таким образом вам нужно идентифицировать все сервера/приложения, которые используют устаревший протокол.
Например, для поиска всех событий аутентификации по NTLMv1 по всем контроллерам домена можно использовать такой PowerShell скрипт:
После того, как вы нашли пользователей и приложения, использующие NTLM в вашем домене, попробуйте перевести их на использование Kerberos (возможно с использованием SPN). Некоторые приложения достаточно донастроить для работы Kerberos авторизации (см. статьи Kerberos авторизация в IIS, использование Kerberos авторизация в браузерах). Из личного опыта: даже действительно большие коммерческие продукты иногда еще не перешли с использования NTLM на Kerberos, некоторые продукты требуют обновления или изменений конфигурации. Все сводится к определению того, какие приложения используют проверку подлинности NTLM, и теперь у вас есть способ для выяснения этого софта и устройств.
Те приложений, которые нельзя переключить на использование NTLM можно добавить в исключения, разрешив им использовать NTLM аутентификацию, даже если она отключена на уровне домена. Для этого используется политика Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain. В список исключений нужно добавить имена серверов, для аутентификации на которых можно использовать NTLM (конечно, в идеале этот список исключений должен быть пустым). Можно использовать знак подстановки *.
Полное отключение NTLM в домене Active Directory
Чтобы проверить, как будет работать аутентификация в различных приложениях в домене без использования NTLM, вы можете добавить учетные записи необходимых пользователей в доменную группу
Protected Users (группа доступна, начиная с Windows Server 2012 R2), членам которой можно аутентифицироваться только по протоколу Kerberos (нельзя использовать NTLM, Digest Authentication или CredSSP). Так вы можете проверить корректность Kerberos аутентификации пользователя в различных приложениях.
Теперь вы можете полностью отключить NTLM в домене с помощью групповой политики Network Security: Restrict NTLM: NTLM authentication in this domain.
В этой политике доступно 5 опций:
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
NTLM (NT LAN Manager)
NTLM (NT LAN Manager) — является протоколом сетевой аутентификации, разработанным фирмой Microsoft для Windows NT. Протоколы проверки подлинности NTLM включают LAN Manager версий 1 и 2, а также NTLM версий 1 и 2. Протоколы проверки подлинности NTLM проверяют подлинность пользователей и компьютеров, основываясь на механизме запроса/подтверждения, доказывающем серверу или контроллеру домена, что пользователю известен пароль, связанный с учетной записью. При использовании протокола NTLM сервер ресурсов должен выполнять одно из следующих действий для проверки удостоверения пользователя или компьютера каждый раз, как возникает необходимость в новом маркере доступа:
Содержание
Принцип работы NTLM
Принцип работы NTLM имеет много общего с LAN Manager [1] и эти протоколы обратно совместимы, но есть и существенные отличия. NT-хэш формируется на основе пароля длиной до 128 символов по алгоритму MD4, пароль регистрозависимый и может содержать не только ACSII символы, но и Unicode, что существенно повышает его стойкость по сравнению с LM. Работа происходит следующим способом(рис.1):
Рис.1 Принципе работы NTLM
Для получения доступа к ресурсу клиент направляет серверу запрос с именем пользователя. Сервер в ответ передает ему случайное число, называемое запросом сервера. Клиент зашифровывает данный запрос по алгоритму DES, используя в качестве ключа NT-хэш пароля, использую 40 или 56 битный ключ(хеш делится на три части и каждая часть шифрует запрос сервера отдельно), так как NT-хэш имеет 128 битную длину.
Зашифрованный хэшем пароля запрос сервера называется ответом NTLM и возвращается обратно серверу, сервер берет из SAM хэш пароля пользователя, чье имя было ему передано и выполняет те же самые действия с запросом сервера, и после сравнивает полученный результат с ответом от NTLM. При совпадении значений, аутентификация считается успешной, и это значит пользователь клиента действительно тот, за кого себя выдает.
При получении доступа третьими ресурсами схема изменяется(рис.2):
Рис.2 Принципе работы NTLM при получении доступа третьими ресурсами
Получив запрос от клиента, сервер направляет ему запрос сервера, но получив NTLM-ответ он не имеет возможности посчитать значение для проверки у себя на стороне, так как у него нету хэша пароля доменного пользователя, и тогда он переадресует NTLM-ответ контроллеру домена и отправляет ему свой запрос сервера. Получив эти данные, контроллер домена извлекает хэш указанного пользователя и вычисляет на основе запроса сервера проверочную последовательность, которую уже и сравнивает с полученным NTLM-ответом. Если они равны, на сервер отправляется сообщение, что аутентификация успешно пройдена.
Несмотря на на что, протокол NTLM на сегодняшний день считается слабым. Слабое шифрование делает возможным достаточно быстро восстановить хэш пароля, а если использовался не только NTLM, а еще и LM-ответ, то и восстановить пароль.
NTLMv2
Поэтому появляется вторая версия в которой учтены ошибки слабого шифрования и низкой криптостойкости. Здесь уже клиент, обращаясь к серверу сообщает ему имя пользователя и имя домена, а сервер в ответ передает ему случайное число, называемое «запрос сервера». В ответ клиент генерирует также случайное число, куда добавляется метка времени, которая называется «запрос клиента». Наличие метки времени позволяет избежать ситуации, когда атакующий первоначально накапливает перехваченные данные, а потом с их помощью осуществляет атаку.
Запрос сервера объединяется с запросом клиента и от этой последовательности вычисляется HMAC-MD5 хэш. Затем от данного хэша берется еще один HMAC-MD5 хэш, ключом в котором выступает NT-хэш пароля пользователя. Получившийся результат называется NTLMv2-ответом и вместе с запросом клиента пересылается серверу.
Сервер, получая NTLMv2-ответ и запрос клиента, соединяет полученные данные и также вычисляет HMAC-MD5 хэш, а после пересылает его вместе с ответом контроллеру домена. Тот берет из хранилища сохраненный хэш пароля пользователя и производит вычисления над HMAC-MD5 хешем запросов сервера и клиента, сравнивая получившийся результат с переданным ему NTLMv2-ответом. В случае совпадения серверу возвращается ответ об успешной аутентификации.
Использование версий протокола
NTLMv2 вполне безопасный протокол, но если система настроена неправильно, то злоумышленник может послать NTLM или LM запрос и получить соответствующий ответ, который позволит успешно осуществить атаку. Поэтому рассмотрим о политиках безопасности, За выбор протокола аутентификации отвечает локальная или групповая политика.
И становится очевидным, что сегодня безопасными могут считаться значения выше 3(Отправлять только NTLMv2 ответ). Записки IT специалистаТехнический блог специалистов ООО»Интерфейс»
Работая в среде Windows каждый системный администратор так или иначе сталкивается с системами аутентификации. Но для многих этот механизм представляет собой черный ящик, когда суть происходящих процессов остается неясна. В тоже время от правильной настройки аутентификации напрямую зависит безопасность сети, поэтому важно не только знать способы и протоколы, но и представлять их работу, хотя бы на общем уровне. В рамках данного материала мы будем рассматривать сознательно упрощенное представление процедур аутентификации, достаточное для понимания базового принципа работы, впоследствии данные знания могут быть углублены путем изучения специализированной литературы. Для начала внесем ясность в термины. Многие путают понятия аутентификации и авторизации, хотя это различные процедуры. Для аутентификации в компьютерных системах традиционно используется сочетания имени пользователя и некой секретной фразы (пароля), позволяющей определить, что пользователь именно тот, за кого себя выдает. Существуют также и иные способы аутентификации, например, по смарт-карте, но в данной статье мы их касаться не будем. Локальная аутентификация
Затем служба LSA обращается к диспетчеру учетных записей безопасности (SAM) и сообщает ему имя пользователя. Диспетчер обращается в базу SAM и извлекает оттуда хэш пароля указанного пользователя, сгенерированный при создании учетной записи (или в процессе смены пароля). Затем LSA сравнивает хэш введенного пароля и хэш из базы SAM, в случае их совпадения аутентификация считается успешной, а хэш введенного пароля помещается в хранилище службы LSA и находится там до окончания сеанса пользователя. В случае входа пользователя в домен, для аутентификации используются иные механизмы, прежде всего протокол Kerberos, однако, если одна из сторон не может его использовать, по согласованию могут быть использованы протоколы NTLM и даже устаревший LM. Работу этих протоколов мы будем рассматривать ниже. LAN Manager (LM)Протокол LAN Manager возник на заре зарождения локальных сетей под управлением Windows и впервые был представлен в Windows 3.11 для рабочих групп, откуда перекочевал в семейство Windows 9.х. Мы не будем рассматривать этот протокол, так как в естественной среде он уже давно не встречается, однако его поддержка, в целях совместимости, присутствует до сих пор. И если современной системе поступит запрос на аутентификацию по протоколу LM, то, при наличии соответствующих разрешений, он будет обработан. Что в этом плохого? Попробуем разобраться. Прежде всего разберемся, каким образом создается хэш пароля для работы с протоколом LM, не вдаваясь в подробности обратим ваше внимание на основные ограничения: Исходя из современных требований к безопасности можно сказать, что 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? Рассмотрим следующую схему: Чтобы получить доступ к ресурсу клиент направляет серверу запрос с именем пользователя. В ответ сервер передает ему случайное число, называемое запросом сервера. Клиент в свою очередь шифрует данный запрос по алгоритму DES, используя в качестве ключа NT-хэш пароля, однако, несмотря на то, что NT-хэш 128-битный, в силу технических ограничений используется 40 или 56 битный ключ (хеш делится на три части и каждая часть шифрует запрос сервера отдельно). Зашифрованный хэшем пароля запрос сервера называется ответом NTLM и передается обратно серверу, сервер извлекает из хранилища SAM хэш пароля того пользователя, чье имя было ему передано и выполняет аналогичные действия с запросом сервера, после чего сравнивает полученный результат с ответом NTLM. Если результаты совпадают, значит пользователь клиента действительно тот, за кого себя выдает, и аутентификация считается успешной. В случае доменной аутентификации процесс протекает несколько иначе. В отличие от локальных пользователей, хэши паролей которых хранятся в локальных базах SAM, хэши паролей доменных пользователей хранятся на контроллерах доменов. При входе в систему LSA отправляет доступному контроллеру домена запрос с указанием имени пользователя и имени домена и дальнейший процесс происходит как показано выше. В случае получения доступа к третьим ресурсам схема также немного изменяется:
Как видим, хэш пароля ни при каких обстоятельствах по сети не передается. Хэш введенного пароля хранит служба LSA, хэши паролей пользователей хранятся либо в локальных хранилищах SAM, либо в хранилищах контроллера домена. Но несмотря на это, протокол NTLM на сегодняшний день считаться защищенным не может. Слабое шифрование делает возможным достаточно быстро восстановить хэш пароля, а если использовался не только NTLM, а еще и LM-ответ, то и восстановить пароль. Но и перехваченного хэша может оказаться вполне достаточно, так как NTLM-ответ генерируется на базе пароля пользователя и подлинность клиента сервером никак не проверяется, то возможно использовать перехваченные данные для неавторизованного доступа к ресурсам сети. Отсутствие взаимной проверки подлинности также позволяет использовать атаки плана человек посередине, когда атакующий представляется клиенту сервером и наоборот, устанавливая при этом два канала и перехватывая передаваемые данные. NTLMv2Осознавая, что протокол NTLM не соответствует современным требованиям безопасности, с выходом Windows 2000 Microsoft представила вторую версию протокола NTLMv2, который был серьезно доработан в плане улучшений криптографической стойкости и противодействия распространенным типам атак. Начиная с Windows 7 / Server 2008 R2 использование протоколов NTLM и LM по умолчанию выключено. Сразу рассмотрим схему с контроллером домена, в случае его отсутствия схема взаимодействия не меняется, только вычисления, производимые контроллером домена, выполняются непосредственно на сервере. Запрос сервера объединяется с запросом клиента и от этой последовательности вычисляется HMAC-MD5 хэш. После чего от данного хэша берется еще один HMAC-MD5 хэш, ключом в котором выступает NT-хэш пароля пользователя. Получившийся результат называется NTLMv2-ответом и вместе с запросом клиента пересылается серверу. Криптостойкость данного алгоритма является актуальной и на сегодняшний день, известно только два случая взлома данного хэша, один из них произведен компанией Symantec в исследовательских целях. Можно с уверенностью сказать, что в настоящий момент нет массовых инструментов для атак на NTLMv2, в отличие от NTLM, взломать который может любой вдумчиво прочитавший инструкцию школьник. Сервер, получив NTLMv2-ответ и запрос клиента, объединяет последний с запросом сервера и также вычисляет HMAC-MD5 хэш, затем передает его вместе с ответом контроллеру домена. Тот извлекает из хранилища сохраненный хэш пароля пользователя и производит вычисления над HMAC-MD5 хешем запросов сервера и клиента, сравнивая получившийся результат с переданным ему NTLMv2-ответом. В случае совпадения серверу возвращается ответ об успешной аутентификации. При этом, как вы могли заметить, NTLMv2, также, как и его предшественник, не осуществляет взаимную проверку подлинности, хотя в некоторых материалах в сети это указывается. Настройки безопасностиТеперь, когда вы имеете представление о работе протоколов аутентификации самое время поговорить о настройках безопасности. NTLMv2 вполне безопасный протокол, но если система настроена неправильно, то злоумышленник может послать NTLM или LM запрос и получить соответствующий ответ, который позволит успешно осуществить атаку.
В нашей же политике мы видим широкий выбор значений, очевидно, что сегодня безопасными могут считаться политики начиная с Отправлять только NTLMv2-ответ и ниже по списку. Эти же значения можно задать через реестр, что удобно в сетях уровня рабочей группы, для этого в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lsa нужно создать параметр DWORD с именем LmCompatibilityLevel, который может принимать значения от 0 до 5. Рассмотрим их подробнее: Внимательный читатель, изучая данную таблицу, обязательно обратит внимание на сеансовую безопасность NTLMv2. Данная возможность, как и вообще все взаимодействие по NTLMv2, довольно плохо документированы, поэтому многие понимают смысл этой возможности неправильно. Но на самом деле все довольно несложно. После того, как клиент пройдет аутентификацию формируется ключ сеанса, который используется для подтверждения подлинности при дальнейшем взаимодействии. Ключ сеанса NTLM основан только на NT-хэше и будет одинаковым до тех пор, пока клиент не поменяет пароль пользователя. Какие угрозы безопасности это несет пояснять, нам кажется, не надо. Сеансовая безопасность NTLMv2 подразумевает вычисление ключа сеанса с использованием не только NT-хэша, но и запросов сервера и клиента, что делает ключ уникальным и гораздо более стойким к возможным атакам. При этом данная возможность может быть использована совместно с NTLM или LM аутентификацией. Мы надеемся, что данный материал поможет вам глубже понять процессы аутентификации в системах Windows. В следующей части мы подробно остановимся на устройстве и работе протокола Kerberos. Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал:  Привет, друзья! Сегодня я хочу рассказать вам о волшебных  Привет, друзья! Сегодня я хочу рассказать вам об очень  Привет, маленькие строители! Сегодня я расскажу вам |
Получив запрос от клиента, сервер точно также направит ему запрос сервера, но получив NTLM-ответ он не сможет вычислить значение для проверки на своей стороне, так как не располагает хэшем пароля доменного пользователя, поэтому он перенаправляет NTLM-ответ контроллеру домена и отправляет ему свой запрос сервера. Получив эти данные, контроллер домена извлекает хэш указанного пользователя и вычисляет на основе запроса сервера проверочную комбинацию, которую сравнивает с полученным NTLM-ответом, при совпадении серверу посылается сообщение, что аутентификация прошла успешно.
В этом же разделе находится политика Сетевая безопасность: не хранить хэш-значения LAN Manager при следующей смене пароля, которая запрещает создание LM-хэша, по умолчанию активна начиная с Vista / Server 2008.
