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

У некоторых пользователей AD отсутствуют дополнительные группы в RHEL Linux

Моя организация пытается присоединить наши серверы RHEL / CentOS 7 к нашему домену Microsoft AD. Контроллеры домена состоят из 2 серверов Windows 2008R2 и 1 сервера Windows 2016.

На стороне Linux я использую realm для присоединения к домену, что мне удалось успешно сделать:

# realm list
mydomain.net
  type: kerberos
  realm-name: MYDOMAIN.NET
  domain-name: mydomain.net
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common-tools
  login-formats: %U@mydomain.net
  login-policy: allow-realm-logins

Я хочу разрешить доступ к SSH только членам определенной группы:

# realm permit -g mygroup@mydomain.net

Вот тогда и возникают проблемы. При тестировании на двух пользователях, userA и userB, userA разрешен, но userB запрещен. В /var/log/sssd/sssd_mydomain.net.log файл показывает, что userB не имеет дополнительных групп:

(Tue Sep 19 20:53:37 2017) [sssd[be[mydomain.net]]] [simple_access_check_send] (0x0200): Simple access check for userB@mydomain.net
(Tue Sep 19 20:53:37 2017) [sssd[be[mydomain.net]]] [simple_check_get_groups_send] (0x0400): User userB@mydomain.net is a member of 0 supplemental groups
(Tue Sep 19 20:53:37 2017) [sssd[be[mydomain.net]]] [simple_check_get_groups_send] (0x0400): All groups had name attribute

Вернее, есть, но SSSD ничего не видит. Следующие команды подтверждают это:

# id userA@mydomain.net
uid=1918001261(userA@mydomain.net) gid=1918000513(domain users@mydomain.net) groups=1918000513(domain users@mydomain.net),1918001757(devops_aws@mydomain.net),1918003900(sccm administrators@mydomain.net),1918004006(ts remote desktop users@mydomain.net),1918004329(macbook_users@mydomain.net)
# id userB@mydomain.net
uid=1918003883(userB@mydomain.net) gid=1918000513(domain users@mydomain.net) groups=1918000513(domain users@mydomain.net)

В конце концов мы обнаружили, что у пользователя A есть adminCount атрибут установлен на 1 в своем объекте AD / LDAP. Я не совсем уверен, какое значение имеет этот атрибут, но, похоже, это причина, по которой SSSD может найти все свои дополнительные группы и, следовательно, не нашел ни одной для пользователя B.

Любая помощь будет принята с благодарностью! Я долго-долго бился головой об этой проблеме.

/etc/sssd/sssd.conf

[sssd]
domains = mydomain.net
config_file_version = 2
services = nss, pam

[domain/mydomain.net]
ad_domain = mydomain.net
krb5_realm = MYDOMAIN.NET
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = simple
simple_allow_groups = mygroup@mydomain.net
debug = 6

Я понял проблему, когда прочитал Устранение неполадок SSSD руководство. В руководстве кратко упоминается:

Если вы используете нестандартные базы поиска LDAP, отключите повышение производительности TokenGroups, установив ldap_use_tokengroups=False. В противном случае поставщик AD получит членство в группе через специальный вызов, который не ограничен пользовательской базой поиска, что приведет к непредсказуемым результатам.

И в сообщении в блоге Ограничьте набор групп, в которые входит пользователь, с помощью SSSD, о TokenGroups объясняется немного больше:

Первый шаг - заставить клиента искать группы, членом которых является пользователь, с помощью простого поиска LDAP вместо поиска специфичного для AD атрибута tokenGroups. Обычно, если должны быть возвращены все группы, использование атрибута tokenGroups дает значительное преимущество в производительности, поскольку список всех групп, в которые входят члены, может быть возвращен с помощью одного поиска записи пользователя в области BASE. Однако атрибут tokenGroups представляет собой многозначный список идентификаторов безопасности, членом которых является пользователь, и, как было сказано ранее, все идентификаторы безопасности в любом случае должны быть преобразованы в имена групп.

Кажется, что TokenGroups - это метод оптимизации, который включен по умолчанию при разрешении групп пользователей. Однако, как упоминалось в этих статьях, это может оказаться проблематичным, как и в моем случае.

Проблема была устранена путем простой установки параметра на false:

[domain/mydomain.net]
ldap_use_tokengroups = false

в моем sssd.conf файл.