Доменная (LDAP) аутентификация в Codeigniter
Статья ориентирована на начинающих 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();
>
Спасибо за внимание.
UPD: нашел еще одну интересную LDAP библиотеку.
Особенности аутентификации контроллера домена с использованием двух разных сертификатов
Как правило, аутентификация контроллера домена в среде Windows представляет собой стандартную задачу. Однако, в некоторых ситуациях эта типовая процедура может быть осложнена необходимостью одновременного использования двух сертификатов для различных сервисов. Данная проблема может возникать, к примеру, если сервер должен предоставлять один сертификат пользователям домена, а другой – для сервисов.
Схожая проблема возникла в одном из наших проектов, где заказчику необходимо было организовать аутентификацию пользователей в домене Microsoft Windows по сертификатам ГОСТ. Обычно подобные задачи решаются путем использования специализированного средства компании «КРИПТО-ПРО», а именно «КриптоПро Winlogon». Данный продукт существует на рынке достаточно давно и максимально проработан, но иногда могут возникать непредвиденные сложности при его внедрении, с которыми нашей компании и пришлось столкнуться. Для его функционирования необходимо соответствующим образом настроить рабочую станцию, домен и контроллеры домена. Одним из требований при настройке контроллера домена в данном случае является выпуск сертификата на ГОСТ.
В случае с нашим заказчиком возникла ситуация, при которой для доступа к контроллеру домена используется, кроме протокола LDAP, еще и LDAP через SSL (LDAPS) с использованием уже установленного на контроллере сертификата RSA.
Небольшое отступление: по умолчанию трафик LDAP не защищен, что предоставляет возможность осуществлять мониторинг трафика между LDAP–клиентом и сервером. Чтобы обеспечить передачу трафика LDAP в безопасном режиме, необходимо использовать технологию SSL/TLS, сокращенно такая технология называется LDAPS.
Комментарий из инструкции:
Так как данная проблема не является распространенной, и, учитывая, что добавляется российская криптография, то для ее решения пришлось искать новые подходы. Изучение инструкций и тематических форумов ответа не дало. В итоге, чтобы решить данную задачу, пришлось углубиться в ее изучение и разобраться, каким именно образом контроллер домена использует сертификаты.
Итак, как же работает выбор сертификата контроллером домена?
При необходимости выбрать сертификат, контроллер обращается к хранилищу сертификатов локального компьютера и использует сертификат из этого хранилища. В большинстве случаев там будет один сертификат, и тогда проблем не возникнет. Если же в хранилище находится больше одного сертификата, то контроллер возьмет первый валидный сертификат для аутентификации сервера. Таким образом, использование одновременно двух (или более) сертификатов для различных целей в хранилище нежелательно.
Однако в Windows Server существует возможность легитимного использования нескольких сертификатов. Для этого используется отдельное хранилище Active Directory Domain Services (NTDS\Personal), в котором хранится сертификат для доступа по LDAPS.
В таком случае процесс выбора сертификата можно описать более подробно: контроллер домена сначала обращается за сертификатом к специализированному хранилищу, а в случае неудачной попытки уже обращается к хранилищу локальной машины.
Чтобы просмотреть хранилище сертификатов сервисов на контролере домена, необходимо запустить консоль управления (MMC) и добавить оснастку «Сертификаты». Далее с помощью диспетчера сертификатов следует выбрать тип управления сертификатами.
Затем необходимо выбрать учетную запись Active Directory Domain Services.
Такой тип использования имеет ряд ограничений, накладываемых Windows. К примеру, невозможность автоматического обновления таких сертификатов для сервисов или управления сертификатами из данного хранилища через командную строку.
Возвращаясь к нашей проблеме, далее для ее решения нам оставалось только создать стенд с использованием двух сертификатов на основе отечественного и западного криптографических алгоритмов.
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Работая в среде Windows каждый системный администратор так или иначе сталкивается с системами аутентификации. Но для многих этот механизм представляет собой черный ящик, когда суть происходящих процессов остается неясна. В тоже время от правильной настройки аутентификации напрямую зависит безопасность сети, поэтому важно не только знать способы и протоколы, но и представлять их работу, хотя бы на общем уровне.
В рамках данного материала мы будем рассматривать сознательно упрощенное представление процедур аутентификации, достаточное для понимания базового принципа работы, впоследствии данные знания могут быть углублены путем изучения специализированной литературы.
Для начала внесем ясность в термины. Многие путают понятия аутентификации и авторизации, хотя это различные процедуры.
Для аутентификации в компьютерных системах традиционно используется сочетания имени пользователя и некой секретной фразы (пароля), позволяющей определить, что пользователь именно тот, за кого себя выдает. Существуют также и иные способы аутентификации, например, по смарт-карте, но в данной статье мы их касаться не будем.
Локальная аутентификация
Затем служба LSA обращается к диспетчеру учетных записей безопасности (SAM) и сообщает ему имя пользователя. Диспетчер обращается в базу SAM и извлекает оттуда хэш пароля указанного пользователя, сгенерированный при создании учетной записи (или в процессе смены пароля).
Затем LSA сравнивает хэш введенного пароля и хэш из базы SAM, в случае их совпадения аутентификация считается успешной, а хэш введенного пароля помещается в хранилище службы LSA и находится там до окончания сеанса пользователя.
В случае входа пользователя в домен, для аутентификации используются иные механизмы, прежде всего протокол Kerberos, однако, если одна из сторон не может его использовать, по согласованию могут быть использованы протоколы NTLM и даже устаревший LM. Работу этих протоколов мы будем рассматривать ниже.
LAN Manager (LM)
Протокол LAN Manager возник на заре зарождения локальных сетей под управлением Windows и впервые был представлен в Windows 3.11 для рабочих групп, откуда перекочевал в семейство Windows 9.х. Мы не будем рассматривать этот протокол, так как в естественной среде он уже давно не встречается, однако его поддержка, в целях совместимости, присутствует до сих пор. И если современной системе поступит запрос на аутентификацию по протоколу LM, то, при наличии соответствующих разрешений, он будет обработан.
Что в этом плохого? Попробуем разобраться. Прежде всего разберемся, каким образом создается хэш пароля для работы с протоколом LM, не вдаваясь в подробности обратим ваше внимание на основные ограничения:
Исходя из современных требований к безопасности можно сказать, что LM-хэш практически не защищен и будучи перехвачен очень быстро расшифровывается. Сразу оговоримся, прямое восстановление хэша невозможно, однако в силу простоты алгоритма шифрования возможен подбор соответствующей паролю комбинации за предельно короткое время.
А теперь самое интересное, LM-хэш, в целях совместимости, создается при вводе пароля и хранится в системах по Windows XP включительно. Это делает возможной атаку, когда системе целенаправленно присылают LM-запрос и она его обрабатывает. Избежать создания LM-хэша можно изменив политику безопасности или используя пароли длиннее 14 символов. В системах, начиная с Windows Vista и Server 2008, LM-хэш по умолчанию не создается.
NT LAN Manager (NTLM)
Новый протокол аутентификации появился в Windows NT и благополучно, с некоторыми изменениями, дожил до наших дней. А до появления Kerberos в Windows 2000 был единственным протоколом аутентификации в домене NT.
Сегодня протокол NTLM, точнее его более современная версия NTLMv2, применяются для аутентификации компьютеров рабочих групп, в доменных сетях Active Directory по умолчанию применяется Kerberos, однако если одна из сторон не может применить этот протокол, то по согласованию могут быть использованы NTLMv2, NTLM и даже LM.
Принцип работы NTLM имеет много общего с LM и эти протоколы обратно совместимы, но есть и существенные отличия. NT-хэш формируется на основе пароля длиной до 128 символов по алгоритму MD4, пароль регистрозависимый и может содержать не только ACSII символы, но и Unicode, что существенно повышает его стойкость по сравнению с LM.
Как происходит работа по протоколу NTLM? Рассмотрим следующую схему:
Чтобы получить доступ к ресурсу клиент направляет серверу запрос с именем пользователя. В ответ сервер передает ему случайное число, называемое запросом сервера. Клиент в свою очередь шифрует данный запрос по алгоритму DES, используя в качестве ключа NT-хэш пароля, однако, несмотря на то, что NT-хэш 128-битный, в силу технических ограничений используется 40 или 56 битный ключ (хеш делится на три части и каждая часть шифрует запрос сервера отдельно).
Зашифрованный хэшем пароля запрос сервера называется ответом NTLM и передается обратно серверу, сервер извлекает из хранилища SAM хэш пароля того пользователя, чье имя было ему передано и выполняет аналогичные действия с запросом сервера, после чего сравнивает полученный результат с ответом NTLM. Если результаты совпадают, значит пользователь клиента действительно тот, за кого себя выдает, и аутентификация считается успешной.
В случае доменной аутентификации процесс протекает несколько иначе. В отличие от локальных пользователей, хэши паролей которых хранятся в локальных базах SAM, хэши паролей доменных пользователей хранятся на контроллерах доменов. При входе в систему LSA отправляет доступному контроллеру домена запрос с указанием имени пользователя и имени домена и дальнейший процесс происходит как показано выше.
В случае получения доступа к третьим ресурсам схема также немного изменяется:
Получив запрос от клиента, сервер точно также направит ему запрос сервера, но получив NTLM-ответ он не сможет вычислить значение для проверки на своей стороне, так как не располагает хэшем пароля доменного пользователя, поэтому он перенаправляет NTLM-ответ контроллеру домена и отправляет ему свой запрос сервера. Получив эти данные, контроллер домена извлекает хэш указанного пользователя и вычисляет на основе запроса сервера проверочную комбинацию, которую сравнивает с полученным NTLM-ответом, при совпадении серверу посылается сообщение, что аутентификация прошла успешно.
Как видим, хэш пароля ни при каких обстоятельствах по сети не передается. Хэш введенного пароля хранит служба LSA, хэши паролей пользователей хранятся либо в локальных хранилищах SAM, либо в хранилищах контроллера домена.
Но несмотря на это, протокол NTLM на сегодняшний день считаться защищенным не может. Слабое шифрование делает возможным достаточно быстро восстановить хэш пароля, а если использовался не только NTLM, а еще и LM-ответ, то и восстановить пароль.
Но и перехваченного хэша может оказаться вполне достаточно, так как NTLM-ответ генерируется на базе пароля пользователя и подлинность клиента сервером никак не проверяется, то возможно использовать перехваченные данные для неавторизованного доступа к ресурсам сети. Отсутствие взаимной проверки подлинности также позволяет использовать атаки плана человек посередине, когда атакующий представляется клиенту сервером и наоборот, устанавливая при этом два канала и перехватывая передаваемые данные.
NTLMv2
Осознавая, что протокол NTLM не соответствует современным требованиям безопасности, с выходом Windows 2000 Microsoft представила вторую версию протокола NTLMv2, который был серьезно доработан в плане улучшений криптографической стойкости и противодействия распространенным типам атак. Начиная с Windows 7 / Server 2008 R2 использование протоколов NTLM и LM по умолчанию выключено.
Сразу рассмотрим схему с контроллером домена, в случае его отсутствия схема взаимодействия не меняется, только вычисления, производимые контроллером домена, выполняются непосредственно на сервере.
Запрос сервера объединяется с запросом клиента и от этой последовательности вычисляется HMAC-MD5 хэш. После чего от данного хэша берется еще один HMAC-MD5 хэш, ключом в котором выступает NT-хэш пароля пользователя. Получившийся результат называется NTLMv2-ответом и вместе с запросом клиента пересылается серверу.
Криптостойкость данного алгоритма является актуальной и на сегодняшний день, известно только два случая взлома данного хэша, один из них произведен компанией Symantec в исследовательских целях. Можно с уверенностью сказать, что в настоящий момент нет массовых инструментов для атак на NTLMv2, в отличие от NTLM, взломать который может любой вдумчиво прочитавший инструкцию школьник.
Сервер, получив NTLMv2-ответ и запрос клиента, объединяет последний с запросом сервера и также вычисляет HMAC-MD5 хэш, затем передает его вместе с ответом контроллеру домена. Тот извлекает из хранилища сохраненный хэш пароля пользователя и производит вычисления над HMAC-MD5 хешем запросов сервера и клиента, сравнивая получившийся результат с переданным ему NTLMv2-ответом. В случае совпадения серверу возвращается ответ об успешной аутентификации.
При этом, как вы могли заметить, NTLMv2, также, как и его предшественник, не осуществляет взаимную проверку подлинности, хотя в некоторых материалах в сети это указывается.
Настройки безопасности
Теперь, когда вы имеете представление о работе протоколов аутентификации самое время поговорить о настройках безопасности. NTLMv2 вполне безопасный протокол, но если система настроена неправильно, то злоумышленник может послать NTLM или LM запрос и получить соответствующий ответ, который позволит успешно осуществить атаку.
В этом же разделе находится политика Сетевая безопасность: не хранить хэш-значения LAN Manager при следующей смене пароля, которая запрещает создание LM-хэша, по умолчанию активна начиная с Vista / Server 2008.
В нашей же политике мы видим широкий выбор значений, очевидно, что сегодня безопасными могут считаться политики начиная с Отправлять только NTLMv2-ответ и ниже по списку.
Эти же значения можно задать через реестр, что удобно в сетях уровня рабочей группы, для этого в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lsa нужно создать параметр DWORD с именем LmCompatibilityLevel, который может принимать значения от 0 до 5. Рассмотрим их подробнее:
Внимательный читатель, изучая данную таблицу, обязательно обратит внимание на сеансовую безопасность NTLMv2. Данная возможность, как и вообще все взаимодействие по NTLMv2, довольно плохо документированы, поэтому многие понимают смысл этой возможности неправильно. Но на самом деле все довольно несложно.
После того, как клиент пройдет аутентификацию формируется ключ сеанса, который используется для подтверждения подлинности при дальнейшем взаимодействии. Ключ сеанса NTLM основан только на NT-хэше и будет одинаковым до тех пор, пока клиент не поменяет пароль пользователя. Какие угрозы безопасности это несет пояснять, нам кажется, не надо. Сеансовая безопасность NTLMv2 подразумевает вычисление ключа сеанса с использованием не только NT-хэша, но и запросов сервера и клиента, что делает ключ уникальным и гораздо более стойким к возможным атакам. При этом данная возможность может быть использована совместно с NTLM или LM аутентификацией.
Мы надеемся, что данный материал поможет вам глубже понять процессы аутентификации в системах Windows. В следующей части мы подробно остановимся на устройстве и работе протокола Kerberos.
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Как настроить аутентификацию и повысить открываемость писем
Блочный редактор писем, готовые шаблоны email, формы подписки и автоматизация. Запускайте email-рассылки, чтобы быть на связи со своими клиентами.
Где взять базу? Как сделать красивое письмо? Какие показатели смотреть? Расскажем об этом в бесплатном курсе из 16 писем. Татуировка в каждом письме!
Рассказываем про инструменты для email-рассылок. Обсуждаем лучшие примеры и механики. Говорим о деньгах. Публикуем вакансии.
Только корпоративная почта
В 2016 году UniSender перестал рассылать письма с бесплатных доменов: @mail.ru, @yandex.ru, @gmail.com. Отправлять можно только с корпоративных адресов, потому что 99% массовых рассылок с бесплатных доменов — спам.
Рассказываем, как завести корпоративный домен и настроить email-аутентификацию.
Что такое аутентификация
Email-аутентификация — процедура проверки подлинности отправителя.
Интернет-провайдеры и почтовые службы анализируют письма, чтобы удостовериться, что письмо пришло от проверенного и добросовестного отправителя, а не от мошенника или спамера.
Настройка аутентификации дает два преимущества:
Аутентификация в 3 шага
Чтобы настроить аутентификацию, нужно зайти на сайт провайдера, который управляет DNS-зоной домена, откуда вы рассылаете почту. В настройках DNS нужно внести несколько TXT-записей:
Запись DKIM
DKIM добавляет в письмо цифровую подпись. Она проверяется на стороне получателя. С её помощью отправителю присваивается та или иная репутация.
Технология DKIM включает в себя несколько методов борьбы со спамом и кражей персональных данных: логинов, паролей, кодов доступа.
Политика DMARC
Мошенники подделывают адреса отправителей так, что спам якобы исходит от пользователя определенного домена, например, вашего.
Политика DMARC содержит указания, что должен сделать узел, принявший сообщение, которое не соответствует требованиям безопасности. Это ограждает от спама как получателей, так и отправителей.
Запись SPF
Указывает, каким почтовым серверам разрешено отправлять электронную почту от имени вашего домена. Например, если вы используете для рассылки почтовый сервер UniSender, это нужно указать в SPF.
Как завести домен и настроить аутентификацию
1. Покупаю домен
Купить домен просто. Нужно выбрать доменное имя, проверить, не занято ли оно, и оплатить. Перечислю несколько популярных регистраторов доменов:
Совет
Не заводите кириллические адреса (в зоне рф). Рассылки с ними делать пока невозможно.
Я выбираю имя asaraev и проверяю наличие свободных зон для него:
После покупки ставлю в настройках галочку «Использовать сервера регистратора».
2. Привязываю домен к хостингу
Привяжу домен («имя» сайта) к хостингу («месту» размещения). Для этого надо настроить DNS. Если нет хостинга — то вот инструкция, как его выбрать. Вот несколько хостеров навскидку:
После покупки хостинга нужно узнать в службе поддержки хостера данные для настройки DNS и ввести их в Панели управления доменом.
Я делаю сайт на Tilda Publishing (платформа для создания красивых сайтов своими руками), поэтому хостинг для сайта мне не нужен. Запрашиваю данные у Тильды и вношу их в настройки.
3. Завожу почту на домене
Подключил. Захожу в аккаунт на Mail.ru и создаю ящик, с которого буду рассылать почту.
4. Настраиваю аутентификацию
Захожу в панель управления на сайте регистратора домена и нахожу ресурсные записи DNS. В моем случае (Reg.ru) путь выглядит так:
Личный кабинет — Мои домены — Управление зоной — Ресурсные записи домена (RRs).
Оказываюсь в том же месте, где привязывал хостинг и домен.
Помимо указания SPF и DKIM Mail.ru требует настройки MX-записи. Она указывает на сервер, который обрабатывает вашу почту. Сперва внесу ее.
В списке операций в Панели управления доменом выбираю, какой тип записи добавить:
