Kerberos, что такое Linux

Обновлено: 25.06.2024

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

Если вы вводите свое имя пользователя, а kinit отвечает этим сообщением:

kinit(v5): клиент не найден в базе данных Kerberos при получении исходных учетных данных

Вы не зарегистрированы как пользователь Kerberos. Обратитесь к системному администратору.

Имя Kerberos обычно состоит из трех частей. Первым является основной, который обычно представляет собой имя пользователя или службы. Второй — это экземпляр, который в случае пользователя обычно равен нулю. Однако некоторые пользователи могут иметь привилегированные экземпляры, такие как «root» или «admin». В случае службы экземпляр — это полное имя машины, на которой он работает; т. е. может быть служба rlogin, работающая на машине ABC, которая отличается от службы rlogin, работающей на машине XYZ. Третья часть имени Kerberos — это область. Область соответствует службе Kerberos, обеспечивающей аутентификацию принципала.

При написании имени Kerberos основное имя отделяется от экземпляра (если оно не нулевое) косой чертой, а область (если не локальная область) следует после знака ''@''. Ниже приведены примеры действительных имен Kerberos: Когда вы аутентифицируетесь с помощью Kerberos, вы получаете первоначальный билет Kerberos. (Билет Kerberos — это зашифрованное протокольное сообщение, обеспечивающее аутентификацию.) Kerberos использует этот билет для сетевых утилит, таких как rlogin и rcp. Транзакции билетов выполняются прозрачно, поэтому вам не нужно беспокоиться об их управлении.

Обратите внимание, однако, что срок действия билетов истекает. Срок действия привилегированных билетов, таких как экземпляр «root», истекает через несколько минут, в то время как билеты с более обычными привилегиями могут быть действительны в течение нескольких часов или суток, в зависимости от политики установки. Если ваш сеанс входа в систему превышает лимит времени, вам придется повторно аутентифицировать себя в Kerberos, чтобы получить новые билеты. Используйте команду kinit для повторной аутентификации.

Если вы используете команду kinit для получения билетов, убедитесь, что вы используете команду kdestroy для уничтожения билетов до завершения сеанса входа в систему. Вы должны поместить команду kdestroy в свой файл .logout, чтобы ваши билеты автоматически уничтожались при выходе из системы. Дополнительные сведения о командах kinit и kdestroy см. на страницах руководства kinit(1) и kdestroy(1).

Билеты Kerberos можно пересылать. Чтобы переадресовать билеты, вы должны запросить пересылаемые билеты при kinit. Если у вас есть пересылаемые билеты, большинство программ Kerberos имеют параметр командной строки для пересылки их на удаленный хост.

Переменные среды

Несколько переменных среды влияют на работу программ с поддержкой Kerberos. К ним относятся: KRB5CCNAME Указывает расположение кэша учетных данных в форме TYPE:residual. Если префикс типа отсутствует, предполагается тип FILE, а residual является путем к файлу кэша. Можно использовать набор из нескольких кэшей, указав тип DIR и путь к частному каталогу (который уже должен существовать). Файл кеша по умолчанию — /tmp/krb5cc_uid, где uid — десятичный идентификатор пользователя. KRB5_KTNAME Указывает расположение файла keytab в форме TYPE:residual. Если тип не указан, предполагается тип FILE, а residual — это путь к файлу keytab. Файл keytab по умолчанию — /etc/krb5.keytab. KRB5_CONFIG Указывает расположение файла конфигурации Kerberos. По умолчанию это /etc/krb5.conf. KRB5_KDC_PROFILE Указывает расположение файла конфигурации KDC, который содержит дополнительные директивы конфигурации для демона центра распространения ключей и связанных программ. По умолчанию это /var/kerberos/krb5kdc/kdc.conf. KRB5RCACHETYPE Указывает тип кэша воспроизведения по умолчанию для серверов. Допустимые типы включают «dfl» для нормального типа файла и «none» для отсутствия кэша воспроизведения. KRB5RCACHEDIR Задает каталог по умолчанию для кэшей воспроизведения, используемых серверами. По умолчанию используется значение переменной среды TMPDIR или /var/tmp, если TMPDIR не задано. KRB5_TRACE Задает имя файла для записи выходных данных журнала трассировки. Журналы трассировки могут помочь пролить свет на решения, принятые внутри библиотек Kerberos. По умолчанию выходные данные журнала трассировки нигде не записываются. Большинство переменных среды отключены для определенных программ, таких как системные программы входа в систему и программы setuid, которые предназначены для обеспечения безопасности при запуске в среде ненадежных процессов.

