Авторизация ntlm: Авторизация с помощью NTLM

Содержание

Авторизация с помощью NTLM | UserGate Support & Service

Авторизация NTLM позволяет прозрачно (без запроса имени пользователя и его пароля) авторизовать пользователей домена Active Directory. При авторизации с помощью NTLM сервер UserGate работает с контроллерами домена, которые выполняют проверку пользователя, который получает доступ в интернет.

1. Создадим LDAP — коннектор для получения информации о пользователях и группах Active Directory.

Перейдем в раздел Пользователи и устройства → Серверы авторизации, нажмем кнопку Добавить → Добавить LDAP коннектор.

В свойствах коннектора LDAP внесем следующие настройки:

Вкладка Настройки

Название: произвольное название LDAP — коннектора.

Доменное имя LDAP или IP-адрес: IP-адрес сервера контроллера домена.

Bind DN («логин»): внесем доменного пользователя в формате DOMAIN\username или username@domain для подключения к серверу LDAP. Данный пользователь уже должен быть заведен в домене.

Пароль: пароль пользователя для подключения к домену.

Вкладка Домены LDAP

Нажмем кнопку Добавить и внесем доменное имя LDAP

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

Сохраним настройки LDAP коннектора нажав на кнопку Сохранить.

2. Создадим NTLM — сервер авторизации.

В разделе Пользователи и устройства → Серверы авторизации, нажмем кнопку Добавить → Добавить NTLM-сервер.

Название: произвольное название сервера авторизации.

IP-адрес: IP адрес контроллера домена.

Домен Windows: доменное имя.

Сохраним настройки NTLM сервера нажав на кнопку Сохранить.

3. Создадим профиль авторизации для NTLM сервера.

В разделе Пользователи и устройства → Профили авторизации, нажмем кнопку Добавить.

Вкладке Общие.

Название: произвольное название профиля авторизации.

Вкладка Методы аутентификации

Нажмем кнопку Добавить и выберем ранее созданный NTLM сервер.

Сохраним настройки профиля авторизации нажав на кнопку Сохранить.

4. Создадим Captive-профиль.

В разделе Пользователи и устройства → Captive-профили, нажмем кнопку Добавить.

Вкладка Общие

Название: произвольное название captive — профиля.

Профиль авторизации: выберем ранее созданный NTLM профиль.

Сохраним настройки Captive-профиля нажав на кнопку Сохранить.

5. Создадим правило Captive-портала для NTLM авторизации.

В разделе Пользователи и устройства → Captive-портал, нажмем кнопку Добавить.

Вкладка Общие

Название: произвольное название правила captive-портала.

Captive-профиль: выберем ранее созданный captive-профиль.

Сохраним настройки правила Captive-портала нажав на кнопку Сохранить.

6. Настроим синхронизацию времени с контроллером домена.

В разделе Настройки → Настройка времени сервера, установим Основной NTP-сервер — IP адрес контроллера домена.

7. Создадим DNS записи для сервера UserGate.

Где 10.1.10.21 IP адрес интерфейса UserGate подключенного в зону Trusted.

8. Изменим адрес домена Auth Captive-портала.

В разделе Настройки →Модули, изменим названия Доменов на созданные доменные имена в предыдущем разделе.

9. Разрешить доступ к сервису HTTP(S) для зоны.

В разделе Зоны разрешить доступ к сервису HTTP(S)-прокси для зоны, к которой подключены пользователи, авторизующиеся с помощью NTLM.

10. Произведем настройки на компьютере пользователя.

Настройка прокси-сервера для авторизации в стандартном режиме.

Панель управления → Свойства браузера → Подключения → Настройка сети → Прокси-сервер и указать IP адрес и порт интерфейса UserGate, к которому будут подключены пользователи.

Настройка авторизации в прозрачном режиме.

Панель управления → Свойства браузера →безопасность → выберите зону Интернет → Уровень безопасности → Другой → Проверка подлинности пользователя и установите Автоматический вход в сеть с текущим именем пользователя и пароля.

Панель управления → Свойства браузера →Безопасность → установить. Разрешить встроенную проверку подлинности Windows.

Проверка подлинности пользователей NTLM — Windows Server

09/27/2020

Чтение занимает 6 мин

В этой статье

В этой статье данная статья содержит некоторые сведения о проверке подлинности пользователей NTLM.

Исходная версия продукта: Windows Server 2012 R2
Исходный номер КБ: 102716

Аннотация

В этой статье обсуждаются следующие аспекты проверки подлинности пользователей NTLM в Windows:

Хранилище паролей в базе данных учетных записей
Проверка подлинности пользователя с помощью пакета MSV1_0 проверки подлинности
Сквозная проверка подлинности

Дополнительные сведения

Хранилище паролей в базе данных учетных записей

Учетные записи пользователей сохраняются в базе данных диспетчера учетных записей безопасности (SAM) или в базе данных Active Directory. Каждая учетная запись связывается с двумя паролями: с паролем, совместимым с LAN Manager, и с паролем Windows. Каждый пароль зашифровывается и сохраняется в базе данных SAM или в базе данных Active Directory.

Пароль, совместимый с lan Manager, совместим с паролем, используемым lan Manager. Этот пароль основан на наборе символов изготовителя оборудования (OEM). Этот пароль не чувствителен к букве и может иметь длину до 14 символов. Версия этого пароля в OWF также называется версией lan Manager OWF или ESTD. Этот пароль вычисляется с помощью шифрования DES для шифрования константы с использованием простого текстового пароля. Пароль OWF lan Manager составляет 16 bytes long. Первые 7 bytes of the clear text password are used to compute the first 8 bytes of the LAN Manager OWF password. Вторые 7 bytes of the clear text password are used to computer the second 8 bytes of the LAN Manager OWF password.

Пароль Windows основан на наборе символов Юникода. Этот пароль чувствителен к букве и может иметь длину до 128 символов. Версия этого пароля в OWF также называется паролем Windows OWF. Этот пароль вычисляется с помощью алгоритма шифрования RSA MD-4. Этот алгоритм вычисляет 16-byte-дайджест строки переменной длины с понятным паролем текста.

У любой учетной записи пользователя может не быть пароля диспетчера локальной сети или пароля Windows. Однако при каждой попытке сохранить обе версии пароля.

Например, если учетная запись пользователя будет переноситься из базы данных UAS lan Manager с помощью PortUas или пароль будет изменен с клиента LAN Manager или клиента Windows для workgroups, будет существовать только версия пароля lan Manager. Если пароль установлен или изменен в клиенте Windows и пароль не имеет представления lan Manager, будет существовать только версия пароля Windows. (Пароль может не иметь представления lan Manager, так как пароль длиннее 14 символов или символы не могут быть представлены в наборе символов OEM.)

Ограничения пользовательского интерфейса в Windows не могут превышать 14 символов. Последствия этого ограничения обсуждаются далее в этой статье.

В Windows 2000 Пакет обновления 2 и более поздних версиях Windows доступен параметр, позволяющий запретить Windows хранить hash пароля lan Manager. Для получения дополнительных сведений проверьте следующий номер статьи, чтобы просмотреть статью в базе знаний Майкрософт:

299656. Как запретить Windows хранить в active Directory и локальных базах данных SAM свой пароль в диспетчере локальной сети

Примечание

Корпорация Майкрософт не поддерживает изменение базы данных SAM вручную или программным путем.

Проверка подлинности пользователя с помощью пакета MSV1_0 проверки подлинности

Windows использует API LsaLogonUser для всех видов проверки подлинности пользователей. API LsaLogonUser позволяет проверить подлинность пользователей, вызывая пакет проверки подлинности. По умолчанию LsaLogonUser вызывает MSV1_0 проверки подлинности MSV. Этот пакет входит в Windows NT. Пакет проверки подлинности MSV сохраняет записи пользователей в базе данных SAM. Этот пакет поддерживает сквозную проверку подлинности пользователей в других доменах с помощью службы Netlogon.

Внутренний пакет проверки подлинности MSV делится на две части. Первая часть пакета проверки подлинности MSV выполняется на компьютере, к который выполняется подключение. Вторая часть выполняется на компьютере с учетной записью пользователя. Когда обе части работают на одном компьютере, первая часть пакета проверки подлинности MSV вызывает вторую часть без использования службы Netlogon. Первая часть пакета проверки подлинности MSV распознает, что необходима сквозная проверка подлинности, так как переданное имя домена не является его собственным доменным именем. Если требуется сквозная проверка подлинности, MSV передает запрос в службу Netlogon. Затем служба Netlogon маршрутит запрос в службу Netlogon на компьютере назначения. В свою очередь служба Netlogon передает запрос другой части пакета проверки подлинности MSV на этом компьютере.

LsaLogonUser поддерживает интерактивные и сервисные и сетевые логины. В пакете проверки подлинности MSV все формы регистрации в учетной записи передают имя учетной записи пользователя, имя домена, который содержит учетную запись пользователя, и некоторые функции пароля пользователя. Разные типы учетных записей представляют пароль по-разному при его передается в LsaLogonUser.

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

