Настроить kerberos active directory

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Настраиваем Squid для работы с Active Directory. Часть 2 — Kerberos-аутентификация

Настраиваем Squid для работы с Active Directory. Часть 2 — Kerberos-аутентификация

Продолжаем цикл статей об интеграции прокси-сервера Squid и Active Directory. Одним из наиболее важных вопросов является прозрачная аутентификация пользователей домена на прокси-сервере. В этой части мы расскажем, как настроить аутентификацию по протоколу Kerberos, которая позволит использовать единую точку входа, когда пользователь вводит логин и пароль один раз — при входе в систему.

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

Подготовка Active Directory

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

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

Теперь создадим специальный keytab-файл, который содержит имя Kerberos-принципала (имя хоста, пользователя и домен) и ключ, созданный на основе пароля. В дальнейшем keytab-файл будет использоваться squid для аутентификации пользователей в AD. Откроем командную строку и введем следующую команду (соблюдая регистр):

На первый взгляд команда довольно сложная. Разберем ее подробнее, ключ -princ обозначает Kerberos-принципала и содержит FQDN имя роутера и область Kerberos, которая совпадает с именем домена, но записывается в верхнем регистре, -mapuser и -pass имя пользователя и пароль соответственно, -ptype — тип принципала и -out — имя и расположение keytab-файла.

Важно! Для нормальной работы Kerberos на роутере его имя хоста, в нашем случае srv-gw01, не должно превышать 8 символов.

Если все сделано правильно, то команда должна отработать без ошибок.

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

Настройка поддержки Kerberos в Ubuntu Server / Debian

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

Затем изменим владельца и установим ограниченные права на файл:

Для поддержки Kerberos установим пакет krb5-user:

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

Теперь откроем файл /etc/krb5.conf, он содержит очень много ненужных параметров, поэтому удаляем или комментируем все лишнее, у вас должно остаться только то, что будет приведено ниже.

Первой идет секция libdefaults, которая содержит параметры по умолчанию, а именно область Kerberos (опция создается автоматически) и keytab-файл:

Следующая секция realms описывает области Kerberos, у нас она одна — INTERFACE31.LAB

Здесь все понятно, единственного пояснения требует опция admin_server, в ее качестве указываем контроллер домена, исполняющий FSMO-роль PDC.

Последняя секция сопоставляет домены с областями Kerberos:

Сохраняем файл. Теперь проверим работу Kerberos, для этого выполним команду:

Если все сделано правильно, вы должны получить сообщение об успешной аутентификации.

Удалим полученный билет командой:

Настройка Kerberos-аутентификации в Squid

Прежде всего следует «научить» squid работать с keytab-файлом, для этого создадим специальный файл настроек:

И внесем в него следующие строки:

Откроем конфигурационный файл /etc/squid3/squid.conf, найдем три строки, начинающиеся с auth_param negotiate, раскомментируем и приведем их к следующему виду:

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

В секцию с элементами ACL добавим:

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

сохраняем изменения, перезагружаем сервер.

На любом ПК войдем в систему под доменным пользователем и откроем любую страницу в браузере (не забываем, что прокси указываем не по IP-адресу, а по FQDN-имени), все должно работать.

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

Также заглянем в /var/log/squid3/cache.log, сюда squid пишет отладочную информацию, в самом конце строки можно увидеть, кто именно прошел аутентификацию и получил доступ.

Убедившись, что все работает как надо, выключаем сбор отладочной информации, убрав ключ -d из строки в /etc/squid3/squid.conf.

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

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник

Настроить kerberos active directory

Добрый день уважаемые читатели, не так давно у меня на работе была задача по настройке групп доступности SQL на Windows кластере, там клиентам сделали красивый веб-инструментарий, все замечательно, теперь клиент ждет следующего развития ситуации, а именно настройка и внедрение механизма Single Sign-On (SSO) или по русски единая точка аутентификация, мы с вами уже с ней знакомились при настройке Vmware vCenter Server. Данный механизм работает на протоколе шифрования kerberos, о котором мы и поговорим. Мы рассмотрим как происходит проверка подлинности kerberos в Active Directory, так как понимание принципов работы, поможет вам в реализации единой точки аутентификации.

Идентификация и доступ в Active Directory

Доменные службы Active Directory (Active Directory Domain Services, AD DS ) обеспечивают идентификацию и доступ (Identity and Access, IDA ) для корпоративных сетей. Давайте посмотрим каким требованиям и критериям должна соответствовать структура IDA:

