Назад | Перейти на главную страницу

Вложенные группы Linux с winbind

У нас есть несколько серверов RHEL6, подключенных к Active Directory с помощью winbind. Все серверы идентично настраиваются с помощью инструмента управления конфигурацией. Однако серверы дают разные результаты при запросе групп с помощью команды groups и / или sudo. Однако Getent и winbind возвращают правильные согласованные результаты на всех серверах.

user.name1 и user.name2 являются членами группы test.group1. test.group1 является членом группы test.group2

Выполнение следующих команд согласовано на всех серверах:

# getent group test.group1 
test.group1:*:16126:user.name1,user.name2

# getent group test.group2
test.group2:*:16125:user.name1,user.name2

# wbinfo --group-info test.group1 
test.group1:*:16126:user.name1,user.name2

# wbinfo --group-info test.group2
test.group2:*:16125:user.name1,user.name2

Однако сервер A неправильно возвращает:

# groups user.name2
test.group1

Сервер B правильно возвращает:

# groups user.name2
test.group1
test.group2

Конфигурация Samba выглядит так:

   winbind use default domain = true
   winbind offline logon = false
   winbind separator = + 
   winbind enum users = Yes
   winbind enum groups = Yes
   winbind nested groups = Yes
   winbind expand groups = 10
   server string = Linux Server
   strict locking = no
   wins server = 192.168.0.1
   idmap config * : range = 10000-50000000
   idmap config * : backend = rid
   idmap config SENT : range = 10000-50000000
   idmap config SENT : default = yes 
   idmap config SENT : backend = rid
   idmap uid = 10000-50000000
   idmap gid = 10000-50000000

nsswitch.conf выглядит так:

passwd:     files winbind
shadow:     files winbind
group:      files winbind

Рискну предположить, что ответ где-то в PAM или, возможно, ошибка поиска winbind. Есть какие-то мысли или предложения, где искать? Winbind / серверы перезагружены, tdb файлы восстановлены. Проблема также может быть временной.


Редактировать:

Наконец-то нужно еще раз взглянуть на эту проблему. Я восстановил аутентификацию с использованием SSSD вместо winbind, и происходит то же самое.

sssd.conf

[sssd] 
config_file_version = 2 
domains = sent.local 
services = nss, pam 
debug_level = 1

[nss] 

[pam] 

[domain/sent.local]
id_provider = ad 
auth_provider = ad 
access_provider = ad

default_shell = /bin/bash 
fallback_homedir = /home/domain/%u

use_fully_qualified_names = False

Теперь у нас есть некоторые интересные результаты: пользователи, которые никогда не были администраторами домена, имеют тот же результат, что и раньше, пока мы предварительно не кэшируем группы, членами которых, как мы знаем, они являются, например:

[root@test-smg1 - (11:46:40) sssd]#  id test.user5
uid=1084806380(test.user5) gid=1084800513(domain users) 
groups=1084800513(domain users)

[root@test-smg1 - (11:46:43) sssd]#  getent group testg2
testg2:*:1084806126:test.user5,test.user4,test.user3,test.user2

[root@test-smg1 - (11:46:46) sssd]#  id test.user5
uid=1084806380(test.user5) gid=1084800513(domain users) 
groups=1084800513(domain users),1084806126(testg2)

[root@test-smg1 - (11:46:49) sssd]#  getent group testg2-nest
testg2-nest:*:1084806125:test.user4,test.user3,test.user2,test.user5

[root@test-smg1 - (11:46:54) sssd]#  id test.user5
uid=1084806380(test.user5) gid=1084800513(domain users) 
groups=1084800513(domain users),1084806126(testg2),1084806125(testg2-nest)

Это заставляет меня думать, что проблема может быть больше связана с активным каталогом и конкретной реализацией AD, чем со стороной Linux. Когда пользователь становится членом Администраторов домена, все его группы отображаются правильно. Удаление пользователя из списка администраторов домена оставляет пользователя в этом «фиксированном» состоянии.

Похоже, это очень специфическая проблема в нашей настройке AD. «Чтение членства в группе» проверяется для аутентифицированных пользователей для пользователей, которые в настоящее время работают, и не проверяется для тех, у кого нет. Добавление этого права устраняет проблему (хотя winbind требует значительного времени, чтобы уловить изменение).


У меня такая же проблема с winbind.
Вот некоторые подробности моего дела:
- данной проблеме подвержены несколько пользователей (всего 800 пользователей).
- для проблемной учетной записи отсутствует только несколько групп (wbinfo -r; id) (некоторые все еще назначены) - вероятно, это не вызвано проблемным разрешением пользователя в AD
- список пользователей в группе завершен (группа getent; к сожалению, я не нашел способ составить список пользователей группы по wbinfo)
- все мои серверы используют одну и ту же версию самбы, и проблема возникает на всех из них с одним и тем же пользователем.
Я попытаюсь настроить SSSD, чтобы убедиться, что эта проблема связана с AD, а не с SAMBA.