Ваш первый контакт с Kerberos напоминает стандартную процедуру сетевого логина. Введите Ваше имя пользователя. Эта часть информации и имя службы, выдающей билеты, посылаются серверу аутентификации (Kerberos). Если сервер аутентификации знает Вас, он генерирует случайный ключ сессии для дальнейшего использования между Вашим клиентом и предоставляющим билеты сервером. Далее сервер аутентификации готовит билет для сервера, предоставляющего билеты. Билет содержит следующую информацию (все зашифровано ключем сессии, который знают только сервер аутентификации и сервер, предоставляющий билеты):

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

Для запроса службы у любого сервера сети, клиентское приложение должно подтвердить подлинность перед сервером. Поэтому приложение генерирует аутентификатор. Аутентификатор состоит из следующих компонентов:

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

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

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

Билеты создаются для использования с конкретным сервером. Это означает, что при запросе к новой службе Вам нужен новый билет. Kerberos реализует механизм получения билетов для отдельных серверов. Эта служба называется «службой получения билетов ». Служба получения билетов использует протоколы доступа описанные ранее. Каждый раз, когда приложению нужен новый билет, оно соединяется с сервером получения билетов. Этот запрос состоит из следующих компонентов:

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

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

Windows 2000 содержит реализацию Kerberos 5 от Microsoft. openSUSE® использует MIT реализацию Kerberos 5, полезная информация и руководство можно найти в документации MIT Раздел 6.5, «Дополнительная информация».

Любое окружение с Kerberos для полноценной работы должно отвечать следующим требованиям:

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

Рисунок 6.1. Сетевая топология Kerberos¶

	Настройка маршрутизации подсети
Для конфигурации подобной Рисунок 6.1, «Сетевая топология Kerberos», настройте маршрутизацию между двумя подсетями (192.168.1.0/24 и 192.168.2.0/24). Обратитесь к Раздел “Configuring Routing” (Глава 9, Basic Networking, ↑Содержание) за дальнейшей информацией о настройке маршрутизации с помощью YaST.

Домен, в котором работает инсталляция Kerberos называется областью и идентифицируется именем, таким как EXAMPLE.COM или просто ACCOUNTING. Kerberos чувствителен к регистру, поэтому example.com является областью, отличной от EXAMPLE.COM. Используйте регистр, который Вам нравится. Однако, общепринятая практика — использовать верхний регистр для имен областей.

Хорошая идея использовать Ваше имя домена из DNS (или поддомена, такого как ACCOUNTING.EXAMPLE.COM). Как показано ниже, Вы можете облечить себе жизнь как администратору, если настроите клиенты Kerberos на поиск KDC и других служб Kerberos с помощью DNS. При этом очень полезно указать имя области как поддомен Вашего доменного имени DNS.

в отличие от пространства имен DNS, Kerberos не иерархичен. Вы не можете подчинить области с именем EXAMPLE.COM, две «подобласти» с именами DEVELOPMENT и ACCOUNTING, так, чтобы подчиненные области наследовали принципалов у EXAMPLE.COM. Вместо этого, Вы получите три разных области, для которых Вам придется настроить межобластную аутентификацию, чтобы пользователи одной области могли взаимодействовать с серверами и пользователями другой области.

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

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

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

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

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

Самым простым способом будет установка на один из компьютеров сервера NTP и синхронизация всех своих часов клиентами с этим сервером. Это можно сделать либо запустив NTP демон в режиме клиента на всех этих компьютерах или при помощи ежедневного запуска ntpdate на всех клиентах (это решение скорее всего будет работать только для небольшого количества клиентов). KDC тоже должен синхронизироваться с общим источником времени. Поскольку запуск NTP демона на этом компьютере будет представлять угрозу безопасности, хорошей идеей будет запуск ntpdate поредством записи в кроне. Что бы настроить клиент NTP, следуйте инструкциям Раздел “Configuring an NTP Client with YaST” (Глава 13, Time Synchronization with NTP, ↑Содержание).

Другой способом безопасно использовать службу времени с NTP-демоном - закрепить один источник точного времени за выделенным NTP-сервером и другой источник точного времени за KDC.

Можно также изменить максимальное отклонение, допускаемое Kerberos при проверке временных меток. Это значение (называемое разброс часов - clock skew) может быть установлено в файле krb5.conf как описано в Раздел 6.4.6.2.3, «Изменения разброса часов».

Эта секция поясняет начальную настройку и установку KDC, включая создание административного принципала. Эта процедура состоит из нескольких шагов:

