Аутентификации Windows (NTLM) и LDAP могут работать независимо друг от друга. Аутентификация Windows требует ввода учетных данных пользователя в окне авторизации браузера. А аутентификация LDAP использует проверку пароля пользователя на сервере Active Directory. Аутентификации Windows (NTLM) и LDAP работают вместе, когда пользователь нажимает ссылку “Войти под доменным пользователем”, и его аккаунт синхронизирован с LDAP.
На заметку. Аутентификация Windows доступна только для on-site приложений в связи с особенностями cloud-архитектуры.
При попытке пользователя войти в систему, используя доменные учетные данные, выполняется следующий алгоритм аутентификации:
Выполняется проверка авторизации пользователя в домене.
Имя и пароль текущего доменного пользователя считываются из cookie-файла, если эти данные записаны в cookie. В противном случае отображается браузерное окно ввода учетных данных.
Дальнейшие шаги зависят от того, синхронизирован ли пользователь с каталогом LDAP.
Если пользователь не синхронизирован с LDAP:
Выполняется проверка подлинности пользователя путем сравнения логина и пароля, записанных в cookie-файл, с учетными данными соответствующей записи Creatio. Таким образом, для возможности Windows-аутентификации пользователя, не синхронизированного с LDAP, необходимо, чтобы при регистрации данного пользователя в Creatio были указаны те же логин и пароль, которые используются им в домене.
Если по результатам проверки данные совпадают и учетная запись пользователя лицензирована, осуществляется авторизация в приложении.
Если пользователь синхронизирован с LDAP:
Браузер посылает запрос в службу Active Directory для проверки подлинности пользователя.
Запрос возвращает учетные данные текущего доменного пользователя, которые сравниваются с логином и паролем, записанными в cookie-файл.
На заметку. Проверка подлинности выполняется как среди пользователей основного приложения, так и среди пользователей портала самообслуживания. Порядок проверки настраивается в файле Web.config приложения-загрузчика. Подробнее: Настроить файл Web.config приложения-загрузчика.
Для использования функциональности аутентификации Windows по протоколу NTLM необходимо зарегистрировать пользователей в системе вручную или импортировать из LDAP и предоставить им лицензии. Также необходимо, чтобы у пользователей в настройках браузера была разрешена запись локальных данных в cookie-файлы.
Настройка выполняется на сервере, где развернуто приложение, и включает в себя:
Настройку сервера IIS, которая активирует аутентификацию по протоколу NTLM. Подробнее: Настроить аутентификацию Windows в IIS.
Настройку файла Web.config приложения-загрузчика, которая определяет провайдеров аутентификации и порядок проверки наличия пользователей среди зарегистрированных в Creatio. Подробнее: Настроить файл Web.config приложения-загрузчика.
Настроить аутентификацию Windows в IIS
Для приложения-загрузчика и веб-приложения включите анонимную аутентификацию и аутентификацию форм (Рис. 1).
На заметку. Обратите внимание, что необходимо выключить настройку “Windows Authentication”, которая в IIS включена по умолчанию.
Для директории Login внутри приложения-загрузчика отключите аутентификацию форм и включите анонимную аутентификацию и аутентификацию Windows (Рис. 2).
Обратите внимание, что анонимная аутентификация приложения-загрузчика и рабочих приложений должна выполняться под пользователем Application Pool Identity. Для этого перейдите в окно редактирования данных входа настроек Authentication по кнопке Edit в боковом меню Actions менеджера IIS, и выберите пользователя “Application Pool Identity” (Рис. 3).
Настроить файл Web.config приложения-загрузчика
InternalUserPassword — провайдер, указанный в файле Web.config по умолчанию. Если вы хотите предоставить возможность аутентификации по NTLM-протоколу только пользователям, которые не синхронизированы с LDAP, не указывайте для параметра providerNames дополнительные значения.
Ldap — добавьте к значениям параметра providerNames данный провайдер, чтобы предоставить возможность аутентификации по NTLM-протоколу пользователям приложения, которые синхронизированы с LDAP.
SSPLdapProvider — добавьте к значениям параметра providerNames данный провайдер, чтобы предоставить возможность аутентификации по NTLM-протоколу пользователям портала самообслуживания, которые синхронизированы с LDAP.
NtlmUser — добавьте к значениям параметра autoLoginProviderNames данный провайдер, чтобы предоставить возможность аутентификации по NTLM-протоколу пользователям приложения, независимо от того, синхронизированы ли они с LDAP и какой тип аутентификации установлен для данных пользователей в Creatio.
SSPNtlmUser — добавьте к значениям параметра autoLoginProviderNames данный провайдер, чтобы предоставить возможность аутентификации по NTLM-протоколу пользователям портала самообслуживания, независимо от того, синхронизированы ли они с LDAP и какой тип аутентификации установлен для данных пользователей в Creatio.
Если после выполнения описанных действий при первой попытке входа в систему отображается окно доменной авторизации, то необходимо дополнительно настроить свойства обозревателя Windows.
Чтобы в дальнейшем окно доменной авторизации не отображалось: В меню “Start” → “Settings” → “Control Panel” → “Network and Internet” выберите пункт “Internet options” (Рис. 4).
Откройте для редактирования файл Web.config приложения-загрузчика.
Укажите в файле провайдеры аутентификации Windows:
Если вы хотите активировать сквозную аутентификацию, чтобы пользователь имел возможность авторизоваться в Creatio, минуя страницу входа, укажите значение “true” для параметра UsePathThroughAuthentication элемента :
В открывшемся окне перейдите на вкладку “Security” и по кнопке “Custom level” перейдите к настройкам безопасности (Рис. 5).
В группе настроек “User Authentication” выберите способ авторизации “Automatic logon with current user name and password” (Рис. 6).
В результате пользователи, которые уже прошли аутентификацию в домене, смогут войти в Creatio по ссылке “Войти как доменный пользователь”, и им не придется повторно вводить учетные данные домена каждый раз для получения доступа к Creatio.
Аутентификация в продукте «Форсайт. Аналитическая платформа»
В продукте «Форсайт. Аналитическая платформа» доступно несколько методов аутентификации. Метод аутентификации выбирается в зависимости от требуемых мер безопасности.
Проверка учётных данных может производиться на сервере СУБД и/или в «Форсайт. Аналитическая платформа».
Настольное приложение
В настольном приложении доступны следующие базовые типы аутентификации:
Доступность базовых методов аутентификации зависит от используемой СУБД:
Тип СУБД \ Тип аутентификации
— тип аутентификации доступен;
— тип аутентификации недоступен.
Парольная аутентификация
Аутентификация производится с использованием логина и пароля. Доступна настройка парольной политики.
Пользователь вводит логин и пароль в «Форсайт. Аналитическая платформа».
«Форсайт. Аналитическая платформа» обращается к СУБД, используя предоставленные данные.
Ролевая аутентификация
Ролевая аутентификация аналогична парольной, производится с использованием логина и пароля. Доступ к объектам определяется по присвоенным пользователю ролям на сервере СУБД, которые совпадают с группами в «Форсайт. Аналитическая платформа».
Пользователь вводит логин и пароль в «Форсайт. Аналитическая платформа».
«Форсайт. Аналитическая платформа» обращается к СУБД, используя предоставленные данные.
СУБД возвращает список ролей пользователя. Список ролей сопоставляется со списком групп платформы. Пользователь получает права, соответствующие группам.
Доменная аутентификация
При доменной аутентификации пользователь подключается с использованием данных указанного доменного пользователя.
Для конечного пользователя доменная аутентификация не отличается от парольной, но упрощает администрирование пользователей при использовании доменных контроллеров.
Пользователь вводит доменное имя и пароль в «Форсайт. Аналитическая платформа».
«Форсайт. Аналитическая платформа» передаёт указанные учётные данные на сервер СУБД.
СУБД обращается к доменному контроллеру, доменный контроллер проверяет правильность указанных данных и делегирует «Форсайт. Аналитическая платформа» право на подключение от имени доменного пользователя с использованием временного билета.
Интегрированная доменная аутентификация
Интегрированная доменная аутентификация аналогична обычной доменной аутентификации, но для авторизации будет использован доменный пользователь, под которым был совершен вход в операционную систему.
Метод аутентификации Kerberos:
При работе с СУБД Teradata интегрированная доменная аутентификация всегда осуществляется с использованием механизма аутентификации Kerberos. Для СУБД PostrgreSQL данный механизм может быть включён опционально в дополнительных параметрах соединения с репозиторием.
Для работы по протоколу Kerberos на клиентском компьютере необходимо установить MIT Kerberos (не входит в комплект поставки «Форсайт. Аналитическая платформа»).
Пользователь вводит доменное имя и пароль при входе в операционную систему.
«Форсайт. Аналитическая платформа» передаёт указанные учётные данные на сервер СУБД.
СУБД обращается к доменному контроллеру, доменный контроллер проверяет правильность указанных данных и делегирует «Форсайт. Аналитическая платформа» право на подключение от имени доменного пользователя с использованием временного билета.
Двухфакторная аутентификация
Пользователь выполняет базовую аутентификацию в «Форсайт. Аналитическая платформа».
После запроса пользователь предоставляет «Форсайт. Аналитическая платформа» сертификат.
При совпадении сертификата «Форсайт. Аналитическая платформа» обращается к СУБД, используя предоставленные данные.
Встроенная аутентификация
При встроенной аутентификации доступ к данным СУБД происходит под встроенным администратором. Проверка прав пользователя осуществляется на уровне платформы. Учётные данные администратора хранятся в зашифрованном виде. Встроенная аутентификация настраивается через контроль доступа.
Пользователь вводит логин и пароль в «Форсайт. Аналитическая платформа».
«Форсайт. Аналитическая платформа» проверяет разрешения пользователя и обращается к СУБД, используя учётные данные встроенного администратора.
Веб-приложение
Для веб-приложения доступны все варианты аутентификации настольного приложения, при этом роль настольного приложения выполняет BI-сервер.
Дополнительно для веб-приложения доступны следующие методы аутентификации:
OAuth
Аутентификация через протоколы OAuth 1.1 и 2.0 позволяет пользователю авторизоваться под учётной записью сервиса Twitter, Google и других. Подключение к СУБД в этом случае будет производиться под сохраненными зашифрованными учётными данными администратора.
Пользователь вводит логин и пароль соответствующего сервиса.
Поставщик данных (сервис) передает BI-серверу подтверждение аутентификации пользователя.
BI-сервер обращается к СУБД, используя данные встроенного администратора.
Протокол SAML позволяет совершать обмен аутентификационными данными между поставщиком аутентификации и «Форсайт. Аналитическая платформа». Подключение к СУБД в этом случае будет производиться под сохраненными зашифрованными учётными данными администратора.
Пользователь предоставляет логин и пароль поставщику аутентификации.
Поставщик аутентификации передает «Форсайт. Аналитическая платформа» результат проверки данных пользователя.
«Форсайт. Аналитическая платформа» обращается к СУБД, используя данные встроенного администратора.
Гостевой вход
Для ознакомительной работы с веб-приложением возможна настройка гостевого входа. Пользователь сможет войти под заранее созданной гостевой учётной записью, не указывая учётных данных. При использовании гостевого входа рекомендуется ограничить права для гостевой учётной записи.
Пользователь переходит по гостевой ссылке.
BI-сервер обращается к СУБД, используя заранее введённые логин и пароль от гостевой учётной записи.
Статья ориентирована на начинающих Codeigniter-щиков, таких как я.
В процессе создания внутреннего сайта одной из российских компаний, возникла необходимость ограничить доступ пользователей к некоторым страницам, функциям. Так как все пользователи в домене, то и на сайте есть смысл использовать доменную аутентификацию.
Найти самостоятельно информацию в принципе не трудно. Поисковые системы еще ни кто не отменял. Я просто решил собрать найденные кусочки и объединить их в один, на русском языке.
Допустим, что CI уже установлен и настроен. Кстати, на одном из западных сайтов, доступно много хороших и исчерпывающих видео уроков по настройке и использованию Codeigniter-а.
Добавим библиотеку и конфигурационный файл
Конечно, существуют некоторые функции в самом PHP, но использовать их не всегда рационально. За основу возьмем библиотеку adLDAP. В ней есть все необходимое и даже больше.
Первым делом создадим конфигурационный файл, например adldap.php и положим его в \system\application\config\
Далее необходимо добавить библиотеку. Но как сделать так, что бы ей можно было пользоваться в CI, как остальными? За нас это уже сделал один программист, и предоставил для общественного пользования (онутверждает, что лицензия не нарушена). Ее мы и добавим в \system\libraries\ и назовем, например Adldap.php.
После выше описанных манипуляций библиотекой можно пользоваться в Codeigniter-е, как и другими, например:
Напишем небольшой код авторизации
Сделать это проще простого. Во-первых, создадим форму для ввода логина и пароля:
Во-вторых, контролер и саму функцию для авторизации в домене. Но домен большой и пользователей много и если просто проверять пароль и логин, то к ограниченным частям сайта будут иметь все члены домена.
Для более тонкой настройки нужен еще один параметр для проверки — группа (Active Directory). Назовем ее, например Web_Group, и добавим нужных нам пользователей:
Вот и все. Теперь в любой другой функции можно делать проверку и в зависимости от результата предоставлять или не предоставлять доступ. Примерно это должно выглядеть так:
//Вытаскиваем и проверяем прошел или нет пользователь авторизацию if ($this->session->userdata(‘is_logged_in’) == true) <
echo «Доступ к данным открыт»;
Теперь осталось только дописать функцию уничтожения сессии (Logout):
function logout() < $this->session->sess_destroy(); redirect(); >
Аутентификация — это незаменимая процедура для каждого пользователя, компьютера и служебной учетной записи Windows, но ее механизм не изучается системными администраторами досконально. Каждый знает, что для регистрации в компьютере необходимо указать верный пароль, но многим ли известно, что происходит потом? Аутентификация Windows и связанные с ней протоколы активизируются каждый раз, когда пользователь, компьютер или служба регистрируются локально или на контроллере домена (DC). В данной статье речь пойдет сначала об основных принципах аутентификации Windows, а затем о связанных с ней протоколах. В заключение приводятся краткие рекомендации по повышению надежности процедуры аутентификации в сети Windows.
Аутентификация: общие принципы
Аутентификация представляет собой один из компонентов любой компьютерной системы управления доступом. Как показано на экране 1, системы управления доступом обеспечивают идентификацию, аутентификацию, авторизацию и отчетность.
Рисунок 1. Механизмы управления доступом и аутентификация Windows
Идентификация (identification). В процессе идентификации используется набор данных, который уникально идентифицирует объект безопасности (например, пользователя, группу, компьютер, учетную запись службы) в общей службе каталогов. Служба каталогов, такая как Active Directory (AD), позволяет уникально идентифицировать объекты, подобно тому как DNS удостоверяет, что два человека не могут иметь одинаковые адреса электронной почты. Во внутренних механизмах Windows используются SID, глобально уникальные идентификаторы (globally unique identifier, GUID) и другие уникальные тэги. В большинстве случаев для идентификации достаточно ввести уникальное имя учетной записи, такое как Rgrimes. В большом лесу AD приходится применять полные имена пользователей (user principal name, UPN), например rgrimes@banneretcs.com. При использовании смарт-карт субъект безопасности может представить свой цифровой сертификат или ключ.
Аутентификация или проверка подлинности (authentication). После того как субъект безопасности вводит с клавиатуры или иным способом предоставляет необходимую для идентификации информацию (например, имя пользователя, маркер безопасности), он должен ввести с клавиатуры или представить частную информацию для аутентификации (например, пароль и PIN-код). В Windows субъект безопасности вводит эту информацию на экране регистрации с помощью программ Microsoft Graphical Identification and Authentication DLL (msgina.dll) и Winlogon.exe. Протокол аутентификации и механизм системы кодируют представленную информацию на настольном компьютере и передают запрос аутентификации. Служба аутентификации Windows может быть базой данных SAM или AD. База данных SAM обслуживает локальные процедуры регистрации и регистрацию на контроллерах домена Windows NT 4.0. AD аутентифицирует запросы в Windows 2000 или доменах более поздних версий этой операционной системы. Протокол аутентификации (например, LAN Manager, NT LAN Manager, NTLM, NTLMv2, Kerberos) используется для транспортировки запросов аутентификации и последующих транзакций между экраном регистрации и службой аутентификации. Чуть ниже каждый протокол аутентификации будет рассмотрен отдельно.
Авторизация (authorization). Если служба аутентификации удостоверяет комбинацию идентификатора и «секретных» данных аутентификации, то подлинность субъекта безопасности считается успешно подтвержденной. Затем система собирает информацию о членстве субъекта безопасности (т. е. пользователя) в группах. Нередко пользователь принадлежит к нескольким точно определенным группам — локальным (local), доменным (domain local), глобальным (global) и универсальным (universal) — в результате обычных процедур назначения членства. Система сверяет локальные группы с локальной базой данных SAM и проверяет локальные и глобальные группы на контроллерах DC в домашнем домене пользователя, а также универсальные группы на DC, который содержит глобальный каталог Global Catalog. Прямо или косвенно система собирает все сведения о членстве в группах, чтобы получить информацию о разрешениях безопасности.
Сразу после аутентификации система собирает идентификаторы SID учетной записи и сведения о членстве в группах в объекте, называемом маркером доступа (access token). Возможно, пользователю придется выйти и вновь зарегистрироваться в системе, чтобы новые разрешения безопасности вступили в силу. Если пользователю нужно получить доступ к объекту (например, файлу, папке, принтеру, разделу реестра), защищенному разрешениями NTFS, то процесс (например, Windows Explorer), выступающий от имени пользователя, предоставляет свой маркер доступа. Каждый объект NTFS располагает списком элементов управления доступом (access control entry, ACE), которые, в сущности, представляют собой знакомые разрешения NTFS (например, Allow Read, Allow Write). Набор элементов ACE, назначенных пользователям и группам, составляет список управления доступом (ACL) данного объекта. Примечательно, что ACL объекта представлен разрешениями безопасности, которые можно просмотреть в Windows Explorer.
Маркер доступа, содержащий учетную запись и группы, с которыми связан пользователь, определяет эффективные разрешения пользователя. Процесс авторизации заключается в разрешении или отказе в доступе к определенному объекту на основе сравнения маркера доступа с ACL объекта. Авторизацию обеспечивает Security Reference Monitor системы Windows (экран 1). В примере, показанном на экране 1, пользователь имеет разрешения Read, Write и Modify. Однако группа Everyone, к которой принадлежит пользователь, не имеет разрешения Modify. Члены других групп располагают разрешениями Read и Modify, но разрешение Deny группы Everyone отменяет разрешение Modify. Объект также располагает списками ACL, которые отказывают в разрешении Full Control группе HR, но пользователь к этой группе не принадлежит. Таким образом, эффективные разрешения пользователя по отношению к объекту на экране 2 — Read и Write.
Отчетность (accounting). Если в Windows режим аудита активизирован, то система сохраняет событие аутентификации в журнале Security, и это последний компонент системы управления доступом — отчетность. Большинство сложных событий начальной регистрации и последующей авторизации происходят за несколько секунд и скрыты от пользователя. Все сложные операции возлагаются на протокол аутентификации.
Задачи протокола
Протокол аутентификации должен выполнять по крайней мере две задачи. Во-первых, он должен безопасно передавать транзакции от запросчика в базу данных аутентификации и на любой другой компьютер, на котором размещен соответствующий ресурс. Во-вторых, он должен безопасно и надежно хранить пароль или маркер. Последнее представляет особый интерес для взломщиков паролей. Протокол аутентификации должен защитить введенную пользователем информацию при пересылке в базу данных аутентификации (т. е. SAM или AD). Для этого протокол подписывает, скрывает или шифрует транзакцию. Кроме того, ей присваивается временная метка, чтобы взломщик не мог воспользоваться учетными данными в будущем. Чтобы не позволить немедленно извлечь пароль пользователя из базы данных, протокол должен обеспечить скрытное хранение паролей в базе данных аутентификации.
В течение более чем десяти лет протоколы аутентификации в основном обеспечивали защиту путем сохранения паролей в скрытой форме (обычно хешированной) в базе данных аутентификации и полного запрета на передачу паролей между запросчиком и базой данных аутентификации простым текстом (даже в скрытой форме). Процесс запрос—ответ выглядит следующим образом:
В протоколах аутентификации используется процесс запрос—ответ, поэтому пароль никогда не передается через сеть.
Локальная и доменная регистрация
При регистрации пользователя одна из первых задач Windows — определить, относится ли процедура только к локальной машине или к учетной записи домена. Пользователи, регистрирующиеся от имени локальной учетной записи, имеют доступ только к ресурсам своего компьютера и только если информация об учетной записи пользователя содержится в локальной базе данных SAM. Если пользователям нужно обратиться к ресурсам на удаленном компьютере без аутентификации в домене, то их учетные записи должны быть продублированы в локальной базе данных SAM каждого доступного компьютера. Учетные записи в каждом компьютере-участнике должны быть синхронизированы (одинаковые имена регистрации, пароли и сроки действия учетных данных на всех машинах). В противном случае положение значительно усложняется. Трудно обслуживать одноранговые (P2P) сети средних размеров, в которых применяются только локальные процедуры регистрации.
На DC не распространяется требование синхронизации нескольких учетных записей пользователей на разных компьютерах. При доменной аутентификации компьютеры, зарегистрированные в домене, отыскивают контроллеры DC, чтобы предъявить учетные данные доменной учетной записи пользователя при запросах аутентификации. Таким образом, если удаленный пользователь пытается получить доступ к локальному ресурсу какой-нибудь машины, то этот компьютер просит DC проверить идентичность запрашивающего пользователя. Учетные записи пользователя домена располагаются только на DC и создаются лишь один раз. Любой компьютер-участник, которому нужно удостоверить учетную запись в домене, может обратиться к контроллерам DC в любое время. Проблемы синхронизации имен регистрации, паролей и сроков их действия не возникает, так как учетные данные и управление учетной записью осуществляются только в одном месте — на DC. Независимо от типа регистрации (локальной или доменной), Windows должна аутентифицировать запрос пользователя.
Протоколы аутентификации Windows
Как отмечалось выше, в Windows применяется четыре основных протокола аутентификации: LAN Manager, NTLM, NTLMv2 и Kerberos. LAN Manager появился во времена DOS и продолжал использоваться с первыми версиями Windows. NTLM был выпущен вместе с NT. Новшеством пакета обновлений NT Server 4.0 Service Pack 4 (SP4) стал NTLMv2, а Windows 2000 привнесла Kerberos. По умолчанию все компьютеры с Windows 2000 и более новыми операционными системами совместимы со всеми четырьмя протоколами аутентификации. Передавая в эти системы соответствующие команды, другие рабочие станции и серверы могут выбирать протокол для обработки запроса аутентификации. Системы Windows 9x и более поздние с полным набором программных исправлений совместимы с LM, NTLM и NTLMv2. На платформе Microsoft Kerberos может использоваться только клиентами Windows 2000 (или более новыми) при обращениях в домены Windows 2000 (и выше). Компьютер с Windows 2000 или более новой версией операционной системы должен иметь Kerberos и по крайней мере еще один из протоколов аутентификации.
Исследования в области безопасности показали, что более старые протоколы (LM и NTLM) уязвимы в случае прослушивания и атак с разгадыванием пароля.
Поэтому, если возможно, рекомендуется использовать только Kerberos и NTLMv2. Чтобы убедиться в правильности этого совета, следует оценить возможности каждого протокола.
LAN Manager
Компания IBM разработала протокол LAN Manager, применив его в ранних версиях Windows и сетях Windows. Как все протоколы аутентификации Microsoft, LAN Manager генерирует хеш паролей (LM hash), который хранится и используется отправителем и получателем в процессе аутентификации. LAN Manager формирует LM-хеши, изменяя все буквы пароля на верхний регистр, разбивая пароль на две 7-символьные половины, а затем шифруя. В дальнейшем LM-хеш используется в нескольких последовательных операциях, аналогичных процессу запрос—ответ, описанному выше.
Если раньше LAN Manager был вполне приемлем, то сейчас он считается очень ненадежным. С помощью специальных инструментов пароли, зашифрованные методом хеширования LAN Manager, можно всего за несколько секунд преобразовать в простой текст. LM-хешам свойственны принципиальные недостатки, а также имеется ряд уязвимых мест:
Почему LAN Manager до сих пор не вышел из употребления? В целях обратной совместимости он активен по умолчанию во всех компьютерах Windows, в том числе Windows Server 2003. В новейших базах данных аутентификации Windows слабый LM-хеш хранится наряду с более надежными просто на случай, если придется выполнить транзакцию LAN Manager. Если на предприятии не используются другие приложения, требующие аутентификации LAN Manager, то можно (и нужно) LAN Manager отключить.
С появлением NT компания Microsoft спроектировала и развернула более надежный протокол аутентификации NTLM. В NTLM используется более эффективный алгоритм аутентификации, который создает более надежный хеш паролей (NTLM hash). Пароль NTLM может содержать до 128 символов. В отличие от хеширования LAN Manager, ограниченного использованием только символов ASCII, NTLM совместим с полным набором символов Unicode, что повышает сложность паролей. NTLM-хеш отсекается на 128-м символе, преобразуется в 16-разрядное значение Unicode, обрабатывается распределительной функцией MD4 и сохраняется в 32-символьной шестнадцатеричной строке. За счет использования NTLM-хеша в операциях запрос—ответ последовательность аутентификации NTLM гораздо сложнее процедуры LAN Manager.
NTLMv2
В итоге выяснилось, что и NTLM уязвим, и специалисты Microsoft подготовили NTLMv2, который до сих пор считается достаточно надежным, хотя сейчас предпочтительный протокол — Kerberos. NTLMv2 по-прежнему широко используется для локальной регистрации и в некоторых других случаях. NTLMv2 похож на NTLM, но в хеше пароля NTLMv2 используется аутентификация сообщений HMAC-MD5, а последовательности запрос—ответ присваивается метка времени, чтобы предотвратить атаки, в ходе которых взломщик записывает учетные данные и впоследствии их использует.
В целом NTLMv2 более устойчив к атакам с применением «грубой силы», нежели NTLM, так как в протоколе применяется 128-разрядный ключ шифрования. Известно только о двух программах взлома паролей (одна из них — LC5 компании Symantec), с помощью которых удавалось открыть хеши паролей NTLMv2.
Kerberos
Компания Microsoft приняла Kerberos в качестве выбираемого по умолчанию протокола доменной аутентификации для доменов Windows 2000, а затем и AD. Kerberos — открытый стандарт, пригодный для взаимодействия с инородными доменами (называемыми областями — realm — в UNIX и Linux). Каждый DC в доменах AD играет роль сервера распределения (Kerberos Distribution Server, KDC) и может участвовать в процедуре аутентификации. Безопасность повышается благодаря следующим характеристикам Kerberos:
Краткое описание работы Kerberos:
Следует обратить внимание, что, хотя принцип работы Kerberos напоминает инфраструктуру с частным открытым ключом (public key infrastructure, PKI), вся информация защищается с использованием симметричных ключей (в отличие от асимметричных ключей, применяемых в большинстве служб аутентификации).
Смарт-карты
Надежность паролей и других методов аутентификации на основе одного параметра быстро снижается. Электронная коммерция проникает в повседневную жизнь и возрастает как число способов кражи личных данных (спам, мошенничество с URL), так и вероятность злоупотреблений паролями. Многие специалисты считают, что аутентификация с двумя параметрами — в форме смарт-карт, USB-устройств или других криптографических устройств — в будущем станет обычным явлением для транзакций в Internet. Разработчики Microsoft встраивают в свои решения функции для работы с цифровыми сертификатами и смарт-картами. Для использования смарт-карт необходимо установить службу Certificate Services и распространить сертификаты смарт-карт. Конечно, нужны также физические смарт-карты, устройства считывания и программное обеспечение поставщика. Затем при необходимости пользователи могут вставлять свои смарт-карты в локальные устройства чтения для доступа к компьютеру Windows. При грамотном использовании смарт-карты могут существенно повысить надежность аутентификации.
Защита протокола аутентификации
В некоторых статьях ошибочно утверждается, что взломать механизм аутентификации Microsoft по-прежнему просто. В действительности из 20 существующих инструментов взлома пароля только два работают с NTLMv2 и лишь один — с Kerberos. Но, предприняв несколько простых шагов, можно отвести и эту угрозу. Для предотвращения попыток разгадывания и сброса пароля нужно принять следующие меры (большинство параметров можно настроить локально или с помощью Group Policy).
Обязанности пользователей
Благодаря NTLMv2, Kerberos и смарт-картам Windows располагает надежными механизмами аутентификации, устойчивыми к подслушиванию и атакам с применением метода перебора. Но оптимальные процедуры и надежные протоколы аутентификации не помогут, если пользователи назначают слабые пароли. Необходимо научить пользователей правильно выбирать пароли и добиться, чтобы пароли были сложными и надежными.