См. также

Авторы

Стив Миллер, MIT Project Athena/Digital Equipment Corporation
Клиффорд Нойман, MIT Project Athena
Грег Хадсон, MIT Kerberos Consortium

История

Реализация MIT Kerberos 5 была разработана в Массачусетском технологическом институте при участии многих сторонних сторон. В настоящее время он поддерживается консорциумом MIT Kerberos.

Ограничения

Авторские права Массачусетского технологического института, 1985,1986,1989–1996,2002,2011 года

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

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

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

11.1. О Kerberos

Kerberos использует криптографию с симметричным ключом [3] для аутентификации пользователей в сетевых службах, что означает, что пароли фактически никогда не передаются по сети.

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

11.1.1. Основы работы Kerberos

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

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

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

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

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

Как показано на рис. 11.1, «Аутентификация Kerberos», каждый пользователь идентифицируется в KDC с помощью уникального идентификатора, называемого принципалом . Когда пользователь в сети с поддержкой Kerberos входит на свою рабочую станцию, его принципал отправляется в KDC как часть запроса на билет на выдачу билетов (или TGT) от сервера аутентификации. Этот запрос может быть отправлен программой входа в систему, чтобы он был прозрачным для пользователя, или может быть отправлен пользователем вручную через программу kinit после входа пользователя в систему.

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

Рисунок 11.1. Аутентификация Kerberos

Программа входа или kinit на клиенте затем расшифровывает TGT с помощью ключа пользователя, который вычисляется на основе пароля пользователя. Ключ пользователя используется только на клиентском компьютере и не передается по сети. Билет (или учетные данные), отправленный KDC, хранится в локальном хранилище, кэше учетных данных (ccache) , который может быть проверен службами, поддерживающими Kerberos. Red Hat Enterprise Linux 7 поддерживает следующие типы кэшей учетных данных:

Демон System Security Services (SSSD) Kerberos Credential Manager (KCM), альтернативный вариант, начиная с Red Hat Enterprise Linux 7.4

При использовании SSSD KCM кэши Kerberos не хранятся в пассивном хранилище, а управляются демоном. В этой настройке библиотека Kerberos, которая обычно используется такими приложениями, как kinit , является клиентом KCM, а демон называется сервером KCM.

Демон сохраняет состояние и может выполнять такие задачи, как обновление кэша учетных данных Kerberos или сбор старых кэшей. Продление и отслеживание возможны не только для билетов, приобретенных самим SSSD, как правило, через вход через pam_sss.so , но и для билетов, приобретенных, например, через kinit .

В отличие от кэша ядра на основе KEYRING, который полностью зависит от UID вызывающей стороны и который в контейнеризованной среде используется всеми контейнерами, точка входа сервера KCM представляет собой сокет UNIX, который можно монтировать с помощью привязки. только в выбранные контейнеры.

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

Срок действия TGT истекает через определенный период времени (обычно от 10 до 24 часов) и хранится в кэше учетных данных клиентского компьютера. Время истечения устанавливается таким образом, чтобы скомпрометированный TGT был полезен злоумышленнику только в течение короткого периода времени. После выдачи TGT пользователю не нужно вводить пароль снова, пока не истечет срок действия TGT или пока он не выйдет из системы и не войдет снова.

Всякий раз, когда пользователю требуется доступ к сетевой службе, клиентское программное обеспечение использует TGT для запроса нового билета для этой конкретной службы с сервера выдачи билетов (TGS). Билет службы затем используется для прозрачной аутентификации пользователя в этой службе.

