Файл Keytab что это такое

Обновлено: 21.11.2024

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

Чтобы добавить служебный ключ в файл keytab, вы добавляете соответствующий субъект-службу в файл keytab хоста с помощью команды ktadd в kadmin . Поскольку вы добавляете субъект-службу в файл keytab, субъект должен уже существовать в базе данных Kerberos, чтобы kadmin мог проверить его существование. На главном KDC файл keytab по умолчанию находится в /etc/krb5/kadm5.keytab. На серверах приложений, предоставляющих услуги Kerberized, файл keytab по умолчанию находится в /etc/krb5/krb5.keytab .

Кнопка аналогична паролю пользователя. Так же, как для пользователей важно защищать свои пароли, для серверов приложений не менее важно защищать свои файлы ключей. Вы всегда должны хранить файлы keytab на локальном диске и делать их доступными для чтения только пользователю root. Кроме того, вы никогда не должны отправлять файл keytab по незащищенной сети.

Есть также специальный экземпляр для добавления принципала root в файл keytab хоста. Если вы хотите, чтобы пользователь клиента SEAM автоматически монтировал файловые системы Kerberized NFS, использующие аутентификацию Kerberos, вы должны добавить участника root клиента в файл keytab клиента. В противном случае пользователи должны использовать команду kinit от имени пользователя root, чтобы получить учетные данные для клиентского принципала root всякий раз, когда они хотят смонтировать файловую систему NFS с поддержкой Kerberos, даже если они используют средство автоматического монтирования. Дополнительные сведения см. в разделе Настройка Root аутентификации для монтирования файловых систем NFS.

При настройке главного KDC необходимо добавить участников kadmind и changepw в файл kadm5.keytab. Этот шаг позволяет KDC расшифровывать билеты Kerberos администраторов, чтобы определить, следует ли предоставлять администраторам доступ к базе данных.

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

Администрирование карты задач Keytabs

Добавить субъект-службу в файл keytab

Используйте команду ktadd в kadmin, чтобы добавить субъект-службу в файл keytab.

Удалить субъект-службу из файла keytab

Используйте команду ktremove в kadmin, чтобы удалить службу из файла keytab.

Отобразить список ключей (участников) в файле keytab

Используйте команду ktutil для отображения списка ключей в файле keytab.

Временно отключить аутентификацию для службы на хосте

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

Прежде чем использовать ktutil для удаления субъекта-службы из файла таблицы ключей сервера, скопируйте исходный файл таблицы ключей во временное расположение. Если вы хотите снова включить службу, скопируйте исходный файл keytab обратно в нужное место.

Как добавить субъект-службу в файл Keytab

Убедитесь, что субъект уже существует в базе данных Kerberos.

Стать суперпользователем на хосте, которому нужно добавить принципала в его файл keytab.

Запустите команду kadmin.

Добавить принципала в файл keytab с помощью команды ktadd.

Указывает файл keytab. По умолчанию используется /etc/krb5/krb5.keytab.

Отображает менее подробную информацию.

Указывает участника, который будет добавлен в файл keytab. Вы можете добавить следующие субъекты-службы: host, root, nfs и ftp.

-glob main-exp

Определяет основные выражения. Все принципалы, соответствующие принципалу, добавляются в файл keytab. Правила для основного выражения такие же, как и для команды list_principals kadmin .

Выйти из команды kadmin.

Пример — добавление субъекта-службы в файл Keytab

В следующем примере участники kadmin/admin и kadmin/changepw добавляются в файл keytab главного KDC. В этом примере файл keytab должен быть файлом, указанным в файле kdc.conf.

В следующем примере участник denver host добавляется в файл keytab denver, чтобы KDC мог аутентифицировать < tt>сетевые службы Денвера.

Как удалить субъект-службу из файла Keytab

Стать суперпользователем на хосте с субъектом-службой, который необходимо удалить из файла keytab.

Запустите команду kadmin.

(Необязательно) Чтобы отобразить текущий список принципалов (ключей) в файле keytab, используйте команду ktutil.

Удалите принципала из файла keytab с помощью команды ktremove.

Указывает файл keytab. По умолчанию используется /etc/krb5/krb5.keytab.

Отображает менее подробную информацию.

Указывает участника, который будет удален из файла keytab.

Удаляет все записи для указанного принципала, номер версии ключа которого соответствует kvno .

Удаляет все записи для указанного принципала.

Удаляет все записи для указанного принципала, кроме участников с наивысшим номером версии ключа.

