Аутентификация в системах Windows. Часть 1 – NTLM | Настройка серверов windows и linux

Lan manager (lm)

В ранних локальных сетях Windows использовался протокол LAN Manager, который позже был перенесен в семейство Windows 9.x. Этот протокол не будет рассматриваться, поскольку он уже давно не существует в природе. Однако он поддерживается и сегодня и все еще используется на практике.

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

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

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

Ntlmv2

Microsoft выпустила вторую итерацию стандарта “KnightLM”, который был значительно улучшен с точки зрения криптографической стойкости и устойчивости к распространенным типам атак. Microsoft поняла, что протокол NTLM не отвечает современным требованиям безопасности. Протоколы NTLM и LM отключены по умолчанию в Windows 7 и Server 2008 R2.

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

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

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

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

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

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

Аудит событий ntlm аутентификации в домене

Проверьте, нужна ли аутентификация NNLAM каким-либо приложениям, прежде чем отключить NTLM в домене и перейти на Kerberos.

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

При установке значения Включить аудит для учетных записей домена, политика Network Security: Ограничение NTLM: Аудит входящего трафика также включается.

После выполнения всех условий аутентификация N TLM включается.

Каждый сервер может отображать данные, которые затем собираются в единый Журнал событий.

События из Windows с идентификатором события 4624 собираются разделом Microsoft-Windows – Аудит безопасности. Посетите эту страницу для получения подробной информации в разделе “Подробная информация об аутентификации”. Для аутентификации пользователей использовался TNF, если в строке Authentication Package не был указан NTLM.

Сейчас следите за значением Package Name (только NTLM). Для обозначения этого используются LM, NTLMv1 или DNH. Благодаря этому вы сможете определить, какие серверы и программы все еще используют старый протокол.

Используйте следующий сценарий PowerShell для поиска всех событий аутентификации NTLMv1:

Аутентификация kerberos

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

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

Работа Kerberos основывается на центральном сервере, называемом Key
Distribution Center (KDC) (Центр распределения ключей), который
предоставляет все необходимые ключи. KDC выпускает так называемые
билеты TGT (Ticket-Granting Tickets) (“Билеты для получения билетов”) и
предоставляет их клиентам, запрашивающим доступ к ресурсу на сервере.

Процедура получения клиентом первого билета TGT показана на рисунке ниже.

1. Пользователь осуществляет вход на компьютер-клиент с указанием имени
   пользователя и пароля.
2. Клиент шифрует пароль и сохраняет его.
3. Клиент отправляет KDC сообщение с запросом на аутентификационные
   данные для службы TGT, а также зашифрованный пароль пользователя.
4. KDC сравнивает зашифрованный пароль со своей эталонной копией для
   проверки их идентичности. Также осуществляется проверка временного
   штампа, приложенного клиентом к запросу, для подтверждения того, что
   указанное в штампе время находится в пределах пяти минут собственного
   времени KDC.
5. В случае полного соответствия KDC создает запрошенные
   аутентификационные данные для службы TGT посредством генерации
   сеансового ключа входа и шифрования его на пользовательском ключе.
6. KDC создает другой фрагмент аутентификационных данных посредством
   шифрования сеансового ключа входа и TGT пользователя своим собственным
   эталонным ключом.
7. KDC отправляет оба фрагмента аутентификационных данных клиенту.
8. Клиент расшифровывает сеансовый ключ входа из первого отрезка
   аутентификационных данных с помощью зашифрованного пароля и сохраняет
   этот сеансовый ключ входа в кэше своего билета.
9. Клиент также сохраняет TGT в своем кэше билета.

Теперь у клиента есть TGT, и он может использовать его для получения
билетов на доступ к ресурсам. Вот как это происходит.

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

Теперь у клиента есть билет, с помощью которого он получает доступ к
ресурсам на сервере.

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

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

Аутентификация по ключам доступа