kdb5_util create -r EXAMPLE.COM -s

Initializing database '/var/lib/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM',
master key name 'K/M@EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:  
Re-enter KDC database master key to verify:  

kadmin.local

kadmin> listprincs

K/M@EXAMPLE.COM
kadmin/admin@EXAMPLE.COM
kadmin/changepw@EXAMPLE.COM
krbtgt/EXAMPLE.COM@EXAMPLE.COM

kadmin.local

kadmin> ank geeko

geeko@EXAMPLE.COM's Password: 
Verifying password: 

После того, как развернута вспомогательная инфраструктура (DNS, NTP) и KDC настроен и запущен, настройте клиентские компьютеры. Для настройки Kerberos клиента Вы можете использовать YaST либо один из двух методов ручной настройки, описанных ниже.

6.4.6.1. Конфигурация клиента Kerberos при помощи YaST¶

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

1. Войдите в систему как root и выберите Сетевые службы+Клиент Kerberos.

2. Выберите Использовать Kerberos.

3. Для настройки клиента Kerberos, использующего DNS выполните следующие действия:

   1. Включите Использовать DNS для получения данных настроек во время работы и проверьте Основные настройки Kerberos отображенные на экране.

      	Использование поддержки DNS
      Опция Использовать DNS не может быть выбрана, если DNS сервер не предоставляет таких данных.

   2. Нажмите Дополнительные настройки для конфигурирования параметров билетов, поддержки OpenSSH, синхронизации времени и экспертных настроек PAM.

4. Для настройки статического клиента Kerberos:

   1. Установите в Домен по умолчанию, Область по умолчанию и Адрес сервера KDC значения, соответствующие Вашей конфигурации.

   2. Нажмите Дополнительные настройки для конфигурирования параметров билетов, поддержки OpenSSH, синхронизации времени и экспертных настроек PAM.

Рисунок 6.2. YaST: Базовая настройка клиента Kerberos

Для конфигурирования параметров билетов в диалоге Дополнительные настройки:

• Укажите Время действия по умолчанию и Обновляемое время действия по умолчанию в днях, часах или минутах, (используя единицы измерения d, h или m, без разделителя между значением и единицей измерения).

• Для переадресации Вашей полной идентификации (для использования Ваших билетов на других хостах), выберите значение в поле Переадресация.

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

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

• Отключите использование аутентификации Kerberos для некоторых пользовательских аккаунтов введя в поле Минимальный UID значение необходимое для активации авторизации. Например, Вы можете пожелать исключить администратора системы (root).

• Используйте Разброс часов, чтобы установить значение максимального отклонения между временными метками и системным временем Вашей машины.

• Для синхронизации системного времени с NTP сервером, Вы также можете настроить NTP клиент, выбрав Настройка NTP , которая откроет диалог YaST Расширенная настройка NTP, описываемый в Раздел “Configuring an NTP Client with YaST” (Глава 13, Time Synchronization with NTP, ↑Содержание). После завершения конфигурации, YaST выполнит все необходимые изменения и клиент Kerberos будет готов к использованию.

Рисунок 6.3. YaST: Дополнительные настройки клиента Kerberos

За подробной информацией о конфигурации вкладок Настройки эксперта PAM и Службы PAM, обратитесь к официальной документации Раздел 6.5, «Дополнительная информация» и man-странице man 5 krb5.conf, входящей в пакет krb5-doc.

[libdefaults]
        default_realm = EXAMPLE.COM

[realms]
        EXAMPLE.COM = {
                kdc = kdc.example.com
                admin_server = kdc.example.com
        }

[domain_realm]
        .example.com = EXAMPLE.COM
        www.foobar.com = EXAMPLE.COM

_kerberos.www.foobar.com.  IN TXT "EXAMPLE.COM"

[libdefaults]
        clockskew = 60

Чтобы добавлять и удалять принципалов из базы данных Kerberos, не имея прямого доступа к консоли KDC, укажите серверу администрирования Kerberos какие действия разрешены каким принципалам отредактировав /var/lib/kerberos/krb5kdc/kadm5.acl. Файл ACL (списка контроля доступа) позволяет Вам задавать привилегии с четким их контролем. За подробностями обратитесь к man-странице man 8 kadmind.

Сейчас просто утановите себе привилегию администрировать базу данных добавив слкдующую строку в файл:

geeko/admin              *

Замените имя пользователя geeko на свое. перезапустите kadmind для применения изменений.

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

