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

NTLM Overview | Microsoft Docs

• 
  10/12/2016
• Чтение занимает 2 мин

В этой статье

Область применения. Windows Server (Semi-Annual Channel), Windows Server 2016Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016

В этой статье для ИТ Professional описывается NTLM, любые изменения в работе и предоставляются ссылки на технические ресурсы по проверке подлинности Windows и NTLM для Windows Server 2012 и предыдущих версий.This topic for the IT professional describes NTLM, any changes in functionality, and provides links to technical resources to Windows Authentication and NTLM for Windows Server 2012 and previous versions.

Описание функцииFeature description

Проверка подлинности NTLM — это семейство протоколов проверки подлинности, которые входят в0.dll Windows Msv1 _ .NTLM authentication is a family of authentication protocols that are encompassed in the Windows Msv1_0.dll. Протоколы проверки подлинности NTLM включают LAN Manager версий 1 и 2, а также NTLM версий 1 и 2.The NTLM authentication protocols include LAN Manager version 1 and 2, and NTLM version 1 and 2. Протоколы проверки подлинности NTLM выполняют проверку подлинности пользователей и компьютеров на основе / механизма реагирования на запрос, который доказывает серверу или контроллеру домена о том, что пользователь знает пароль, связанный с учетной записью.The NTLM authentication protocols authenticate users and computers based on a challenge/response mechanism that proves to a server or domain controller that a user knows the password associated with an account. При использовании протокола NTLM сервер ресурсов должен выполнять одно из следующих действий для проверки удостоверения пользователя или компьютера каждый раз, как возникает необходимость в новом маркере доступа:When the NTLM protocol is used, a resource server must take one of the following actions to verify the identity of a computer or user whenever a new access token is needed:

• Свяжитесь со службой проверки подлинности домена на контроллере домена, чтобы получить домен учетной записи компьютера или пользователя, если эта учетная запись является учетной записью в домене.Contact a domain authentication service on the domain controller for the computer’s or user’s account domain, if the account is a domain account.

• Если же учетная запись пользователя или компьютера является локальной учетной записью, то ее можно найти в локальной базе данных учетных записей.Look up the computer’s or user’s account in the local account database, if the account is a local account.

Текущие приложенияCurrent applications

Аутентификация NTLM по-прежнему поддерживается и обязательна для использования при выполнении аутентификации Windows с системами, настроенными как элемент рабочей группы.NTLM authentication is still supported and must be used for Windows authentication with systems configured as a member of a workgroup. Проверка подлинности NTLM также используется для проверки подлинности локального входа на — контроллеры, не являющиеся доменами.NTLM authentication is also used for local logon authentication on non-domain controllers. Проверка подлинности Kerberos версии 5 является предпочтительным методом проверки подлинности для Active Directoryных сред, но приложение, не — использующее Майкрософт или Microsoft, может по-прежнему использовать NTLM.Kerberos version 5 authentication is the preferred authentication method for Active Directory environments, but a non-Microsoft or Microsoft application might still use NTLM.

Для того чтобы сократить использование протокола NTLM в ИТ-среде, необходимо знать требования развернутых в NTLM приложений, а также стратегии и шаги, необходимые для настройки вычислительных сред, использующих другие протоколы.Reducing the usage of the NTLM protocol in an IT environment requires both the knowledge of deployed application requirements on NTLM and the strategies and steps necessary to configure computing environments to use other protocols. Добавлены новые инструменты и параметры, которые помогут вам понять принципы использования NTLM и выборочно ограничить трафик NTLM.New tools and settings have been added to help you discover how NTLM is used in order to selectively restrict NTLM traffic. Сведения о том, как анализировать и ограничивать использование NTLM в своих средах, см. в разделе Вводные сведения об ограничении аутентификации NTLM (руководство по аудиту и ограничению использования NTLM).For information about how to analyze and restrict NTLM usage in your environments, see Introducing the Restriction of NTLM Authentication to access the Auditing and restricting NTLM usage guide.

Новые и измененные функцииNew and changed functionality

Нет изменений в функциональности NTLM для Windows Server 2012.There are no changes in functionality for NTLM for Windows Server 2012 .

Удаленные или устаревшие функциональные возможностиRemoved or deprecated functionality

Отсутствует удаленная или устаревшая функциональность для NTLM для Windows Server 2012.There is no removed or deprecated functionality for NTLM for Windows Server 2012 .

Сведения о диспетчере сервераServer Manager information

NTLM нельзя использовать с диспетчером серверов.NTLM cannot be configured from Server Manager. Для управления использованием проверки подлинности NTLM между компьютерными системами можно использовать параметры политики безопасности или групповые политики.You can use Security Policy settings or Group Policies to manage NTLM authentication usage between computer systems. В доменах протоколом проверки по умолчанию является Kerberos.In a domain, Kerberos is the default authentication protocol.

См. такжеSee also

В следующей таблице представлены материалы по NTLM и другим технологиям проверки подлинности Windows.The following table lists relevant resources for NTLM and other Windows authentication technologies.

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

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

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

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

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

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

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

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

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

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

Затем служба 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? Рассмотрим следующую схему:

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

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

