Подсказки, советы и решение проблем с Kerberos

• При использовании портов как Heimdal так и MIT Kerberos убедитесь, что в PATH версии Kerberos клиентов указаны перед их версиями в базовой системе.

• Все ли компьютеры в пределах данного realm синхронизированы по времени? Если нет, аутентификация может завершиться неудачно. Разд. 26.10 описывает как синхронизировать часы с использованием NTP.

• MIT и Heimdal успешно взаимодействуют. За исключением kadmin, протокол для которого не стандартизован.

• Если вы изменяете hostname, потребуется также изменить учётную запись host/ и обновить keytab. Это также необходимо для специальных записей в keytab, таких как www/ запись модуля Apache www/mod_auth_kerb.

• Все хосты под общим идентификатором должны разрешаться DNS (прямое и обратное разрешение), или как минимум через /etc/hosts. Записи CNAME будут работать, но записи A и PTR должны быть корректны и находиться на своем месте. Сообщение об ошибке не всегда интуитивно понятно: Kerberos5 refuses authentication because Read req failed: Key table entry not found.

• Некоторые операционные системы, способные работать в качестве клиентов KDC не устанавливают права для ksu в setuid root. Это означает, что ksu не работает, что хорошо является хорошей идеей для безопасности, но неудобно. Это не ошибка KDC.

• С MIT Kerberos, если вы хотите продлить действие доступа до значения большего, чем десять часов по умолчанию, используйте команду modify_principal в kadmin для изменения maxlife доступа к самой учётной записи и к учётной записи krbtgt. Затем возможно использование kinit с параметром -l для запроса доступа с большим временем действия.

•

Замечание: Если вы запускаете перехватчик пакетов на KDC для разрешения проблем, а затем запускаете kinit с рабочей станции, то увидите, что TGT посылается непосредственно при запуске kinit — даже до того, как вы введете пароль! Объяснение в том, что сервер Kerberos свободно распространяет TGT (Ticket Granting Ticket) на каждый неавторизованный запрос; однако, каждый TGT зашифрован ключом, полученным из пароля пользователя. Следовательно, когда пользователь вводит свой пароль, он не отправляется на KDC, а используется для расшифровка TGT, который уже получен kinit. Если в процессе расшифровки получается правильный билет с правильным значением времени, у пользователя есть действующее ''удостоверение''. Это удостоверение содержит ключ сессии для установления безопасного соединения с сервером Kerberos, как и действующий TGT, зашифрованный ключом сервера Kerberos. Второй уровень шифрования недоступен пользователю, но позволяет серверу Kerberos проверять правильность каждого TGT.

• Если вы хотите установить большое время жизни доступа (например, неделю), и используете OpenSSH для соединения с компьютером, где хранится ''билет'', убедитесь, что параметр Kerberos TicketCleanup установлен в no в файле sshd_config, или билеты будут уничтожены при выходе из сеанса.

• Запомните, что время жизни билетов хостов больше. Если время жизни билета для учётной записи пользователя составляет неделю, а время жизни учётной записи хоста, к которому вы подсоединяетесь девять часов, учётная запись хоста в кэше устареет и кэш билетов будет работать не так, как ожидается.

• При настройке файла krb5.dict на предотвращение использования определенных плохих паролей (страница справочника для kadmind кратко рассказывает об этом), запомните, что это применимо только к учётным записям, для которых действует политика паролей. Формат файла krb5.dict прост: одно слово на строку. Может помочь создание символической ссылки на /usr/share/dict/words.