Настройка Sudo с использованием SSSD
Попытка войти в системы Linux, используя учетную запись Windows AD. Сконфигурировано успешно с использованием SSSD.
Использовал LDAP в качестве провайдеров идентификации и доступа и Kerberos в качестве провайдера аутентификации.
Я сделал все это без присоединения систем Linux к домену.
Сейчас я пытаюсь настроить LDAP в качестве поставщика sudo. Но это не удачно. Я не могу повысить разрешения sudo для пользователей рекламы. Я даже пытался использовать файл sudoers, там я могу повысить разрешения для конкретного пользователя, но не для группы объявлений.
Вот конфигурация SSSD в конфигурации sudo
**sudo_provider = ldap
ldap_sudo_search_base = ou=groups,dc=ad,dc=example,dc=com
ldap_sudorule_object_class = sudoRole
ldap_sudorule_object_class = top
ldap_sudorule_command = ALL
ldap_sudorule_host = ALL
ldap_sudorule_user = %domain_group
ldap_sudorule_runasuser = ALL
ldap_sudorule_runas = ALL
ldap_sudorule_runasgroup = ALL
ldap_sudorule_option = !authenticate**
Я попытался включить ведение журнала на уровне отладки 7, упомянув, что не удалось загрузить локальные правила.
С уважением, Удай.
1 ответ
Я думаю, что вы неправильно поняли назначение переключателей конфигурационного файла - они служат для отображения значений LDAP запрашиваемых объектов. В директивах по умолчанию используются значения, указанные в классе вспомогательных объектов (схема находится в /usr/share/doc/sudo-*/schema.ActiveDirectory в CentOS).
Предполагается, что вы импортируете эту схему в свою AD, создадите объекты, представляющие роли sudo, используя этот класс объектов, и получите SSSD-запрос к ним.
Найдите исчерпывающий пример ниже:
Вот пример конфигурации SSSD, запрашивающей пользователей, группы и роли sudo из LDAP. Замените <> прилагаемые детали значениями, соответствующими вашей среде:
[domain/default]
id_provider = ldap
auth_provider = ldap
access_provider = ldap
chpass_provider = ldap
sudo_provider = ldap
ldap_uri = ldaps://<ldap-server-address>:636
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
ldap_tls_reqcert = demand
ldap_default_bind_dn = <proxy-user-dn>
ldap_default_authtok_type = obfuscated_password
ldap_default_authtok = <obfuscated password>
ldap_search_base = <search base for users>
ldap_schema = rfc2307bis
ldap_group_search_base = <search base for groups>
ldap_sudo_search_base = <search base for sudo rules>
cache_credentials = false
enumerate = false
[sssd]
services = nss, pam, ssh, sudo
config_file_version = 2
domains = default
[nss]
[pam]
[sudo]
[autofs]
[ssh]
В вашем каталоге LDAP создайте объект ниже ldap_sudo_search_base выглядит примерно так:
objectClass: Top
objectClass: sudoRole
sudoRunAsUser: ALL
sudoHost: yourhost.example.com
sudoUser: %wheel
sudoCommand: ALL
description: Allows members of wheel to become root
cn: wheel_group_sudo_role
Это позволяет всем членам группового колеса стать пользователем root на хосте yourhost.example.com.
Бег sudo -U testuser -ll как root на целевом хосте должен дать:
LDAP Role: wheel_group_sudo_role
RunAsUsers: ALL
RunAsGroups: ALL
Commands:
ALL
редактировать:
Как вы уже поняли, поскольку SSSD предоставляет пользователей для Linux, вы можете рассматривать их как обычных пользователей Linux и, таким образом, создавать локальное правило sudo:
/etc/sudoers.d/00-local-admin-rule
%ad-admin-group ALL: (ALL) ALL
Это позволяет членам ad-admin-group вызвать sudo, чтобы стать пользователем root.
Когда говорим о *_search_baseподразумевается DN некоторой формы объекта-контейнера LDAP, например, организационная единица, такая как ou = users, o = corg, dc = example, dc = org или любая другая иерархия, имеющаяся в вашем каталоге. Создайте объекты нужных типов ниже указанного контейнера.