Чтобы получить доступ к ресурсу клиент направляет серверу запрос с именем пользователя. В ответ сервер передает ему случайное число, называемое запросом сервера. Клиент в свою очередь шифрует данный запрос по алгоритму DES, используя в качестве ключа NT-хэш пароля, однако, несмотря на то, что NT-хэш 128-битный, в силу технических ограничений используется 40 или 56 битный ключ (хеш делится на три части и каждая часть шифрует запрос сервера отдельно).

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

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

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

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

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

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

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

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

NTLMv2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Материал сайта pyatilistnik.org

Прозрачная NTLM авторизация на корпоративном портале / Хабр

Привет Хабрасообществу.
Хотел бы посвятить этот топик корпоративному порталу от Bitrix 14 версии, а точнее тому, как его подружить с доменной структурой.

Введение

Все началось с того что решили мы внедрить в организации корпоративный портал (сотрудники, тел. книга, календарь дней рождений) и систему заявок в IT отдел. Попробовав в качестве системы заявок GLPI и Request Tracker, поняли, что слишком громоздко для нас. Рыская по просторам сети в поисках других таких систем наткнулся на модуль «Тех. Поддержка» в продукте от компании Bitrix, ну и собственно решил попробовать убить двух зайцев организовать и заявки, и корпоративный портал.
Поставив систему захотелось организовать прозрачную авторизацию на портале под доменными учетками и вот тут начались проблемы… На их сайте довольно-таки много документации и статей, но беда в том что храниться это все в одной кучи и непонятно что, к какой версии относится. С первого раза настроить NTLM авторизацию самому не получилось, точнее авторизация проходила, но после портал запрашивал еще локальную учетку/пароль. Задав вопрос на форуме битрикса ответ не получил, зато нашел еще несколько человек с такой же проблемой. Не успокоившись решил копать сам.
В итоге делюсь со всеми how-to настройки КП под BitrixVM и IIS 7.

Вводные данные:

Домен организации: company.ru
Доменное имя машины КП: intranet.company.ru

BitrixVM

Скачав и запустив образ заходим на машинку по ssh и видим менюшку.
Выбрав 15 пункт вводим компьютер в домен:

Netbios domain name: COMPANY
Full domain name: COMPANY.RU
Domain password server (имя контроллера домена): DC.COMPANY.RU
Server netbios name: INTRANET
Domain administrator user name: admin

Проверяем, что компьютер успешно введен в домен командой:

net ads testjoin 

На своем компьютере открываем браузер и заходим по http на intranet.company.ru
Производим установку той редакции, которая нужна. Далее производим установку как на картинках:
Картинка в помощь

_{Примечание: В AD был создан пользователь Bitrix с правами пользователя домена. После ввода всей информации нажимаем проверить и автоматически заполниться «Корень дерева».}

После того как установка завершена попадаем на созданный нами портал. Переходим на вкладку «Администрирование» и донастраиваем NTLM авторизацию в следующих местах:

Настройки -> AD/LDAP;

Настройки -> Настройки продукта -> Настройки модулей -> Главный модуль;

Настройки -> Настройки продукта -> Настройки модулей -> AD/LDAP интеграция.

Картинка в помощь

_{Примечание: Домен для NTLM авторизации должен быть именно company (без .ru).}

Добавляем адрес нашего корпоративного портала в зону безопасности Интранет. Лучше это сделать сразу для всех через групповую политику.

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

IIS

С IIS сервером все аналогично, за исключением того, что его нужно сначала подготовить. Как это сделать подскажет Яндекс по фразе «Установка и настройка IIS + PHP + MySQL».
Единственное надо будет немного донастроить модуль PHP и добавить для него расширение «php_ldap.dll», разрешить доменную авторизацию и настроить на сайте нужные порты (как минимум 80 и 8890).Картинка в помощь

Настройка аутентификации на прокси через NTLM в службе каталогов Microsoft AD¶

В данной инструкции описывается настройка аутентификации пользователей на веб-прокси через протокол NTLM.

Данный метод аутентификации поддерживается для служб каталогов Microsoft AD.

NTLM обеспечивает SSO.

Примечание

SSO-аутентификация избавляет доменного пользователя от повторных запросов на прохождение аутентификации. Пользователь вводит доменный логин / пароль всего один раз — при логоне в операционную систему. При последующем обращении в Интернет через прокси Traffic Inspector Next Generation, аутентификация происходит прозрачно и автоматически.

В нашем примере используется следующая схема сети:

Контроллер домена имеет IP-адрес 192.168.137.2 и DNS-имя controller.dom.loc.

Устройство Traffic Inspector Next Generation имеет IP-адрес 192.168.137.8 и DNS-имя tinga.dom.loc.

Настройка устройства Traffic Inspector Next Generation

Настройка общих параметров

Пройдите в раздел Система -> Настройки -> Общие настройки.

• В поле Имя хоста укажите PQDN DNS-имя устройства TING (в нашем примере, FQDN-имя — это tinga.dom.loc, а PQDN-имя — это tinga).

• В поле Домен укажите полное DNS-имя домена (в нашем примере, домен называется dom.loc).

• В поле DNS-серверы, укажите IP-адрес доменного DNS-сервера. В нашем примере, это IP-адрес 192.168.137.2.

• В поле Настройки DNS-сервера, установите флаг напротив опции Не используйте перенаправляющий DNS-сервер или DNS-преобразователь в качестве DNS-сервера для межсетевого экрана