Выйти из команды kadmin.

Пример — удаление субъекта-службы из Keytab

В следующем примере участник denver host удаляется из файла keytab denver.

Как отобразить список ключей (участников) в файле Keytab

Стать суперпользователем на хосте с файлом keytab.

Хотя вы можете создавать файлы keytab, принадлежащие другим пользователям, расположение по умолчанию для файла keytab требует владения root.

Запустите команду ktutil.

Прочитайте файл keytab в буфер списка ключей с помощью команды read_kt.

Отобразите буфер списка ключей с помощью команды list.

Отображается текущий буфер списка ключей.

Закройте команду ktutil.

Пример — отображение списка ключей (участников) в файле Keytab

В следующем примере отображается список ключей в файле /etc/krb5/krb5.keytab на хосте denver.

Как временно отключить аутентификацию для службы на хосте

Иногда может потребоваться временно отключить механизм аутентификации для службы, например rlogin или ftp, на сервере сетевых приложений. Например, вы можете захотеть запретить пользователям входить в систему, пока вы выполняете процедуры обслуживания. Команда ktutil позволяет выполнить эту задачу, удалив субъект-службу из файла keytab сервера, не требуя прав kadmin. Чтобы снова включить аутентификацию, вам просто нужно скопировать исходный файл keytab, который вы сохранили, обратно в исходное местоположение.

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

Стать суперпользователем на хосте с файлом keytab.

Сохранить текущий файл таблицы ключей во временный файл.

Запустите команду ktutil.

Прочитайте файл keytab в буфер списка ключей с помощью команды read_kt.

Отобразите буфер списка ключей с помощью команды list.

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

Чтобы временно отключить службу хоста, удалите определенный субъект-службу из буфера списка ключей с помощью команды delete_entry.

В этом примере slot-number указывает номер слота удаляемого субъекта-службы, который отображается с помощью команды list.

Запишите буфер списка ключей в файл keytab с помощью команды write_kt.

Закройте команду ktutil.

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

ВНИМАНИЕ! Если вы используете keytab для аутентификации WebAuth, посетите страницу объявлений WebAuth, чтобы узнать о будущем направлении веб-аутентификации Stanford.

Фон

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

Каждая сетевая служба, в которой пользователь может пройти аутентификацию, должна иметь субъект-службу с соответствующим ключом. Сетевой сервис должен иметь копию этого ключа в системе, чтобы он мог проверить личность пользователя. Этот ключ хранится в специально отформатированном файле, называемом keytab. В одном файле keytab может храниться несколько ключей, либо несколько ключей для одного и того же субъекта-службы, либо даже ключи для нескольких разных субъектов-служб. В системе UNIX вы можете просмотреть содержимое таблицы ключей с помощью команды klist -k.

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

Из-за того, как работает Kerberos, сетевая служба должна иметь отдельный ключ для каждого поддерживаемого типа шифрования. В настоящее время мы поддерживаем 256-битное шифрование AES (самое надежное и самое современное, но еще не повсеместно поддерживаемое), тройной DES и (для устаревшей совместимости, которая будет постепенно прекращена) DES. Поэтому у большинства субъектов-служб будет три ключа, по одному для каждого типа шифрования. Kerberos автоматически выбирает самый надежный ключ, поддерживаемый как клиентом, так и сервером, поэтому обычно вам не нужно беспокоиться об этой детали реализации.

Напомним, что субъект-служба — это учетная запись, идентификатор, хранящийся в Kerberos для определенного приложения. Этот субъект-служба имеет один или несколько ключей, аналогичных паролям. Эти ключи хранятся на сервере, на котором работает служба, в файле с именем keytab, который можно просмотреть с помощью команды klist -k.

Типы субъектов-служб

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

