Как я могу использовать разные принципы kerberos для sudo, чем для system-auth?

В моей организации мы должны использовать разные принципы kerberos при аутентификации для sudo, чем для других типов auth, таких как вход в систему. Например, мой обычный (логин) главный может быть вызван foobar@DOMAIN , тогда как мой главный судья называется foobar/sudo@DOMAIN . В прошлом мы выполнили это требование, построив свое собственное sudo с --with-kerb5 и --enable-kerb5-instance=sudo установленными во время сборки. Это означает, что наша версия sudo подключается непосредственно к kerberos, никогда не используя PAM-стек вообще.

Мы пытаемся понять, можем ли мы удовлетворить требование разделения глав, не строя и не распределяя нашу собственную сборку sudo. Мой вопрос: возможно ли это, и если да, то как?

Используя стандартный пакет RHEL 6/7 sudo, я не могу использовать --with-kerb5 build-time; Я должен использовать PAM в качестве стека аутентификации. Это означает, что я должен использовать pam_krb5 . С pam_krb5 я заметил, что я могу сопоставить имена пользователей с именами /etc/krb5.conf в /etc/krb5.conf используя appdefaults/pam/mappings . Это помогает мне частично, так как это позволяет мне сопоставить имя пользователя foobar с основным именем foobar/sudo . Однако из того, что я могу сказать, нет способа установить сопоставления для каждого приложения (kerberos рассматривает PAM как одно приложение, независимо от того, какое приложение вызывает стек PAM), что означает, что сопоставление применяется к любым приложениям, которые используют pam_krb5 в своей конфигурации PAM , Поэтому я могу заставить систему использовать принципы sudo для sudo и login, или для логинов для обоих, но я не могу заставить систему использовать принципы sudo для участников sudo и login для входа.

Есть идеи? Или я застрял с необходимостью строить и распространять пользовательские sudo?

One Solution collect form web for “Как я могу использовать разные принципы kerberos для sudo, чем для system-auth?”

Это не полный ответ, но мне интересно, можно ли это сделать с помощью SSSD.

Модуль pam_sss позволяет ограничить службу только рассмотрением отдельных доменов в /etc/sssd/sssd.conf . Из pam_sss(8) :

домены

Позволяет администратору ограничивать домены, для которых определенная служба PAM разрешена для проверки подлинности. Формат представляет собой список доменных имен SSSD, разделенный запятыми, как указано в файле sssd.conf.

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

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

Обновить

Также похоже, что более поздние версии модуля pam_krb5 поддерживают параметр alt_auth_map который делает именно то , что вы хотите. То есть, в /etc/pam.d/sudo , я могу сделать это:

 auth required pam_krb5.so alt_auth_map=%s/sudo only_alt_auth 

… и теперь sudo всегда будет использовать принцип <username>/sudo для аутентификации.

Эта версия pam-krb5 распространяется с Ubuntu, но, предположительно, можно построить rpm и установить ее на свои системы без лишней суеты.

  • / etc / sudoers vs /etc/sudoers.d/ для включения sudo для пользователя
  • Может sudo заменить su?
  • как требовать sudo для просмотра файлов?
  • как выполнять административные команды без sudo?
  • Как я могу «alias sudo !!»?
  • ssh master - выполнить su удаленно
  • Не удалось запустить команду sudo на linux
  • Установка пароля root и sudo -i
  • «Команда не найдена», когда функция sudo'ing от ~ / .zshrc
  • Sudo mkdir не удается из-за разрешения отклонить ошибку
  • Проблема с BASH dd
  • Interesting Posts
    Linux и Unix - лучшая ОС в мире.