Bug 45374 - Machine Password 30 day mismatch
Summary: Machine Password 30 day mismatch
Status: NEW
Alias: None
Product: Sisyphus
Classification: Development
Component: sssd-ad (show other bugs)
Version: unstable
Hardware: x86 Linux
: P5 critical
Assignee: Evgeny Sinelnikov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-02-22 16:03 MSK by Евгений
Modified: 2023-05-25 18:03 MSK (History)
7 users (show)

See Also:


Attachments
Переключение sssd в привилегированный режим (91.42 KB, image/png)
2023-05-25 18:03 MSK, Evgeny Sinelnikov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Евгений 2023-02-22 16:03:13 MSK
Добрый день
Мат часть проблематики не соответствия:
https://adsecurity.org/?p=280

Фактическая проблема.
В ревизии альт рабочая станция 10, когда механизм сссд пытается обновить пароль арм, он отправляет новый пароль на сервер КД АД, при этом у себя оставляя старый пароль. Далее при очередной сверке хеша, получают разные значения и арм автоматически исключается из среды ад. Либо меняет только у себя, не отправляя данные на КД.

Вот пример с тестовой машины выпавшей из домена.
МД4 хеш:
На АРМ:        069dcbd3adf4a633891a0139a9494913
В AD:             70a04beada1fb594b4c070a19e29a286

У АРМ не выпавшей из домена хеш сходятся 
У клиентов ввиду этой "особенности"  каждые 30 дней приходится пере вводить арм в домен.
Comment 1 Евгений 2023-02-22 17:11:30 MSK
Дополню, что если в конфиг дописать password age =0
то вылета из домена не происходит
Comment 2 Evgeny Sinelnikov 2023-02-27 16:07:21 MSK
Кроме опций разрешающих конфликт между winbind и sssd:
https://git.altlinux.org/gears/a/alterator-auth.git?p=alterator-auth.git;a=commitdiff;h=6998fb705c666636de5ac9f8e94a73159cd151d0

Основное текущее подозрение в том, что adcli, который использует sssd для смены пароля машины, запускается без необходимого набора привелегий - не из-под рута. В итоге, сменить пароль машины на сервере прав хватает, а обновить файлы с паролем на хосте - уже нет.

Предварительное решение - запускать sssd из-под рута.

Для решения этой задачи имеется инструмент:

# grep user /etc/sssd/sssd.conf
user = _sssd

# control sssd-drop-privileges
unprivileged

# control sssd-drop-privileges help
unprivileged: SSSD running from unprivileged user (as the _sssd user)
privileged: SSSD running from privileged user (as the root user)
default: SSSD running from default user (different in various versions)

# control sssd-drop-privileges privileged

# grep user /etc/sssd/sssd.conf
user = root

Но можно и руками в файле /etc/sssd/sssd.conf указать user = root.
Comment 3 Евгений 2023-04-12 07:33:17 MSK
Ручные изменения помогли, вылетов из домена по прошествии 30 дней нет.
Требуется внесение исправлений пакетов в репозитарий.
Comment 4 Evgeny Sinelnikov 2023-05-25 17:59:53 MSK
Для дальнейшей диагностики требуется более подробный разбор конфигураций, на которых воспроизводится данная проблема. На текущий момент при вводе машины в домен предлагаю рассматривать переключение на работу sssd из-под привилегированного пользователя.
Comment 5 Evgeny Sinelnikov 2023-05-25 18:03:26 MSK
Created attachment 13270 [details]
Переключение sssd в привилегированный режим

Привожу снимок экрана с примером переключения sssd в привилегированный режим в графическом конфигураторе acc (вкладка Аутентификация).