• Она должна хранить информацию, о всех объектах Active Directory, среди которых: пользователи, группы безопасности, компьютеры, принтеры и другие объекты идентификации. Под объектом идентификации (identity) подразумевается, некое представление сущности, в задачи которой входит выполнение каких-либо действий в корпоративной сети. Простой пример, есть пользователь Вася и он работает с документами в общей папке на сервере. Эти документы имеют защиту на доступ, который определяет список контроля доступа (Access Contro l List, ACL). Доступом у нужным файлам, управляет подсистема безопасности сервера, где лежит папка, и при обращении к ней он производит сравнение объекта идентификации пользователя с теми объектами, которые присутствуют в его списке ACL, и уже на основании этого, он принимает решение предоставить или запретить пользователю доступ. Так как службы, компьютеры, группы и другие объекты выполняют определенные вещи в локальной сети, то у каждого из них есть свой объект идентификации. Данный объект содержит много информации, уникальной для каждого из них, например, имя пользователя, его идентификатор безопасности (Security Identifier, SID), пароль. Так, что хранилище объектов идентификации, является неотъемлемой частью Identity and Access. Все данные в Active Directory, располагаются в каталоге AD, которым управляет контроллер домена.
• Проверка подлинности объекта идентификации. Тут общий принцип такой, когда пользователь обращается к документу, то сервер его ему не покажет, пока тот, не подтвердит подлинность объекта идентификации, который фигурирует в запросе. Чтобы все это сделать, у пользователя есть некая секретная информация, которая известна ему и инфраструктуре IDA, вот эти данные как раз и сравниваются с теми, что есть в хранилище объектов идентификации в момент проверки подлинности.

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

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

Именно за счет провайдеров Security Support Provider (SSP) сделан механизм аутентификации. Операционная система Windows уже имеет встроенные модули, но никто не мешает программистам, взять и написать свой и подключить его к SSPI

Протокол аутентификации kerberos пришел на смену устаревшему и уже с точки зрения не безопасному, протоколу NTLM, он был основным до Windows 2000. Протокол Kerberos всегда используется в построении механизмов Single Sign-On. В его основе лежит такой принцип, что если двум участникам известен некий ключ и у них есть возможность подтвердить это, то они смогут однозначно идентифицировать друг друга.

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

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

Ключ службы (service key) — тут все просто, очень часто системные администраторы для запуска службы создают отдельного доменного пользователя, в следствии чего служба получит его ключ, но если она запускается под учетной записью системы (LocalSystem), то получит ключ компьютера.

Междоменный ключ (inter-realm key). Этот ключ обеспечивает междоменную аутентификацию и используется для обеспечения доверительных отношений в среде Aсtive Directory.

• Давайте рассматривать каким образом происходит проверка подлинности Kerberos в домене Active Directory. И так пользователь или же компьютер, пытаются войти в локальную сеть домена, именно протокол Kerberos удостоверяется в подлинности указанных реквизитов, в следствии чего выдает пакет данных, а точнее билет или тикет (Ticket), по правильному он называется TGT (Ticket Granting Ticket).

Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей). TGT шифруется при помощи ключа, общего для служб KDC, то есть клиент не может прочитать информацию из своего билета. Этот билет используется клиентом для получения других билетов.

• Теперь когда у пользователя или компьютера есть билет TGT, он может его предоставлять любому сервису или ресурсу. В дальнейшем, при обращении к отдельным ресурсам сети, пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Service Ticket (TGS). Данный билет будет идентифицировать прошедшего проверку подлинности пользователя на сервере. Пользователь предоставит TGS билет для доступа к серверу, он его примет и подтвердит прохождение проверки подлинности. Вот тут Kerberos и показывает все свои достоинства, ему требуется лишь один сетевой вход и после получения им билета TGT он проходит проверку подлинности для всего домена целиком, что дает ему возможность получать идентификационные билеты на доступ к службам, не вводя ни каких учетных данных, все эти операции осуществляются за счет встроенных клиентов и служб Kerberos в Kerberos.

Сам Ticket-Granting Service состоит из двух вещей, первая это копия сессионного ключа и информация о клиенте. Все эти данные зашифрованы ключом, общим между сервисом к которому идет обращение и KDC. Это означает, что пользователь не сможет посмотреть эти данные, а вот служба или сервер к которому идет обращение да.

Еще очень важным моментом, является тот фактор, что служба KDC, должна точно знать к какому именно сервису идет обращение и каким ключом шифрования производить обработку. Для этого есть такой механизм, как Service Principal Names, по сути это уникальный идентификатор службы, который будет прописан в вашей базе Active Directory. Из требований к нему, он должен быть уникален в рамках леса. Каждая служба, которая будет использовать Kerberos, должна иметь зарегистрированный SPN. Без правильно настроенного идентификатора протокол для этой службы или сервера работать не будет.

