не может добавить 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

CAVEAT: The использование 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 директории.