Как я могу использовать разные принципы 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 и установить ее на свои системы без лишней суеты.

  • Безопасный способ разрешить любому пользователю запускать программы в определенном сетевом пространстве имен
  • выполнить команду с помощью sudo и выполнить скрипт Bash с помощью sudo
  • Запустить bash-скрипт с sudo, некоторые команды в качестве обычного пользователя
  • Отрицательные / недопустимые настройки Ubuntu без полномочий root sudo
  • вставить текст в файл с помощью команды echo
  • zsh хочет исправить vim для .vim
  • rsync как другой пользователь
  • Нет действительных источников судопроизводства
  • Команда, чтобы заставить пользователя вводить пароль - RHEL / Centos
  • Как я могу поместить пользователя в файл суперпользователей?
  • ssh с -Y приводит к «shell-init: ошибка получения текущего каталога: getcwd: невозможно получить доступ к родительским каталогам ...»
  • Linux и Unix - лучшая ОС в мире.