kadmin -p geeko/admin
Authenticating as principal geeko/admin@EXAMPLE.COM with password.
Password for geeko/admin@EXAMPLE.COM:
kadmin:  getprivs
current privileges: GET ADD MODIFY DELETE
kadmin:

Используя команду getprivs, проверьте, какие у Вас привилегии. Список выше отображает полный набор привилегий.

В качестве примера, измените принципала geeko:

kadmin -p geeko/admin
Authenticating as principal geeko/admin@EXAMPLE.COM with password.
Password for geeko/admin@EXAMPLE.COM:

kadmin:  getprinc geeko
Principal: geeko@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:47:17 CET 2005 (admin/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]

kadmin:  modify_principal -maxlife "8 hours" geeko
Principal "geeko@EXAMPLE.COM" modified.
kadmin:  getprinc joe
Principal: geeko@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 08:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:59:49 CET 2005 (geeko/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]
kadmin:

Это изменит максимальное время жизни билета, установив его равным восьми часам. Подробную информацию о команде kadmin и доступных опциях смотрите в пакете krb5-doc, по ссылке http://web.mit.edu/kerberos/www/krb5-1.8/krb5-1.8.3/doc/krb5-admin.html#Kadmin%20Options, или на man-странице man8 kadmin.

До настоящего момента мы обсуждали только аутентификацию пользователей. Однако, службы совместимые с Kerberos обычно также должны аутентифицировать себя перед клиентами. Таким образом, в базе данных Kerberos должны существовать специальные служебные принципалы для каждой службы работающей данной области. Например, если ldap.example.com предоставляет службу LDAP, вам нужен служебный принципал, ldap/ldap.example.com@EXAMPLE.COM, для аутентификации этой службы перед всеми клиентами.

Соглашение именования для служебных принципалов служба/имяхоста@ОБЛАСТЬ, где имя_хоста — полное имя хоста.

Действительные дескрипторы служб:

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

Вместо этого, ключ для расшифровки первого билета служебного принципала получается администратором от KDC всего один раз и хранится в локальном файле с именем keytab. Службы, такие как демон SSH, читают этот ключ и, при необходимости, используют его для получения нового билета автоматически. Файл keytab по умолчанию находится в /etc/krb5.keytab.

Для создания сервисного принципала хоста jupiter.example.com введите следующие команды в сессии kadmin:

kadmin -p geeko/admin
Authenticating as principal geeko/admin@EXAMPLE.COM with password.
Password for geeko/admin@EXAMPLE.COM:
kadmin:  addprinc -randkey host/jupiter.example.com
WARNING: no policy specified for host/jupiter.example.com@EXAMPLE.COM;
defaulting to no policy
Principal "host/jupiter.example.com@EXAMPLE.COM" created.

Вместо установки пароля для нового принципала, флаг -randkey указывает kadmin создать случайный ключ. Он используется потому, что для этого принципала не нужно взаимодействие с пользователем. Это серверная учетная запись.

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

kadmin:  ktadd host/jupiter.example.com
Entry for principal host/jupiter.example.com with kvno 3, encryption type Triple
DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/jupiter.example.com with kvno 3, encryption type DES
cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
kadmin:

После завершения убедитесь, что вы уничтожили администраторский билет, полученный kinit выше командой kdestroy.

openSUSE® содержит модуль PAM с именем pam_krb5, который поддерживает вход в систему через Kerberos и изменение пароля. Этот модуль может использоваться как консольными приложениями: login, su, так и приложениями графической авторизации, например KDM (где пользователь вводит пароль и хочет, чтобы приложение, удостоверяющее подлинность, получило для него начальный билет Kerberos). Для настройки поддержки PAM в Kerberos, используйте следующую команду:

pam-config --add --krb5

Эта команда добавляет модуль pam_krb5 в существующие файлы конфигурации PAM и проверяет, в правильном порядке ли он запускается. Для точной настройки использования pam_krb5, отредактируйте файл /etc/krb5.conf и добавьте приложения по умолчанию в pam. Подробности доступны на man-странице man 5 pam_krb5.

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

OpenSSH поддерживает аутентификацию Kerberos как для протоколов версии  1 и 2. В версии 1, есть специальные сообщения протокола передачи билетов Kerberos. Версия 2 уже не использует Kerberos напрямую, полагаясь на GSSAPI, Общее API служб безопасности (General Security Services API). Это программный интерфейс, не характерный только для Kerberos — он был создан для скрытия особенностей систем аутентификации, будь то Kerberos, система аутентификации на основе открытого ключа наподобие SPKM или другая. Однако, имеющаяся библиотека GSSAPI поддерживает только Kerberos.