11.1.2. Об основных именах Kerberos

Субъект идентифицирует не только пользователя или службу, но и область, к которой принадлежит объект. Основное имя состоит из двух частей: идентификатора и области:

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

Когда Kerberos запрашивает билет, он всегда разрешает псевдонимы доменных имен (записи DNS CNAME) в соответствующий адрес DNS (записи A или AAAA). Затем имя хоста из записи адреса используется при создании участников службы или хоста.

11.1.3. О сопоставлении домена и области

По умолчанию в качестве имени области используется DNS-имя домена сервера, написанное заглавными буквами.

В некоторых конфигурациях этого будет достаточно, но в других производное имя области будет именем несуществующей области. В этих случаях сопоставление имени домена DNS сервера с именем его области должно быть указано в разделе domain_realm файла /etc/krb5.conf клиентской системы. Например:

В конфигурации указаны два сопоставления. Первое сопоставление указывает, что любая система в домене DNS example.com принадлежит области EXAMPLE.COM. Второй указывает, что система с точным именем example.com также находится в области. Различие между доменом и конкретным хостом отмечается наличием или отсутствием начального символа точки. Сопоставление также можно хранить непосредственно в DNS с помощью записей «_kerberos TXT», например:

11.1.4. Экологические требования

Kerberos полагается на способность разрешать имена компьютеров. Таким образом, требуется работающая служба доменных имен (DNS). И записи DNS, и хосты в сети должны быть правильно настроены, что описано в документации по Kerberos в /usr/share/doc/krb5-server- номер_версии.

Приложения, которые принимают аутентификацию Kerberos, требуют синхронизации времени. Вы можете настроить приблизительную синхронизацию часов между машинами в сети, используя такой сервис, как ntpd. Для получения информации о службе ntpd см. документацию в /usr/share/doc/ntp- номер_версии /html/index.html или справочную страницу ntpd (8).

Примечание

Клиенты Kerberos под управлением Red Hat Enterprise Linux 7 поддерживают автоматическую корректировку времени с помощью KDC и не предъявляют строгих требований к времени. Это позволяет лучше справляться с разницей в синхронизации при развертывании клиентов IdM с Red Hat Enterprise Linux 7.

11.1.5. Рекомендации по развертыванию Kerberos

Хотя Kerberos устраняет распространенную и серьезную угрозу безопасности, его трудно внедрить по ряду причин:

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

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

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

Перенос паролей пользователей из стандартной базы данных паролей UNIX, такой как /etc/passwd или /etc/shadow , в базу данных паролей Kerberos может быть утомительным. Не существует автоматизированного механизма для выполнения этой задачи. Методы миграции могут существенно различаться в зависимости от конкретного способа развертывания Kerberos. Вот почему рекомендуется использовать функцию управления идентификацией; у него есть специальные инструменты и методы для миграции.

Предупреждение

Система Kerberos может быть скомпрометирована, если пользователь в сети проходит аутентификацию в службе, не поддерживающей Kerberos, путем передачи пароля в виде обычного текста. Использование служб, не поддерживающих Kerberos (включая telnet и FTP), крайне не рекомендуется. Другие зашифрованные протоколы, такие как SSH или SSL-защищенные службы, предпочтительнее незашифрованных служб, но это все же не идеально.

11.1.6. Дополнительные ресурсы для Kerberos

Kerberos может быть сложной службой для реализации, с большой гибкостью в том, как она развертывается. Табл. 11.1, «Внешняя документация по Kerberos» и Табл. 11.2, «Важные справочные страницы Kerberos» содержат список нескольких наиболее важных или наиболее полезных источников дополнительной информации об использовании Kerberos.

Таблица 11.1. Внешняя документация по Kerberos

Таблица 11.2. Важные справочные страницы Kerberos

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

Руководства, учебные пособия, обзоры и новости для системных администраторов.

Как настроить Linux для аутентификации с использованием Kerberos

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

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

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

Подготовка к сертификации RHCE? Посмотрите наш видеокурс RHCE на сайте Udemy со скидкой 20 % при использовании кода ROOTUSER.