Настройка сетевого времени

Настройка времени на устройстве производится в рамках работы мастера первоначальной настройки, который доступен в разделе Система -> Мастер.

Также, настройки времени доступны в разделе Службы -> Сетевое время -> Общие настройки. В поле Серверы времени укажите ваш предпочитаемый сервер времени, например, time.bakulev.ru. В доменной среде, в качестве NTP-сервера, укажите DNS-имя или IP-адрес контроллера домена, в нашем примере, controller.dom.loc (192.168.137.2).

Примечание

Время на контроллере домена и устройстве TING должно быть синхронизированно.

Установка плагина os-proxy-ntlm

Пройдите в раздел Система -> Прошивка -> Обновления. На вкладке Плагины нажмите на кнопку + напротив плагина os-proxy-ntlm для его установки.

После установки плагина os-proxy-ntlm, в разделе Службы -> Веб-прокси появляется подраздел Аутентификация NTLM.

Настройка NTLM

В разделе Службы -> Веб-прокси -> Аутентификация NTLM, на вкладке Общие настройки, установите флаг Включить аутентификацию NTLM.

В разделе Службы -> Веб-прокси -> Аутентификация NTLM, на вкладке Присоединить домен,

В поле Имя администратора AD, укажите имя учетной записи администратора домена.

В поле Пароль администратора AD, укажите пароль для учетной записи администратора домена.

Нажмите на кнопку Присоединить домен.

Для проверки настройки, на контроллере домена AD, через оснастку Пользователи и компьютеры Active Directory, в контейнере Computers, проверьте существование аккаунта для Вашего устройства TING. В нашем случае, созданный аккаунт называется TINGA-NTLM.

Настройки веб-прокси

В разделе Службы -> Веб-прокси -> Администрирование, на вкладке Основные настройки прокси, установите флаг Включить прокси, если он еще не установлен.

Примечание

Использование механизмов прозрачного HTTP-проксирования или перехвата / дешифровки SSL не совместимо ни с одним методом аутентификации. Чтобы использовать аутенитификацию NTLM, данные механизмы должны быть выключены.

В разделе Службы -> Веб-прокси -> Администрирование, на вкладке Перенаправляющий прокси, в меню Основные настройки перенаправления снимите флаги Включить прозрачный HTTP-прокси и Включить режим SSL, если они установлены.

Пройдите в раздел Службы -> Веб-прокси -> Администрирование, на вкладку Перенаправляющий прокси, пункт меню Настройки аутентификации.

В поле Метод аутентификации выберите Local Database.

В поле Процесс аутентификации укажите значение 15.

Настройка компьютера пользователя

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

Сетевая безопасность: ограничения аудита NTLM проверки подлинности NTLM в этом домене (Windows 10) — Windows security

• 
  04/19/2017
• Чтение занимает 3 мин

В этой статье

Область примененияApplies to

В этой статье описаны рекомендации, расположение, значения, аспекты управления и рекомендации по обеспечению безопасности для сетевой безопасности: ограничения NTLM: Аудит проверки подлинности NTLM в этом параметре политики безопасности домена.Describes the best practices, location, values, management aspects, and security considerations for the Network Security: Restrict NTLM: Audit NTLM authentication in this domain security policy setting.

Справочные материалыReference

Сетевая безопасность: ограничения NTLM: Аудит проверки подлинности NTLM в этом параметре политики домена позволяет проводить аудит проверки подлинности NTLM контроллера домена в этом домене.The Network Security: Restrict NTLM: Audit NTLM authentication in this domain policy setting allows you to audit on the domain controller NTLM authentication in that domain.

При включении этого параметра политики на контроллере домена будет регистрироваться только трафик для проверки подлинности на этот контроллер домена.When you enable this policy setting on the domain controller, only authentication traffic to that domain controller will be logged.

При включении этой политики аудита она работает так же, как Сетевая безопасность: ограничения NTLM: проверка подлинности NTLM в этом параметре домена, но не блокирует трафик.When you enable this audit policy, it functions in the same way as the Network Security: Restrict NTLM: NTLM authentication in this domain policy setting, but it does not actually block any traffic. Таким образом, вы можете эффективно пользоваться трафиком проверки подлинности для контроллеров домена и, когда вы будете готовы заблокировать этот трафик, вы можете включить сетевую безопасность: Restricting для проверки подлинности NTLM: в этом параметре политики домена и выберите запретить для учетных записей домена на серверах доменныхданных, запретить для серверов доменныхадресов или запретить для учетных записей домена.Therefore, you can use it effectively to understand the authentication traffic to your domain controllers and when you are ready to block that traffic, you can enable the Network Security: Restrict NTLM: NTLM authentication in this domain policy setting and select Deny for domain accounts to domain servers, Deny for domain servers, or Deny for domain accounts.

Возможные значенияPossible values

• ОтключитьDisable

  Контроллер домена, на котором настроена эта политика, не будет регистрировать события для входящего трафика NTLM.The domain controller on which this policy is set will not log events for incoming NTLM traffic.

• Включение для доменных учетных записей на серверах доменных данныхEnable for domain accounts to domain servers

  Контроллер домена, на котором настроена эта политика, будет регистрировать события для попыток входа в систему проверки подлинности NTLM для учетных записей на серверах доменных данных, когда проверка подлинности NTLM будет отвергнута, так как Сетевая безопасность: ограничения NTLM: проверка подлинности для учетных записей домена на серверах доменных адресов.The domain controller on which this policy is set will log events for NTLM authentication logon attempts for accounts in the domain to domain servers w

