Bug 34010
| Summary: | Не подключаются группы Active Directory | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | pavel_sharapov |
| Component: | alterator-auth | Assignee: | qa-team <qa-team> |
| Status: | REOPENED --- | QA Contact: | qa-sisyphus |
| Severity: | normal | ||
| Priority: | P3 | CC: | boyarsh, lav, nfsmobile, pavel_sharapov, sem, sin |
| Version: | unstable | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
Группы появились после выполнения следующих операций: 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 с проверкой дополнительных групп доменного пользователя. |
Description
pavel_sharapov 2017-10-13 17:46:17 MSK