Первая часть пакета проверки подлинности MSV преобразует понятный пароль как в пароль OWF lan Manager, так и в Windows NT OWF. Затем первая часть пакета передает текстовый пароль либо в службу NetLogon, либо во вторую часть пакета. Вторая часть затем запрашивает в базе данных SAM пароли OWF и делает их идентичными.

Для сетевых подключений клиенту, подключаемому к компьютеру, ранее была предоставлена 16-байтовая задача или «nonce». Если клиент является клиентом Lan Manager, он вычисляет 24-byte запрос, шифруя 16-byte challenge с помощью 16-byte LAN Manager пароля OWF. Затем клиент LAN Manager передает этот ответ «Запрос lan Manager» серверу. Если клиент является клиентом Windows, «Windows NT Challenge Response» вычисляется с помощью того же алгоритма. Однако клиент Windows использует 16-byte windows OWF data instead of the LAN Manager OWF data. Затем клиент Windows передает серверу как ответ на запрос lan Manager, так и ответ Windows NT запроса. В любом случае сервер проходит проверку подлинности пользователя, передавая В API LsaLogonUser все следующие данные:

Имя домена
Имя пользователя
Исходная задача
Ответ на запросы lan Manager
Необязательный Windows NT запроса

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

Примечание

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

Как упоминалось ранее, в базе данных SAM или в базе данных Active Directory может не быть пароля. Кроме того, в вызове LsaLogonUser может отсутстить любая версия пароля. Если доступны и версия пароля Windows из базы данных SAM, и версия Windows пароля из LsaLogonUser, они оба используются. В противном случае для сравнения используется версия пароля lan Manager. Это правило помогает обеспечить чувствительность к событиям, когда происходит сетевой перенаправить пользователей из Windows в Windows. Это правило также обеспечивает обратную совместимость.

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

Служба NetLogon реализует сквозную проверку подлинности. Он выполняет следующие функции:

Выбирает домен, в который передается запрос на проверку подлинности.
Выбирает сервер в домене.
Передает запрос проверки подлинности на выбранный сервер.

Выбрать домен просто. Имя домена передается в LsaLogonUser. Доменное имя обрабатывается следующим образом:

Если доменное имя совпадает с именем базы данных SAM, проверка подлинности обрабатывается на этом компьютере. На рабочей станции Windows, которая является членом домена, имя базы данных SAM считается именем компьютера. На контроллере домена Active Directory имя базы данных учетных записей — это имя домена. На компьютере, который не является членом домена, все запросы для регистрации в сети запрашивается локально.
Если указанное доменное имя является доверенным для этого домена, запрос на проверку подлинности передается в доверенный домен. На контроллерах домена Active Directory список доверенных доменов легко доступен. На члене домена Windows запрос всегда передается в основной домен рабочей станции, позволяя основному домену определить, является ли указанный домен доверенным.
Если указанное доменное имя не является доверенным для домена, запрос на проверку подлинности обрабатывается на компьютере, к которому подключается, как если бы указанное доменное имя было этим именем домена. NetLogon не различает несущевидный домен, недоверенный домен и неправильно типированное доменное имя.

NetLogon выбирает сервер в домене с помощью процесса, называемого обнаружением. На рабочей станции Windows в основном домене обнаруживается имя одного из контроллеров домена Windows Active Directory. Контроллер домена Active Directory обнаруживает имя контроллера домена Active Directory в каждом надежном домене. Компонентом, который выполняет обнаружение, является dc Locator, который выполняется в службе Netlogon. Dc Locator использует разрешение NETBIOS или DNS-имен для поиска необходимых серверов в зависимости от типа настроенного домена и доверия.

Аутентификация NTLM-это просто приглашение (вызов) или она действительно аутентифицируется?

У меня есть (java) веб-приложение, и я включил аутентификацию NTLM.

Когда приглашение входа в систему представлено браузером в нашей интрасети (windows).
Поведение, которое я вижу, таково:

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

Итак, что мне нужно проверить на стороне сервера, чтобы узнать, прошла ли аутентификация успешно или нет?

java

security

web-applications

ntlm

Поделиться

Источник

Jasper

07 августа 2012 в 03:35

2 ответа

