sssd_be завершается по SIGSEGV при обработке групповой политики, у которой пусты атрибуты gPCMachineExtensionNames/gPCUserExtensionNames. Именно так GPO выглядит в LDAP сразу после создания через `samba-tool gpo create` (CSE-атрибуты проставляет уже редактор политик, admc/gpui).

Стенд (клоны шаблонов poligon, dist-upgrade 2026-09-17, x86_64):
- DC: клон 3125 (sisyphus-server, textmode), samba-dc-4.22.11-alt3, домен TEST.ALT
  (`samba-tool domain provision --realm=TEST.ALT --dns-backend=SAMBA_INTERNAL --server-role=dc --use-rfc2307`,
  уровень леса/домена 2008 R2).
- Клиент: клон 3138 (sisyphus-workstation), сеанс MATE (mate-default-1.26.0-alt3), вход через lightdm;
  sssd-2.12.0-alt1 (sssd-ad-2.12.0-alt1), samba-client-4.22.11-alt3, gpupdate-0.16.3-alt1.
  Ввод в домен: `system-auth write ad TEST.ALT client TEST administrator '<пароль>'`, `net ads testjoin` -> Join is OK.

Шаги:
1. На DC создать и привязать политику штатными средствами samba:

    samba-tool gpo create 'gp-test' -U administrator
    samba-tool gpo setlink 'DC=test,DC=alt' '{GUID}' -U administrator

   У созданного так объекта в LDAP gPCMachineExtensionNames и gPCUserExtensionNames пусты.
2. На клиенте выполнить вход доменным пользователем (обработка GPO провайдером ad в sssd_be).

Фактический результат: sssd_be падает с SIGSEGV (segfault виден в `journalctl -k`), обработка политик не доходит до конца.

Проверка от противного: после того как тому же GPO в LDAP были проставлены CSE-GUID реестрового расширения

    gPCMachineExtensionNames: [{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{D02B1F72-3407-48AE-BA88-E8213C6761F1}]

падения прекратились. Клиент, DC и сценарий входа при этом не менялись — отличается только этот атрибут.

Ожидаемый результат: GPO без CSE-атрибутов игнорируется или обрабатывается как пустой (в худшем случае с диагностикой в журнале), sssd_be не падает. Падение бэкенда ломает разрешение имён и доменную аутентификацию до его перезапуска, и достаточно одной политики, созданной из командной строки, чтобы это получить.

Оговорка о полноте данных: находка попутная (ретест багов gpupdate), стенд уже удалён — backtrace sssd_be и точная строка `kernel: sssd_be[...]: segfault at ...` не сохранены, есть только наблюдавшийся факт падения и то, что оно ушло после простановки CSE. Готов поднять стенд и снять core/backtrace, если это нужно для разбора.

Апстрим: точного тикета про падение не нашёл. Ближайшее по условию — https://pagure.io/SSSD/sssd/issue/3114 (gPCMachineExtensionNames без GUID ломает обработку GPO, там речь о сбое разбора, не о SIGSEGV); отдельно есть https://github.com/SSSD/sssd/issues/6790 (SIGSEGV, но в gpo_child и по другой причине) и https://github.com/SSSD/sssd/pull/844 (исправления обработки GPO, созданных Samba DC).