LINUX.ORG.RU

sssd доменные пользователи и локальные группы.

 


0

1

Доброго времени суток.

Есть сервер под rhel 8.4 с доменной авторизацией. Подскажите, как добавить доменного пользователя в локальную группу? Т.е. usernod -aG добавляет, но когда проверяю id username, то вижу только доменные группы. Что-то мне подсказывает, что надо где-то в /etc/pam.d/ шаманить, но что именно? Спасибо.

Ответ на: комментарий от Pinkbyte

Приветствую. Нет. В домене группы nginx нет. Причем пробовал на Ubuntu, то там все ок. Вижу что id отдает (показывает) локальную группу

Извеняюсь. Что-то скрыть это полотно не получается. Я убрал все что закоментированно #

passwd:     sss files systemd
group:      sss files systemd
netgroup:   sss files
automount:  sss files
services:   sss files


shadow:     files sss
hosts:      files dns myhostname

aliases:    files
ethers:     files
gshadow:    files
# Allow initgroups to default to the setting for group.
# initgroups: files
networks:   files dns
protocols:  files
publickey:  files
rpc:        files
mplane ()
Последнее исправление: mplane (всего исправлений: 5)
Ответ на: комментарий от Pinkbyte

Как видно, доменный пользователь присутствует в локальной группе.

[root@server ~]# getent group | grep nginx
nginx:x:986:fakeuser 

Если просто ввести id fakeuser, то получим вывод всех доменных груп в которых он учавствует. Но локальная группа nginx не подтянулась

[root@server ~]# id fakeuser | grep nginx
mplane ()
Ответ на: комментарий от mplane

Ты случаем на этот веселый баг не напоролся?

TL;DR - id показывает фактическое членство в группах, которое определяется при ЛОГИНЕ пользователя.

То есть если ты залогинился под пользователем aaa, потом из другой консоли добавил его в группу bbb, то в сессии пользователя aaa будет виден(и фактически применяться) СТАРЫЙ набор групп(и тут неважно локальные они, или через AD). Лечится костылем - а именно закрытием/открытием новой сессии пользователя aaa.

getent плюет на эти условности - он забирает список групп непосредственно из источника, будь то passwd и/или локальные файлы

Update: хотя нет, не похоже - id ты вызываешь из под рута. Тогда другой вопрос - эти настройки в sssd есть?

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 2)
Ответ на: комментарий от Pinkbyte

Блин. Вообще ерунда получилась. Что я нашел. Чисто случайно. Итак сейчас сервера скажем заводятся в новый домен, пусть будет newdomain.local, а юзера попрежнему находятся в старом домене, olddomain.local. Между доменами настроены доверительные отношения. Так вот. На серверах которые еще числятся в старом домене olddomain.local, добавление в группу происходит нормально и id вычитывает локальную группу + кучу доменных. А вот на заведенных уже в новый домен server.newdomain.local уже id не отрабатывает как хочется. В sssd.conf я естественно прописал default_domain_suffix = newdomain, чтобы не приходилось писать fakeuser@newdomain

Но опять же. Ubuntu как-то обошла данная проблема.

З.Ы. hiera то у меня нет. Но строчку добавлять пытался.

mplane ()
Ответ на: комментарий от mplane

Интересно. А сервера те же самые заводятся в новый домен или разворачиваются новые(на более новой версии ОС, например)? Если те же самые, то это вообще не понятно - я бы понял проблемы с определением ДОМЕННЫХ групп, но локальные-то при чем?

Pinkbyte ★★★★★ ()
Ответ на: комментарий от mplane

И вот что пишут

1.1.2. Data providers in /etc/nsswitch.conf
The default sssd profile establishes SSSD as a source of information by creating sss entries in
/etc/nsswitch.conf:
passwd: sss files
group: sss files
netgroup: sss files
automount: sss files
services: sss files
...
This means that the system first looks to SSSD if information concerning one of those items is
requested:
passwd for user information
group for user group information
netgroup for NIS netgroup information
automount for NFS automount information
services for information regarding services



Only if the requested information is not found in the sssd cache and on the server providing
authentication, or if sssd is not running, the system looks at the local files, that is /etc/*.
For example, if information is requested about a user ID, the user ID is first searched in the sssd cache. If
it is not found there, the /etc/passwd file is consulted. Analogically, if a user’s group affiliation is
requested, it is first searched in the sssd cache and only if not found there, the /etc/group file is
consulted.
In practice, the local files database is not normally consulted. The most important exception is the case
of the root user, which is never handled by sssd but by files

т.е. получается у меня не смотрит в files

mplane ()
Последнее исправление: mplane (всего исправлений: 2)