Created attachment 9850 [details] sssd logs Конфигурация стендов: 1. dc.samba.testdomain (p10 server x86_64) - SambaDC 2. Клиент на Alt Linux desktop (p10 workstation x86_64), введенный в домен samba-4.14.7-alt3 1) Создано 100 пользователей, 3000+ групп с именем по 200 символов (латинские буквы). Каждый пользователь добавился в каждую группу. 2) Попытка входа на клиенте. Результат: вход невозможен. Ожидаемый результат: успешный вход. Дополнительно: во время создания групп периодически проверяла вход. На ~2200 группах вход еще был возможен.
Этот момент нужно уточнить. Нашёл такое объяснение: https://windowsnotes.ru/activedirectory/maksimalnye-ogranicheniya-active-directory/ "Ограничение на членство в группах Каждый из субъектов безопасности (пользователей, компьютеров или групп) может быть членом не более чем 1015 групп, вне зависимости от их вложенности. Это связано с ограничением на размер токена доступа, который создается для каждого субъекта безопасности." В оригинальной документации такого с ходу не нашёл: Active Directory Maximum Limits - Scalability https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc756101(v=ws.10) Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2
Нужно детально подойти к вопросу разбора ограничений: - где, конкретно, мы упёрлись в узкое горлышко? - при каких обстоятельствах это произошло? - не повлияло ли, например, тут ограничение на общее количество объектов безопасности? - не оказалось ли тут проблемы ограничений количество доступных связей при отображении SID'ов на UID'ы и GID'ы (ipmapping)? Похоже, что дело в структурах Kerberos на уровне SSSD: * (2021-10-20 9:58:54): [pam] [cache_req_search_domains] (0x0400): CR #1: Search will bypass the cache and check the data provider * (2021-10-20 9:58:54): [pam] [cache_req_validate_domain_type] (0x2000): Request type POSIX-only for domain SAMBA.TESTDOMAIN type POSIX is valid * (2021-10-20 9:58:54): [pam] [cache_req_set_domain] (0x0400): CR #1: Using domain [SAMBA.TESTDOMAIN] * (2021-10-20 9:58:54): [pam] [cache_req_prepare_domain_data] (0x0400): CR #1: Preparing input data for domain [SAMBA.TESTDOMAIN] rules * (2021-10-20 9:58:54): [pam] [cache_req_search_send] (0x0400): CR #1: Looking up test5522@samba.testdomain * (2021-10-20 9:58:54): [pam] [cache_req_search_ncache] (0x0400): CR #1: Checking negative cache for [test5522@samba.testdomain] * (2021-10-20 9:58:54): [pam] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/SAMBA.TESTDOMAIN/test5522@samba.testdomain] * (2021-10-20 9:58:54): [pam] [cache_req_search_ncache] (0x0400): CR #1: [test5522@samba.testdomain] is not present in negative cache * (2021-10-20 9:58:54): [pam] [cache_req_search_dp] (0x0400): CR #1: Looking up [test5522@samba.testdomain] in data provider * (2021-10-20 9:58:54): [pam] [sss_dp_get_account_send] (0x0400): Creating request for [SAMBA.TESTDOMAIN][0x3][BE_REQ_INITGROUPS][name=test5522@samba.testdomain:-] * (2021-10-20 9:59:11): [pam] [sbus_dispatch_reconnect] (0x0400): Connection lost. Terminating active requests. * (2021-10-20 9:59:11): [pam] [cache_req_common_process_dp_reply] (0x0040): CR #1: Could not get account info [1432158213]: Terminated ********************** BACKTRACE DUMP ENDS HERE ********************************* (2021-10-20 9:59:11): [pam] [pam_dp_send_req_done] (0x0020): PAM handler failed [1432158212]: SSSD is offline ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: * (2021-10-20 9:59:11): [pam] [cache_req_common_process_dp_reply] (0x0400): CR #1: Due to an error we will return cached data * (2021-10-20 9:59:11): [pam] [sss_domain_get_state] (0x1000): Domain SAMBA.TESTDOMAIN is Active * (2021-10-20 9:59:11): [pam] [cache_req_search_cache] (0x0400): CR #1: Looking up [test5522@samba.testdomain] in cache * (2021-10-20 9:59:11): [pam] [cache_req_search_ncache_filter] (0x0400): CR #1: This request type does not support filtering result by negative cache * (2021-10-20 9:59:11): [pam] [cache_req_search_done] (0x0400): CR #1: Returning updated object [test5522@samba.testdomain] * (2021-10-20 9:59:11): [pam] [cache_req_create_and_add_result] (0x0400): CR #1: Found 2176 entries in domain SAMBA.TESTDOMAIN * (2021-10-20 9:59:11): [pam] [cache_req_done] (0x0400): CR #1: Finished: Success * (2021-10-20 9:59:11): [pam] [pd_set_primary_name] (0x0400): User's primary name is test5522@samba.testdomain * (2021-10-20 9:59:11): [pam] [pam_initgr_check_timeout] (0x4000): User [test5522] not found in PAM cache. * (2021-10-20 9:59:11): [pam] [pam_initgr_cache_set] (0x2000): [test5522] added to PAM initgroup cache * (2021-10-20 9:59:11): [pam] [pam_dp_send_req] (0x0100): Sending request [CID #1] with the following data: * (2021-10-20 9:59:11): [pam] [pam_print_data] (0x0100): [CID #1] command: SSS_PAM_AUTHENTICATE * (2021-10-20 9:59:11): [pam] [pam_print_data] (0x0100): [CID #1] domain: SAMBA.TESTDOMAIN * (2021-10-20 9:59:11): [pam] [pam_print_data] (0x0100): [CID #1] user: test5522@samba.testdomain * (2021-10-20 9:59:11): [pam] [pam_print_data] (0x0100): [CID #1] service: lightdm * (2021-10-20 9:59:11): [pam] [pam_print_data] (0x0100): [CID #1] tty: :0 * (2021-10-20 9:59:11): [pam] [pam_print_data] (0x0100): [CID #1] ruser: not set * (2021-10-20 9:59:11): [pam] [pam_print_data] (0x0100): [CID #1] rhost: not set * (2021-10-20 9:59:11): [pam] [pam_print_data] (0x0100): [CID #1] authtok type: 1 (Password) * (2021-10-20 9:59:11): [pam] [pam_print_data] (0x0100): [CID #1] newauthtok type: 0 (No authentication token available) * (2021-10-20 9:59:11): [pam] [pam_print_data] (0x0100): [CID #1] priv: 1 * (2021-10-20 9:59:11): [pam] [pam_print_data] (0x0100): [CID #1] cli_pid: 3660 * (2021-10-20 9:59:11): [pam] [pam_print_data] (0x0100): [CID #1] logon name: test5522 * (2021-10-20 9:59:11): [pam] [pam_print_data] (0x0100): [CID #1] flags: 0 * (2021-10-20 9:59:11): [pam] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 * (2021-10-20 9:59:11): [pam] [pam_dp_send_req_done] (0x0020): PAM handler failed [1432158212]: SSSD is offline ********************** BACKTRACE DUMP ENDS HERE *********************************
Немаловажный вопрос: "Откуда пришла задача - добавить пользователя в более, чем 3000 групп беопасности?" Тут нужно понимать, что часть из этих групп (в виде 128-битных SID'ов) прилетает в Kerberos-токене, у которого есть ограничение на размер этого блока. https://docs.microsoft.com/ru-ru/windows/security/identity-protection/access-control/active-directory-security-groups Group scope https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc755692(v=ws.10)?redirectedfrom=MSDN https://social.technet.microsoft.com/Forums/ru-RU/a9e67621-0b4e-4a46-8a1d-50f5a3d4f146/104310881091108710871099-1074-ad?forum=windowsserverru "Там использован довольно сложный язык. Вкратце: - Используйте глобальные группы для объединения пользователей по функциональному или географическому признаку (Менеджеры, Операторы, Бухгалтеры или Работники Рижского отделения компании, Сотрудники Третьего Этажа и т.п.) - Используйте локальные группы для назначения доступа к ресурсам (Пользователи Базы 1С, Принтер HPLJ2600, Общие Документы Бухгалтерии) - Добавляйте глобальные группы в локальные, выражая нужды простым человеческим языком: "Хочу, чтобы Менеджеры имели доступ к Базе 1С". - Используйте универсальные группы, когда нужно дать доступ Множеству пользователей из Множества доменов к Множеству ресурсов, расположенных в Многих доменах. MCITP: Enterprise Administrator; MCT; Microsoft Security Trusted Advisor; CCNA; CCSI" "Локальная в домене это группа для предоставления доступа к ресурсам текущего домена. в нее входят юзеры и компьютеры как текущего домена, так и леса. Глобальная группа - это для предоставления к ресурсам не только домена но и леса. в нее входят только пользователи и компьютеры того домена где расположен каталог." "Золотые правила" применения групп https://www.osp.ru/winitpro/2007/02/4236796 "* Глобальная группа может быть членом другой глобальной группы, универсальной группы или локальной группы домена. * Универсальная группа может быть членом другой универсальной группы или локальной группы домена, но не может быть членом глобальной группы. * Локальная группа домена может быть членом только другой локальной группы домена."
Технически подробности в плане Kerberos: Проблемы с проверкой подлинности Kerberos, когда пользователь принадлежит к многим группам: https://docs.microsoft.com/ru-ru/troubleshoot/windows-server/windows-security/kerberos-authentication-problems-if-user-belongs-to-groups Для большинства реализаций должно быть достаточно значения в MaxTokenSize 48 000 bytes. Это значение по умолчанию в Windows Server 2012 и более поздних версиях. Однако, если вы решите использовать большее значение, просмотрите известные проблемы в этом разделе. Ограничение размера в 1010 групповых SID для маркера доступа к LSA Поэтому, чтобы не забивать PAC-поле билета TGT, массово стоит добавлять пользователей в группы безопасности домена: http://itband.ru/2010/09/ad-answers/ "Для построения маркера (для заполнения PAC-поля билета TGT в случае аутентификации Kerberos) используются данные из КЭШа (Universal Group Membership Caching - UGMC). Поэтому если вы, добавите пользователя в глобальную или универсальную группу из того же домена, то эти данные запишутся в БД на DC, далее они должны будут реплицироваться на GC, а потом с этого GC будет произведено обновления КЭШа (в соответствии с периодичностью обновления и расписанием репликации). Только после этого эти данные попадут в маркер пользователя (во время входа или обновления билета- TGT)." Исторический контекст: https://www.atraining.ru/groups-windows-nt-active-directory-explained/ Некоторые детали по-русски и с картинками: http://pyatilistnik.org/maxtokensize-and-kerberos-token-size-settings/ "Расчет размера токена Kerberos Существует математическая формула для расчета значения токена для пользователя: Microsoft документирует его в этой статье (https://support.microsoft.com/fr-fr/help/327825/problems-with-kerberos-authentication-when-a-user-belongs-to-many-grou), и мы можем взять его здесь: TokenSize = 1200 байт + (40 байт X d ) + (8 байт X s ) d : Представляет количество локальных групп, к которым принадлежит пользователь + количество универсальных групп вне домена учетной записи пользователя + количество групп, представленных в истории SID. s : представляет количество глобальных групп, к которым принадлежит пользователь + количество универсальных групп в домене учетной записи пользователя. 1200: представляет приблизительное значение для остальной части билета. Это значение может варьироваться в зависимости от таких факторов, как длина доменного имени DNS, имя клиента и другие факторы."
Давайте в итоге решим, корректен ли тест на 3000+ групп? В comment#1 предлагается цифра 1015. Если нет возражений, скорректируем нагрузочный тест на эту цифру.
(Ответ для Vera Blagoveschenskaya на комментарий #5) > Давайте в итоге решим, корректен ли тест на 3000+ групп? Он с самого начала некорректен для групп безопасности. > В comment#1 предлагается цифра 1015. > Если нет возражений, скорректируем нагрузочный тест на эту цифру. Я бы предложил забивать пользователей в 1500 локальных доменных групп и в 1000 доменных групп безопасности. Итого, было бы 2500 групп, из которых в ткоене прилетает не выходящее за пределы 1015 групп значение. Тогда нагрузка была бы более полной.
Created attachment 12644 [details] sssd-logs.txt (Ответ для Evgeny Sinelnikov на комментарий #6) > Я бы предложил забивать пользователей в 1500 локальных доменных групп и в > 1000 доменных групп безопасности. Итого, было бы 2500 групп, из которых в > ткоене прилетает не выходящее за пределы 1015 групп значение. > > Тогда нагрузка была бы более полной. Добавил пользователя в 1500 локальных групп и 1000 групп безопасности. Результат не изменился, вход пользователя в систему невозможен. Логи sssd (debug_level = 9) во вложении. Примечание: на этом же клиенте вход пользователя, который не добавлен в такое количество групп, выполняется успешно.
Ошибка актуальна для p11 (проверялось с версией samba 4.21.7-alt1 из задания 387440). Некоторые системы входят в сессию, но с переменным успехом. Подробнее: * На всех клиентах ожидание несколько секунд после ввода имени пользователя до появления поля ввода пароля. * После ввода пароля: ** KDE: Workstation K, Education (KDE): чёрный экран с символом нижнего подчёркивания (аналогично https://bugzilla.altlinux.org/55210), через пару минут возвращается на экран ввода имени пользователя. ** XFCE: Education (XFCE): отображается только фон экрана входа в течение ~10 минут, затем успешно входит в сессию. ** GNOME: Workstation: ожидание > 10 секунд после ввода пароля, после чего возвращается на экран ввода пароля, или отображается сообщение "org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application [...]" и зависает на пустом сером экране, или (после ожидания в несколько минут с таким сообщением) входит в сессию, однако не отображает никаких приложений (см. скриншот workstation). * Подключение ко всем системам по SSH может занимать > 10 секунд, в зависимости от состояния. Дополнительно: Eсли попробовать войти пользователем на машине с Windows, то вход невозможен, но отображается сообщение "При попытке входа в систему контекст безопасности пользователя накопил слишком много идентификаторов безопасности." и система не зависает.
Created attachment 19100 [details] workstation.png
Created attachment 19101 [details] journalctls.tar.xz
Результат проверки актуальности Состояние: Подтверждено на p11 15.07.2025 (samba 4.21.7-alt1). Сейчас samba 4.21.9-alt3.p11.1 / 4.22.11-alt3. В changelog samba и sssd исправления нет. Рекомендация: оставить открытым.
На p11 вход теперь возможен, но первый вход очень медленный. Пользователь в 1500 локальных и 1000 глобальных группах, DC Samba 4.21.9, клиент Рабочая станция K p11 (sssd 2.9.8-alt3): kinit работает (ccache 9,8 КБ); первый вход по ssh с паролем — успех за 280 с, id показывает 2519 групп; повторный вход — 8 с, id без кэша (sss_cache -E) — 24 с. Графический вход не проверял: экран входа может не дождаться 4,5 минут.