Пример среды

Вот список наших серверов, которые мы будем тестировать, оба работают под управлением CentOS 7.

Сервер Kerberos (KDC): 192.168.1.13. Этот сервер Linux будет действовать как наш KDC и выдавать билеты Kerberos.
Клиент Kerberos: 192.168.1.14 — этот клиент Linux будет запрашивать билеты Kerberos из KDC.

Предпосылки

Для правильной работы Kerberos необходимо сначала настроить на обоих серверах следующее.

NTP: требуется синхронизация времени, если разница во времени превышает 5 минут, аутентификация не будет выполнена. Дополнительные сведения о настройке см. в нашем руководстве по синхронизации времени с NTP.
DNS: в идеале полные доменные имена должны разрешаться в надлежащей среде, однако здесь мы обходимся только использованием IP-адресов. Изменение /etc/hosts также подойдет для тестирования, однако рекомендуется правильно использовать DNS.

Настройка KDC

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

Следующие команды выполняются на нашем сервере KDC.

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

Создание базы данных Kerberos

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

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

Управление услугами

Говоря об автоматическом запуске, мы хотим включить и запустить как kadmin, так и krb5kdc, чтобы наши службы Kerberos KDC были автоматически доступны после перезагрузки системы.

Дополнительную информацию об управлении базовыми службами с помощью systemctl см. в нашем руководстве здесь.

Конфигурация брандмауэра

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

Предопределенная служба Kerberos пропускает трафик TCP/UDP через порт 88. Мы можем проверить и подтвердить, что служба krb5kdc действительно прослушивает эти порты для установления подключений.

Мы разрешили только Kerberos, обратите внимание, что трафик к kadmin требует TCP 749, поэтому, если вы хотите получить к нему удаленный доступ, вам также нужно рассмотреть возможность его открытия, однако для наших целей и для повышения безопасности мы оставим это как только локальный доступ.

Администрирование Kerberos

KDC можно администрировать с помощью команды kadmin.local. Чтобы просмотреть доступные команды в контексте kadmin.local, просто запустите «?». Из этой полезной информации видно, что addprinc можно использовать для добавления принципала Kerberos, что мы и сделаем для нашей учетной записи пользователя.

Теперь наш KDC готов принимать клиентские подключения и предоставлять билеты субъекту-«пользователю».

Настройка клиента

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

После завершения просто запустите «authconfig-gtk» из окна терминала в графическом интерфейсе. Это откроет окно конфигурации аутентификации. На вкладке «Идентификация и аутентификация» выберите LDAP в раскрывающемся списке «Конфигурация учетной записи пользователя», чтобы получить доступ к конфигурации аутентификации, где мы выберем пароль Kerberos и предоставим информацию о нашей области и KDC.

После того как вы определили свою область и KDC, нажмите кнопку "Применить".

Если вы не являетесь поклонником графического интерфейса или просто не установили его, вы также можете использовать вместо этого текстовый пользовательский интерфейс, запустив «authconfig-tui». Оба они автоматически настроят наш файл /etc/sssd/sssd.conf, однако вы можете отредактировать его вручную, если знаете, что делаете. Лично у меня всегда были ужасные попытки установить sssd.conf вручную, поэтому я определенно рекомендую использовать любой из этих инструментов authconfig.

Создайте пользователя

В нашем KDC мы создали участника для «пользователя», теперь мы создадим локальную учетную запись пользователя в клиентской системе. Технически это не требуется, мы должны иметь возможность выполнять kinit от другого пользователя, однако для согласованности мы будем использовать эту учетную запись.

Теперь мы готовы попытаться получить билет от KDC. Сначала мы становимся новым пользователем и запускаем команду kinit, которая используется для получения и кэширования нашего билета Kerberos.

Из «klist» мы видим, что нам выдан билет, действительный в течение 24 часов.

Обзор

Мы успешно настроили центр распространения ключей (KDC), который может предоставлять клиентам билеты Kerberos.

