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

Как сопоставить Windows ACL с Linux на общей папке CIFS?

Контекст

У нас есть сервер Windows с доменом Active Directory и сетевым ресурсом.

У меня есть Linux-машина, и я хочу смонтировать общий ресурс.

sudo mount -t cifs //server/share /mnt/share -o user=[act-dir user],domain=[domain],uid=[linux user],gid=[linux group]

Это более-менее нормально. Мой пользователь Linux сопоставляется со всеми файлами на общем ресурсе, и некоторые списки ACL переводятся. Но я хочу пойти еще дальше:

Решение и проблема

Samba предлагает вариант монтирования cifsacl что требует настройки cifs.idmap и winbindd. Оба установлены, я прочитал обе страницы руководства и попытался их настроить, но это не работает. Новая команда монтирования теперь:

sudo mount -t cifs //server/share /mnt/share -o user=[act-dir user],domain=[domain],cifsacl

Но все привязано к root: root, что означает, что cifs.idmap не может быть выполнен.

На самом деле, я не совсем удивлен, потому что я не понимал, где написать фактическое сопоставление, так где я должен писать, что Windows userX действительно сопоставляется с Linux userY? И я не уверен, что конфигурация winbindd правильная, какой должен быть минимальный набор параметров и требуется ли запуск smbd и / или nmbd? Нужно ли открывать порт в брандмауэре?

Справочная информация

Структура акций

В общем каталоге есть несколько подкаталогов, некоторые общие и некоторые «частные» (хотя частные каталоги фактически доступны для чтения всем). Каждому пользователю необходимо время от времени получать доступ к общему пространству, а также к частным каталогам других пользователей, но в основном / часто к их собственному каталогу.

Технические данные

Как установить многопользовательское крепление CIFS

CIFS - это протокол на основе сеансов. Это означает, что сеанс выполняется с привилегиями пользователя, выполнившего вход в сеанс CIFS. Следовательно, нормальный способ использования CIFS - это монтировать общие ресурсы во время входа пользователя в систему с привилегиями входа пользователя в систему. Это то, для чего был разработан протокол.

Тем не менее, драйвер Linux CIFS предлагает способ монтировать общий ресурс уже во время запуска. Это называется многопользовательское крепление. Стратегия многопользовательского монтирования заключается в монтировании общего ресурса во время запуска с минимальными привилегиями. Для каждого пользователя, обращающегося к общему ресурсу, драйвер CIFS внутренне создает отдельный сеанс CIFS с сервером.

Когда пользователь впервые обращается к монтируемому многопользовательскому ресурсу, драйверу CIFS необходимо создать сеанс CIFS с файловым сервером для этого пользователя. Для этого требуется информация о безопасности, например имя пользователя и пароль. Поскольку драйвер не может запрашивать данные для входа в систему, он будет искать в связке ключей ядра текущего пользователя Linux. Если подходящая информация о безопасности может быть найдена, драйвер CIFS будет использовать ее для создания сеанса CIFS для текущего пользователя с файловым сервером, и пользователь сможет получить доступ к общему ресурсу.

Этот пост может выглядеть как практическое руководство, но на самом деле он предназначен как сборник возможных ошибок.

Шаг 1: Создать акцию SHARE на файловом сервере FILESERVER и локальный пользователь CIFS_GUEST на файловом сервере с минимальными привилегиями. Пользователю должно быть разрешено монтировать общий ресурс только с удаленного компьютера. Пароль пользователя никогда не должен истекать.

Примечания и подводные камни:

  • Пользователь делает не должны быть в локальной группе «Пользователи удаленного рабочего стола» FILESERVER.

  • Если доля SHARE это так называемый "административная доля", затем пользователи (в том числе CIFS_GUEST) должны иметь административные привилегии. Рекомендуется создать общий ресурс обычного, неадминистративного типа.

    Шаг 2: Смонтируйте общий ресурс с вашего компьютера Linux, например

    mount.cifs // FILESERVER / SHARE / mnt --verbose -o domain = FILESERVER, имя пользователя = CIFS_GUEST

Это должно правильно установить общий ресурс. Если нет, я рекомендую посмотреть справочную страницу mount.cifs(8).

Примечания и подводные камни:

  • Обязательно укажите опцию domain=FILESERVER. В противном случае файловый сервер может предположить, что CIFS_GUEST является пользователем домена (не локальным) и запрещает доступ.
  • Если у вас возникнут проблемы с аутентификацией, проверьте журналы сервера (например, журналы событий Windows в случае файлового сервера Windows).
  • Вы можете добавить опцию монтирования noperm чтобы отключить проверку разрешений на стороне клиента. Разрешения в любом случае применяются сервером.

Шаг 3: Снова установите с multiuser вариант:

umount /mnt
mount.cifs //FILESERVER/SHARE /mnt -v -o multiuser,domain=FILESERVER,username=CIFS_GUEST

Подтвердите это multiuser был использован:

