Группа domain users linux

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

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

Покажи nsswitch.conf. Если доменная группа по имени совпадает с локальной, то очевидно, что нифига не получится.

Приветствую. Нет. В домене группы 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 ( 23.06.21 12:38:02 MSK )
Последнее исправление: mplane 23.06.21 12:43:16 MSK (всего исправлений: 5)

Ок, давай по порядку, что выдаёт:

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

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

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

[root@server ~]# id fakeuser | grep nginx 

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

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

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

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

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

Pinkbyte ★★★★★ ( 23.06.21 18:54:09 MSK )
Последнее исправление: Pinkbyte 23.06.21 18:57:00 MSK (всего исправлений: 2)

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

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

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

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

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 ( 23.06.21 20:40:07 MSK )
Последнее исправление: mplane 23.06.21 20:43:33 MSK (всего исправлений: 2)

Похожие темы

• Форум Как добавить доменного пользователя в локальную группу? (2022)
• Форум Как включить доменного пользователя в локальную группу линуксовой машины (2007)
• Форум Добавить доменную группу в группу Linux (2021)
• Форум Доменные пользователи (2017)
• Форум Разрешение доступа к CUPS для доменного пользователя (2022)

• Форум Шифрование каталога доменного пользователя (2019)
• Форум Авторизация pop3d в NT домене ADC (2005)
• Форум SAMBA как PDC: проблемы с добавлением юзеров в локальную группу Administrators на winXP (2002)
• Форум Локальный пользователь с группами AD (2015)
• Форум не работает pam_smb_auth (2002)

Источник

unixforum.org

[Решено] Как включить доменного пользователя в локальные группы Линукс

[Решено] Как включить доменного пользователя в локальные группы Линукс

Сообщение Equilibrium » 23.10.2008 10:31

Подключил Лниукс-машину к AD, под доменной учёткой вхожу на Линукс-машину, доступ к виндовс-серверам есть, но при попытке ввести в терминале команду su выдает «Отказано в доступе». Как ввести доменного пользователя в локальные группы линукс-машины?

Re: [Решено] Как включить доменного пользователя в локальные группы Линукс

Сообщение Ariasp » 23.10.2008 11:34

Re: [Решено] Как включить доменного пользователя в локальные группы Линукс

Сообщение Equilibrium » 24.10.2008 03:35

Спасибо, проблема вроде как решилась, но не до конца:
Я вручную добавил доменного пользователя в файлы /etc/group, /etc/gshadow, /etc/gshadow. Вроде всё получилось: пользователь появился в списке окна входа в систему, я зашел под этим пользователем, доступ к папкам на сервере Windows остался, команда su в терминале стала выполняться, но это была уже другая учётная запись: домашний каталог у неё был /home/domain/domain-user, а у доменной учётной записи — /home/DOMAIN/domain-user.
Когда я вручную исправил domain на DOMAIN в /etc/passwd, то KDM меня не пустил, выдал ошибку.
Отсюда вопрос: как сделать, чтобы при первом входе под доменной учётной записью она автоматом прописывалась в /etc/group, /etc/gshadow, etc/gshadow в качестве локального юзера Linux-машины?

Re: [Решено] Как включить доменного пользователя в локальные группы Линукс

Сообщение Ariasp » 24.10.2008 12:30

Отсюда вопрос: как сделать, чтобы при первом входе под доменной учётной записью она автоматом прописывалась в /etc/group, /etc/gshadow, etc/gshadow в качестве локального юзера Linux-машины?

а оно вам точно надо? — если у тебя winbind назначает uid и gid доменным учёткам, то доменного юзера не нужно прописывать в /etc/group — всё решается использованием pam_winbind, pam_mkhomedir и настройкой nsswitch.conf; если в выводе команды getent group присутствуют доменные группы, значит всё настроено верно, и вышеописанных проблем по идее быть не должно (добавление в /etc/group имеет смысл только с точки зрения дополнительных прав доменной учётки на линукс-машине, например для возможности выполнять команду su -> добавить доменную учётку в группу wheel хоть редактированием /etc/group, хоть командой gpasswd)

Re: [Решено] Как включить доменного пользователя в локальные группы Линукс

Сообщение Equilibrium » 24.10.2008 13:11

всё решается использованием pam_winbind, pam_mkhomedir и настройкой nsswitch.conf; если в выводе команды getent group присутствуют доменные группы, значит всё настроено верно

pam_winbind, pam_mkhomedir прописаны, домашняя директория создаётся, но getent group выводит только содержимое файла /etc/group, доменных групп в ней нет. Команды wbinfo -g и wbinfo -u выводят доменные группы и доменных пользователей соответственно.

Я в предыдущем посте немного ошибся, написал «Я вручную добавил доменного пользователя в файлы /etc/group, /etc/gshadow, /etc/gshadow», а надо было «Я вручную добавил доменного пользователя в файлы /etc/group, /etc/gshadow, /etc/passwd», т.е. я вручную прописал пользователя и в /etc/passwd.

Спасибо, вроде помогло! А в остальные группы типа cdrom, scanner, radio и им подобных тоже пользователя тоже надо вручную добавлять?

Удалил я внесённого вручную пользователя из /etc/group, /etc/gshadow, /etc/passwd, соответственно, в окне менеджера входа в систему (KDM) из списка он пропал. А можно ли сделать так, чтобы он там остался?

Источник

Edit Sudoers file to allow sudo rights to a AD domain group

I recently managed to get my Ubuntu Server 18.04 machine connected to my companies Windows AD. I am able to login with my AD credentials however I want to take it a step further. This is the article I followed in order to get my Ubuntu 18.04 machine onto the windows domain, note I did not do any configuration on restricting ssh login to a domain group as I am still struggling. https://www.smbadmin.com/2018/06/connecting-ubuntu-server-1804-to-active.html?showComment=1548915938955#c6716393705599388679 However.

The goal of what I am trying to achieve is as follows:

• Add a line to /etc/sudoers file that specifies an AD group within my organization.
• This groups members should have sudo access on the Linux machines in our organisation.

What I’ve done:

• I tried adding lines like :
• «nameofdomain\nameofgroup ALL=(ALL:ALL) ALL»
• And more. However whenever I try to sudo with a user I know is in the group I receive the usual «. user not in sudoers. incident will be reported. «

What could be the reason for this? Is it perhaps due to the configurations I’ve specified when connecting the machine to the AD domain?

The full path to this group is as follows: — domainname/Groups/Elab/Elab-Level3

Here is the configuration for my files used to join the AD domain:

[libdefaults] default_realm = MYREALM dns_lookup_kdc = true dns_lookup_realm = true 

[users] default-home = /home/%D/%U default-shell = /bin/bash [active-directory] default-client = sssd os-name = Ubuntu Server os-version = 18.04 [service] automatic-install = no [mydomain] fully-qualified-names = yes automatic-id-mapping = no user-principal = yes manage-system = yes 

[sssd] domains = mydomain config_file_version = 2 services = nss, pam, ssh [domain/mydomain] ad_domain = mydomain krb5_realm = MYDOMAIN realmd_tags = manages-system joined-with-adcli cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = False fallback_homedir = /home/%u@%d access_provider = ad ldap_user_ssh_public_key = altSecurityIdentities 

I’m really hoping that someone here has the answer, I’ve searched many many threads and have not been able to crack this nut

Источник