Как мне запустить контейнеры Docker от имени пользователя домена Active Directory (SSSD)? (“не удалось найти пользователя”)

Я запускаю несколько Samba-общих папок на выделенной машине с Debian 9.6, присоединенной к AD-домену (Zentyal с SMB 4).

Я использую довольно простую установку SSSD, которая до сих пор идеально подходит для наших нужд.

Я хочу настроить Ambar так, чтобы различные пользователи домена могли искать документы на указанных Samba-общих папках. Однако я хочу, чтобы Ambar сканировал только “публичные” документы и ничего из частных/”управленческих” папок.

Я изменил файл docker-compose.yml так, чтобы Docker запускал контейнеры от имени пользователя crawler, но когда я выполняю docker-compose up -d, я получаю следующую ошибку:

ERROR: for Shared-folder Cannot start service Shared-folder: linux spec user: unable to find user crawler: no matching entries in passwd file

Редактирование файла /etc/passwd вручную здесь не помогает. Я все еще получаю ту же ошибку.

Вот как выглядит соответствующая конфигурация docker-compose.yml:

Shared-folder:
  depends_on:
    serviceapi:
      condition: service_healthy
  image: ambar/ambar-local-crawler
  restart: always
  networks:
    - internal_network
    expose:
    - "8082"
  environment:
    - name=Shared-folder
    - ignoreExtensions=.{exe,dll,rar,s,so}
    - apiUrl=http://serviceapi:8081
  user: crawler
  volumes:
    - /shared/Shared-folder:/usr/data

Обратите внимание, что если я уберу строку user: crawler, все будет работать, как ожидается (и root сканирует все мои документы).

Вот мой файл /etc/sssd/sssd.conf:

[sssd]
services = nss, pam
config_file_version = 2
domains = MY.COMPANY.COM

[domain/MY.COMPANY.COM]
id_provider = ad
access_provider = ad
ad_gpo_map_interactive = +cron
dyndns_update_ptr=false

# Используйте это, если пользователи входят в систему в /.
# Этот пример указывает /home/DOMAIN-FQDN/user как $HOME. Используйте с pam_mkhomedir.so
override_homedir = /home/%u
ldap_idmap_autorid_compat = True

А вот мой /etc/pam.d/common-session:

#
# /etc/pam.d/common-session - модули сессий, общие для всех служб
#
# Этот файл включается из других конфигурационных файлов PAM, специфичных для служб,
# и должен содержать список модулей, которые определяют задачи для выполнения
# в начале и в конце сессий *любого* типа (как интерактивных, так и
# неинтерактивных).
#
# Начиная с pam 1.0.1-6, этот файл по умолчанию управляется pam-auth-update.
# Чтобы воспользоваться этим, рекомендуется настраивать любые
# локальные модули либо до, либо после блока по умолчанию, и использовать
# pam-auth-update для управления выбором других модулей. См.
# pam-auth-update(8) для получения подробностей.

# вот модули по пакету (блок "Основной")
session [default=1]                     pam_permit.so
# вот резервный вариант, если ни один модуль не сработал
session requisite                       pam_deny.so
# подготовьте стек с положительным значением возврата, если такового еще нет;
# это позволяет нам не возвращать ошибку просто потому, что ничего не устанавливает код успеха,
# поскольку модули выше просто будут перескакивать
session required                        pam_permit.so
# и вот еще модули по пакету (блок "Дополнительный")
session required        pam_unix.so
session required        pam_mkhomedir.so skel=/etc/skel/ umask=0066
session optional                        pam_winbind.so
session optional                        pam_sss.so
session optional        pam_systemd.so
# конец конфигурации pam-auth-update

Пожалуйста, дайте мне знать, если какие-либо конфигурации могут быть полезны! Я полагаю, что smb.conf не так уж важен в этом случае, и что может быть какой-то способ сказать Docker просто доверять PAM?

Конфигурация домена в sssd.conf не содержит use_fully_qualified_names = False. Без этого от вас могут ожидать использование полных квалифицированных имен (например, [email protected]). Это не строго необходимо для решения вашей проблемы, но я нахожу это полезным, если машина ссылается только на один домен. В альтернативном варианте:

• Вы можете попробовать указать полное квалифицированное имя для пользователя в docker-compose.yaml (т.е. user: [email protected]). Я не пробовал это, поэтому не могу подтвердить, что это сработает, как ожидается.

• Вы можете использовать uid пользователя вместо имени. Это метод, который я использую, поэтому могу подтвердить, что он работает нормально. Вы можете получить uid, выполнив id <username> (убедившись, что используете формат, соответствующий вашей настройке use_fully_qualified_names).

В любом случае, если вы не можете получить uid вашего пользователя, выполнив id <username>, то ваша проблема, скорее всего, заключается в настройке SSSD, а не в конфигурации докера.