Мы находимся в процессе настройки sssd для использования с активным каталогом, используя конфигурацию ниже.
Мы не используем сопоставление атрибутов, так как хотим использовать атрибуты, определенные в объектах AD ldap, такие как пользовательский uid, unixHomeDirectory, открытые ключи и т. Д.
sssd.conf:
[sssd]
domains = company.domain
config_file_version = 2
services = nss, pam, sudo, ssh
debug_level = 6
[domain/sew.online]
ad_hostname = EXAMPLESERVER01 #This is templated using ansible
ad_domain = company.domain
krb5_realm = COMPANY.DOMAIN
krb5_store_password_if_offline = true
use_fully_qualified_names = false
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad
lookup_family_order = ipv4_only
cache_credentials = true
dns_discovery_domain = {{ prod_domain_name }}
create_homedir = true
auto_private_groups = true
ad_gpo_access_control = permissive
ad_gpo_cache_timeout = 30
ad_site = SITENAME
case_sensitive = false
enumerate = false
default_shell = /bin/bash
ldap_schema = ad
ldap_id_mapping = False
ldap_user_shell = loginShell
ldap_user_principal = samAccountName
ldap_user_ssh_public_key = altSecurityIdentities
ldap_user_home_directory = unixHomeDirectory
fallback_homedir = /home/%u
ldap_force_upper_case_realm = true
ldap_purge_cache_timeout = 0
ldap_account_expire_policy = ad
ldap_group_search_base = DN=etc...
ldap_user_search_base = DN=etc...
debug_level = 6
[nss]
fallback_homedir = /home/%u
reconnection_retries = 3
debug_level = 6
[pam]
offline_credentials_expiration = 3
offline_failed_login_attempts = 10
offline_failed_login_delay = 30
pam_verbosity = 3
pam_id_timeout = 10
pam_pwd_expiration_warning = 30
reconnection_retries = 3
debug_level = 6
krb5.conf
[logging]
default = FILE:/var/log/krb5libs.log
[libdefaults]
default_realm = COMPANY.DOMAIN
ticket_lifetime = 1d
renew_lifetime = 7d
dns_lookup_realm = true
dns_lookup_kdc = true
rdns = false
allow_weak_crypto = false
permitted_enctypes = aes256-cts-hmac-sha1-96
default_tkt_enctypes = aes256-cts
default_tgs_enctypes = aes256-cts
kdc_timesync = 1
kdc_timeout = 3000
forwardable = true
renewable = true
proxiable = true
udp_preference_limit = 1
rnds = false
Вот pastebin различных файлов журнала sssd: https://pastebin.com/2P58uybg
Журналы показывают, что пользователь домена, который уже успешно вошел в систему (через sshd и аутентификацию с открытым ключом), пытается запустить sudo bash
Помимо паролей, интеграция с рекламой работает по желанию:
В качестве шага по устранению неполадок я настроил LDAPS на контроллерах домена с внутренним доверенным сертификатом, добавленным в хранилище ca ubuntu.
Я просмотрел журналы sudo (очень подробные), и они показывают, что группа успешно сопоставлена и позволяет пользователю sudo.
Любая помощь приветствуется.
Редактировать:
ОС хоста: Ubuntu 18.04
nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: compat systemd sss
group: compat systemd sss
shadow: compat sss
gshadow: files
hosts: files dns
networks: files
protocols: db files
services: db files sss
ethers: db files
rpc: db files
netgroup: nis sss
sudoers: files sss
Установленные пакеты для роли ansible:
Глядя на предоставленную конфигурацию, sssd пытается получить правила sudo из LDAP / AD, но, похоже, не получает никаких соответствующих записей.
13:38:35 [sssd[sudo]] [sudosrv_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=example_user@company.domain)(sudoUser=#1010101)(sudoUser=%example_leadership@company.domain)(sudoUser=%acl_win_admins@company.domain)(sudoUser=%example_team@company.domain)(sudoUser=%meta_managed_by_ansible@company.domain)(sudoUser=%example_web@company.domain)(sudoUser=%example_ols@company.domain)(sudoUser=%acl_jump_access@company.domain)))]
13:38:35 [sssd[sudo]] [sudosrv_fetch_rules] (0x0400): Returning 0 rules for [example_user@company.domain@company.domain]
В руководстве по устранению неполадок Ubuntu sssd sudo содержится несколько советов о том, как проверить запрос правил sudo. https://docs.pagure.org/SSSD.sssd/users/sudo_troubleshooting.html#what-to-look-for-in-the-logs
Похоже, в вашей конфигурации отсутствуют соответствующие разделы для настройки деталей ldap для правил sudo. Начиная с версии sssd 1.11.5, должна быть возможность использовать sssd_provider = ad
.
https://pagure.io/SSSD/sssd/issue/2256
На последних страницах руководства указано: https://linux.die.net/man/5/sssd.conf
sudo_provider (string)
Default: The value of "id_provider" is used if it is set.
"none" disables SUDO explicitly.
Если ваша используемая версия sssd достаточно новая, ее следует настроить для sudo_provider=ad
.
Согласно Ubuntu sssd версии 1.16, кажется, что параметры взяты из параметров sssd-ldap при использовании объявления в качестве поставщика sudo: https://github.com/SSSD/sssd/blob/sssd-1_16_4/src/providers/ad/ad_sudo.c#L49
ad_options->id->sudorule_map = ldap_options->sudorule_map;
Должна применяться приведенная выше документация для карт правил sudo со страницы руководства sssd-sudo: https://linux.die.net/man/5/sssd-sudo
Предлагаем установить: ldap_sudo_search_base =
в соответствии с вашими потребностями.
Если вы хотите использовать файловую систему sudo, предложите попробовать отключить провайдера, используя: sudo_provider=none
Кроме того, было бы хорошо явно отключить поиск sssd в /etc/nssswitch.conf
добавление / изменение строки sudoers: files
.