mount | grep cifs

Шаг 4: Создайте файл учетных данных для автоматического неинтерактивного монтирования. Защитите его от любого доступа без полномочий root.

Содержимое файла /etc/cifs.SHARE.cred:

username=CIFS_GUEST
password=<pass>
Domain=FILESERVER

Затем выполните:

chown root /etc/cifs.SHARE.cred
chmod 600 /etc/cifs.SHARE.cred

Примечания и подводные камни:

  • Убедитесь, что файл учетных данных не содержат метку порядка байтов (BOM) при использовании кодировки UTF-8. В противном случае вы можете получить ложное сообщение «Учетные данные отформатированы неправильно» от mount.cifs.

Шаг 5: Попробуйте смонтировать общий ресурс с файлом учетных данных. Теперь это должно быть полностью не интерактивным:

umount /mnt
mount.cifs //FILESERVER/SHARE /mnt -v -o multiuser,credentials=/etc/cifs.SHARE.cred

Если это сработает, вы можете добавить крепление к /etc/fstab:

...
//FILESERVER/SHARE /mnt cifs rw,auto,multiuser,credentials=/etc/cifs.SHARE.cred 0 0
...

Примечания и подводные камни:

  • Опция auto добавлена ​​возможность автоматического монтажа лемеха.

Шаг 6: Войдите в систему как обычный пользователь на машине Linux. Попробуйте получить доступ к смонтированному общему ресурсу, например

cd /mnt
ls

В разрешении следует отказать.

Затем вручную сохраните учетные данные CIFS в связке ключей сеанса:

cifscreds add FILESERVER -u <username>

Вам будет предложено ввести пароль. После этого вы сможете получить доступ к общему ресурсу, если <username> имеет разрешение на доступ к общему ресурсу на файловом сервере.

Примечания и подводные камни:

  • Вы можете использовать проводник Windows, чтобы убедиться, что <username> имеет разрешения на доступ к общему ресурсу. Таким образом можно исключить, что ошибка возникла. FILESERVER.
  • Если cifscredsвыдает предупреждение о непостоянном связке ключей сеанса, затем введите keyctl session и попробуй еще раз.
  • Вы можете отобразить содержимое связки ключей с помощью keyctl show -3.
  • В cifscreds не будет создавать сеанс CIFS с файловым сервером. Он просто помещает информацию о безопасности в связку ключей, чтобы драйвер CIFS мог использовать ее для создания сеанса CIFS при доступе к общему ресурсу. Это означает, что изменение ключа в связке ключей с cifscreds update ... оставит вас в системе со старым пользователем (!).

Шаг 7: Наконец, этап подачи брелка можно автоматизировать. От имени пользователя root добавьте следующие строки в конфигурацию PAM (например, /etc/pam.d/login):

...
auth optional pam_cifscreds.so debug
...
session optional pam_cifscreds.so domain=<AD Domain> debug
...

В первой строке записан пароль при входе в систему. Пароль сохраняется до создания сеанса. Когда сеанс создан, вторая строка помещает запись в связку ключей. Звонить не будет cifscreds и общий ресурс должен быть доступен сразу после входа в систему.

Примечания и подводные камни:

  • Вы можете удалить debug опция после тестирования, чтобы уменьшить подробность ведения журнала.
  • Убедитесь, что обе строки выполняются в каждом случае в стеке PAM. (последовательность записей в конфигурационном файле)
  • Вы можете заменить optional с участием required для принудительной аутентификации на файловом сервере.
  • Перед второй строкой должно быть обеспечено наличие постоянного ключа сеанса. В случае сомнений добавьте следующую строку непосредственно перед второй строкой: session required pam_keyinit.so
  • Обе строки должны оставлять сообщения в системных журналах при использовании debug вариант.
  • Такие же изменения следует внести в конфигурацию других программ входа в систему с поддержкой PAM, например к /etc/pam.d/sshd, /etc/pam.d/xdm, ...

До этого момента разрешения на доступ к файлам и папкам в общем ресурсе обеспечиваются FILESERVER. Разрешения, имена пользователей и имена групп, отображаемые на стороне Linux, полностью неверны. Чтобы получить их должным образом, добавьте опцию крепления cifsacl и установить отображение идентичности. Однако для этого, вероятно, потребуется, помимо прочего, настроить службу Winbind. Дополнительную информацию можно найти на странице руководства. mount.cifs(8).

Возможно, вам потребуется использовать функцию сопоставления имен пользователей внутри samba (winbind), чтобы сопоставление работало, чтобы winbind знал об учетной записи AD для каждого пользователя Linux. Я считаю, что карта имен пользователей может принимать команды и списки (и некоторые преобразования шаблонов), но гораздо проще, если имена пользователей Linux могут совпадать с именами пользователей AD, например, используя pam_winbind. Я предполагаю, что когда отображение работает, вы можете начать проверять, работает ли общий ресурс.