Сам SPN будет хранится в атрибуте Service-Principal-Name, у той учетной записи к которой он привязан и под которым стартует служба. Таким образом, SPN связывает воедино все части процесса. Клиент знает, к какой службе он хочет получить доступ. И при запросе ключа он строит строку SPN, к примеру, при помощи функции DsMakeSpn. Сервер KDC, получив эти данные, может найти учетную запись, под которой стартует эта служба, и, используя ключ этой учетной записи из Active Directory, создать билет доступа к службе и зашифровать его этим ключом.

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

Детальная проверка kerberos от начала логирования

Давайте еще в картинках я расскажу более детально как происходит проверка подлинности kerberos, от момента ввода пароля пользователем. И так:

• Человек видит поля ввода логина и пароля у себя на компьютере
• Компьютер получив от пользователя первичные данные делает запрос к контроллеру домена, а точнее к службе Key Distribution Center, где передает KDC имя пользователя в открытом виде, имя домена и текущее время на рабочей станции, еще раз напоминаю, что оно не должно отличаться от времени на контроллере домена более ,чем на 5 минут. Значение текущего времени передается в зашифрованном виде, и будет выступать аутентификатором. Напоминаю, что ключ шифрования (пользовательский ключ) формируется из пароля пользователя, как результат хеширования.

• Служба KDC видит обращение с компьютера и начинает поиск пользователя в Active Directory, проверяет его пользовательский ключ и расшифровывает аутентификатор, если по русски она получает время отправления запроса. После чего Key Distribution Center создает два тикета. Первый это сессионный ключ, он нужен для шифрования данных между клиентом и KDC. Второй тикет, это билет на получение билета (Ticket-Granting Ticket (TGT)), как только он появился у пользователя, тот сможет запрашивать тикеты для сервисов и серверов. Сам TGT билет состоит из таких частей: копия ключа сессии, время окончания жизни билета и имя пользователя. TGT шифруется с использованием мастер ключа самой службы Key Distribution Center, поэтому пользователь не может его расшифровать.
• Как только эти билеты сформированы Key Distribution Center шифрует аутентификатор пользователя (time stamp) и сессионный ключ, с помощью пользовательского ключа и спокойно передает их пользователю.

• Так как у пользователя есть его, пользовательский ключ, он спокойно расшифровывает билеты от Key Distribution Center и проверяет аутентификатор. В итоге он теперь обладает и ключем сессии и TGT ключом, теперь первый этап Kerberos закончен и пользователю больше не нужно в этой сессии заказывать эти билеты.
• Далее клиент хочет получить доступ на сервис, так как у него уже есть ключ на получение других ключей (TGT), для доступа к сервису он предоставляет KDC, свой Ticket-Granting Ticket и штамп времени, которые шифрует сессионным ключом.
• KDC получает этот запрос и билеты, расшифровывает их используя свой ключ. Контроллер домена подтверждает, что запрос поступил именно от нужного пользователя.

• Следующим шагом Key Distribution Center, генерирует два тикета (Service Ticket (TGS)), один для обратившегося клиента, а второй для сервиса, к которому клиент обращается. Каждый из тикетов, будет содержать имя пользователя, кто просит доступ, кто должен получить запрос, штамп времени, рассказывающий, когда создан тикет, и срок его жизни, а так же новый ключ Kcs. Kcs — это ключ для сервиса и клиента, в задачи которого входит обеспечение безопасного взаимодействия между ними. Далее KDC шифрует билет сервиса, используя для этого системный ключ сервера и вкладывает этот билет внутрь билета клиента, у которого так же есть свой Kcs ключ.
• Теперь все это дело шифруется сессионным ключом и передается клиенту.

• Клиент получает билет, расшифровывает его с помощью сессионного ключа и видит свой TGS тикет, и Kcs сервиса, клиент не может прочитать Kcs предназначенный для сервиса

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

• Когда сервер с сервисом, получает эту информацию, он сразу видит пакет от KDC предназначенный для него с ключом TGS (Kcs). Он расшифровывает им штамп времени от клиента.
• Так как у обоих участников есть TGS ключ, они могут быть обо уверены, что клиент правильно идентифицирован, т. к. для шифрования маркера времени был использован Kcs . В случае необходимости ответа сервера клиенту, сервер воспользуется ключом Kcs . Клиент будет знать, что сервер правильно идентифицирован, поскольку сервер должен использовать, чтобы получить Kcs.

Источник