Процедура аутентификации Windows | Windows IT Pro/RE

Протоколы, составляющие основу процедуры

Аутентификация — это незаменимая процедура для каждого пользователя, компьютера и служебной учетной записи Windows, но ее механизм не изучается системными администраторами досконально. Каждый знает, что для регистрации в компьютере необходимо указать верный пароль, но многим ли известно, что происходит потом? Аутентификация Windows и связанные с ней протоколы активизируются каждый раз, когда пользователь, компьютер или служба регистрируются локально или на контроллере домена (DC). В данной статье речь пойдет сначала об основных принципах аутентификации Windows, а затем о связанных с ней протоколах. В заключение приводятся краткие рекомендации по повышению надежности процедуры аутентификации в сети Windows.

Аутентификация: общие принципы

Аутентификация представляет собой один из компонентов любой компьютерной системы управления доступом. Как показано на экране 1, системы управления доступом обеспечивают идентификацию, аутентификацию, авторизацию и отчетность.

Идентификация (identification). В процессе идентификации используется набор данных, который уникально идентифицирует объект безопасности (например, пользователя, группу, компьютер, учетную запись службы) в общей службе каталогов. Служба каталогов, такая как Active Directory (AD), позволяет уникально идентифицировать объекты, подобно тому как DNS удостоверяет, что два человека не могут иметь одинаковые адреса электронной почты. Во внутренних механизмах Windows используются SID, глобально уникальные идентификаторы (globally unique identifier, GUID) и другие уникальные тэги. В большинстве случаев для идентификации достаточно ввести уникальное имя учетной записи, такое как Rgrimes. В большом лесу AD приходится применять полные имена пользователей (user principal name, UPN), например [email protected]. При использовании смарт-карт субъект безопасности может представить свой цифровой сертификат или ключ.

Аутентификация или проверка подлинности (authentication). После того как субъект безопасности вводит с клавиатуры или иным способом предоставляет необходимую для идентификации информацию (например, имя пользователя, маркер безопасности), он должен ввести с клавиатуры или представить частную информацию для аутентификации (например, пароль и PIN-код). В Windows субъект безопасности вводит эту информацию на экране регистрации с помощью программ Microsoft Graphical Identification and Authentication DLL (msgina.dll) и Winlogon.exe. Протокол аутентификации и механизм системы кодируют представленную информацию на настольном компьютере и передают запрос аутентификации. Служба аутентификации Windows может быть базой данных SAM или AD. База данных SAM обслуживает локальные процедуры регистрации и регистрацию на контроллерах домена Windows NT 4.0. AD аутентифицирует запросы в Windows 2000 или доменах более поздних версий этой операционной системы. Протокол аутентификации (например, LAN Manager, NT LAN Manager, NTLM, NTLMv2, Kerberos) используется для транспортировки запросов аутентификации и последующих транзакций между экраном регистрации и службой аутентификации. Чуть ниже каждый протокол аутентификации будет рассмотрен отдельно.

Авторизация (authorization). Если служба аутентификации удостоверяет комбинацию идентификатора и «секретных» данных аутентификации, то подлинность субъекта безопасности считается успешно подтвержденной. Затем система собирает информацию о членстве субъекта безопасности (т. е. пользователя) в группах. Нередко пользователь принадлежит к нескольким точно определенным группам — локальным (local), доменным (domain local), глобальным (global) и универсальным (universal) — в результате обычных процедур назначения членства. Система сверяет локальные группы с локальной базой данных SAM и проверяет локальные и глобальные группы на контроллерах DC в домашнем домене пользователя, а также универсальные группы на DC, который содержит глобальный каталог Global Catalog. Прямо или косвенно система собирает все сведения о членстве в группах, чтобы получить информацию о разрешениях безопасности.

Сразу после аутентификации система собирает идентификаторы SID учетной записи и сведения о членстве в группах в объекте, называемом маркером доступа (access token). Возможно, пользователю придется выйти и вновь зарегистрироваться в системе, чтобы новые разрешения безопасности вступили в силу. Если пользователю нужно получить доступ к объекту (например, файлу, папке, принтеру, разделу реестра), защищенному разрешениями NTFS, то процесс (например, Windows Explorer), выступающий от имени пользователя, предоставляет свой маркер доступа. Каждый объект NTFS располагает списком элементов управления доступом (access control entry, ACE), которые, в сущности, представляют собой знакомые разрешения NTFS (например, Allow Read, Allow Write). Набор элементов ACE, назначенных пользователям и группам, составляет список управления доступом (ACL) данного объекта. Примечательно, что ACL объекта представлен разрешениями безопасности, которые можно просмотреть в Windows Explorer.

