Попытка войти в систему 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, упомянув, что не удалось загрузить локальные правила.
С уважением, Удай.
Я думаю, вы неправильно поняли назначение переключателей файла конфигурации - они служат для сопоставления значений 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
Это позволяет всем членам группы wheel стать 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 или любая другая иерархия, которую имеет ваш каталог. Создайте объекты желаемых типов ниже указанного контейнера.