host/* — удаленный вход через SSH, rlogin или rsh и проверка локальных входов
webauth/* — аутентификация WebAuth для веб-серверов

Чтобы разрешить удаленный вход в систему с использованием проверки подлинности Kerberos, в этой системе должен быть субъект-служба host/*. Этот принципал также используется для проверки локальных входов (например, в консоль), если он существует. Keytab для этого субъекта-службы должен быть установлен локально по пути, ожидаемому серверами входа (обычно /etc/krb5.keytab).

Чтобы использовать WebAuth, веб-сервер должен иметь субъект-службу webauth/*, а его keytab должен быть установлен в расположении, указанном в конфигурации WebAuth.

Субъекты на основе хоста не должны использоваться совместно и повторно. Каждый хост, предоставляющий услугу, должен иметь отдельного принципала на основе хоста для этой службы, и если этот хост заменяется другим с новым именем, должен быть получен новый принципал на основе хоста. В частности, даже если набор веб-серверов является частью пула, который использует WebAuth для обслуживания одного сайта, каждый сервер должен иметь отдельный принцип WebAuth на основе хоста и не должен использовать один и тот же. Основное имя не зависит от URL-адреса обслуживаемого веб-сайта и должно совпадать с основным именем системы в NetDB.

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

Второй тип субъекта-службы — это субъект, используемый приложением для аутентификации в других сетевых службах. Наиболее распространенными сетевыми службами, в которых автоматизированные процессы хотят пройти аутентификацию, являются служба каталогов LDAP университетского городка и файловая система AFS на уровне университетского городка, но некоторым приложениям может потребоваться доступ и к другим службам. Эти типы субъектов-служб связаны с приложением, а не с конкретной системой, и при перемещении этого приложения они будут перемещены в другую систему. В Стэнфорде имена этих директоров:

где application — краткое, но понятное обозначение приложения, которое будет использовать этот субъект-службу.

Создание субъектов-служб

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

В таблице ключей (сокращение от "таблица ключей") хранятся долгосрочные ключи для одного или нескольких субъектов. Таблицы ключей обычно представлены файлами в стандартном формате, хотя в редких случаях они могут быть представлены другими способами. Вкладки Keytabs чаще всего используются для того, чтобы серверные приложения могли принимать аутентификацию от клиентов, но их также можно использовать для получения исходных учетных данных для клиентских приложений.

Вкладки клавиш именуются в формате тип : значение. Обычно type — это FILE, а value — это абсолютный путь к файлу. Другим возможным значением для type является MEMORY , что указывает на временную таблицу ключей, хранящуюся в памяти текущего процесса.

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

Вкладку можно отобразить с помощью команды klist с параметром -k. Вкладки ключей можно создавать или добавлять к ним, извлекая ключи из базы данных KDC с помощью команды kadmin ktadd. Вкладками можно управлять с помощью команд ktutil и k5srvutil.

Вкладка по умолчанию¶

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

Переменная среды KRB5_KTNAME.
Переменная профиля default_keytab_name в [libdefaults].
Жестко заданное значение по умолчанию, DEFKTNAME.

Таблица ключей клиента по умолчанию¶

Таблица ключей клиента по умолчанию используется, если она присутствует и доступна для чтения, для автоматического получения исходных учетных данных для клиентских приложений GSSAPI. Основное имя первой записи в таблице ключей клиента используется по умолчанию при получении исходных учетных данных. Имя ключевой таблицы клиента по умолчанию определяется следующим, в порядке убывания предпочтений:

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

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

Диалоговое окно Keytab Entry, доступное в разделе Secret Key на экранах Kerberos Client и Kerberos Service после нажатия кнопки Add Principal, по существу является графическим интерфейсом для записей в файле Kerberos Keytab.

Это диалоговое окно позволяет создавать записи таблицы ключей. Вы можете удалить записи из файла Keytab, нажав кнопку «Удалить запись» на экранах «Клиент Kerberos» и «Служба Kerberos». Вы можете настроить клиенты Kerberos и службы Kerberos в узле External Connections в дереве Policy Studio.

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

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

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

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

Настройте следующие поля в диалоговом окне Keytab Entry:

Субъект Kerberos:
Выберите существующий субъект Kerberos из раскрывающегося списка или добавьте новый, нажав кнопку "Добавить". Принципы Kerberos можно настроить глобально в узле External Connections в дереве Policy Studio. Дополнительные сведения о настройке участников Kerberos см. в разделе Принципы Kerberos.

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

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

Чтобы обеспечить максимальную совместимость между клиентами/службами Kerberos, настроенными в Enterprise Gateway, и различными типами KDC, по умолчанию выбраны все типы шифрования. При такой конфигурации сгенерированный файл Keytab содержит отдельный ключ шифрования для каждого перечисленного здесь типа шифрования, где каждый ключ сопоставляется с именем принципала, выбранным выше.

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

Примечание:
Для Windows 2003 Active Directory по умолчанию билет службы шифруется с использованием типа шифрования rc4-hmac. Однако, если у пользователя службы включен параметр Использовать типы шифрования DES для этой учетной записи, используется тип шифрования des-cbc-md5.

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