Вопросы Теги

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

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

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

# 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)

В конце концов мы обнаружили, что у пользователя userA атрибут 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
1
задан 20 September 2017 в 00:00
1 ответ

Я понял проблему, когда прочитал руководство по устранению неполадок 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 файл.

1
ответ дан 3 December 2019 в 23:25

Теги

Похожие вопросы