Этот пост является частью нашей серии руководств по подготовке к экзамену Red Hat Certified Engineer (RHCE). Для получения дополнительных сообщений и информации, связанных с RHCE, ознакомьтесь с нашим полным учебным пособием по RHCE.

3.1. О Kerberos

Kerberos — это протокол сетевой аутентификации, созданный Массачусетским технологическим институтом и использующий криптографию с симметричным ключом [1] для аутентификации пользователей в сетевых службах, что означает, что пароли фактически никогда не передаются по сети.

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

Как показано на рис. 3.1, «Аутентификация Kerberos, пошаговая инструкция», каждый пользователь идентифицируется в KDC с помощью уникального идентификатора, называемого принципалом . Когда пользователь в сети с поддержкой Kerberos входит на свою рабочую станцию, его принципал отправляется в KDC как часть запроса на билет для получения билета (или TGT) от сервера аутентификации. Этот запрос может быть отправлен программой входа в систему, чтобы он был прозрачным для пользователя, или может быть отправлен пользователем вручную через программу kinit после входа пользователя в систему.

Рисунок 3.1. Аутентификация Kerberos, по шагам

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

Срок действия TGT истекает через определенный период времени (обычно от десяти до двадцати четырех часов) и хранится в кэше учетных данных клиентского компьютера. Время истечения устанавливается таким образом, чтобы скомпрометированный TGT был полезен злоумышленнику только в течение короткого периода времени. После выдачи TGT пользователю не нужно повторно вводить свой пароль, пока не истечет срок действия TGT или пока он не выйдет из системы и не войдет снова.

Предупреждение

Kerberos использует возможность разрешения имен машин и точных временных меток для выдачи и истечения срока действия билетов. Таким образом, для правильной работы Kerberos требуется как адекватная синхронизация часов, так и работающая служба доменных имен (DNS).

Приблизительную синхронизацию часов между машинами в сети можно настроить с помощью такой службы, как ntpd , которая задокументирована в /usr/share/doc/ntp- номер_версии /html/index. .html .

Записи DNS и хосты в сети должны быть правильно настроены, что описано в документации по Kerberos в /usr/share/doc/krb5-server-номер_версии.

3.1.2. Рекомендации по развертыванию Kerberos

Хотя Kerberos устраняет распространенную и серьезную угрозу безопасности, его трудно внедрить по ряду причин:

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

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

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

3.1.3. Дополнительные ресурсы для Kerberos

Kerberos может быть сложной службой для реализации, с большой гибкостью в том, как она развертывается. Табл. 3.1, «Внешняя документация по Kerberos» и Табл. 3.2, «Важные справочные страницы по Kerberos» содержат список нескольких наиболее важных или наиболее полезных источников дополнительной информации об использовании Kerberos.

Таблица 3.1. Внешняя документация по Kerberos

Таблица 3.2. Важные справочные страницы Kerberos

Справочная страница	Описание
Клиентские приложения
kerberos	Введение в систему Kerberos, в котором описывается, как работают учетные данные, и приводятся рекомендации по получению и уничтожению билетов Kerberos. В нижней части справочной страницы есть ссылки на ряд связанных справочных страниц.
kinit	Описывает, как использовать эта команда для получения и кэширования билета на выдачу билетов.
kdestroy	Описывает, как использовать эту команду для уничтожения учетных данных Kerberos.
klist	Описывает, как использовать эту команду для получения списка кэшированных учетных данных Kerberos.< /td>
Административные приложения
kadmin	Описывает, как использовать эту команду для администрирования базы данных Kerberos V5.
kdb5_util	Описывает, как использовать эту команду для создания и выполнения l административные функции в базе данных Kerberos V5.
Серверные приложения
krb5kdc	Описывает доступные параметры командной строки для Kerberos V5 KDC.
kadmind< /td>	Описывает доступные параметры командной строки для сервера администрирования Kerberos V5.
Файлы конфигурации
krb5.conf	Описывает формат и параметры, доступные в файле конфигурации для библиотеки Kerberos V5.
kdc.conf	Описывает формат и параметры, доступные в файле конфигурации для AS Kerberos V5 и КДК.

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

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