Javascript/Ajax проверки подлинности по протоколу NTLM
Я разрабатываю мобильное приложение HTML5, которое взаимодействует с WebServices . WebServices используйте протокол аутентификации NTLM. Мне трудно справиться с рукопожатием через JavaScript. NTLM посылает 401 unauthorized в ответ на мой POST, на который я не нашел никакого способа ответить….
Windows аутентификация — Kerberos или NTLM (Negotiate oYICO…)
У меня есть проблемы с одним пользователем в приложении интрасети. Клиентская сторона-это приложение WPF, которое взаимодействует с веб-службой ASP. Net Web API. Клиент отправляет HTTPS GET и POST запросов с помощью HttpClientHandler handler = new HttpClientHandler() { AutomaticDecompression =…

Идея NTLM auth заключается в том, что вошедший в систему пользователь может продолжить соединение без явного повторного ввода своего имени пользователя и пароля. Таким образом, все, что запрашивает ваше приложение, не имеет значения (как вы можете видеть сами), и вместо этого используются ваши системные учетные данные.

Поделиться

Eugene Mayevski ‘Callback

07 августа 2012 в 05:07

NTLM аутентификация была нарушена в течение нескольких лет — NTLM 2 поставляется с NT 4, так что, надеюсь, люди уже перешли. Если вы хотите использовать регистрационные данные Active Directory, вместо этого вам следует использовать Kerberos.

Поделиться

Billy ONeal

08 августа 2012 в 17:26

NTLM Failed в ManageEngine ServiceDesk

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов рунета Pyatilistnik.org. В прошлый раз мы с вами устранили ошибку входа на удаленный рабочий стол «Удаленный компьютер имя. Причиной ошибки может быть исправление шифрования CredSSP «. Сегодня я вам расскажу, как решается проблема с единым входом на сервис ManageEngine ServiceDesk 10500. Данную заметку я больше делаю для себя, так как ее выполнение не частое и все быстро забывается, в рунете ее решение я не нашел.

Как выглядит ошибка входа на ManageEngine ServiceDesk 10500

После того, как я на тестовом сервере включил сквозную авторизацию на ManageEngine ServiceDesk, я решали это воспроизвести и на продакшн сервере. Для этого я скриптом создал объект компьютера в Active Directory от имени которого служба цеплялась к базе. Я с помощью групповых политик настроил SSO в Google Chrome и Internet Explore. Все сделал, как и для тестового стенда.

Пытаюсь открыть в браузере нужный мне адрес моего хелпдеска, но в результате вижу ошибку:

NTLM Failed Redirecting To Login Page

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

Решение проблемы с единым входом на ManageEngine ServiceDesk

Я потратил пару дней, на то, чтобы решить данную проблему. Оказалась вот такая петрушка, оказывается, что когда вы создаете объект компьютера от имени которого будет авторизовываться служба в Active Directory, его имя не должно превышать 13-ти символов, разработчики вы серьезно? Вот как выглядела моя конфигурация, когда она не работала. В имени моего компьютера 14 символов, как в 2019 году может быть такая ересь.

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

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

Еще хочу добавить, что если у вас компьютер не доменный или вы делаете вход в мобильного устройства на сайт, хотя для этого есть мобильное приложение, то у вас будет так же выскакивать окно «NTLM Failed Redirecting To Login Page» и это логично, так как вы в вашей системе работает изначально не под доменным пользователем, поэтому сквозная авторизация не может корректно отработать.

На этом у меня все, еще раз передаю привет программистам индусам, которые знают чем потренировать мой мозг в рабочее время. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

Авторизация прокси по NTLM в Linux

В корпоративной среде основанной на продуктах Microsoft, достаточно часто можно встретить использование прокси-сервера встроенного в ISA Server/Forefront TMG. Как правило, авторизация пользователей на таком прокси производится c помощью NTLM.

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

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

Установка cntlm

Чтобы установить cntlm в Debian/Ubuntu выполните следующую команду:

# apt-get install cntlm

Для установки cntlm в CentOS/RHEL необходимо подключить репозиторий Epel. После чего выполнить команду:

# yum -y install cntlm

Настройка cntlm

Откройте конфигурационный файл:

# nano /etc/cntlm.conf

Установите имя пользователя, домен, адрес и порт прокси-сервера, локальный интерфейс и порт на котором cntlm будет принимать входящие соединения:

Username        user
Domain          domain.net
Proxy           192.168.1.1:8080
Listen          127.0.0.1:3128

Запускаем cntlm:

# cntlm -c /etc/cntlm.conf

Выясним какой тип авторизации использует наш прокси-сервер:

# cntlm -c /etc/cntlm.conf -M http://ya.ru
Password:
Config profile  1/4... OK (HTTP code: 200)
----------------------------[ Profile  0 ]------
Auth            NTLMv2
PassNTLMv2      C9ACE7FB80841EB5B94D1C4E10D7DB5B
------------------------------------------------

Теперь когда мы знаем тип используемой аутентификации и хеш нашего пароля. Необходимо добавить в сntlm.conf следующие параметры:

Username        user
Domain          domain. net
Proxy           192.168.1.1:8080
Listen          127.0.0.1:3128
Auth NTLM
PassNTLMv2      C9ACE7FB80841EB5B94D1C4E10D7DB5B

Для использования cntlm в качестве локального прокси в Linux, нужно настроить переменные окружения http_proxy, https_proxy, ftp_proxy:

# export {http,https,ftp}_proxy="http://127.0.0.1:3128/"

Чтобы отключить прокси, выполните команду:

# unset {http,https,ftp}_proxy

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

Недавно в логах получил сообщение

The number of correctable errors associated with this memory module has exceeded acceptable levels.

Как точно определить сбойный модуль? Через fmadm faulty определяем UUID события и смотрим детали по нему:

Читать далее →

Запись опубликована 10. 02.2021 автором skeletor в рубрике Solaris.

Если так случилось, что ваш grub перестал грузить Solaris, то эта статья для вас. Скажу сразу, что бывает 2 режима: rescue и normal. Если вам не повезло и вас выбрасывает в rescue (об этом сообщает приглашение grub rescue>), то нужно с него загрузится в normal и потом уже грузить ОС. Отличие rescue от normal’a — значительны: в rescue доступны лишь 4 команды (ls, set, unset, insmod). Если у вас режим normal, то можете пропустить этот абзац.

Читать далее →

Запись опубликована 25.11.2020 автором skeletor в рубрике Solaris.

EPOLL

For few fds, this backend is a bit little slower than poll and select, but it scales phenomenally better. While poll and select usually scale like O(total_fds) where n is the total number of fds (or the highest fd), epoll scales either O(1) or O(active_fds).

Читать далее →

Запись опубликована 09.10.2020 автором skeletor в рубрике Разное, мелочи.

В базовом функционале roundcube уже есть плагин sieve. И тут остаётся дело за малым: прикрутить это всё к dovecot+exim (via dovecot delivery). И так, ниже настройки dovecot.conf:

Читать далее →

Запись опубликована 21.09.2020 автором skeletor в рубрике Почтовые системы, Разное, мелочи.

При использовании proxy_pass, особенно если в качестве upstream’ов используется DNS name есть один нюанс, который хоть и описан в документации, но требует пояснения. Ниже цитата из рассылки nginx:

Читать далее →

Запись опубликована 19.09.2020 автором skeletor в рубрике www, Разное, мелочи.

Исходные данные: в пуле с дисками 500Gb построенном на slice’ах вылетел один из дисков. Новый диск — 2Tb. И так:

# zpool status rpool
  pool: rpool
 state: DEGRADED
status: One or more devices are unavailable in response to persistent errors.
        Sufficient replicas exist for the pool to continue functioning in a
        degraded state.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or 'fmadm repaired', or replace the device
        with 'zpool replace'.
        Run 'zpool status -v' to see device specific details.
  scan: resilvered 2.20G in 4m56s with 0 errors on Fri Jan 18 07:07:30 2019

config:

        NAME          STATE      READ WRITE CKSUM
        rpool         DEGRADED      0     0     0
          mirror-0    DEGRADED      0     0     0
            c3t1d0s0  UNAVAIL       0     0     0
            c3t0d0s0  ONLINE        0     0     0

errors: No known data errors

Читать далее →

Запись опубликована 19. 09.2020 автором skeletor в рубрике Solaris.

Если кратко, то данная ошибка говорит, что размер письма отличается от ожидаемого. Такое поведение возникает, если содержимое файла письма изменилось (случайно или преднамеренно). При этом разные клиенты могут по-разному отображать это письмо: частично или вообще никак (показывать ошибку). В сети почти все варианты решения выглядят так: удалите из папки Maildir файлы dovecot.* и перезапустите dovecot (dovecot перепланирует папку и создаст заново эти файлы). Такой рецепт подойдёт, если у вас старая версия, до 2.0.X включительно. Но если у вас версия 2.1.Х, то это не поможет.

Читать далее →

Запись опубликована 26.05.2020 автором skeletor в рубрике Почтовые системы, Разное, мелочи.

pure-authd очень удобный механизм для внешней аутентификации. Но при большой нагрузке это может стать реальной проблемой: он однопоточный. Да, он все запросы складывает в свой backlog, но легче от этого не становится. И вы можете ждать своей очереди на аутентификацию и минуту и две и больше. Но у большинства ftp-клиентов таймаут на аутентификацию стоит в 20 секунд, поэтому это не вариант на высоких нагрузках.

Читать далее →

Запись опубликована 22.05.2020 автором skeletor в рубрике Разное, мелочи.

Ниже будут выдержки цитат из рассылки nginx, которые объясняют простые вещи при открытии/переоткрытии сокета не только в случае nginx’a, а и некоторых общих случаях.

Читать далее →

Запись опубликована 28.04.2020 автором skeletor в рубрике Linux, Разное, мелочи.

Нашёл хорошую статью на эту тему. Данный функционал появился, начиная с 11.3

Запись опубликована 20. 03.2020 автором skeletor в рубрике FreeBSD.

Старый баг NTLM-аутентификации Windows позволяет деанонимизировать пользователя

Исследователи годами рассказывают на конференциях о том, что технологии единого входа (Single Sign-on) небезопасны. Такую систему единой аутентификации для всего и сразу уже давно применяет Microsoft, а специалисты по информационной безопасности еще в 1997 году говорили о том, что это не слишком хорошая идея. В очередной раз уязвимость единого входа в целом и в случае работы с SMB-ресурсами в частности продемонстрировал российский исследователь ValdikSS. Он описал способ, который позволяет скомпрометировать Microsoft Account жертвы, деанонимизировать пользователей Microsoft и узнать данные о VPN.

По сути, для успешной реализации атаки злоумышленнику достаточно замаскировать ссылку на собственный SMB-ресурс (сетевые ресурсы: файлы и папки, принтеры и прочее), к примеру, под картинку и заставить жертву ее открыть. Атака работает на всех современных ОС, включая Windows 10 с последними обновлениями. Причем об этих проблемах с NTLM-аутентификацией говорили не только в 1997 году, о них вспоминают регулярно. Так, этот вопрос поднимали (PDF) в прошлом году на конференции BlackHat. К сожалению, от частых упоминаний ничего не меняется.

На «Хабрахабре» пользователь ValdikSS рассказал о том, как можно эксплуатировать этот «баг из 90-х» в наши дни. Исследователь пишет:

«Как только вы пытаетесь открыть ссылку на SMB-ресурс в стандартном браузере (Internet Explorer, Edge) или любом приложении, работающем через стандартные вызовы API Windows или использующим Internet Explorer в качестве движка для отображения HTML (Outlook, проводник Windows), SMB-ресурс сразу получает данные вашей учетной записи еще до того, как вы увидите диалог ввода имени и пароля. Атакующему достаточно, например, добавить ссылку на картинку с SMB-сервера на страницу сайта, или отправить вам письмо, которое достаточно будет просто открыть, и — бум! — данные вашей учетной записи в руках злоумышленника».

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

«Из названия домена обычно несложно понять, к какой организации относится учетная запись, а дальше, в случае успешного подбора пароля, можно попробовать аутентифицироваться на корпоративных ресурсах, доступных из интернета (почта, VPN).
Но пароль не всегда необходимо подбирать. Если вы наперед знаете какой-то ресурс, куда можно входить с использованием NTLM-аутентификации, вы можете в режиме реального времени, как только клиент подключится к вашему SMB-серверу, проксировать запросы от клиента к удаленному серверу и от сервера к клиенту, и успешно на нем аутентифицируетесь!», — объясняет ValdikSS.

Ситуация также усугубляется тем, что в современные ОС Microsoft активно продвигают использование единого Microsoft Account, буквально вынуждая пользователя создать его. Для пользователей Microsoft Account подобные атаки могут быть опасны вдвойне, причем не только для организаций, но и для частных лиц. Дело в том, что в случае атаки на SMB-сервер злоумышленника будут переданы данные, которые, по сути, скомпрометируют Microsoft Account жертвы, а к нему привязано множество сервисов (Skype, Xbox, OneDrive, Office 360, MSN, Bing, Azure и так далее).

Также исследователь пишет, что в ряде случаев атаку можно использовать для извлечения данных о логине и хеше пароля VPN-подключения жертвы.

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

«Эксплуатация с целью деанонимизации — поинтересней. Учетка будет отправляться со страниц сайта, если жертва использует Internet Explorer, или при клике внутри письма, в случае с Outlook. Почти все веб-интерфейсы почтовых служб фильтруют картинки со схемой file:// при выводе письма (схема file:// является аналогом схемы \\), но не Яндекс, который не считает это своей уязвимостью (что, в общем-то, корректно). Деанонимизация с использованием почты более опасна, т.к. дает связь не только IP-адреса с аккаунтом Windows, но и с почтой.
Chrome схема file:// тоже работает, но только из адресной строки. Загрузить что-либо с SMB картинкой или при нажатии на ссылку не получится. Так как Chrome гораздо популярней Internet Explorer, придется применять социальную инженерию.
Можно воровать аккаунты себе во благо. Некоторые VPN-провайдеры используют одинаковые логины и пароли как для входа в аккаунт, так и для VPN-аутентификации. Принадлежность аккаунта к тому или иному сервису можно определить по IP-адресу входящего подключения пользователя. А если вам достался Microsoft Account, и вы нашли пароль из хеша, то поздравляю — у вас есть доступ к файлам в облаке OneDrive, почте Outlook, аккаунту Skype, если он привязан к Microsoft-аккаунту, и еще куче всего».

В заключение ValdikSS пишет, что защититься от подобных атак можно, к примеру, ограничив доступ к 445 TCP-порту для всех диапазонов адресов, кроме:

192.168.0.0/16
169.254.0.0/16
172.16.0.0/12
10.0.0.0/8
fd00::/8
fe80::/10

Также в комментариях к статье пользователи предложили следующий метод:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
«RestrictReceivingNTLMTraffic»=dword:00000002
«RestrictSendingNTLMTraffic»=dword:00000002

Кроме того, исследователь создал специальную страницу, которая позволяет проверить свою систему на уязвимость перед данным типом атак.

Фото: ValdikSS

Общие сведения об аутентификации NTLM, шаг за шагом

Вот формулировка из официального источника:

Следующие шаги представляют схему NTLM неинтерактивного
аутентификация. На первом этапе предоставляются учетные данные NTLM пользователя.
и происходит только как часть интерактивной аутентификации (входа в систему)
процесс.
(только интерактивная проверка подлинности) Пользователь обращается к клиентскому компьютеру и предоставляет имя домена, имя пользователя и пароль. В
клиент вычисляет криптографический хеш пароля и отбрасывает
фактический пароль.
Клиент отправляет имя пользователя на сервер (в виде открытого текста).
Сервер генерирует 16-байтовое случайное число, называемое запросом или одноразовым номером, и отправляет его клиенту.
Клиент шифрует этот запрос хешем пароля пользователя и возвращает результат серверу. Это называется
отклик.
Сервер отправляет контроллеру домена следующие три элемента:
Имя пользователя
Запрос отправлен клиенту
Ответ от клиента
Контроллер домена использует имя пользователя для получения хэша пароля пользователя из базы данных Security Account Manager. Это
использует этот хэш пароля для шифрования запроса.
Контроллер домена сравнивает зашифрованный запрос, вычисленный им (на шаге 6), с ответом, вычисленным клиентом (на шаге 4). Если
они идентичны, аутентификация прошла успешно.

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

Методы шифрования различаются в зависимости от версии NTLM и различных настроек сервера.

Вот немного из Википедии:

И LMv2, и NTv2 хэшируют вызовы клиента и сервера с NT
хеш пароля пользователя и другая идентифицирующая информация. В
точная формула должна начинаться с NT Hash, который хранится в SAM
или AD и продолжайте хеширование, используя HMAC-MD5, имя пользователя и
доменное имя.

Аутентификация пользователя NTLM — Windows Server

000Z» data-article-date-source=»ms.date»> 27.09.2020
8 минут на чтение

В этой статье

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

Исходная версия продукта: Windows Server 2012 R2
Оригинальный номер базы знаний: 102716

Сводка

В этой статье обсуждаются следующие аспекты аутентификации пользователей NTLM в Windows:

Хранение паролей в базе данных аккаунта
Аутентификация пользователя с помощью пакета аутентификации MSV1_0
Сквозная аутентификация

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

Хранение паролей в базе данных аккаунта

Записи пользователей хранятся в базе данных диспетчера учетных записей безопасности (SAM) или в базе данных Active Directory.Каждая учетная запись пользователя связана с двумя паролями: паролем, совместимым с LAN Manager, и паролем Windows. Каждый пароль зашифрован и хранится в базе данных SAM или в базе данных Active Directory.

Пароль, совместимый с LAN Manager, совместим с паролем, который используется LAN Manager. Этот пароль основан на наборе символов производителя оригинального оборудования (OEM). Этот пароль не чувствителен к регистру и может содержать до 14 символов. Версия OWF этого пароля также известна как версия LAN Manager OWF или ESTD.Этот пароль вычисляется с использованием шифрования DES для шифрования константы открытым текстовым паролем. Пароль OWF LAN Manager имеет длину 16 байт. Первые 7 байтов пароля в открытом виде используются для вычисления первых 8 байтов пароля LAN Manager OWF. Вторые 7 байтов пароля в виде открытого текста используются для вычисления вторых 8 байтов пароля LAN Manager OWF.

Пароль Windows основан на наборе символов Unicode. Этот пароль чувствителен к регистру и может содержать до 128 символов.Версия OWF этого пароля также известна как пароль Windows OWF. Этот пароль вычисляется с использованием алгоритма шифрования RSA MD-4. Этот алгоритм вычисляет 16-байтовый дайджест строки переменной длины из байтов пароля в открытом виде.

У любой учетной записи пользователя может отсутствовать пароль LAN Manager или пароль Windows. Однако предпринимаются все попытки сохранить обе версии пароля.

Например, если учетная запись пользователя перенесена из базы данных LAN Manager UAS с помощью PortUas, или если пароль изменен из клиента LAN Manager или из клиента Windows for Workgroups, будет существовать только версия пароля LAN Manager.Если пароль установлен или изменен на клиенте Windows, и пароль не имеет представления LAN Manager, будет существовать только версия пароля для Windows. (Пароль может не иметь представления LAN Manager, поскольку длина пароля превышает 14 символов или символы не могут быть представлены в наборе символов OEM.)

Ограничения пользовательского интерфейса в Windows не позволяют паролям Windows превышать 14 символов. Последствия этого ограничения обсуждаются далее в этой статье.

В Windows 2000 с пакетом обновления 2 и в более поздних версиях Windows доступен параметр, позволяющий запретить Windows сохранять хэш вашего пароля LAN Manager. Для получения дополнительных сведений проверьте следующий номер статьи в базе знаний Microsoft:

299656 Как запретить Windows хранить хэш-код вашего пароля LAN Manager в Active Directory и локальных базах данных SAM

Примечание

Microsoft не поддерживает ручное или программное изменение базы данных SAM.

Аутентификация пользователя с использованием пакета аутентификации MSV1_0

Windows использует LsaLogonUser API для всех видов аутентификации пользователей. API LsaLogonUser аутентифицирует пользователей, вызывая пакет аутентификации. По умолчанию LsaLogonUser вызывает пакет аутентификации MSV1_0 (MSV). Этот пакет входит в состав Windows NT. Пакет аутентификации MSV хранит пользовательские записи в базе данных SAM. Этот пакет поддерживает сквозную аутентификацию пользователей в других доменах с помощью службы Netlogon.

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

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

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

Первая часть пакета аутентификации MSV преобразует пароль в открытом виде как в пароль LAN Manager OWF, так и в пароль Windows NT OWF. Затем первая часть пакета передает пароль в открытом виде либо в службу NetLogon, либо во вторую часть пакета. Вторая часть затем запрашивает в базе данных SAM пароли OWF и проверяет их идентичность.

Для входа в сеть клиент, который подключается к компьютеру, ранее получил 16-байтовый запрос или «одноразовый номер».«Если клиент является клиентом LAN Manager, клиент вычислил 24-байтовый ответ на запрос, зашифровав 16-байтовый запрос 16-байтовым паролем OWF LAN Manager. Затем клиент LAN Manager передает этот« Ответ на вызов LAN Manager » сервер. Если клиент является клиентом Windows, «ответ на вызов Windows NT» вычисляется с использованием того же алгоритма. Однако клиент Windows использует 16-байтовые данные Windows OWF вместо данных LAN Manager OWF. Клиент Windows затем передает на сервер ответ на запрос LAN Manager и ответ на запрос Windows NT.В любом случае сервер аутентифицирует пользователя, передавая все следующие данные API LsaLogonUser:

Доменное имя
Имя пользователя
Оригинальный вызов
Ответ на вызов LAN Manager
Дополнительный ответ на вызов Windows NT

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

Примечание

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

Как упоминалось ранее, любая версия пароля может отсутствовать в базе данных SAM или в базе данных Active Directory.Кроме того, при вызове LsaLogonUser может отсутствовать любая версия пароля. Если доступны как версия пароля для Windows из базы данных SAM, так и версия пароля для Windows из LsaLogonUser, используются обе версии. В противном случае для сравнения используется версия пароля LAN Manager. Это правило помогает обеспечить чувствительность к регистру при входе в сеть из Windows в Windows. Это правило также допускает обратную совместимость.

Сквозная аутентификация

Служба NetLogon реализует сквозную аутентификацию.Выполняет следующие функции:

Выбирает домен для передачи запроса аутентификации.
Выбирает сервер в домене.
Передает запрос аутентификации выбранному серверу.

Выбрать домен очень просто. Доменное имя передается LsaLogonUser. Доменное имя обрабатывается следующим образом:

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

NetLogon выбирает сервер в домене с помощью процесса, называемого обнаружением. Рабочая станция Windows обнаруживает имя одного из контроллеров домена Windows Active Directory в своем основном домене. Контроллер домена Active Directory обнаруживает имя контроллера домена Active Directory в каждом доверенном домене. Компонент, который выполняет обнаружение, — это DC Locator, который работает в службе Netlogon. Локатор DC использует разрешение имен NETBIOS или DNS для поиска необходимых серверов, в зависимости от типа домена и настроенного доверия.

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

В Active Directoy (AD) могут использоваться два протокола аутентификации:

NT LAN Manager (NTLM): Это протокол аутентификации запрос-ответ, который использовался до того, как стал доступен Kerberos. Однако в организации все еще могут быть компьютеры, использующие NTLM, поэтому он по-прежнему поддерживается в Windows Server.
Kerberos: Этот протокол работает на основе билетов и требует присутствия доверенной третьей стороны.

Основы работы NTLM

Вот пошаговое описание того, как работает проверка подлинности NTLM:

Пользователь указывает свое имя пользователя, пароль и имя домена на интерактивном экране входа в систему клиента.
Клиент разрабатывает хэш пароля пользователя и отбрасывает фактический пароль.
Клиент отправляет имя пользователя в виде обычного текста серверу, к которому он хочет получить доступ.
Сервер отправляет запрос клиенту.Это 16-байтовое случайное число.
Затем клиент отправляет ответ серверу. Этот ответ представляет собой запрос, зашифрованный хешем пароля пользователя.
Сервер отправляет запрос, ответ и имя пользователя контроллеру домена (DC).
Контроллер домена извлекает хэш пароля пользователя из своей базы данных, а затем шифрует запрос, используя его.
Контроллер домена сравнивает зашифрованный запрос, вычисленный им (на шаге выше), с ответом клиента.Если эти два совпадают, пользователь аутентифицируется.

NTLMv2 — большое улучшение по сравнению с NTLMv1

NTLMv2 — более безопасная версия NTLM (обсуждалась выше). Он отличается от своего предшественника следующим образом:

Он предоставляет запрос переменной длины вместо 16-байтового запроса случайного числа, используемого NTLMv1.
В NTLMv2 клиент добавляет дополнительные параметры к запросу сервера, такие как одноразовый номер клиента, одноразовый номер сервера, временная метка и имя пользователя.Затем он шифрует это хешем пароля пользователя с помощью алгоритма HMAC-MD5. Напротив, в NTLMv1 клиент добавляет только одноразовый номер клиента и одноразовый номер сервера к запросу сервера. Затем он шифрует это с помощью хеш-кода пароля пользователя с помощью относительно слабого алгоритма DES.

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

Как работает Kerberos

Kerberos был разработан в Массачусетском технологическом институте в 1980-х годах и в настоящее время стал наиболее широко используемой системой для аутентификации и авторизации в компьютерных сетях. Название Керберос происходит из древнегреческой мифологии, в которой Керберос — трехголовый пес, охраняющий подземный мир. Три главы Kerberos представлены в протоколе клиентом, ищущим аутентификацию, сервером, к которому клиент хочет получить доступ, и центром распределения ключей (KDC).KDC — это доверенная третья сторона, которая проверяет подлинность пользователей и является контроллером домена, на котором работает AD. Вот пошаговый процесс работы Kerberos:

Пользователь пытается подключиться к сети через интерактивный экран входа в систему клиента.
Клиент создает пакет, называемый аутентификатором , который содержит информацию о клиенте (имя пользователя, дату и время). За исключением имени пользователя, вся остальная информация, содержащаяся в аутентификаторе, зашифрована паролем пользователя.
Затем клиент отправляет зашифрованный аутентификатор в KDC.
KDC сразу узнает личность клиента, отправившего аутентификатор, по имени пользователя. Затем KDC будет искать в своей базе данных AD пароль пользователя, который является общим секретом. Затем он расшифровывает аутентификатор с паролем. Если KDC может расшифровать аутентификатор, это означает, что личность клиента проверена.
После подтверждения личности клиента KDC создает билет для выдачи билетов (TGT), который зашифрован ключом, известным только KDC.
KDC отправляет TGT клиенту. Клиент хранит TGT в своем лотке Kerberos. Он может использовать этот билет всякий раз, когда ему нужно получить доступ к ресурсу на сервере в сети (в течение типичного ограничения по времени в восемь часов).
Когда клиенту требуется доступ к другому серверу, он отправляет TGT в KDC вместе с запросом на доступ к ресурсу.
KDC расшифровывает TGT своим ключом. Этот шаг проверяет, что клиент ранее аутентифицировался в KDC.
KDC генерирует билет для клиента для доступа к общему ресурсу. Этот билет зашифрован ключом сервера. Затем KDC отправляет этот билет клиенту.
Клиент сохраняет этот билет в лотке Kerberos и отправляет его копию на сервер.
Сервер использует свой собственный пароль для расшифровки билета.

Если сервер успешно расшифровывает билет, он знает, что билет законный. Затем сервер откроет билет и решит, есть ли у клиента необходимое разрешение для доступа к ресурсу, просмотрев список управления доступом (ACL).

Теги: Аутентификация Active Directory, Аутентификация AD, разница между аутентификацией NTLM и Kerberos, как работает аутентификация NTLM, как Kerberos используется в Active Directory, как работает Kerberos, Kerberos, процесс аутентификации Kerberos, NTLM, аутентификация ntlmv1, NTLMv2, ntlmv2 проверка подлинности, что такое Kerberos и как он работает, что такое проверка подлинности Kerberos в активном каталоге, что такое служба проверки подлинности Kerberos, что такое проверка подлинности NTLM и Kerberos, для чего используется NTLM, какова функция Kerberos, Где используется Kerberos

Как NTLM Authentication Works — реализация Windows Server 2003 Network

Клиент

Контроллер домена

Клиент

Контроллер домена

Хэш пароля пользователя + Хеш пароля пользователя

Безопасность

Счета

База данных

Хэш пароля пользователя + Хеш пароля пользователя

Хэш пароля пользователя

Безопасность

Аккаунты

База данных

Хэш пароля пользователя

ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ

незаконно для использования не тренером

Введение

Процесс аутентификации

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

Следующие шаги демонстрируют поток событий, которые происходят, когда клиент проходит проверку подлинности на контроллере домена с использованием любого из протоколов NTLM. Клиент и сервер согласовывают протокол аутентификации. Это достигается с помощью поставщика поддержки безопасности Microsoft согласовать (SSP).

1. Клиент отправляет имя пользователя и имя домена контроллеру домена.

2.Контроллер домена генерирует 16-байтовую случайную строку символов, называемую одноразовым номером.

3. Клиент шифрует одноразовый номер хешем пароля пользователя и отправляет его обратно контроллеру домена.

4. Контроллер домена получает хэш пароля пользователя из базы данных учетных записей безопасности.

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

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

Имя пользователя

Целевой сервер

KDC создает пару билетов, один для клиента и один для сервера, на котором клиент хочет получить доступ к ресурсам. Каждый билет содержит имя пользователя, запрашивающего услугу, получателя запроса, метку времени, которая объявляет, когда билет был создан, и продолжительность времени, которая говорит, как долго билеты действительны.Оба билета также содержат новый ключ (KAB).

**************************** незаконно для использования без обучающих программ ************** **************** Введение Три компонента Kerberos:

■ Клиент, запрашивающий услуги или аутентификацию.

■ Сервер, на котором размещаются услуги, запрашиваемые клиентом.

■ Компьютер, которому доверяют клиент и сервер. (В данном случае контроллер домена Windows Server 2003, на котором запущена служба KDC. )

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

Примечание. Чтобы сократить количество раз, когда пользователь должен проходить аутентификацию в KDC, клиенты Kerberos реализуют кэширование билетов. Для получения дополнительной информации о механизме кэширования билетов см. Kerberos.doc в разделе Дополнительная литература на веб-странице компакт-диска «Материалы учащегося».

Проверка подлинности Kerberos В среде Kerberos процесс проверки подлинности начинается при входе в систему. Следующие шаги описывают процесс аутентификации Kerberos.

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

2. KDC ищет главный ключ пользователя (KA), который основан на пароле пользователя. Затем KDC создает два элемента: сеансовый ключ (SA) для совместного использования с пользователем и Ticket-Granting Ticket (TGT).TGT включает в себя вторую копию SA, имя пользователя и срок действия. KDC шифрует этот билет, используя свой собственный главный ключ (KKDC), который знает только KDC.

Примечание. Kerberos реализует криптографию с секретным ключом, которая отличается от криптографии с открытым ключом тем, что не использует пару открытого и закрытого ключей.

3. Клиентский компьютер получает информацию от KDC и запускает пароль пользователя с помощью функции одностороннего хеширования, которая преобразует пароль в KA пользователя.Клиентский компьютер теперь имеет сеансовый ключ и TGT, чтобы он мог безопасно взаимодействовать с KDC. Теперь клиент аутентифицирован в домене и готов получить доступ к другим ресурсам в домене с помощью протокола Kerberos.

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

4. Когда клиенту Kerberos требуется доступ к ресурсам на сервере, который является членом того же домена, он обращается к KDC. Клиент представит свой TGT и временную метку, зашифрованную с помощью сеансового ключа, который уже используется KDC. KDC расшифровывает TGT, используя свой KKDC. TGT содержит имя пользователя и копию SA. KDC использует SA для расшифровки отметки времени. KDC может подтвердить, что этот запрос действительно исходит от пользователя, потому что только пользователь может использовать SA.

5.Затем KDC создает пару билетов, один для клиента и один для сервера, на котором клиенту требуется доступ к ресурсам. Каждый билет содержит имя пользователя, запрашивающего услугу, получателя запроса, метку времени, которая объявляет, когда билет был создан, и продолжительность времени, которая говорит, как долго билеты действительны. Оба билета также содержат новый ключ (KAB), который будет совместно использоваться клиентом и сервером, чтобы они могли безопасно обмениваться данными.

6. KDC берет билет сервера и шифрует его с помощью главного ключа сервера (КБ).Затем KDC вкладывает билет сервера в билет клиента, который также содержит KAB. KDC шифрует все, используя сеансовый ключ, которым он делится с пользователем в процессе входа в систему. Затем KDC отправляет пользователю всю информацию.

7. Когда пользователь получает билет, он расшифровывает его с помощью SA. Это открывает клиенту KAB, а также выставляет билет для сервера. Пользователь не может прочитать билет сервера. Пользователь зашифрует метку времени с помощью KAB и отправит метку времени и билет сервера на сервер, на котором клиент хочет получить доступ к ресурсам.Когда он получает эти два элемента, сервер сначала расшифровывает свой собственный билет, используя свой КБ. Это разрешает доступ к KAB, который затем может расшифровать временную метку от клиента.

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

Читать здесь: Имена учетных записей служб

Была ли эта статья полезной?

NTLM — Поддержка Kemp

NT LAN Manager (NTLM) — это протокол проверки подлинности Windows Challenge / Response, который часто используется в сетях, включающих системы под управлением операционной системы Windows и Active Directory.

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

Kerberos повышает безопасность сети, чем системы NTLM, и предоставляет системам на базе Windows встроенный механизм единого входа (SSO).Хотя Kerberos часто является предпочтительным методом проверки подлинности, для определенных сценариев клиент / сервер может потребоваться NTLM, например, когда брандмауэр предотвращает доступ к службам Kerberos.

Учетные данные

NTLM основаны на данных, полученных в процессе интерактивного входа в систему, и состоят из имени домена и пользователя. NTLM использует зашифрованный механизм запроса / ответа для аутентификации пользователя без отправки пароля пользователя по сети. Вместо этого система, запрашивающая аутентификацию, должна выполнить расчет, подтверждающий, что у нее есть доступ к защищенным учетным данным NTLM.Этот процесс состоит из трех подлежащих обмену сообщений, обычно называемых типом 1 (согласование), типом 2 (запрос) и типом 3 (аутентификация).

Интерактивная аутентификация NTLM по сети обычно включает две системы: клиентскую систему, где пользователь запрашивает аутентификацию, и контроллер домена, где хранится информация, относящаяся к паролю пользователя. Неинтерактивная проверка подлинности, которая может потребоваться для разрешения уже вошедшему в систему пользователя для доступа к ресурсу, такому как серверное приложение, обычно включает три системы: клиент, сервер (обычно сервер Exchange) и контроллер домена, который выполняет аутентификация от имени сервера.

Edge Security Pack (ESP) на Kemp LoadMaster поддерживает несколько методов аутентификации, включая NTLM. Это позволяет пользователям беспрепятственно проходить аутентификацию в виртуальных сервисах, защищенных ESP, и безопасно подключаться к серверным приложениям, таким как Microsoft Exchange и SharePoint. Назначение документа

Цель этого документа — предоставить пошаговые инструкции по настройке LoadMaster для использования аутентификации NTLM.

1.1 Целевая аудитория

Этот документ предназначен для использования клиентами, которые заинтересованы в том, чтобы узнать, как настроить LoadMaster для использования аутентификации NTLM, и которые уже имеют некоторое представление о протоколе NTLM.

1.2 Связанная версия прошивки

Опубликовано с LMOS версии 7.2.48.3 LTS. Этот документ не требовал изменений с 7.2.48.3 LTS. Однако контент синхронизируется с последней прошивкой LoadMaster LTS.

Чтобы установить и настроить аутентификацию NTLM с помощью Kemp LoadMaster и ESP, необходимо выполнить ряд шагов. Пошаговые инструкции см. В разделах ниже.

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

NTLM на LoadMaster не работает с некоторыми программами безопасности Windows 10, такими как Credential Guard, которые не поддерживают NTLM.Как указано в документации Credentials Guard: «Когда вы включаете Credential Guard в Защитнике Windows, вы больше не можете использовать классическую проверку подлинности NTLM для единого входа».

2.1 Настройка параметров Интернета на клиентском компьютере

Адрес сайта безопасности необходимо добавить в зону локальной интрасети на клиентском компьютере. Для этого выполните следующие действия:

1. Нажмите Пуск и выберите Панель управления .

2.Щелкните Свойства обозревателя .

3. Выберите вкладку Security .

4. Щелкните Местная интрасеть .

5. Щелкните Сайты .

6. Щелкните Advanced .

7. Введите адрес сайта безопасности и нажмите Добавить .

8.Нажмите Закрыть .

9. Щелкните ОК .

10. Еще раз нажмите ОК .

2.2 Настройка LoadMaster

Для того, чтобы NTLM работала с LoadMaster, необходимо создать домен SSO как клиента, так и сервера. Инструкции по добавлению этих SSO-доменов в LoadMaster см. В разделах ниже.

2.2.1 Настройка домена SSO на стороне сервера

Чтобы настроить домен SSO на стороне сервера, выполните следующие действия в пользовательском веб-интерфейсе LoadMaster (WUI):

1.В главном меню выберите Virtual Services> Manage SSO .

2. В разделе Конфигурации единого входа на стороне сервера введите имя домена единого входа (SSO) в текстовое поле Имя и нажмите Добавить .

3. Выберите Ограниченное делегирование Kerberos в качестве протокола аутентификации .

4.Введите адрес Kerberos Realm и нажмите Set Kerberos Realm . Нажмите ОК .

Область Kerberos обычно является доменом. Область Kerberos должна быть именем (а не IP-адресом), например kemptech.local . Если указан IP-адрес, аутентификация работать не будет. В этом поле можно указать только одно имя.

В этом поле нельзя использовать двойные кавычки.

5. Введите Центр распространения ключей Kerberos имя и щелкните Установить Kerberos KDC .Нажмите ОК .

Это поле принимает только один Центр распространения ключей. Адрес центра распространения ключей обычно является IP-адресом экземпляра Active Directory.

В этом поле нельзя использовать двойные кавычки.

6. Введите Имя доверенного пользователя Kerberos и нажмите Установить имя доверенного пользователя KCD . Нажмите ОК .

Имя доверенного пользователя Kerberos должно совпадать с именем хоста LoadMaster.Доверенный пользователь представляет LoadMaster. Обратитесь к документу «Ограниченное делегирование Kerberos, описание функций», чтобы узнать о некоторых дополнительных ключевых требованиях, касающихся доверенной учетной записи пользователя.

Двойные и одинарные кавычки не допускаются в поле Kerberos Trusted User Name .

7. Введите пароль доверенного пользователя Kerberos и нажмите Установить пароль доверенного пользователя KCD . Нажмите ОК .

2.2.2 Настройка домена SSO на стороне клиента

Клиентский домен SSO можно создать, перейдя в Virtual Services> Manage SSO> Add (в разделе Client Side Single Sign On Configurations ) и заполнив необходимые сведения. Протокол аутентификации должен быть установлен на LDAP , чтобы аутентификация NTLM работала.

Информацию о настройке конечной точки LDAP см. В следующей статье базы знаний: Как настроить конечную точку LDAP.

2.2.3 Настройка виртуальной службы

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

Эти шаги предполагают, что виртуальная служба уже настроена и настроена по мере необходимости (кроме настроек ESP). Для получения дополнительной информации о виртуальных службах в целом см. Виртуальные службы и шаблоны, Описание функций. Для получения дополнительной информации о различных полях в LoadMaster WUI, пожалуйста, обратитесь к Веб-интерфейсу пользователя (WUI), Руководству по настройке.

1. В главном меню LoadMaster WUI выберите Virtual Services> View / Modify Services .

2. Щелкните Изменить в соответствующей виртуальной службе.

3. Разверните раздел ESP Options .

4. Установите флажок Включить ESP , чтобы включить ESP.

5. Выберите NTLM в качестве Client Authentication M ode .

6. Выберите домен SSO на стороне клиента, который был создан в разделе «Настроить домен SSO на стороне клиента» в раскрывающемся списке Домен SSO .

7. Задайте любые Разрешенных виртуальных хостов и Разрешенных виртуальных каталогов , если необходимо.

8. Выберите KCD в качестве режима аутентификации сервера .

9. Выберите домен SSO на стороне сервера, который был создан в разделе «Настройка домена SSO на стороне сервера» в раскрывающемся списке Конфигурация на стороне сервера .

10. Настройте любые другие параметры ESP, если необходимо.

Для получения дополнительной информации о параметрах ESP WUI и ESP в целом см. Edge Security Pack (ESP), Описание функций.

2.3 Настройте Firefox для разрешения NTLM (при необходимости)

Во многих организациях Internet Explorer настроен на использование NTLM на внутренних сайтах, а Firefox — нет. Чтобы настроить Firefox для разрешения определенных сайтов, выполните следующие действия:

1.Откройте Firefox.

2. В адресной строке введите about: config .

3. Может появиться предупреждение, нажмите кнопку, чтобы продолжить.

4. В текстовом поле Search введите network.automatic .

5. Дважды щелкните запись network.automatic-ntlm-auth.trusted-uris.

6. Введите адрес (а) соответствующего сайта.

Можно добавить несколько сайтов, разделив их запятой.

7. Щелкните ОК .

Возможно, потребуется перезапустить Firefox, чтобы изменения вступили в силу.

В некоторых средах может потребоваться обновление следующих трех параметров:

network.automatic-ntlm-auth.trusted-uris

network.negotiate-auth.delegation-uris

network.negotiate-auth.trusted-uris

Также может потребоваться изменить signon.autologin.proxy на t rue (дважды щелкните параметр, чтобы изменить значение).

2.4 Устранение неисправностей

При устранении проблем с аутентификацией NTLM в LoadMaster может быть полезно просмотреть журналы ESP.

Различные уровни журналов ESP могут быть включены для каждой виртуальной службы, установив флажки в разделе ESP Logging .

Эти журналы затем можно просмотреть, выбрав «Конфигурация системы »> «Параметры ведения журнала»> «Расширенные файлы журналов ».Для получения дополнительной информации о ведении журнала ESP см. Edge Security Pack (ESP), Описание функции.

Если не указано иное, следующие документы можно найти по адресу http://kemptechnologies.com/documentation.

Edge Security Pack (ESP), описание функции

Веб-интерфейс пользователя (WUI), Руководство по настройке

Виртуальные службы и шаблоны, описание функций

Ограниченное делегирование Kerberos, описание функции

Последний раз этот документ обновлялся 7 декабря 2020 г.

Раскрытие внутренней информации

с использованием скрытой аутентификации NTLM | автор: m8r0wn | The Startup

Фото vishnu vijayan на Pixabay

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

NTLM — это протокол аутентификации типа «запрос / ответ», используемый системами Windows, в котором фактический пароль пользователя никогда не пересылается по сети. Вместо этого запрашивающий клиент получает ответ на запрос от сервера и должен выполнить вычисление, подтверждающее его личность. Я сильно упрощаю этот процесс, но приведенная ниже диаграмма является хорошим примером того, как эта схема аутентификации работает в среде Windows AD.

Итак, как это помогает в получении конфиденциальной внутренней информации? Как только цель идентифицирована как использующая аутентификацию NTLM, мы можем инициировать соединение и отправить анонимные (нулевые) учетные данные или волшебную строку «TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA =», которая предложит серверу ответить ответом на запрос NTLM типа 2. Это ответное сообщение может быть декодировано для отображения информации о сервере, такой как: NetBIOS, DNS и информация о версии сборки ОС:

 Target_Name: DEMO 
 NetBIOS_Domain_Name: DEMO 
 NetBIOS_Computer_Name: SRV01 
 DNS_Domain_Name: demo. local 
 DNS_Computer_Name: srv01.demo.local 
 DNS_Tree_Name: demo.local 
 Product_Version: 6.3.9600

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

Хотя это и не самая престижная уязвимость, но если она будет обнаружена в отношении цели bug bounty, вы можете воспользоваться этим внутренним раскрытием для нескольких быстрых точек:

Обычно при посещении веб-сайта или каталога, требующего привилегированного доступа, сервер инициирует приглашение для входа в систему. Это позволяет клиенту отправлять пустые значения имени пользователя и пароля для проверки подлинности NTLM и получения зашифрованного ответа. Однако, если целевой сервер настроен на разрешение windowsAuthentication, этот ответ может быть вызван без приглашения на вход.Это можно сделать, добавив «Авторизация: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAA =» в заголовки запроса.

После того, как запрос NTLM возвращается в значении «WWW-Authenticate» заголовков ответа, его можно декодировать для захвата внутренней информации. Я лично использую Burp’s NTLM Challenge Decoder, но было написано несколько других скриптов, которые могут выполнять эти действия.

Немногие могут знать трюк с добавлением заголовка «Авторизация» для запроса ответа от сервера, но я недавно обнаружил NTLM в других протоколах, которые можно использовать с помощью аналогичного подхода.Через Telnet мы можем взаимодействовать с другими службами вне браузера, чтобы вызвать ответ на запрос NTLM и декодировать это значение для получения той же информации.

 SMTP корень @ поташ: телнет example.com 587 
 220 example.com SMTP Server Banner >> HELO 
 250 example.com Здравствуйте [хххх] >> AUTH NTLM 334 
 NTLM поддерживается >> TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA = 
 334 TlRMTVNTUAACAAAACgAKADgAAAAFgooCBqqVKFrKPCMAAAAAAAAAAEgASABCAAAABgOAJQAAAA9JAEkAUwAwADEAAgAKAEkASQBTADAAMQABAAoASQBJAFMAMAAxAAQACgBJAEkAUwAwADEAAwAKAEkASQBTADAAMQAHAAgAHwMI0VPy1QEAAAAA

IMAP

 root @ kali: пример telnet.com 143 
 * OK Служба Microsoft Exchange IMAP4 готова. >> a1 AUTHENTICATE NTLM 
 + >> TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA = 
 +

TlRMTVNTUAACAAAACgAKADgAAAAFgooCBqqVKFrKPCMAAAAAAAAAAEgASABCAAAABgOAJQAAAA9JAEkAUwAwADEAAgAKAEkASQBTADAAMQABAAoASQBJAFMAMAAxAAQACgBJAEkAUwAwADEAAwAKAEkASQBTADAAMQAHAAgAHwMI0VPy1QEAAAAA и больше …

Если вы провели в любое время вокруг Windows, вы уже догадались, что это возможно, так как проверка подлинности NTLM можно найти в любом количестве мест. Такие протоколы, как HTTP, SMTP, IMAP, POP3, RDP, MS-SQL, NNTP, TELNET и другие, также могут быть подвержены этому типу раскрытия. Хотя для использования этого в других протоколах требуется нечто большее, чем просто сеанс Telnet, мы можем легко автоматизировать поиск, используя сценарии NSE NMAP:

 root @ kali: nmap -sS -v --script = * - ntlm-info --script-timeout = 60s example.com Отчет о сканировании Nmap для xxxx 
 Host работает (задержка 0,0063 с). 
 Не показано: 998 фильтрованных портов 
 PORT STATE SERVICE 
 80 / tcp open http 
 | http-ntlm-info: 
 | Target_Name: IIS01 
 | NetBIOS_Domain_Name: IIS01 
 | NetBIOS_Computer_Name: IIS01 
 | DNS_Domain_Name: IIS01 
 | DNS_Computer_Name: IIS01 
 | _ Product_Version: 6.3.9600

Эта команда запустит протокол NMAP для целевого объекта и выполнит сценарии, перечисленные ниже, если определены правильные порты. По умолчанию http-ntlm-info.nse будет пытаться выполнить запрос аутентификации, добавив заголовок «Авторизация» к корневой странице сервера. Это можно изменить, добавив «- script-args http-ntlm-info.root = / EWS» к аргументам командной строки и изменив значение страницы по мере необходимости.

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

Ссылки и дополнительные ресурсы:

http://davenport.sourceforge.net/ntlm.html
https://docs.microsoft.com/en-us/windows/win32/secauthn/microsoft-ntlm
https: / /blog.gdssecurity.com/labs/2014/2/12/http-ntlm-information-disclosure.html

ntlm-auth · PyPI

Об этой библиотеке

Эта библиотека обрабатывает низкоуровневые детали аутентификации NTLM для
использовать при аутентификации с помощью службы, использующей NTLM.Он создаст и
проанализировать 3 разных типа сообщений в требуемом порядке и создать
Значение в кодировке base64, которое можно прикрепить к заголовку HTTP.

Цель этой библиотеки — предложить полную поддержку NTLM, включая подписывание
и запечатывание сообщений, а также поддержка MIC для целостности сообщения
а также возможность настраивать и устанавливать ограничения на отправляемые сообщения. Пожалуйста
см. «Функции» и «Журнал невыполненных работ», чтобы узнать, что есть, а что нет
поддерживается.

Установка

ntlm-auth поддерживает Python 2.6, 2.7 и 3.3+

Для установки используйте pip:

 pip install ntlm-auth

Для установки из исходного кода загрузите исходный код и запустите:

 установка python setup.py

Использование

Практически все пользователи должны использовать
запросы-ntlm вместо
эта библиотека. Библиотека requests-ntlm — это плагин, который использует это
библиотека под капотом и обеспечивает более простую функцию в использовании и
понимать.

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

При инициализации контекста ntlm вам необходимо указать NTLM
уровень совместимости. Ключевое различие между разными auth
уровни — это переменная ntlm_compatibility, предоставляемая при инициализации
Ntlm. Обзор того, что каждый набор, представлен ниже; * 0 — LM Auth и
NTLMv1 Auth * 1 — LM Auth и NTLMv1 Auth с расширенным сеансом
Безопасность (NTLM2) * 2 — NTLMv1 Auth с расширенной безопасностью сеанса
(NTLM2) * 3 — NTLMv2 Auth (выбор по умолчанию) * 4 — NTLMv2 Auth
* 5 — NTLMv2 Auth

Уровни 3–5 одинаковы с точки зрения клиента, но отличаются тем, как
сервер обрабатывает аутентификацию, которая выходит за рамки этого проекта.Этот
настройка устанавливается независимо на этом сервере, поэтому выберите 3, 4 или 5, когда
вызов Ntlm не будет иметь никакого значения. Видеть
LmCompatibilityLevel
Больше подробностей.

Extended Session Security — это функция безопасности, предназначенная для увеличения
безопасность LM и NTLMv1 auth. Это не замена NTLMv2, но
лучше, чем ничего, и его следует использовать по возможности, когда вам нужен NTLMv1
совместимость.

Необходимые переменные указаны ниже; * имя пользователя —
имя пользователя для аутентификации, не должно иметь префикса домена,
я.е. USER not DOMAINUSER * пароль — пароль пользователя к
аутентифицироваться с * доменом — домен пользователя, то есть DOMAIN.
Может быть пустым, если не в среде домена * рабочая станция —
рабочая станция, на которой вы работаете. Может быть пустым, если вы не хотите отправлять
this * cbt_data — (только NTLMv2)
gss_channel_bindings.GssChannelBindingsStruct, используемый для связывания с
ответ авторизации. Может иметь значение None, если привязка не требуется

LM Auth / NTLMv1 Auth

LM и NTLMv1 Auth — старые методы аутентификации, которые должны быть
по возможности избегать.Выбор между этими методами аутентификации
почти идентичны, за исключением того, где вы указываете ntlm_compatiblity
уровень.

 импортная розетка

из ntlm_auth. ntlm импортировать NtlmContext

username = 'Пользователь'
пароль = 'Пароль'
domain = 'Domain' # Может быть пустым, если вы не в домене
workstation = socket.gethostname (). upper () # Может быть пустым, если вы не хотите отправлять эту информацию

ntlm_context = NtlmContext (имя пользователя, пароль, домен, рабочая станция, ntlm_compatibility = 0) # Здесь укажите уровень ntlm_compatibility, 0-2 для LM Auth / NTLMv1 Auth
gotiate_message = ntlm_context.шаг()

# Присоедините сообщениеgotiate_message к вашему HTTP-заголовку NTLM / NEGOTIATE и отправьте на сервер. Получите ответ на запрос от сервера
Challenge_message = http.response.headers ['HEADERFIELD']

Authenticate_message = ntlm_context.step (сообщение_вызова)

# Прикрепите Authenticate_message к вашему HTTP-заголовку NTLM_NEGOTIATE и отправьте на сервер. Теперь вы аутентифицированы с помощью NTLMv1

NTLMv2

NTLMv2 Auth — это новейший метод NTLM-аутентификации от Microsoft, который должен быть
опция, выбранная по умолчанию, если вам не требуется более старый метод аутентификации. Реализация такая же, как NTLMv1, но с добавлением
необязательная переменная server_certificate_hash и
ntlm_compatibility не указана.

 импорт base64
импортный сокет

из ntlm_auth.gss_channel_bindings импортировать GssChannelBindingsStruct
из ntlm_auth.ntlm импортировать NtlmContext

username = 'Пользователь'
пароль = 'Пароль'
domain = 'Domain' # Может быть пустым, если вы не в домене
workstation = socket.gethostname (). upper () # Может быть пустым, если вы не хотите отправлять эту информацию

# создайте структуру CBT, если хотите связать ее с ответом auth
server_certificate_hash = '96B2FC1EC30792619286A0C7FD62863E81A6564E72829CBC0A46F7B1D5D92A18'
certificate_digest = base64.b16decode (server_certificate_hash)
cbt_data = GssChannelBindingsStruct ()
cbt_data [cbt_data.APPLICATION_DATA] = b'tls-server-end-point: '+ certificate_digest

ntlm_context = NtlmContext (имя пользователя, пароль, домен, рабочая станция, cbt_data, ntlm_compatibility = 3)
gotiate_message = ntlm_context.step ()

# Присоедините сообщениеgotiate_message к вашему HTTP-заголовку NTLM / NEGOTIATE и отправьте на сервер.  Получите ответ на запрос от сервера
Challenge_message = http.response.headers ['HEADERFIELD']

Authenticate_message = ntlm_context.шаг (Challenge_message)

# Прикрепите Authenticate_message к вашему HTTP-заголовку NTLM_NEGOTIATE и отправьте на сервер. Теперь вы аутентифицированы с помощью NTLMv1

Подпись / печать

Все версии NTLM поддерживают подпись (целостность) и запечатывание.
(конфиденциальность) содержания сообщения. Эта функция может добавлять эти
улучшения сообщения, отправляемого и получаемого с сервера.
Хотя он шифрует данные, если поддерживается сервером, он только
сделано с RC4 со 128-битным ключом, который не очень безопасен и на старых
В системах длина ключа может составлять 56 или 40 бит.Эта функциональность пока
протестировано и соответствует документации Microsoft, еще не полностью
протестирован в интегрированной среде. Еще раз этого не было
тщательно протестирован и прошел только юнит-тесты и их ожидания.

импорт base64
импортный сокет
из ntlm_auth. ntlm импортировать NtlmContext
username = 'Пользователь'
пароль = 'Пароль'
domain = 'Domain' # Может быть пустым, если вы не в домене
workstation = socket.gethostname (). upper () # Может быть пустым, если вы не хотите отправлять эту информацию
# создайте структуру CBT, если хотите связать ее с ответом auth
server_certificate_hash = '96B2FC1EC30792619286A0C7FD62863E81A6564E72829CBC0A46F7B1D5D92A18'
certificate_digest = base64.b16decode (server_certificate_hash)
cbt_data = GssChannelBindingsStruct ()
cbt_data [cbt_data.APPLICATION_DATA] = b'tls-server-end-point: '+ certificate_digest
ntlm_context = NtlmContext (имя пользователя, пароль, домен, рабочая станция, cbt_data, ntlm_compatibility = 3)
gotiate_message = ntlm_context.step ()
# Присоедините сообщениеgotiate_message к вашему HTTP-заголовку NTLM / NEGOTIATE и отправьте на сервер. Получите ответ на запрос от сервера
Challenge_message = http.response.headers ['HEADERFIELD']
Authenticate_message = ntlm_context.шаг (Challenge_message)
# Прикрепите Authenticate_message к вашему HTTP-заголовку NTLM_NEGOTIATE и отправьте на сервер.
No related posts.

Ноябрь 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

Авторизация ntlm: Авторизация с помощью NTLM | UserGate Support & Service

Авторизация с помощью NTLM | UserGate Support & Service

Проверка подлинности пользователей NTLM — Windows Server

В этой статье

Аннотация

Дополнительные сведения

Хранилище паролей в базе данных учетных записей

Проверка подлинности пользователя с помощью пакета MSV1_0 проверки подлинности

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

Аутентификация NTLM-это просто приглашение (вызов) или она действительно аутентифицируется?

2 ответа

Похожие вопросы:

NTLM Failed в ManageEngine ServiceDesk

Как выглядит ошибка входа на ManageEngine ServiceDesk 10500

Решение проблемы с единым входом на ManageEngine ServiceDesk

Авторизация прокси по NTLM в Linux

Установка cntlm

Настройка cntlm

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

Старый баг NTLM-аутентификации Windows позволяет деанонимизировать пользователя

Общие сведения об аутентификации NTLM, шаг за шагом

Аутентификация пользователя NTLM — Windows Server

В этой статье

Сводка

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

Хранение паролей в базе данных аккаунта

Аутентификация пользователя с использованием пакета аутентификации MSV1_0

Сквозная аутентификация

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

Основы работы NTLM

NTLMv2 — большое улучшение по сравнению с NTLMv1

Как работает Kerberos

Как NTLM Authentication Works — реализация Windows Server 2003 Network

Процесс аутентификации

NTLM — Поддержка Kemp

1.1 Целевая аудитория

1.2 Связанная версия прошивки

2.1 Настройка параметров Интернета на клиентском компьютере

2.2 Настройка LoadMaster

2.2.1 Настройка домена SSO на стороне сервера

2.2.2 Настройка домена SSO на стороне клиента

2.2.3 Настройка виртуальной службы

2.3 Настройте Firefox для разрешения NTLM (при необходимости)

2.4 Устранение неисправностей

с использованием скрытой аутентификации NTLM | автор: m8r0wn | The Startup

IMAP

TlRMTVNTUAACAAAACgAKADgAAAAFgooCBqqVKFrKPCMAAAAAAAAAAEgASABCAAAABgOAJQAAAA9JAEkAUwAwADEAAgAKAEkASQBTADAAMQABAAoASQBJAFMAMAAxAAQACgBJAEkAUwAwADEAAwAKAEkASQBTADAAMQAHAAgAHwMI0VPy1QEAAAAA и больше …

Ссылки и дополнительные ресурсы:

ntlm-auth · PyPI

Об этой библиотеке

Установка

Использование

LM Auth / NTLMv1 Auth

NTLMv2

Подпись / печать

Добавить комментарий Отменить ответ