ALT Linux Bugzilla – #34010

Группы появились после выполнения следующих операций:

systemctl stop sssd
sed -i -- 's/\[SUCCESS\=merge\]//g' /etc/nsswitch.conf
rm -f /var/lib/sss/db/*
rm -f /var/lib/sss/mc/*
systemctl start sssd

(В ответ на комментарий №1)
> Группы появились после выполнения следующих операций:
> 
> systemctl stop sssd
> sed -i -- 's/\[SUCCESS\=merge\]//g' /etc/nsswitch.conf
> rm -f /var/lib/sss/db/*
> rm -f /var/lib/sss/mc/*
> systemctl start sssd
Уже нельзя понять, то ли надо было просто
# sss_cache -E
то ли sssd был не запущен.

Но проблемы нет.

(В ответ на комментарий №2)
> (В ответ на комментарий №1)
> > Группы появились после выполнения следующих операций:
> > 
> > systemctl stop sssd
> > sed -i -- 's/\[SUCCESS\=merge\]//g' /etc/nsswitch.conf
> > rm -f /var/lib/sss/db/*
> > rm -f /var/lib/sss/mc/*
> > systemctl start sssd
> Уже нельзя понять, то ли надо было просто
> # sss_cache -E
> то ли sssd был не запущен.
> 
> Но проблемы нет.

sssd включил сразу после ввода в домен командой (как указано в заявке https://bugzilla.altlinux.org/show_bug.cgi?id=34011):

systemctl enable sssd

Затем нужно пару раз перезагрузить компьютер, ну или перезапустить sssd и перелогиниться.
Вывод команды id, когда группы не отваливаются, должен быть таким:

id
uid=xxxxxxxxxx(pavel_sharapov) gid=xxxxxxxxxx(domain users)
группы=xxxxxxxxxx(domain
users),xxxxxxxxxx(ad_group1),xxxxxxxxxx(ad_group2),xxxxxxxxxx(ad_group3),...,14(uucp),19(proc),22(cdrom),71(floppy),80(cdwriter),81(audio),83(radio),100(users),467(fuse),470(video),481(camera),498(xgrp),499(scanner)

Ошибка воспроизводится с учетом комментария 3.

(В ответ на комментарий №4)
> Ошибка воспроизводится с учетом комментария 3.
То есть вы повторили её ещё раз, с чистого листа?

(В ответ на комментарий №5)
> (В ответ на комментарий №4)
> > Ошибка воспроизводится с учетом комментария 3.
> То есть вы повторили её ещё раз, с чистого листа?

Да, сейчас проверил на системе, установленной и обновленной 19.10.2017.

Нужно включить логи и приложить. Желательно статически, чтобы было видно до момента проявления проблемы и после.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html

In versions of SSSD older than 1.8, debug log levels could be set globally in the [sssd] section. Now, each domain and service must configure its own debug log level.

Вариантов в новой версии два:
- указать в каждой секции debug_level = 4
- выполнить sss_debuglevel 4

[root@tor sssd]# cd /var/log/sssd/
[root@tor sssd]# tail -f sssd_
sssd_DARKMASTERSIN.NET.log  sssd_nss.log                sssd_pam.log
[root@tor sssd]# tail -f sssd_DARKMASTERSIN.NET.log 
(Thu Oct 26 06:01:01 2017) [sssd[be[DARKMASTERSIN.NET]]] [handle_getpw_result] (0x0080): User not found.
(Thu Oct 26 07:01:01 2017) [sssd[be[DARKMASTERSIN.NET]]] [handle_getpw_result] (0x0080): User not found.
(Thu Oct 26 08:01:01 2017) [sssd[be[DARKMASTERSIN.NET]]] [handle_getpw_result] (0x0080): User not found.
(Thu Oct 26 09:01:01 2017) [sssd[be[DARKMASTERSIN.NET]]] [handle_getpw_result] (0x0080): User not found.
(Thu Oct 26 10:01:01 2017) [sssd[be[DARKMASTERSIN.NET]]] [handle_getpw_result] (0x0080): User not found.
(Thu Oct 26 11:01:01 2017) [sssd[be[DARKMASTERSIN.NET]]] [handle_getpw_result] (0x0080): User not found.
(Thu Oct 26 12:01:01 2017) [sssd[be[DARKMASTERSIN.NET]]] [handle_getpw_result] (0x0080): User not found.
(Thu Oct 26 12:33:24 2017) [sssd[be[DARKMASTERSIN.NET]]] [get_initgr_groups_process] (0x0100): User [sin] appears to be member of 31 groups
(Thu Oct 26 12:33:30 2017) [sssd[be[DARKMASTERSIN.NET]]] [handle_getpw_result] (0x0080): User not found.
(Thu Oct 26 12:38:09 2017) [sssd[be[DARKMASTERSIN.NET]]] [server_common_rotate_logs] (0x0010): Debug level changed to 0x00f0

^Z
[1]+  Stopped                 tail -f sssd_DARKMASTERSIN.NET.log
[root@tor sssd]# bg
[1]+ tail -f sssd_DARKMASTERSIN.NET.log &
[root@tor sssd]# sss_debuglevel 4
(Thu Oct 26 12:43:50 2017) [sssd[be[DARKMASTERSIN.NET]]] [server_common_rotate_logs] (0x0010): Debug level changed to 0x01f0

Логи можно не делать - я воспроизвёл проблему в сизифе. Действительно - проблема в настройках NSS.

Так не работает:
group: files [SUCCESS=merge] sss role

Так работает:
group: files sss role

Проблема все еще присутствует в p8?

(In reply to comment #9)
> Проблема все еще присутствует в p8?

Группы по-прежнему пропадают, но теперь sssd запускается автоматически, т.е. исправлена проблема 34011.

Установленные пакеты:
alterator-auth-0.35-alt0.M80P.1
task-auth-ad-sssd-0.35-alt0.M80P.1
sssd-pac-1.15.3-alt5.M80P.1.1
sssd-client-1.15.3-alt5.M80P.1.1
sssd-krb5-common-1.15.3-alt5.M80P.1.1
sssd-ad-1.15.3-alt5.M80P.1.1
sssd-1.15.3-alt5.M80P.1.1

(In reply to comment #9)
> Проблема все еще присутствует в p8?

Обновился до сизифа - не помогло

alterator-auth-0.35-alt1

Привет из 2022 alt k10 вводится в домен через alterator, с этим проблем не замечено

(Ответ для Evgeny Sinelnikov на комментарий #8)
> Логи можно не делать - я воспроизвёл проблему в сизифе. Действительно -
> проблема в настройках NSS.
> 
> Так не работает:
> group: files [SUCCESS=merge] sss role
> 
> Так работает:
> group: files sss role

Нужно определится со смыслом этой настройки:
SUCCESS=merge

Результат проверки актуальности

Состояние:
После исходного отчёта SSSD исправил обработку неполных объектов групп, а в 2022 году сообщалось, что на K10 проблема не наблюдается. Однако alterator-auth по-прежнему создаёт правило group: files [SUCCESS=merge] sss role, которое связывали с проявлением ошибки. Доказательств полного исправления нет.

Рекомендация:
Перенести на Sisyphus и выполнить ретест ввода в AD через alterator с проверкой дополнительных групп доменного пользователя.