Для использования sshd с аутентификацией Kerberos, отредактируйте файл /etc/ssh/sshd_config и установите следующие опции:

# These are for protocol version 1 
#
# KerberosAuthentication yes
# KerberosTicketCleanup yes

# These are for version 2 - better to use this
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

Затем перезапустите демон SSH с помощью команды rcsshd restart.

Для использования аутентификации Kerberos с протоколом версии 2, включите его на стороне клиента. Это можно сделать либо в системном файле конфигурации /etc/ssh/ssh_config или на уровне пользователя, отредактировав ~/.ssh/config. В любом случае, добавьте опцию GSSAPIAuthentication yes.

Теперь Вы сможете подключаться используя аутентификацию Kerberos. Используйте klist для проверки наличия действительного билета, затем подключитесь к серверу SSH. Для принудительного использования версии 1 протокола SSH, укажите опцию -1 в командной строке.

	Дополнительная информация
В файле /usr/share/doc/packages/openssh/README.kerberos содержит более подробное описание взаимодействия OpenSSH и Kerberos.

при использовании Kerberos, одним из способов распространения пользовательской информации (такой как ID пользователя, его группы и домашняя директория) в Вашей локальной сети, является использование LDAP. Это требует надежного механизма аутентификации, предотвращающего подмену пакетов и другие атаки. Одним из решений является использование Kerberos для взаимодействия с LDAP.

OpenLDAP реализует большинство способов аутентификации через SASL, уровень простой сессионной авторизации. SASL это сетевой протокол, созданный для аутентификации. Реализацией SASL является cyrus-sasl, который поддерживает различные методы аутентификации. Аутентификация Kerberos выполняется посредством GSSAPI (General Security Services API). По умолчанию плагин SASL для GSSAPI не установлен. Установите cyrus-sasl-gssapi при помощи YaST.

Чтобы разрешить Kerberos использование сервера OpenLDAP, создайте принципала ldap/ldap.example.com и добавьте его в keytab.

По умолчанию сервер LDAP slapd запущен от пользователя и группы ldap, в то время как файл keytab может читать только root. Поэтому, либо измените конфигурацию LDAP, чтобы сервер работал от root или разрешите чтение файла keytab группе ldap. Это можно автоматизировать используя скрипт запуска OpenLDAP (/etc/init.d/ldap) если файл keytab был указан в переменной OPENLDAP_KRB5_KEYTAB файла /etc/sysconfig/openldap и переменная OPENLDAP_CHOWN_DIRS установлена в yes, что уже сделано по умолчанию. Если OPENLDAP_KRB5_KEYTAB пуста, используется keytab файл /etc/krb5.keytab и Вы должны сами изменить права доступа согласно дальнейшей инструкции.

Для запуска slapd от root, отредактируйте /etc/sysconfig/openldap. Отключите переменные OPENLDAP_USER и OPENLDAP_GROUP, добавив перед ними символ комментария.

Чтобы разрешить чтение файла keytab группе LDAP, выполните

chgrp ldap /etc/krb5.keytab
chmod 640 /etc/krb5.keytab

Третье (и возможно наилучшее) решение — использовать с OpenLDAP отдельный файл keytab. Для этого запустите kadmin и введите следующую команду после добавления принципала ldap/ldap.example.com:

ktadd -k /etc/openldap/ldap.keytab ldap/ldap.example.com@EXAMPLE.COM

Затем выполните в консоли:

chown ldap.ldap /etc/openldap/ldap.keytab 
chmod 600 /etc/openldap/ldap.keytab

Чтобы указать OpenLDAP использовать отдельный файл keytab, измените переменную в файле /etc/sysconfig/openldap:

OPENLDAP_KRB5_KEYTAB="/etc/openldap/ldap.keytab"

И наконец, перезапустите сервер LDAP с помощью rcldap restart.

ldapsearch -b ou=people,dc=example,dc=com '(uid=geeko)'

SASL/GSSAPI authentication started
SASL SSF: 56
SASL installing layers
[...]

# geeko, people, example.com
dn: uid=geeko,ou=people,dc=example,dc=com
uid: geeko
cn: Olaf Kirch
[...]

# This is required for things to work _at all_
access to dn.base="" by * read
# Let each user change their login shell
access to dn="*,ou=people,dc=example,dc=com" attrs=loginShell
       by self write
# Every user can read everything
access to *
       by users read

authz-regexp
   uid=(.*),cn=GSSAPI,cn=auth 
   uid=$1,ou=people,dc=example,dc=com