Маркер доступа, содержащий учетную запись и группы, с которыми связан пользователь, определяет эффективные разрешения пользователя. Процесс авторизации заключается в разрешении или отказе в доступе к определенному объекту на основе сравнения маркера доступа с ACL объекта. Авторизацию обеспечивает Security Reference Monitor системы Windows (экран 1). В примере, показанном на экране 1, пользователь имеет разрешения Read, Write и Modify. Однако группа Everyone, к которой принадлежит пользователь, не имеет разрешения Modify. Члены других групп располагают разрешениями Read и Modify, но разрешение Deny группы Everyone отменяет разрешение Modify. Объект также располагает списками ACL, которые отказывают в разрешении Full Control группе HR, но пользователь к этой группе не принадлежит. Таким образом, эффективные разрешения пользователя по отношению к объекту на экране 2 — Read и Write.

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

Задачи протокола

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

В течение более чем десяти лет протоколы аутентификации в основном обеспечивали защиту путем сохранения паролей в скрытой форме (обычно хешированной) в базе данных аутентификации и полного запрета на передачу паролей между запросчиком и базой данных аутентификации простым текстом (даже в скрытой форме). Процесс запрос—ответ выглядит следующим образом:

1. Компьютер получает данные для идентификации и аутентификации от пользователя и запрашивает аутентификацию на соответствующем сервере.
2. Сервер аутентификации генерирует случайное произвольное значение (называемое запросом — challenge) и посылает его запросчику.
3. Запросчик получает запрос и производит над ним и скрытой формой пароля математические операции, а затем передает результат (называемый ответом — response) серверу аутентификации.
4. Сервер аутентификации также выполняет математические манипуляции с запросом методом, идентичным используемому на рабочей станции, и сравнивает результат с полученным ответом. Если результаты совпадают, то запросчик считается успешно аутентифицированным.

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

Локальная и доменная регистрация

При регистрации пользователя одна из первых задач Windows — определить, относится ли процедура только к локальной машине или к учетной записи домена. Пользователи, регистрирующиеся от имени локальной учетной записи, имеют доступ только к ресурсам своего компьютера и только если информация об учетной записи пользователя содержится в локальной базе данных SAM. Если пользователям нужно обратиться к ресурсам на удаленном компьютере без аутентификации в домене, то их учетные записи должны быть продублированы в локальной базе данных SAM каждого доступного компьютера. Учетные записи в каждом компьютере-участнике должны быть синхронизированы (одинаковые имена регистрации, пароли и сроки действия учетных данных на всех машинах). В противном случае положение значительно усложняется. Трудно обслуживать одноранговые (P2P) сети средних размеров, в которых применяются только локальные процедуры регистрации.

На DC не распространяется требование синхронизации нескольких учетных записей пользователей на разных компьютерах. При доменной аутентификации компьютеры, зарегистрированные в домене, отыскивают контроллеры DC, чтобы предъявить учетные данные доменной учетной записи пользователя при запросах аутентификации. Таким образом, если удаленный пользователь пытается получить доступ к локальному ресурсу какой-нибудь машины, то этот компьютер просит DC проверить идентичность запрашивающего пользователя. Учетные записи пользователя домена располагаются только на DC и создаются лишь один раз. Любой компьютер-участник, которому нужно удостоверить учетную запись в домене, может обратиться к контроллерам DC в любое время. Проблемы синхронизации имен регистрации, паролей и сроков их действия не возникает, так как учетные данные и управление учетной записью осуществляются только в одном месте — на DC. Независимо от типа регистрации (локальной или доменной), Windows должна аутентифицировать запрос пользователя.

Протоколы аутентификации Windows

Как отмечалось выше, в Windows применяется четыре основных протокола аутентификации: LAN Manager, NTLM, NTLMv2 и Kerberos. LAN Manager появился во времена DOS и продолжал использоваться с первыми версиями Windows. NTLM был выпущен вместе с NT. Новшеством пакета обновлений NT Server 4.0 Service Pack 4 (SP4) стал NTLMv2, а Windows 2000 привнесла Kerberos. По умолчанию все компьютеры с Windows 2000 и более новыми операционными системами совместимы со всеми четырьмя протоколами аутентификации. Передавая в эти системы соответствующие команды, другие рабочие станции и серверы могут выбирать протокол для обработки запроса аутентификации. Системы Windows 9x и более поздние с полным набором программных исправлений совместимы с LM, NTLM и NTLMv2. На платформе Microsoft Kerberos может использоваться только клиентами Windows 2000 (или более новыми) при обращениях в домены Windows 2000 (и выше). Компьютер с Windows 2000 или более новой версией операционной системы должен иметь Kerberos и по крайней мере еще один из протоколов аутентификации.

Исследования в области безопасности показали, что более старые протоколы (LM и NTLM) уязвимы в случае прослушивания и атак с разгадыванием пароля.

Поэтому, если возможно, рекомендуется использовать только Kerberos и NTLMv2. Чтобы убедиться в правильности этого совета, следует оценить возможности каждого протокола.

LAN Manager

Компания IBM разработала протокол LAN Manager, применив его в ранних версиях Windows и сетях Windows. Как все протоколы аутентификации Microsoft, LAN Manager генерирует хеш паролей (LM hash), который хранится и используется отправителем и получателем в процессе аутентификации. LAN Manager формирует LM-хеши, изменяя все буквы пароля на верхний регистр, разбивая пароль на две 7-символьные половины, а затем шифруя. В дальнейшем LM-хеш используется в нескольких последовательных операциях, аналогичных процессу запрос—ответ, описанному выше.

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

