не удается добавить группу ldap к локальному пользователю системы

Я искал ответ на тот же вопрос (как видите).

Я пришел к выводу, что вы не можете назначить группу LDAP пользователю, который существует только локально.

Это два мира: - либо пользователь (и его группы) локальны, либо нет, т.е. все хранится в каталоге.

Например: что произойдет, если у пользователя уже есть первичная группа, которая является локальной, и вы попытаетесь добавить вторичную группу к этому пользователю? Обычно это хранится в / etc / group, но в этом случае ему придется изменить каталог, что, вероятно, не может.

Так что я думаю, это не годится.

Из моего собственного расследования, если у вас все нормальные PAM / nsswitch.conf сантехника настроила, вы жестяная банка сделайте это, но только добавив локального пользователя в группу в базе данных LDAP напрямую, используя ldapmodify на memberUid атрибут на сервере LDAP (см. Вот):

$ ldapmodify -D <admin DN> -h <ldaphost> -W
password: [enter password]
dn: cn=vipb,ou=groups,dc=example,dc=com
changetype: modify
add: memberUid
memberUid: fred

^D

Обратите внимание, что пустая строка является нужно.

Затем вам нужно сделать недействительным кеш NCSD на сервере 2:

$ nscd --invalidate=group

Затем вы можете проверить членство в группе на сервере 2, выполнив:

$ id -nG fred

ПРЕДОСТЕРЕЖЕНИЕ: использование LDAP в качестве пользовательской базы данных зависит от схемы, подробно описанной в этом проекте стандарта: rfc2307bis-02. На данный момент существует ТРИ версии стандарта. Среди вещей, которые изменяются между версиями, являются атрибуты member и memberUid; это означает, что ваша настройка LDAP может работать некорректно. Полностью совместимая установка bis-02 должен содержат и поддерживают оба атрибута: memberUid (для локальных логинов членов группы LDAP, без dn) и member (для пользователей LDAP с полным dn) внутри данной группы. Они также должны позволять одному или обоим быть пустыми, разрешая пустые группы. Ваш опыт может отличаться - вам нужно будет проверить схему вашего сервера.

Такие инструменты, как webmin, могут быть полезны для управления пользователями и группами LDAP и базой данных LDAP; но опять же, они могут плохо работать с rfc2307bis-02. Например, модуль «Пользователи и группы LDAP» Webmin справляется с memberUid, но не с member.

Где все становится действительно мутным, это memberof служба поддержки. Некоторые системы (например, ранние ownCloud) полагаются на memberof поддержка определения групп, членом которых является пользователь, без необходимости дважды запрашивать базу данных LDAP. Часто memberof работает только для одного из атрибутов и только после серьезной настройки конфигурации LDAP.

В RHEL, вы можете сделать это через ldap_rfc2307_fallback_to_local_users параметр:

Операции аутентификации и инструменты идентификации, такие как idтем не менее, проходите через SSSD, и нет записи о локальном пользователе в провайдере идентификации LDAP, настроенном для SSSD. SSSD может обрабатывать локального пользователя двумя способами:

• Он может удалить пользователя из локального passwd файл, как если бы он был остатком удаленной локальной учетной записи.

• Он может запрашивать список локальных пользователей (passwd) в качестве запасного варианта, если пользователь в группе не найден в LDAP, а затем добавьте этого пользователя в свой кеш, как если бы он был пользователем LDAP.

Это поведение настраивается в ldap_rfc2307_fallback_to_local_users параметр для домена поставщика удостоверений. По умолчанию это false, что означает, что распознаются только пользователи, которые существуют в поставщике LDAP, а локальный пользователь удаляется, если он добавлен в группу LDAP. Это может быть установлено в значение true, которое запрашивает пользователей локальной системы в качестве запасного варианта, если член группы LDAP не найден в каталоге LDAP.