Bug 41174

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

Примечание: на этом же клиенте вход пользователя, который не добавлен в такое количество групп, выполняется успешно.