Назад | Перейти на главную страницу

sssd интеграция пароля активного каталога не работает

Мы находимся в процессе настройки 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.