Этот способ чаще всего используется для аутентификации устройств, сервисов или других приложений при обращении к веб-сервисам. Здесь в качестве секрета применяются ключи доступа (
access key, API key

Аутентификация по одноразовым паролям

Аутентификация по одноразовым паролям обычно применяется дополнительно к аутентификации по паролям для реализации
two-factor authentication
(2FA). В этой концепции пользователю необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей). Наличие двух факторов позволяет в значительной степени увеличить уровень безопасности, что м. б. востребовано для определенных видов веб-приложений.

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

Одноразовые пароли могут быть созданы различными способами. Наиболее распространенные:

1. Аппаратные или программные токены, способные генерировать одноразовые пароли на основе секретного ключа, введенного в эти токены, и текущего времени. Секретные ключи пользователей, которые являются собственным фактором, также хранятся на сервере, что позволяет проверить введенные одноразовые пароли. RSA SecurID является примером реализации аппаратного токена; приложение Google Authenticator – пример реализации программного токена.
2. Случайно сгенерированные коды, которые передаются пользователю через SMS или другой канал связи. В этой ситуации фактором владения является телефон пользователя (в частности, SIM-карта, привязанная к определенному номеру).
3. Распечатка или скретч-карта со списком предварительно сгенерированных одноразовых паролей. Для каждого нового входа в систему необходимо вводить новый одноразовый пароль с указанным номером.

Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.

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

Аутентификация по сертификатам

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

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

Сертификат X.509 является компонентом протокола SSL/TLS, используемого для подключения к серверу в рамках TLA, и исторически использовался веб-приложениями. В браузерах есть функции, позволяющие пользователю выбрать и применить сертификат для аутентификации.

Использование сертификата для аутентификации.

При проверке сертификата сервер проверяет его в соответствии со следующими правилами:

1. Сертификат должен быть подписан доверенным центром сертификации (проверка цепочки сертификатов).
2. Сертификат должен быть действителен на текущую дату (проверка действительности).
3. Сертификат не должен быть отозван соответствующим центром сертификации (проверка списка исключений).

Пример X.509 сертификата.

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

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

Аутентификация посредством .net passport

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

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

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

Система .NETPassport является бесплатной для регистрации и
использования. Пользователи интернета входят и выходят из системы на
сервере Passport и направляются на нужный веб-сайт после успешного
прохождения процедуры аутентификации.

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

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

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

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

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

Интегрированная аутентификация windows

Интегрированная аутентификацияWindows является наиболее безопасным
методом аутентификации, однако она доступна только в Internet Explorer.
Этот тип аутентификации раньше был известен как аутентификацияNTLM и
аутентификацияWindows NT вопрос/ответ.

Интегрированная аутентификацияWindows поддерживает как протокол
Kerberos v5, так и протокол NTLM (NT LAN Manager) для аутентификации
посредством пакета Negotiate.

При наличии ActiveDirectory и
соответствующей поддержке браузером (IE 5 или выше на платформе Windows
2000) используется протокол Kerberos, иначе – протокол NTLM.

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

Использование нескольких методов аутентификации

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

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

Выполняется интегрированная аутентификацияWindows, если она включена и
совместима с браузером.

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

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

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

Настройка сайта на работу с системой .net passport

Если веб-сайт или виртуальный каталог настроен на аутентификацию
пользователей посредством системы .NET Passport, то при первом запросе
пользователем файла на этом сайте появится запрос аутентификационных
данных .NET Passport.

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

Для реализации на сайте IIS аутентификации .NET Passport выполните
следующие шаги.

1. Откройте оснастку IIS MMC и разверните узел Web Sites (Веб-узлы) в
   левой части консоли.
2. Щелкните правой кнопкой мыши на соответствующем веб-сайте или
   виртуальном каталоге, для которого необходимо реализовать
   аутентификацию .NET Passport. Выберите Properties (Свойства).
3. В окне Properties откройте вкладку Directory Security (Безопасность
   каталога).
4. Нажмите на кнопку Edit (Изменить), расположенную в области
   Authentication And Access Control (Аутентификация и контроль доступа).
   Откроется окно Authentication Methods (Методы аутентификации).
5. В области Authenticated Access (Аутентифицируемый доступ) включите
   опцию .NET Passport Authentication (Аутентификация .NET Passport).
   После выбора той опции все остальные методы аутентификации будут
   недоступны. Тем не менее, вы по-прежнему сможете выбрать анонимный
   доступ.
