Назад | Перейти на главную страницу

Автоматическое продление билета Kerberos (бессрочно)

В настоящее время я переключаю нашу среду с NIS на Kerberos + LDAP.

Во время этого перехода я столкнулся со следующей ситуацией.

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

Как мне лучше всего автоматически продлевать эти билеты для пользователей?

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

Конец 2018 года, и я столкнулся с тем же вопросом, что и вы. После некоторого раскопок я могу предложить рецензию на потомство.

tl; доктор:

  • «Бесконечное обновление» невозможно и, вероятно, никогда не будет
  • SSSD продлит билеты, если вы войдете в систему с паролями
  • SSSD обновит все билеты в какой-то момент в будущем

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

При этом вы не должны. Скорее всего, вы используете «Демон служб безопасности системы» или SSSD. Если вы это сделаете, вы можете использовать встроенные параметры продления krb5_renew_interval и krb5_renewable_lifetime для автоматического продления билетов пользователей:

[domain/yourdomain.example.com]
krb5_renewable_lifetime = 90d
krb5_renew_interval = 500

Вы можете заглянуть в man 5 sssd-krb5 для подробностей. С этими настройками SSSD будет запрашивать возобновляемые билеты (максимальный срок действия 90 дней) при каждом входе в систему * и каждые 500 секунд просматривать список билетов * и обновлять существующие билеты, которые можно продлить.

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

*) Пока все замечательно. К сожалению, здесь есть несколько ошибок.

В то время, когда я пишу это, SSSD может продлевать только те билеты, которые он сам просил. Это все логины, которые проходят через pam_sss Модуль PAM, например (но не ограничиваясь этим):

  • Набор текста su $USER на вашем терминале
  • Вход в вашу систему через графическую оболочку
  • Разблокировка экрана через графическую оболочку
  • Вход через SSH с помощью PasswordAuthentication метод.

Что заметно не хватает в этом списке:

  • Бег kinit
  • Вход через SSH с помощью PubkeyAuthentication метод.
  • Вход через SSH с помощью GSSAPIAuthentication метод.
  • Вход через SSH, пока GSSAPIDelegateCredentials опция включена.

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

Однако это может стать немного проще.

SSSD теперь предоставляет «диспетчер кеша Kerberos», KCM, который называется sssd-kcm. По сути, это небольшой сервер, на котором будут храниться билеты (KCM: когда ты бежишь klist) вместо связки ключей ядра (KEYRING: когда ты бежишь klist) или файл в / tmp (FILE: когда ты бежишь klist).

Надеюсь, что в какой-то момент в будущем SSSD сможет продлить все билеты (а не только те, которые он запрашивал сам), когда sssd-kcm реализует продление билетов. Этого еще не произошло и отслеживается в Выпуск 1723 на трекере ошибок SSSD.

Если вы используете систему на основе Red Hat (RHEL, CentOS, Fedora), то SSHD также необходимо научиться уважать выбранный механизм создания кеша. Это отслеживается в выпуск 1639376 на багтрекере Red Hat.

Быстрый поиск в Google дает мне эта тема

Если вы настаиваете на постоянном использовании, вы можете запустить задание cron, которое будет периодически получать новый билет (используя kinit).