В этом разделе описывается установка и настройка сервера Kerberos, а также некоторые примеры конфигураций клиентов.

Обзор

Если вы новичок в Kerberos, есть несколько терминов, которые полезно понять перед настройкой сервера Kerberos. Большинство терминов будут относиться к вещам, с которыми вы можете быть знакомы в других средах:

Субъект: любые пользователи, компьютеры и службы, предоставляемые серверами, должны быть определены как участники Kerberos.

Экземпляры используются для субъектов-служб и специальных административных субъектов.

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

Билет на предоставление билетов: выдаваемый сервером аутентификации (AS), билет на предоставление билетов (TGT) шифруется в пароле пользователя, который известен только пользователю и KDC.

Сервер предоставления билетов: (TGS) выдает служебные билеты клиентам по запросу.

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

Файлы Keytab: — это файлы, извлеченные из основной базы данных KDC и содержащие ключ шифрования для службы или хоста.

Чтобы сложить все воедино, Realm имеет по крайней мере один KDC, желательно больше для избыточности, который содержит базу данных Принципалов. Когда участник-пользователь входит на рабочую станцию, настроенную для проверки подлинности Kerberos, KDC выдает билет на предоставление билетов (TGT). Если предоставленные пользователем учетные данные совпадают, пользователь проходит проверку подлинности и может затем запрашивать билеты для служб Kerberized с сервера предоставления билетов (TGS). Билеты службы позволяют пользователю аутентифицироваться в службе без ввода другого имени пользователя и пароля.

Сервер Kerberos

Установка

Для этого обсуждения мы создадим домен MIT Kerberos со следующими функциями (измените их в соответствии с вашими потребностями):

Основной пользователь: ubuntu

Принцип администратора: ubuntu/admin

Примечание

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

Кроме того, протокол Kerberos чувствителен ко времени. Таким образом, если локальное системное время между клиентской машиной и сервером отличается более чем на пять минут (по умолчанию), рабочая станция не сможет пройти аутентификацию. Чтобы решить эту проблему, время на всех хостах должно быть синхронизировано с использованием одного и того же сервера Network Time Protocol (NTP). Дополнительные сведения см. в главе NTP.

Первым шагом в создании области Kerberos является установка пакетов krb5-kdc и krb5-admin-server. В терминале введите:

В конце установки вам будет предложено указать имя хоста для серверов Kerberos и Admin, которые могут быть или не быть одним и тем же сервером для области. Поскольку мы собираемся создать область и, следовательно, эти серверы, введите полное имя хоста этого сервера.

Примечание

По умолчанию область создается из доменного имени KDC.

Затем создайте новую область с помощью утилиты kdb5_newrealm:

Он запросит у вас мастер-пароль базы данных, который используется для шифрования локальной базы данных. Выберите безопасный пароль: его надежность не проверяется для вас.

Конфигурация

Вопросы, заданные во время установки, используются для настройки файлов /etc/krb5.conf и /etc/krb5kdc/kdc.conf. Первый используется библиотеками Kerberos 5, а второй настраивает KDC. Если вам нужно настроить параметры Центра распространения ключей (KDC), просто отредактируйте файл и перезапустите демон krb5-kdc. Если вам нужно перенастроить Kerberos с нуля, возможно, чтобы изменить имя области, вы можете сделать это, набрав

Примечание

Справочная страница для krb5.conf находится в пакете krb5-doc.

После правильной работы KDC необходим пользователь-администратор — администратор-принципал. Рекомендуется использовать имя пользователя, отличное от вашего обычного имени пользователя. С помощью утилиты kadmin.local в терминале введите:

Далее новый пользователь-администратор должен иметь соответствующие разрешения списка управления доступом (ACL). Разрешения настраиваются в файле /etc/krb5kdc/kadm5.acl:

Эта запись предоставляет ubuntu/admin возможность выполнять любые операции со всеми субъектами в области. Вы можете настроить участников с более строгими привилегиями, что удобно, если вам нужен участник администратора, который младшие сотрудники могут использовать в клиентах Kerberos. Дополнительные сведения см. на справочной странице kadm5.acl.