6. При необходимости введите имя домена в текстовом поле Default Domain
   (Домен по умолчанию). Это домен, которому будут принадлежать имена
   пользователей на главном сервере после прохождения ими аутентификации
   .NET Passport. Для определения организации или домена при
   взаимодействии с системой, разработанной другой компанией (не
   Microsoft) можно задать Realm (Область).
7. Нажмите на кнопку OK для закрытия окна Authentication Methods (Методы
   аутентификации). Затем нажмите на кнопку OK для закрытия окна
   Properties (Свойства).

Если служба .NET Passport настроена правильно, то пользователям
отобразится запрос .NET Passport (см. рис. 7.2), за тем исключением,
что в нем будут указаны настройки, из таблицы 7.1, а не значения по
умолчанию, показанные на рисунке 7.2.

Настройка службы .net passport

Перед использованием службы .NET Passport необходимо подготовить
соответствующий сайт. Ниже приведена последовательность действий для
настройки на работу с сервером .NET Passport.

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

Теперь, когда вы знакомы с тем, как работают протоколы аутентификации, давайте обсудим параметры безопасности. Протоколы NTLM или LM являются безопасными, но если система настроена неправильно (например, ошибка в конфигурации).

Выбор протокола аутентификации основан на локальной или групповой политике. Откройте Конфигурация компьютера – Функциональные политики – Локальная политика в редакторе политик. Этот раздел содержит политику.

Политика сетевой безопасности в этом разделе гласит, что не следует сохранять хэш-значения LAN Manager при следующей смене пароля. Начиная с Vista и Server 2008, эта функция активна по умолчанию; до этого в Windows XP и более ранних версиях она была отключена по умолчанию (из-за вновь введенной информации).

Однако, исходя из нашего опыта, самыми безопасными версиями политики являются те, которые начинаются с Send NTLMv2-response only и ниже.

Вы можете указать значения в разделе HKE с помощью реестра. В качестве примера, чтобы указать значение LmCompatibilityLevel, необходимо создать DWORD-параметр MIMESetservicesLsa, который принимает значения от 0 до 5. Давайте рассмотрим их более подробно:

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

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

Какие риски для безопасности представляет это утверждение? Для вычисления сеансового ключа для безопасности сеанса NTLMv2 используются запросы сервера или клиента, а также данные клиента и сервера. DDS и EU-интерфейс могут быть объединены с аутентификацией NTLM или LME.

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

Материал сайта vhod-v-lichnyjkabinet.ru

Несколько слов о microsoft negotiate

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

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

Полное отключение ntlm в домене active directory

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

Стандарт saml

Взаимодействие провайдера и сервиса подробно описано стандартом Security Assertion Markup Language (SAML). В 2002-2003 годах были выпущены обновленные версии 1.0 и 1.1, а всего несколько лет спустя – несовместимая версия 2.1.

Он поддерживает многочисленные сценарии системной интеграции и является достаточно сложным. Основными компонентами стандарта являются

Стандарты ws-trust и ws-federation

Частью группы стандартов, определяющих службы SOAP/XML, являются W S-Trust и WS Federation. Среди участников – компании Microsoft, IBM и VeriSign. Эти технологии, которые отличаются от стандарта SAML и используются в основном в корпоративной среде, довольно сложны.

Интерфейс службы авторизации Secure Token Service (STS) описан в стандарте WS-Trust. Эта служба поддерживает создание, продление и отмену токенов. Хотя стандарт допускает различные форматы токенов, обычно используются токены SAML.

Механизмы сервисного взаимодействия между предприятиями описываются W S-Federation, в частности, протоколы обмена токенами. Сервис STS, описанный в стандарте WS, будет одновременно иметь функциональность и интерфейс, расширенные WS-Federation. Стандарт WS-Federation также определяет:

Хотя их методы различаются, можно сказать, что WS-Federation и SAML решают одни и те же задачи.

Форматы токенов

Существует множество типичных форматов токенов для веб-приложений, включая:

Заключение

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