Этот момент нужно уточнить. Нашёл такое объяснение:
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 минут.