Примечание

Привилегия extract не включена в привилегию подстановочного знака; он должен быть назначен явно. его привилегия позволяет пользователю извлекать ключи из базы данных, и с ней следует обращаться очень осторожно, чтобы избежать раскрытия важных ключей, таких как ключи участников kadmin/* или krbtgt/*. Подробности смотрите на справочной странице kadm5.acl.

Теперь перезапустите krb5-admin-server, чтобы новый ACL вступил в силу:

Новый субъект пользователя можно протестировать с помощью утилиты kinit:

После ввода пароля используйте утилиту klist для просмотра информации о билете на предоставление билетов (TGT):

Где имя файла кеша krb5cc_1000 состоит из префикса krb5cc_ и идентификатора пользователя (uid), который в данном случае равен 1000 .

Подробные инструкции по настройке DNS см. в главе DNS.

Теперь ваша новая область Kerberos готова для аутентификации клиентов.

Дополнительный ЦОД

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

Примечание

Объясняемый здесь собственный механизм репликации основан на cronjob и, по сути, создает дамп БД на первичном сервере и загружает его резервную копию на вторичном. Возможно, вы захотите взглянуть на использование серверной части kldap, которая может использовать механизм репликации OpenLDAP. Это объясняется ниже.

Сначала установите пакеты и при запросе имен серверов Kerberos и Admin введите имя основного KDC:

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

Убедитесь, что используемый вами участник имеет дополнительные права извлечения ключей в файле kdc01 /etc/krb5kdc/kadm5.acl. Что-то вроде этого:

Где "*" означает все привилегии (кроме extract-keys ), а e означает именно Extract-keys .

Извлеките файл keytab:

Теперь в текущем каталоге должен быть keytab.kdc02, переместите файл в /etc/krb5.keytab :

Примечание

Если путь к файлу keytab.kdc02 отличается, исправьте его соответствующим образом.

Кроме того, вы можете перечислить участников в файле Keytab, который может быть полезен при устранении неполадок, с помощью утилиты klist:

Опция -k указывает, что файл является файлом keytab.

Далее на каждом KDC должен быть файл kpropd.acl, в котором перечислены все KDC для Realm. Например, на первичном и вторичном KDC создайте файл /etc/krb5kdc/kpropd.acl :

Создайте пустую базу данных на дополнительном KDC:

Теперь установите демон kpropd, который прослушивает соединения утилиты kprop с основного kdc:

Служба будет запущена сразу после установки.

С терминала на основном KDC создайте файл дампа основной базы данных:

Оставаясь на основном KDC, извлеките его файл keytab и скопируйте его в /etc/krb5.keytab :

Примечание

Теперь вы можете удалить привилегию извлечения ключей из этого принципала в файле kdc01 /etc/krb5kdc/kadm5.acl

На основном KDC запустите утилиту kprop, чтобы отправить созданный ранее дамп базы данных на дополнительный KDC:

Обратите внимание на сообщение SUCCEEDED, означающее, что распространение сработало. Если есть сообщение об ошибке, проверьте /var/log/syslog на вторичном KDC для получения дополнительной информации.

Вы также можете создать задание cron для периодического обновления базы данных на вторичном KDC. Например, следующий код будет отправлять базу данных каждый час:

Вернувшись на вторичный KDC, создайте файл stash для хранения главного ключа Kerberos:

Наконец, запустите демон krb5-kdc на вторичном KDC:

Примечание

На Вторичном KDC не работает сервер администратора, так как это копия только для чтения

Вторичный KDC теперь должен иметь возможность выдавать билеты для Realm. Вы можете проверить это, остановив демон krb5-kdc на основном KDC, а затем используя kinit для запроса билета. Если все пойдет хорошо, вы должны получить билет от вторичного KDC. В противном случае проверьте /var/log/syslog и /var/log/auth.log во вторичном KDC.

Клиент Kerberos для Linux

В этом разделе описывается настройка системы Linux в качестве клиента Kerberos. Это позволит получить доступ к любым службам с поддержкой Kerberos после того, как пользователь успешно войдет в систему.

Обратите внимание, что одного лишь Kerberos недостаточно для существования пользователя в системе Linux. Это означает, что мы не можем просто направить систему на сервер kerberos и ожидать, что все участники kerberos смогут входить в систему linux просто потому, что эти пользователи не существуют локально. . Kerberos обеспечивает только аутентификацию: он не знает о группах пользователей, uid и gid Linux, домашних каталогах и т. д. Обычно для получения этой информации используется другой сетевой источник, например сервер LDAP или Windows, а в старые времена — NIS. также использовался для этого.

Установка

Если у вас есть локальные пользователи, соответствующие субъектам в области Kerberos, и вы просто хотите переключить аутентификацию с локальной на удаленную с помощью Kerberos, вы можете следовать этому разделу. Это не совсем обычный сценарий, но он служит для выделения разделения между аутентификацией пользователя и информацией о пользователе (полное имя, uid, gid, домашний каталог, группы и т. д.). Если вы просто хотите получить билеты и использовать их, достаточно установить krb5-user и запустить kinit .

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

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

Примечание

Если вы добавили соответствующие записи SRV в DNS, ни один из этих запросов не требует ответа.

Конфигурация

Если вы пропустили вопросы ранее, вы можете перенастроить пакет, чтобы заполнить их снова: sudo dpkg-reconfigure krb5-config .

Вы можете протестировать конфигурацию Kerberos, запросив билет с помощью утилиты kinit. Например:

Примечание

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

Раз мы уже на этом, давайте также создадим участника без прав администратора для Ubuntu:

Теперь осталась только конфигурация для sssd. Создайте файл /etc/sssd/sssd.conf со следующим содержимым:

Приведенная выше конфигурация будет использовать kerberos для аутентификации ( auth_provider ), но будет использовать пользователей локальной системы для информации о пользователях и группах ( id_provider ).

Настройте права доступа к файлу конфигурации и запустите sssd:

Просто установив sssd и его зависимости, PAM уже будет настроен на использование sssd с откатом к локальной аутентификации пользователя. Чтобы попробовать, если это рабочая станция, просто переключите пользователей (в графическом интерфейсе), или откройте терминал входа в систему (CTRL-ALT-), или создайте оболочку входа с помощью sudo login и попробуйте войти в систему, используя имя принципал керберос. Помните, что этот пользователь уже должен существовать в локальной системе:

И у вас будет билет Kerberos сразу после входа в систему.

Ресурсы

Дополнительную информацию о версии Kerberos от Массачусетского технологического института см. на сайте MIT Kerberos.

Дополнительная информация содержится на странице Ubuntu Wiki Kerberos.

O’Reilly’s Kerberos: The Definitive Guide — отличный справочник по настройке Kerberos.

Читайте также:

Справочная страница	Описание
Клиентские приложения
kerberos	Введение в систему Kerberos, в котором описывается, как работают учетные данные, и даются рекомендации по получению и уничтожению билетов Kerberos. В нижней части справочной страницы есть ссылки на ряд связанных справочных страниц.
kinit	Описывает, как использовать эта команда для получения и кэширования билета на выдачу билетов.
kdestroy	Описывает, как использовать эту команду для уничтожения учетных данных Kerberos.
klist	Описывает, как использовать эту команду для получения списка кэшированных учетных данных Kerberos.< /td>
Административные приложения
kadmin	Описывает, как использовать эту команду для администрирования базы данных Kerberos V5.
kdb5_util	Описывает, как использовать эту команду для создания и выполнения l административные функции в базе данных Kerberos V5.
Серверные приложения
krb5kdc	Описывает доступные параметры командной строки для Kerberos V5 KDC.
kadmind< /td>	Описывает доступные параметры командной строки для сервера администрирования Kerberos V5.
Файлы конфигурации
krb5.conf	Описывает формат и параметры, доступные в файле конфигурации для библиотеки Kerberos V5.
kdc.conf	Описывает формат и параметры, доступные в файле конфигурации для AS Kerberos V5 и КДК.