• пароли могут состоять из ограниченной последовательности 128 символов ASCII;
• длина пароля не превышает 14 символов;
• если пароль содержит менее 14 символов, то отсутствующие символы заменяются легко угадываемой хешированной формой, что позволяет точно определить длину пароля;
• перед кэшированием LAN Manager преобразует все буквенные символы пароля в верхний регистр.

Почему LAN Manager до сих пор не вышел из употребления? В целях обратной совместимости он активен по умолчанию во всех компьютерах Windows, в том числе Windows Server 2003. В новейших базах данных аутентификации Windows слабый LM-хеш хранится наряду с более надежными просто на случай, если придется выполнить транзакцию LAN Manager. Если на предприятии не используются другие приложения, требующие аутентификации LAN Manager, то можно (и нужно) LAN Manager отключить.

NTLM

С появлением NT компания Microsoft спроектировала и развернула более надежный протокол аутентификации NTLM. В NTLM используется более эффективный алгоритм аутентификации, который создает более надежный хеш паролей (NTLM hash). Пароль NTLM может содержать до 128 символов. В отличие от хеширования LAN Manager, ограниченного использованием только символов ASCII, NTLM совместим с полным набором символов Unicode, что повышает сложность паролей. NTLM-хеш отсекается на 128-м символе, преобразуется в 16-разрядное значение Unicode, обрабатывается распределительной функцией MD4 и сохраняется в 32-символьной шестнадцатеричной строке. За счет использования NTLM-хеша в операциях запрос—ответ последовательность аутентификации NTLM гораздо сложнее процедуры LAN Manager.

NTLMv2

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

В целом NTLMv2 более устойчив к атакам с применением «грубой силы», нежели NTLM, так как в протоколе применяется 128-разрядный ключ шифрования. Известно только о двух программах взлома паролей (одна из них — LC5 компании Symantec), с помощью которых удавалось открыть хеши паролей NTLMv2.

Kerberos

Компания Microsoft приняла Kerberos в качестве выбираемого по умолчанию протокола доменной аутентификации для доменов Windows 2000, а затем и AD. Kerberos — открытый стандарт, пригодный для взаимодействия с инородными доменами (называемыми областями — realm — в UNIX и Linux). Каждый DC в доменах AD играет роль сервера распределения (Kerberos Distribution Server, KDC) и может участвовать в процедуре аутентификации. Безопасность повышается благодаря следующим характеристикам Kerberos:

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

Краткое описание работы Kerberos:

1. После успешной обычной аутентификации компьютер пользователя запрашивает билет безопасности из сервера Kerberos (DC) для будущих запросов аутентификации.
2. Сервер Kerberos выдает запросчику билет для участия в будущих событиях аутентификации и авторизации без повторного предъявления первоначальных учетных данных аутентификации.
3. Когда запросчику нужно обратиться к ресурсу сервера-участника, он получает другой билет доступа от сервера Kerberos и предъявляет его серверу ресурса для проверки.
4. Первоначальные учетные данные аутентификации не передаются по сетевым каналам ни в одном из последующих сеансов аутентификации (до тех пор, пока не истечет срок действия билета, выданного на этапе 2).

Следует обратить внимание, что, хотя принцип работы Kerberos напоминает инфраструктуру с частным открытым ключом (public key infrastructure, PKI), вся информация защищается с использованием симметричных ключей (в отличие от асимметричных ключей, применяемых в большинстве служб аутентификации).

Смарт-карты

Надежность паролей и других методов аутентификации на основе одного параметра быстро снижается. Электронная коммерция проникает в повседневную жизнь и возрастает как число способов кражи личных данных (спам, мошенничество с URL), так и вероятность злоупотреблений паролями. Многие специалисты считают, что аутентификация с двумя параметрами — в форме смарт-карт, USB-устройств или других криптографических устройств — в будущем станет обычным явлением для транзакций в Internet. Разработчики Microsoft встраивают в свои решения функции для работы с цифровыми сертификатами и смарт-картами. Для использования смарт-карт необходимо установить службу Certificate Services и распространить сертификаты смарт-карт. Конечно, нужны также физические смарт-карты, устройства считывания и программное обеспечение поставщика. Затем при необходимости пользователи могут вставлять свои смарт-карты в локальные устройства чтения для доступа к компьютеру Windows. При грамотном использовании смарт-карты могут существенно повысить надежность аутентификации.

Защита протокола аутентификации

В некоторых статьях ошибочно утверждается, что взломать механизм аутентификации Microsoft по-прежнему просто. В действительности из 20 существующих инструментов взлома пароля только два работают с NTLMv2 и лишь один — с Kerberos. Но, предприняв несколько простых шагов, можно отвести и эту угрозу. Для предотвращения попыток разгадывания и сброса пароля нужно принять следующие меры (большинство параметров можно настроить локально или с помощью Group Policy).

• Отключить хранение LM-хешей, как описано в статье Microsoft «How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases» (http://support.microsoft.com/ default.aspx?scid=kb;en-us;299656). Это делается для того, чтобы помешать взломщикам открыть исходный пароль.
• Отключить все протоколы аутентификации, кроме NTLMv2 и Kerberos (после исчерпывающего тестирования). Процедура описана в статье Microsoft TechNet «Network security: LAN Manager authentication level» (http://www.microsoft.com/resources/ documentation/windowsserv/2003/ standard/proddocs/en-us/576.asp).
• Запретить начальную загрузку со сменных носителей, чтобы предотвратить запуск инструментов взлома пароля в обход операционной системы. Запрет начальной загрузки со всех дисков, кроме выбираемого по умолчанию, предотвращает доступ автономных программ взлома пароля к базе данных аутентификации, где хранятся хеши паролей.
• Пользователи должны назначать сложные пароли длиной не менее 8 символов.
• Пользователи должны менять свои пароли по крайней мере раз в квартал.
• Активизировать блокировку учетной записи хотя бы на одну минуту с автоматическим сбросом. Это предотвращает разгадывание паролей в сети.

Обязанности пользователей

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

Роджер Граймз — Редактор Windows IT Pro и консультант по проблемам безопасности. Имеет сертификаты CPA, CISSP, CEH, CHFI, TICSA, MCT, MCSE: Security и Security+. [email protected]

Поделитесь материалом с коллегами и друзьями

Уровень проверки подлинности в сети Network Security Manager (Windows 10) — Windows security

• 
  04/19/2017
• Чтение занимает 4 мин

В этой статье

Область примененияApplies to

В этой статье описаны рекомендации, расположение, значения, политики управления политиками и безопасности для сетевой безопасности: параметр политики безопасности уровня проверки подлинности LAN Manager .Describes the best practices, location, values, policy management and security considerations for the Network security: LAN Manager authentication level security policy setting.

Справочные материалыReference

Этот параметр политики определяет, какой протокол проверки подлинности запроса или ответа используется для входа в сеть.This policy setting determines which challenge or response authentication protocol is used for network logons. LAN Manager (LM) включает клиентский компьютер и программное обеспечение сервера от корпорации Майкрософт, позволяющее пользователям связывать личные устройства в одной сети.LAN Manager (LM) includes client computer and server software from Microsoft that allows users to link personal devices together on a single network. Сетевые возможности включают прозрачный общий доступ к файлам и принтерам, функции безопасности пользователей и средства администрирования сети.Network capabilities include transparent file and print sharing, user security features, and network administration tools. В доменах Active Directory протокол Kerberos является протоколом проверки подлинности по умолчанию.In Active Directory domains, the Kerberos protocol is the default authentication protocol. Тем не менее, если по какой-либо причине протокол Kerberos не согласован, Служба каталогов Active Directory использует LM, NTLM или NTLM версии 2 (NTLMv2).However, if the Kerberos protocol is not negotiated for some reason, Active Directory uses LM, NTLM, or NTLM version 2 (NTLMv2).

Проверка подлинности LAN Manager включает варианты LM, NTLM и NTLMv2, и это протокол, который используется для проверки подлинности всех клиентских устройств, работающих под управлением операционной системы Windows, при выполнении указанных ниже действий.LAN Manager authentication includes the LM, NTLM, and NTLMv2 variants, and it is the protocol that is used to authenticate all client devices running the Windows operating system when they perform the following operations:

• Присоединение к доменуJoin a domain
• Проверка подлинности между лесами службы каталогов Active DirectoryAuthenticate between Active Directory forests
• Проверка подлинности доменов на основе более ранних версий операционной системы WindowsAuthenticate to domains based on earlier versions of the Windows operating system
• Проверка подлинности на компьютерах, на которых не выполняются Windowsoperating системы, начиная с Windows 2000Authenticate to computers that do not run Windowsoperating systems, beginning with Windows2000
• Проверка подлинности на компьютерах, которых нет в доменеAuthenticate to computers that are not in the domain

Возможные значенияPossible values

• Отправлять ответы LM & NTLMSend LM & NTLM responses
• Отправлять LM & NTLM — использовать сеансовую безопасность NTLMv2 при согласованииSend LM & NTLM — use NTLMv2 session security if negotiated
• Отправлять только ответы NTLMSend NTLM responses only
• Отправлять только ответы NTLMv2Send NTLMv2 responses only
• Отправлять только ответы NTLMv2.Send NTLMv2 responses only. Отклонять LMRefuse LM
• Отправлять только ответы NTLMv2.Send NTLMv2 responses only. Отказ от LM & NTLMRefuse LM & NTLM
• Не определеноNot Defined

Параметр безопасность сети: уровень проверки подлинности LAN Manager определяет, какой протокол проверки подлинности запросов и ответов используется для входа в сеть.The Network security: LAN Manager authentication level setting determines which challenge/response authentication protocol is used for network logons. Этот выбор влияет на уровень протоколов проверки подлинности, используемых клиентами, уровень безопасности сеанса, на котором согласуются компьютеры, и уровень проверки подлинности, принимаемый серверами.This choice affects the authentication protocol level that clients use, the session security level that the computers negotiate, and the authentication level that servers accept. В приведенной ниже таблице указаны параметры политики, описание параметра и определение уровня безопасности, используемого в соответствующем параметре реестра, если вы решили использовать реестр для управления этим параметром, а не параметром политики.The following table identifies the policy settings, describes the setting, and identifies the security level used in the corresponding registry setting if you choose to use the registry to control this setting instead of the policy setting.

РекомендацииBest practices

• Рекомендации зависят от конкретных требований к безопасности и проверки подлинности.Best practices are dependent on your specific security and authentication requirements.

Расположение политикиPolicy Location

Параметры компьютера Configuration\Windows Settings\Security Settings\Local Policies\SecurityComputer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Расположение в реестреRegistry Location

HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevelHKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

Значения по умолчаниюDefault values

В приведенной ниже таблице перечислены фактические и действующие значения по умолчанию для этой политики.The following table lists the actual and effective default values for this policy. Значения по умолчанию также можно найти на странице свойств политики.Default values are also listed on the policy’s property page.

Управление политикойPolicy management

В этом разделе описаны возможности и

Протокол проверки подлинности NTLM и поставщик поддержки безопасности

Терминология NTLM

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

NTLM-аутентификация — это схема запрос-ответ, состоящая из трех
сообщения, обычно называемые Тип 1 (согласование), Тип 2 (вызов) и
Тип 3 (аутентификация). В основном это работает так:

1. Клиент отправляет серверу сообщение типа 1.Это в первую очередь содержит
   список функций, поддерживаемых клиентом и запрашиваемых сервером.
2. Сервер отвечает сообщением типа 2. Это содержит список функций
   поддерживаются и согласовываются сервером. Но самое главное, что это
   содержит запрос, созданный сервером.
3. Клиент отвечает на запрос сообщением типа 3. Это содержит
   несколько частей информации о клиенте, включая домен и
   имя пользователя клиента.Он также содержит один или несколько ответов на
   Задача 2-го типа.

Ответы в сообщении типа 3 являются наиболее важной частью, поскольку они доказывают
серверу, что клиентский пользователь знает пароль учетной записи.

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

В этом документе, чтобы избежать путаницы (во всяком случае, насколько это возможно),
будет соблюдаться следующее соглашение:

• При обсуждении аутентификации версия протокола будет использовать «v-нумерацию»;
  например, «NTLM v1 Аутентификация».
• При обсуждении безопасности сеанса (подписание и запечатывание) буква «v» будет
  опущено; например, «NTLM 1 Безопасность сеанса».

Это должно прояснить ситуацию, за исключением, возможно, неудобного случая
Аутентификация «NTLM2 Session Response» (вариант аутентификации NTLMv1
который используется вместе с безопасностью сеанса NTLM2). Надеюсь, что
когда мы туда доберемся, все это будет иметь гораздо больший смысл.

Для наших целей «короткий» — это 16-битное беззнаковое значение с прямым порядком байтов.
Например, десятичное значение «1234», представленное как короткое
будет физически представлен как «0xd204» в шестнадцатеричном формате.

«Длинный» — это 32-битное беззнаковое значение с прямым порядком байтов. Десятичное значение
«1234», представленное как длинное в шестнадцатеричном формате, будет
«0xd2040000».

Строка Unicode — это строка, в которой каждый символ представлен как
16-битное значение с прямым порядком байтов (16-битный формат преобразования UCS-2,
порядок байтов с прямым порядком байтов, без метки порядка байтов и нулевого конца).Строка «привет» в Юникоде будет представлена ​​в шестнадцатеричном виде как
«0x680065006c006c006f00».

Строка OEM — это строка, в которой каждый символ представлен как
8-битное значение из собственного набора символов локальной машины (кодовая страница DOS).
Нет нулевого терминатора. В сообщениях NTLM OEM-строки обычно
представлены в верхнем регистре. Строка «HELLO» в OEM будет представлена
гексидцимально как «0x48454c4c4f».

«Буфер безопасности» — это структура, используемая для указания на буфер двоичных данных.Это состоит из:

1. Короткий, содержащий длину содержимого буфера в байтах (может быть нулевым).
2. Шорт, содержащий выделенное пространство для буфера в байтах
   (больше или равно длине; обычно равно длине).
3. Длинный, содержащий смещение до начала буфера в байтах
   (с начала сообщения NTLM).

Таким образом, буфер безопасности «0xd204d204e1100000» будет читаться как:

Длина: 0xd204 (1234 байта)

Выделенное пространство: 0xd204 (1234 байта)

Смещение: 0xe1100000 (4321 байт)

Если вы начали с первого байта сообщения и пропустили вперед 4321 байт,
вы будете в начале буфера данных.Вы бы прочитали 1234 байта
(длина буфера). Поскольку выделенное пространство для буфера
также 1234 байта, тогда вы окажетесь в конце буфера.

Макет заголовка сообщения NTLM

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

Все сообщения начинаются с подписи NTLMSSP, которая (достаточно удачно)
строка ASCII с завершающим нулем «NTLMSSP» (шестнадцатеричная
«0x4e544c4d53535000»).

Далее идет длинный, содержащий тип сообщения (1, 2 или 3). Тип 1
сообщение, например, имеет шестнадцатеричный тип «0x01000000».

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

Флаги NTLM

Флаги сообщения содержатся в битовом поле заголовка. Это
long, в котором каждый бит представляет определенный флаг. Большинство из них
будут иметь больше смысла позже, но мы продолжим и представим их здесь, чтобы
установите систему отсчета для остальной части обсуждения.Флаги, помеченные как «неопознанные» или «неизвестные» в таблице ниже, находятся за пределами
область знаний автора (что ни в коем случае не является абсолютным).

.

c ++ — NTLM-аутентификация для приложения на стороне веб-сервера

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

Загрузка…

2. Авторизоваться
   зарегистрироваться

3. текущее сообщество
   

.