Модуль 7. Дополнительные подсистемы ALD Pro
Введение
Из этого модуля вы узнаете о том, как с помощью штатных подсистем ALD Pro закрыть базовые потребности предприятий по обеспечению общего доступа к файлам. Мы рассмотрим не только процесс установки и настройки подсистемы через портал управления, но и разберем, как работают лежащие в ее основе компоненты, поэтому материал будет полезен даже в том случае, если вам потребуется настроить все врукопашную.
Процедура развертывания подсистем
Давайте сравним процесс установки ролей Windows и подсистем ALD Pro.
Установка ролей в Windows Server
Операционная система Windows из соображений безопасности по умолчанию устанавливается в минимальной комплектации, что позволяет администраторам настраивать сервера, которые будут выполнять только строго возложенные на них функции без чего бы то ни было лишнего. Процедура установки дополнительного программного обеспечения из состава операционной системы называется добавлением роли или компонентов (Add Roles and Features).
Серверные роли определяют основную функцию сервера в инфраструктуре предприятия, какие услуги он предоставляет пользователям или другим серверам в сети, например, контроллер домена, файловый сервер, принт-сервер, веб-сервер и т.д. Компоненты системы — это дополнительные приложения, которые устанавливаются вместе с ролями для расширения функциональности. Например, для роли веб-сервера можно дополнительно включить службу FTP или функцию публикации WebDAV.
Установка выполняется из Диспетчера сервера (англ. Server Manager) с помощью Мастера добавления ролей и компонентов (англ. Add Roles and Features Wizard), см. рис. 274.
рис. 274 Установка ролей из диспетчера сервера
Запустить приложение можно как непосредственно с того сервера, которым планируется управлять, так и с любого другого рабочего места. В этом случае Мастер установки будет выполнять PowerShell-командлеты удаленно по протоколу Windows Remote Management (WinRM), который является частной реализацией SOAP-протокола WS-Management, см. рис. 275. По умолчанию протокол WinRM должен быть включен на всех серверах Windows.
рис. 275 Удаленная установка ролей через WinRM
Удаленная установка ролей и компонентов выполняется в интерактивном режиме, как по SSH, в связи с чем требуется постоянный доступ по сети к управляемым узлам. Когда мастер установки запускает командлет на удаленном хосте, PowerShell автоматически сериализует передаваемые объекты в XML и обратно, поэтому процесс ничем не отличается от того, как если бы Диспетчер был бы запущен локально.
Для настройки ролей используются специализированные оснастки, такие как Центр управления Active Directory (англ. Active Directory Administrative Center), Диспетчер DNS (англ. DNS Manager) и др. Удаленное управление серверами в этих оснастках выполняется аналогично через WinRM.
Установка подсистем в ALD Pro
Подсистемы ALD Pro, как роли Windows Server, определяют основную функцию сервера. Их можно установить на серверы ALSE 1.7.x с уровнем защищенности «Максимальный» («Смоленск»), но если в Windows объединение нескольких ролей на одном сервере считается просто нежелательным, то в ALD Pro это недопустимо.
Как мы уже отмечали, в Linux очень высок уровень повторного использования кода, и разные приложения довольно часто используют одни и те же компоненты, поэтому во избежание проблем с зависимостями пакетов каждая подсистема должна устанавливаться исключительно в отдельной операционной системе. Для этого вместе с лицензией на контроллер ALD Pro поставляется восемь лицензий на ALSE, одна из которых нужна для установки контроллера, а семь оставшихся вы можете использовать для установки любых подсистем.
Процедура установки подсистемы предполагает два шага: сначала сервер вводится в домен, а затем на него через портал управления назначается необходимая роль. Повышение роли сервера выполняется автоматически с помощью системы конфигурирования Salt, см. рис. 276. На доменных компьютерах установлена служба Salt Миньон, которая подключается на порт 4505/TCP к шине ZeroMQ на Salt Мастере и в режиме длинных опросов ожидает получения команд. Для загрузки дополнительных файлов и отправки отчета о результатах выполнения команд Salt Миньон подключается к Salt Мастеру дополнительно на порт 4506/TCP.
рис. 276 Удаленная установка ролей через Salt
В установке подсистем ALD Pro участвует много компонентов системы. Более подробно процесс представлен на рис. 277.
При установке роли происходит следующее взаимодействие между компонентами:
Фронтенд портала управления (веб-страница) отправляет Бэкенду портала (Django приложение) POST-запрос на 443/TCP.
Бэкенд портала управления отправляет сообщение в Обменник RabbitMQ ( CANRUNNERS) на том же контроллере домена и сразу же возвращает Фронтенду результат «Операция выполнена». Обменник RabbitMQ на контроллере домена перекладывает сообщение в Очередь RabbitMQ (CANRUNNER:dc-1.ald.company.lan).
Из Очереди RabbitMQ сообщение вычитывает локально запущенный Раннер RabbitMQ (служба ad-salt-canrunner).
Раннер RabbitMQ по unix-сокету ставит задание в Salt Мастер (служба salt-master) на контроллере домена.
Salt Мастер на контроллере домена через ZeroMQ передает задание службе Salt Миниона на файловом сервере, которая подключена к ZeroMQ по порту 4505/TCP.
Salt Minion на файловом сервере выполняет установку подсистемы и отчитывается о результатах Мастеру через ZeroMQ по порту 4506/TCP.
ZeroMQ передает результаты в службу Salt Мастер, который записывает результаты выполнения задания в базу PostgreSQL.
Раннер RabbitMQ через триггер PostgreSQL подписан на изменения в базе данных, поэтому получает их немедленно, как только SaltMaster записывает их в базу.
Раннер RabbitMQ отправляет сообщение в Обменник RabbitMQ (CANCLIENTS) о результатах выполнения задания. Обменник RabbitMQ на контроллере домена перекладывает сообщение в Очередь RabbitMQ (CANCLIENT:aldpro:dc-1.ald.company.lan).
Из Очереди RabbitMQ сообщение вычитывает Клиент RabbitMQ (служба aldpro-canclient).
Клиент RabbitMQ (служба aldpro-canclient) отмечает в базе PostgreSQL портала управления статус выполнения задания автоматизации.
Пользователь обновляет веб-страницу, и Фронтенд портала управления отправляет Бэкенду портала (Django приложение) POST-запрос на 443/TCP.
Бэкенд портала управления извлекает данные из базы PostgreSQL.
Бэкенд портала отдает запрошенные данные Фронтенду.
рис. 277 Потоки данных при установке роли
Вам будут полезны следующие советы и рекомендации:
Автоматизация не предполагает, что администратору нужно разбираться с тем, как она работает, но если вам потребуется ознакомиться с порядком установки подсистем, то соответствующие скрипты вы найдете на контроллере домена. За установку подсистемы общего доступа к файлам, например, отвечает скрипт
install.slsиз каталога/srv/salt/states/aldpro/subsystems/smb/.Установка подсистем может занимать много времени, и, если вам потребуется убедиться в том, что процесс не стоит на месте, вы можете найти подтверждение на целевом сервере в журналах Salt Миньона,
term.logили черезjournalctl$ sudo tail -f /var/log/salt/minion /var/log/apt/term.log $ sudo journalctl -f
Если служба aldpro-canclient.service будет выключена, то задание автоматизации по установке подсистемы останется в состоянии «Запущено» до следующего запуска службы.
А вот если служба ad-salt-canrunner.service будет выключена, то задание автоматизации на установку подсистемы так и останется в состоянии «Запущено». Повторный запуск службы не поможет, т.к. она получает событие по триггеру только в момент добавления данных в базу.
Для того чтобы вручную извлечь актуальные данные о результатах выполнения задания, воспользуйтесь следующим запросом, где jobID – это номер задания, который можно увидеть в адресной строке браузера, если открыть соответствующее задание на портале управления.
$ sudo --user=postgres psql -d salt -c "select * from task_started where uuid='jobID'"
Служба Salt Мастер в своей работе использует таймауты, значения которых оптимизированы под современное оборудование. Но если у вас на контроллере домена будут установлены медленные диски, то в момент получения результатов выполнения задания от Миньона служба Salt Master может не уложиться в таймаут обращения к базе данных и решит, что задание было обработано с ошибкой. В этом случае в отчете о выполнении задания автоматизации на портале управления будет присутствовать ошибка «Run failed on minions», хотя роль установилась успешно и сервер доступен для дальнейшего конфигурирования.
Если вы столкнетесь с такими симптомами в своей инфраструктуре, то на контроллерах домена в конфигурационный файл
/etc/salt/master.d/master.confнужно будет добавить параметр gather_job_timeout со значением 300 секунд (5 минут).
admin@dc-1:~$ sudo cat /etc/salt/master.d/masters.conf
timeout: 180
auto_accept: True
worker_threads: 12
. . .
gather_job_timeout: 300
. . .
Для возможности отправки команд с портала управления любого контроллера необходимо, чтобы Миньон был подключен ко всем Мастерам сразу. Для этого на доменных компьютерах работает служба aldpro-client-service-discovery, которая вписывает адреса контроллеров в конфигурационный файл
/etc/salt/minion.d/masters.conf. В небольших инфраструктурах такая архитектура работает надежно, но если у вас более десяти контроллеров, то Миньон уже не сможет удерживать надежное соединение со всеми сразу.В этом случае потребуется отключить службу автоматического обнаружения сервисов и указать в настройках masters.conf только те серверы, с которых вы хотите выполнять конфигурирование подсистем.
Управление подсистемами в настоящий момент осуществляется двумя способами. Основным является управление через Salt-Мастер и Salt-Миньон, а в качестве дополнительного интерфейса некоторые подсистемы, такие как сервер репозиториев и подсистема печати, используют REST API на порту 443/TCP.
рис. 278 Поток данных при настройке подсистем через Salt
Приведем пример потока данных при настройке файлового сервера, см. рис. 278:
Фронтенд портала управления отправляет Бэкенду портала POST-запрос.
Бэкенд портала управления отправляет команду серверу через утилиту salt.
Утилита salt по unix-сокету ставит задание в Salt Мастер (служба salt-master) на контроллере домена.
Salt Мастер на контроллере домена передает задание в ZeroMQ.
ZeroMQ передает задание службе Salt Миньона на файловом сервере, которая подключена к ZeroMQ по порту 4505.
Salt Minion на файловом сервере выполняет изменения в файле
/etc/samba/smb.conf, перезагружает параметры и отчитывается о результатах в ZeroMQ по порту 4506.ZeroMQ передает результаты в службу Salt Мастер.
Salt Мастер возвращает результаты выполнения команды утилите salt.
Утилита Salt возвращает результаты Бэкенду портала управления.
Бэкенд портала возвращает результат POST-запроса Фронтенду.
Ожидаемые изменения в ALD Pro 2.4.0
В версии 2.4.0 ожидается значительное повышение надежности скриптов установки, настройки и обновления подсистем.
В настоящий момент передача команд на установку и обновление подсистем выполняется с использованием шины данных ZeroMQ от SaltStack. Это крайне удобный механизм централизованного управления, который отлично подходит для оркестрации приложений в датацентрах с хорошей сетевой связанностью, но в ИТ-инфраструктуре крупных предприятий с высокой географической распределенностью с ним иногда возникают проблемы.
Для повышения надежности скриптов установки, настройки и обновления подсистем передача информации до целевых систем будет реализована через LDAP-каталог. Такие изменения потребуют пересмотра подходов к управлению подсистемами от императивных заданий автоматизации к декларативным описаниям целевого состояния, но вместе с тем позволят использовать расширенную ролевую модель для распределения прав доступа на управление подсистемами в зависимости от положения сервера в иерархии структурных подразделений.
Администраторам будет доступна как централизованная установка подсистем с портала управления, так и установка вручную непосредственно с целевого хоста с занесением необходимой информации в каталог.
Подсистема «Общий доступ к файлам»
Подсистема общего доступа к файлам ALD Pro реализована на базе программного обеспечения Samba, которое позволяет серверу Linux предоставлять доступ к своим ресурсам по протоколу общего доступа к сетевым файлам CIFS (Common Internet File System) аналогично тому, как это делает сервер Windows.
Протокол CIFS является диалектом протокола SMB (Server Message Block) от компании Microsoft, и оба названия могут использоваться как синонимы. Следует понимать, что этот протокол позволяет выполнять любые удаленные вызовы (Remote Protocol Calls, RPC), поэтому через него в Windows работает не только общий доступ к файлам и принтерам, но и такие функции, как NETLOGON и LSA. Этой особенностью протокола объясняется, почему в Samba были реализованы в том числе функции контроллеров домена NT4 и Active Directory.
В настоящее время Samba представляет собой комбайн со множеством функций и настроек, некоторые из которых даже несовместимы друг с другом, поэтому для правильной настройки этой службы нужно знать ее архитектуру и особенности каждого из режимов работы.
Архитектура подсистемы
Основными компонентами Samba на файловом сервере являются следующие, см. рис. 279:
smdb – служба, реализующая доступ к ресурсам сервера по SMB на порту 445/TCP.
nmdb – служба, реализующая NetBIOS. Используется для разрешения NetBIOS имен в IP-адреса.
winbind – клиентская часть, которая позволяет хосту быть участником домена Active Directory. Служба используется, например, для автоматического обнаружения контроллеров домена, преобразования идентификаторов, NTLM-аутентификации. В настоящий момент служба считается устаревшей, и часть ее функций передана SSSD.
sssd – клиентская часть, которая позволяет хосту быть участником домена. На серверах с Samba служба SSSD берет на себя часть функций winbind, иногда ограничивая возможности Samba.
Например, разработчики SSSD по соображениям безопасности принципиально против реализации в своем продукте поддержки протокола NTLM, поэтому, если файловый сервер Samba устанавливается совместно со службой SSSD, то проксирование аутентификационных запросов по протоколу NTLM будет невозможно.
ipsam passdb – модуль passdb позволяет Samba работать в режиме автономного сервера (standalone), извлекая информацию о пользователях и паролях из локальной базы данных.
Реализация модуля ipasam позволяет вместо локальной базы использовать данные из LDAP-каталога. При подключении к каталогу модуль выполняет аутентификацию по протоколу Kerberos, а для шифрования трафика использует GSSAPI SASL, поэтому допустимо обращение к каталогу не только по unix-сокету, но и по сети.
рис. 279 Архитектура подсистемы общего доступа к файлам
Обратите внимание на два дополнительных компонента от ALD Pro:
salt-minion – эта служба отвечает за удаленную настройку подсистемы с контроллера домена. Через нее производится установка подсистемы и внесение настроек в основной конфигурационный файл
/etc/samba/smb.conf.aldpro-samba-discovery – эта служба отвечает за автоматическое обнаружение сервисов. Она выполняет поиск SRV-записей контроллеров домена и прописывает их в специальный атрибут passdb backend в конфигурационном файле
/etc/samba/smb.conf.
admin@file-1:~$ cat /etc/samba/smb.conf
[global]
. . .
passdb backend = ipasam:"ldap://dc-1.ald.company.lan:389 ldap://dc-2.ald.company.lan:389"
. . .
Установка подсистемы
Ранее мы уже создавали виртуальные машины для установки подсистем, но если вы этого не сделали, давайте напомним основные моменты:
Клонируйте машину «Стенд ALD Pro — file-1.ald.company.lan» из снимка, см. Не забывайте сгенерировать новый MAC-адрес для сетевого интерфейса, см. рис. 280.
рис. 280 Клонирование виртуальной машины
рис. 281 Генерация нового MAC-адреса
Назначьте сетевому интерфейсу адрес 10.0.1.26/24 через NetworkManager (или в файле
/etc/network/interfaces) и примените изменения.Введите компьютер в домен:
$ set +o history
$ sudo /opt/rbta/aldpro/client/bin/aldpro-client-installer --domain ald.company.lan --account admin -- password 'AstraLinux_174' --host file-1 --gui --force
$ set -o history
Перезагрузите машину:
$ sudo reboot
Теперь в портале управления на странице на вкладке назначьте эту роль новому серверу file-1. Для этого нажмите на кнопку и заполните карточку.
рис. 282 Добавление нового сервера общего доступа к файлам
Выберите сервер file-1.ald.company.lan из списка и укажите сайт «Головной офис». Чтобы применить изменения, нажмите на кнопку .
Привязка к сайту будет использоваться в будущих релизах для настройки гранулярного доступа. Планируется реализовать возможность делегирования прав на администрирование серверов в соответствии с их положением в иерархии структурных подразделений. Реализация этой функции станет возможна за счет перехода к управлению подсистемами через настройку их целевого состояния в LDAP-каталоге.
рис. 283 Назначение роли общего доступа к файлам на сервер file-1
Проверить выполнение скрипта автоматизации можно на странице , вкладка «Журнал заданий».
рис. 284 Журнал заданий автоматизации
Установка может занять 10-15 минут. В случае успешной установки вы увидите уведомление «Команда samba_install на file-1.ald.company.lan выполнена», а в списке заданий соответствующая строка будет иметь статус «успешно».
рис. 285 Успешная установка файлового сервера
Детальную информацию по выполнению отдельного шага задания можно получить на контроллере домена, с портала управления которого был запущен процесс развертывания подсистемы мониторинга, путем выполнения команды sudo salt-run jobs.print_job <jid>, где jid — это идентификатор задания, который можно скопировать из поля «Отчет о выполнении задания».
admin@dc-1:~$ sudo salt-run jobs.print_job 20240403202702272936
20240314215723654575:
----------
Arguments:
- aldpro.subsystems.smb.install
. . .
В портале управления в разделе « на вкладке появился новый сервер:
рис. 286 Файловый сервер, готовый к настройке
Работа с сервером общего доступа к файлам
Просмотр общих папок
На странице откройте карточку сервера и перейдите на вкладку .
рис. 287 Общие папки файлового сервера
После установки подсистемы на сервере создается общая папка shared, доступная по протоколу smb по адресу smb://file-1.ald.company.lan/shared. Вы можете открыть эту папку с любого компьютера в домене с аутентификацией по Kerberos, см. рис. 288. Если у вас не сработает Kerberos-аутентификация, проверьте, что у пользователя в связке ключей есть действительный TGT-билет.
рис. 288 Доступ к папке shared
Управление общей папкой
Откройте общую папку для того, чтобы перейти к ее настройкам. Перед вами будет три вкладки:
Основное – на этой вкладке вы можете изменить название папки и узнать ее текущий размер. Внизу справа расположена кнопка «Удалить папку» для выполнения соответствующего действия.
рис. 289 Основные настройки общей папки
Доступ пользователей – на вкладке представлен список пользователей, которым предоставлен доступ к папке на уровне SMB-подключения, с указанием типа предоставляемого права допуска (чтение/полный доступ). Для изменения прав доступа необходимо нажать на кнопку «Редактировать доступ». По умолчанию список пуст.
рис. 290 Права доступа для пользователей
Доступ групп – на вкладке представлен список групп, которым предоставлен доступ на уровне SMB-подключения.
Так как по умолчанию списки прав доступа для пользователей и групп пустые, то никто не имеет прав на общую папку. В этом можно убедиться, попробовав создать файл. Перейдем в окно менеджера файлов на pc-1, где мы открывали эту папку и попробуем создать файл.
рис. 291 Ошибка при создании файлов в случае отсутствия прав доступа
Назначение прав на общую папку
Предоставим полные права пользователю admin на общую папку. Для этого в карточке общей папки на вкладке «Доступ пользователей» кликнем на кнопку «редактировать доступ».
На карточке «Редактирование доступа пользователей» можно выбрать:
Чтение – доступ на просмотр.
Полный доступ – доступ на просмотр, добавление, изменение и удаление.
Выберем вариант «Полный доступ» и добавим пользователя «Administrator». Для применения не забудем нажать кнопку «Сохранить».
рис. 292 Назначение прав доступа на пользователя
После назначения прав доступа вы можете убедиться, что никаких ошибок при создании файлов больше не возникает.
Попробуйте отредактировать этот файл в текстовом редакторе Kate, после чего откройте сетевую папку из-под учетной записи другого пользователя, например, iivanov, и убедитесь, что файл ему недоступен. Предоставим права пользователю iivanov на чтение общей папки shared через портал управления, используя группу «moscow-office-employee-it».
рис. 293 Назначение прав доступа на группу
Обновите окно менеджера файлов и убедитесь, что пользователь iivanov получил право на просмотр файлов из общей папки, но у него нет прав на запись.
рис. 294 Проверка прав доступа на файлы
Создание общей папки
Для создания общей папки на карточке сервера общего доступа к файлам перейдем на вкладку «Общие папки» и кликнем по кнопке «+ Новая папка».
рис. 295 Создание новой общей папки
После создания новой общей папки вам нужно будет настроить права доступа на вкладках «Доступ пользователей» и «Доступ групп».
Если планируется, что общая папка будет занимать очень много места, вы можете разместить ее физически на другом диске и примонтировать через fstab. Физически она находится на сервере по адресу /opt/samba_shares/test_share.
Конфигурационный файл Samba-сервера
Все настройки при создании и изменении общих папок, выполняемых через портал управления сохраняются в конфигурационном файле Samba-сервера /etc/samba/smb.conf. Посмотрим его содержимое.
[global]
workgroup = ALDPRO
realm = ald.company.lan
log level = 7
domain master = No
domain logons = Yes
dedicated keytab file = FILE:/etc/samba/samba.keytab
kerberos method = dedicated keytab
log file = /var/log/samba/log.%m
passdb backend = ipasam:"ldap://dc-1.ald.company.lan:389 ldap://dc-2.ald.company.lan:389"
ldap group suffix = cn=groups,cn=accounts
ldap machine suffix = cn=computers,cn=accounts
ldap user suffix = cn=users,cn=accounts
ldap ssl = off
ldap suffix = dc=ald,dc=company,dc=lan
ldap admin dn = cn=Directory Manager
max log size = 100000
disable spoolss = Yes
security = user
create krb5 conf = No
rpc_daemon:lsasd = fork
rpc_daemon:epmd = fork
rpc_server:tcpip = yes
rpc_server:netlogon = external
rpc_server:samr = external
rpc_server:lsasd = external
rpc_server:lsass = external
rpc_server:lsarpc = external
rpc_server:epmapper = external
ldapsam:trusted = yes
idmap config \* : backend = tdb
restrict anonymous = 2
usershare allow guests = no
[homes]
browsable = yes
writable = yes
create mask = 0600
directory mask = 0700
valid users = %S
read only = No
guest ok = no
[shared]
path = /home/share
writable = yes
browseable = yes
valid users = admin, @moscow-office-employee-it
admin users = admin
read list = @moscow-office-employee-it
[test_share]
path = /opt/samba_shares/test_share
browseable = yes
valid users = @admin
В файле на файловом сервере ALD Pro присутствуют следующие разделы:
[global] – параметры этого раздела применяются к серверу в целом.
[homes] – в этом разделе задаются параметры для сетевых папок пользователей, которые будут «создаваться на лету» при обращении пользователей к файловому серверу. В этой секции должны быть определены следующие параметры:
«valid users = %S» — шаблон %S автоматически заменяется именем удаленного пользователя в тот момент, когда он пытается получить доступ к своему общему ресурсу.
Путь к каталогу отсутствует, по умолчанию он указывает на
/home/%S.Следует понимать, что папку пользователя на диске в каталоге /home/ нужно создать заранее, иначе пользователь будет видеть ее при подключении по SMB, но не сможет создавать в ней файлы.
[shared] – раздел с параметрами общей папки, создаваемой по умолчанию. Её путь указывает на
/home/share.[test_share] – раздел с параметрами общей папки, которую мы создали вручную.
Файл /etc/samba/smb.conf является основным конфигурационным файлом службы, но вы можете вносить в него изменения напрямую, т.к. при изменении настроек через портал управления содержимое конфигурационного файла обновляется инкрементально, а не полностью переопределяется по шаблону.
Если в секции [global] конфигурационного файла smb.conf задан параметр include = registry, то Samba будет включать настройки из базы /var/lib/samba/registry.tdb, которая имеет структуру, аналогичную реестру Windows. На файловых серверах реестр не используется, но на контроллерах домена это хранилище хранит большую часть настроек. Вы можете задействовать реестр на файловых серверах с той же целью.
Для управления реестром нужно запускать утилиту samba-regedit, параметры службы Samba хранятся в ветке реестра /HKEY_LOCAL_MACHINE/SOFTWARE/Samba/smbconf/.
Результирующие настройки можно увидеть с помощью утилиты testparm:
admin@dc-1:~$ sudo testparm
Load smb config files from /etc/samba/smb.conf
lpcfg_do_global_parameter: WARNING: The "domain logons" option is deprecated
Loaded services file OK.
Weak crypto is allowed
idmap range not specified for domain '*'
ERROR: Invalid idmap range for domain *!
Server role: ROLE_DOMAIN_PDC
Press enter to see a dump of your service definitions
# Global parameters
[global]
create krb5 conf = No
dedicated keytab file = FILE:/etc/samba/samba.keytab
disable spoolss = Yes
domain logons = Yes
domain master = No
kerberos method = dedicated keytab
ldap admin dn = cn=Directory Manager
ldap group suffix = cn=groups,cn=accounts
ldap machine suffix = cn=computers,cn=accounts
...
Аутентификация на файловом сервере Samba
Аутентификация по протоколу Kerberos
При установке подсистемы общего доступа к файлам Kerberos-аутентификация работает из коробки. Скрипты автоматизации присоединяют службу Samba к домену, выполняя следующие действия:
Создают запись «krbprincipalname=cifs/fs-1.ald.company.lan@ALD.COMPANY.LAN» в контейнере «cn=services,cn=accounts,dc=ald, dc=company,dc=lan».
Выгружают ключи этой учетной записи в файл /etc/samba/samba.keytab.
Указанная учетная запись используется службой Samba для проверки сервисных билетов Kerberos и получения информации из службы каталога по LDAP-протоколу. Содержимое keytab-файла можно посмотреть с помощью команды klist:
admin@dc-1:~$ sudo klist -ket /etc/samba/samba.keytab
Keytab name: FILE:/etc/samba/samba.keytab
KVNO Timestamp Principal
---- ------------------- ------------------------------------------------------
1 10.03.2024 16:38:27 cifs/file-1.ald.company.lan@ALD.COMPANY.LAN (aes256-cts-hmac-sha1-96)
1 10.03.2024 16:38:27 cifs/file-1.ald.company.lan@ALD.COMPANY.LAN (aes128-cts-hmac-sha1-96)
Требование использовать указанный keytab-файл задано в параметрах «kerberos method» и «dedicated keytab» конфигурационного файла smb.conf:
admin@dc-1:~$ sudo cat /etc/samba/smb.conf
[global]
...
kerberos method = dedicated keytab
dedicated keytab file = /etc/samba/samba.keytab
...
Кроме «dedicated keytab» служба Samba может работать еще в двух режимах:
system keytab, когда используется системный keytab-файл /etc/krb5.keytab.
secrets only, когда используется учетная запись из локальной базы secrets.tdb. Если kerberos method не задан, то служба работает в режиме secrets only по умолчанию.
Аутентификация по протоколу NTLM (по паролю)
Если подключаться к файловому серверу по IP-адресу или с компьютера, который не является участником домена, то служба smbd предложит выполнить аутентификацию по протоколу NTLMv2, и в сетевом трафике можно будет увидеть пакеты NTLMSSP.
Как вы помните, протокол аутентификации NTLM предполагает, что есть три участника: Клиент, Сервер и Контроллер домена. Сервер при получении запроса на аутентификацию должен сгенерировать «challenge» сообщение размером 8 байт и попросить Клиента зашифровать его своим паролем. Полученное от Клиента сообщение вместе с исходным числом Сервер должен передать для проверки Контроллеру, который проверяет аутентичность Клиента и сообщает о своем решении Серверу, см. рис. 296.
рис. 296 Поток данных при NTLM-аутентификации
Таким образом, в вопросах аутентификации пользователей файловый сервер должен действовать как участник домена, у которого нет прямого доступа к учетным данным. Именно так и работают режимы «security = domain» и «security = ads». Однако на файловом сервере ALD Pro устанавливается библиотека libwbclient от SSSD, которая не поддерживает перенаправление NTLM-запросов, поэтому данный механизм работать не будет.
Однако на файловом сервере ALD Pro служба smbd по умолчанию работает в режиме BDC NT4 контроллера домена (параметр «security» равен «user») и чисто технически может самостоятельно выполнять аутентификацию пользователей по паролю без проксирования запросов, извлекая ipaNTHash из LDAP-каталога с помощью модуля ipasam, см. параметр passdb backend в файле smb.conf:
security = user
passdb backend = ipasam:ldap://dc-1.ald.company.lan:389
Но из соображений безопасности учетная запись файлового сервера по умолчанию не имеет доступа к атрибуту ipaNThash, то есть модуль ipasam на файловом сервере участвует только в преобразовании идентификаторов. Если вам нужна NTLM-аутентификация и вы готовы администрировать файловый сервер теми же сотрудниками, кто отвечает за домен, то вам нужно назначить учетной записи сервера роль «ALDPRO - CIFS server»:
admin@dc-1:~$ ipa role-add-member "ALDPRO - CIFS server" --services=cifs/file-1.ald.company.lan
...
Имя роли: ALDPRO - CIFS server
Описание: Служебная роль для системных сервисов.
Privileges: CIFS server privilege
Службы-участники: cifs/file-1.ald.company.lan@ALD.COMPANY.LAN
-----------------------------------
Количество добавленных участников 1
-----------------------------------
После назначения роли «ALDPRO - CIFS server» файловый сервер сможет извлекать NTLM-хеш и выполнять проверку аутентичности пользователей по протоколу NTLM. Подключение к LDAP-каталогу модуль ipasam выполняет с использованием безопасной Kerberos-аутентификации, а трафик дополнительно шифруется механизмом SASL GSS-API Integrity.
И обратите внимание, что при выполнении NTLM-аутентификации файловый менеджер fly-fm предложит сохранить пароль в связке ключей gnome-keyring, которую не нужно путать со связкой ключей в ядре Linux, где лежат Kerberos-ключи.
Благодаря gnome-keyring пользователь может входить на файловый сервер по паролю без его повторного входа даже после перезагрузки машины. Физически пароль будет находиться в файле ~/.local/share/keyrings/login.keyring, поэтому для очистки кэша вы можете просто удалить этот файл или дополнительно установить удобный диспетчер паролей seahorse, см. рис. 297.
рис. 297 Просмотр NTLM-пароля в связке ключей Seahorse
Авторизация на файловом сервере Samba
Авторизация – это предоставление субъектам информационной системы доступа к ресурсам на основе разрешений. Такую модель называют дискреционной или избирательной (от англ. discretionary access control, DAC).
Для того чтобы одних пользователей можно было отличить от других, им назначаются уникальные имена и идентификаторы безопасности. Для авторизации по протоколу SMB используются идентификаторы SID в стиле Windows, а внутри Linux-систем мы работаем с POSIX-идентификаторами.
Мы уже знаем два существенных отличия между этими идентификаторами, которые оказывают значительное влияние на работу с общими файловыми ресурсами:
В идентификаторе Windows S-1-5-21-1491017894-2377586105-2170988794-500 последнее значение 500 идентифицирует субъект относительно домена, а предшествующие ему три числа 1491017894-2377586105-2170988794 предназначены для идентификации домена и совпадают для всех пользователей и групп. В POSIX мы имеем дело с обычными целыми числами от 0 до 2^32 (4 294 967 296), т.е. нет уникальной доменной части, поэтому для идентификации доменов приходится выделять в этом множестве отдельные диапазоны.
В системе Windows пользователи и группы находятся в одном пространстве идентификаторов SID, а в модели POSIX – это два разных непересекающихся множества: идентификаторы пользователей называют UID (User Identifier), а идентификаторы групп – GID (Group Identifier), поэтому пользователь root с идентификатором 0 и одноименная группа root с идентификатором 0 — это совершенно разные субъекты безопасности, что значительно затрудняет преобразование идентификаторов для обеспечения совместимости.
Извлечение авторизационной информации об участии пользователей в группах и преобразование идентификаторов могут выполнять следующие компоненты:
ipasam.so – модуль бэкенда базы данных, который обеспечивает работу Samba в режиме контроллера с извлечением данных из LDAP-каталога. Конкретно этот модуль был разработан специально для FreeIPA и учитывает особенности ее схемы данных.
cifs_idmap_sss.so – модуль для преобразования идентификаторов от sssd, который подключается, если в smb.conf для опции idmap config используется backend = sss.
libwbclient.so – модуль службы winbind, который должен использоваться для преобразования идентификаторов сторонних доменов. На компьютерах, где установлен freeipa-client, он заменен на модуль от sssd, в котором нет поддержки перенаправления NTLM-запросов на контроллер.
libnss_sss.so – модуль для NSS от SSSD, используется при обращении к функциям glibc операционной системой для извлечения информации о пользователях и группах, когда в nsswitch.conf источником базы указан sss.
Авторизация при подключении по Kerberos
Служба smbd имеет доступ к файлу /etc/samba/samba.keytab, что позволяет ей расшифровывать Kerberos-билеты и извлекать из них PAC-сертификат с информацией об участии пользователя в группах. В процессе авторизации участвуют службы sssd и winbind.
В журналах winbind вы сможете увидеть, что PAC-сертификат успешно раскодирован, но на этапе преобразования SID-идентификаторов в POSIX возникают ошибки, поэтому в конечном итоге информацию об участии пользователя в группах служба smbd берет через SSSD.
Ошибки возникают по причине того, что файловый сервер по умолчанию ставится как BDC-контроллер, поэтому SID хоста совпадает с SID домена, а в нашем случае нужно, чтобы SID у хоста был другим. Назначить новое значение можно, например, следующей командой:
net setlocalsid "S-1-5-21-$(shuf -i 1000000000-4294967295 -n 1)-$(shuf -i 1000000000-4294967295 -n 1)-
$(shuf -i 1000000000-4294967295 -n 1)"
После этого можно будет отключить passdb backend, установить режим ADS и перезагрузить службы сервера:
cat /etc/samba/smb.conf
...
#passdb backend = ...
security = ADS
...
С версии 2.4.0 указанные настройки будут применяться по умолчанию, и авторизация будет работать через PAC-сертификат.
Авторизация при подключении по NTLM
В случае NTLM-аутентификации служба winbind не требуется, информацию об участии пользователей в группах служба smbd получает через SSSD, см. параметр ipa_server в файле /etc/sssd/sssd.conf.
Особенности настройки прав доступа к файлам в Samba
В случае файлового сервера Samba ресурсами являются общие файлы, в роли субъектов выступают пользователи и группы, а разрешения, так же как для файлового сервера Windows, могут быть заданы на двух уровнях:
Сначала применяются разрешения на уровне SMB-подключения, которые задаются на вкладке «Share Permissions».
Затем дополнительно накладываются разрешения, установленные списками доступа файловой системы, которые задаются на вкладке «Security».
Если на уровне SMB-подключения пользователю предоставлены права только на чтение, то, имея даже «полный доступ» на уровне файловой системы, он все равно не сможет редактировать файлы в этой общей папке.
Разрешения на уровне SMB-подключения
Интерфейс Windows для настройки SMB-разрешений отображает шесть флажков, и может показаться, что их допустимо устанавливать в любом сочетании, см. рис. 298. Однако, если вы кликните по флажку «Allow Full Control», то увидите, что флажки «Allow Change» и «Allow Read» будут включены автоматически, то есть мы имеем дело фактически с одним выпадающим списком из трех значений, каждое из которых вбирает в себя разрешения предыдущих уровней.
рис. 298 Настройка SMB-разрешений в Windows
С флажками Deny еще интереснее: они точно так же, как флажки Allow, представляют собой один выпадающий список с тремя значениями, но при этом пользователь полностью потеряет право на подключение к общему ресурсу вне зависимости от того, какой из флажков вы установите: «Deny Read», «Deny Change» или «Deny Full Control».
В системе Windows разрешения SMB предоставляют следующие права:
Разрешение |
Описание |
|---|---|
Read (Чтение) |
Дает право:
|
Change (Изменение) |
Дополняет предыдущее разрешение следующими правами:
|
Full Control (Полный доступ) |
Дополняет предыдущее разрешение правами:
Разрешение Full Control имеет смысл только в том случае, если общая папка расположена на томе NTFS, который поддерживает списки доступа. |
В службе Samba для настройки SMB-разрешений предназначены две группы параметров:
одна группа определяет права на подключение;
вторая отвечает за уровень разрешений в рамках установленного подключения.
Права на подключение к общему ресурсу задаются двумя параметрами «valid users» и «invalid users» по алгоритму, который представлен на рисунке рис. 299.
Параметр |
Описание |
|---|---|
valid users |
Позволяет ограничить доступ к общей папке указанному списку пользователей и групп пользователей. Если параметр не задан, то по умолчанию доступ предоставляется всем пользователям. Служба Samba может работать с разными источниками групп, порядок обращения к которым задается специальными символами в начале имени группы:
Технология сетевых групп NIS уже устарела, но служба каталога FreeIPA ее поддерживает, и при установке клиента freeipa в конфигурационном файле |
invalid users |
Позволяет запретить доступ к общей папке указанному списку пользователей и групп пользователей. Если пользователь входит сразу в оба списка, и в «valid users» и в «invalid users», то доступ к общей папке этому пользователю будет запрещен. По умолчанию параметр не задан. |
рис. 299 Алгоритм определения прав на подключение к общему ресурсу
Если подключение разрешено, то доступ может быть либо на чтение, либо на запись. Права доступа определяются параметрами «read list», «write list», «read only» и «writable» по алгоритму, который представлен на рисунке рис. 300.
Параметр |
Описание |
|---|---|
read list |
Определяет список пользователей и групп пользователей, доступ которых будет ограничен правами на чтение. Параметр «read list» имеет смысл, если пользователям по умолчанию предоставлены права на запись с помощью параметров «writable = YES» или «read only = NO». Параметр «read list» не действует, если пользователя явно включили в «write list». |
write list |
Определяет список пользователей и групп пользователей, которым будет предоставлен доступ «на изменение», т.е. «чтение» + «запись». Если пользователь через разные группы входит сразу и в «read list» и в «write list», то этому пользователю будут предоставлены права на изменение. |
read only |
Определяет уровень доступа «по умолчанию» для пользователей, которые не включены в списки «read list» и «wrtie list». Если параметр не задан, предполагается, что «read only = yes», поэтому пользователи будут ограничены правами на «чтение». |
writable или writeable |
Параметры writable и writeable являются синонимами, допустимо использовать любое написание. Оба параметра являются инверсией параметру read only, поэтому не имеет разницы, что вы укажете «read only = yes» или «writable = no». Если параметры заданы несколько раз, то силу имеет последнее из указанных значений. |
рис. 300 Алгоритм определения прав доступа к общему ресурсу
Учитывая особенность алгоритма, для разграничения прав доступа используют одну из следующих стратегий:
Разрешают всем пользователям «чтение» и далее расширяют кому-то из них права до уровня «изменение» с помощью «write list».
writable = no
write list = editor_user_1 editor_user_2
Разрешают всем пользователям «запись» по умолчанию и далее урезают права для определенных пользователей с помощью «read list» (так сделано в ALD Pro).
writable = yes
read list = reader_user_1 reader_user_2
Схемы предоставления прав доступа Windows и Samba немного отличаются, поэтому можно привести только частичное соответствие:
Права Windows |
Права Samba |
|---|---|
Allow Read |
Права доступа «Чтение». Субъект нужно включить в списки:
|
Allow Write |
Нет полного соответствия, т.к. добавление пользователя в «write list» дает ему не только права на запись, но и права на изменение прав доступа к объектам, если он является их владельцем. |
Allow Full Control |
Права доступа «Полный доступ в соответствии с ACL файловой системы». Субъект нужно включить в списки:
Для информации. Изменение прав доступа будет возможно только из приложения |
Нет аналога |
Административный доступ, сейчас в интерфейсе ALD Pro называется «полный доступ». Субъект нужно включить в списки:
В этом случае пользователь будет действовать в общей папке от имени root в обход ACL файловой системы. Для информации. В настоящий момент ALD Pro не добавляет таких пользователей в список «write list», поэтому пользователь будет ограничен правами на чтение, если он одновременно является участником группы, которой дан такой уровень доступа. Добавьте пользователя в список «write list» вручную. С версии 2.4.0 эта настройка будет выполняться автоматически для данного уровня прав доступа. |
Deny Read, Deny Write или Deny Full Control |
Доступ запрещен. Субъект нужно включить в список «invalid users». |
Разрешения на уровне списков доступа файловой системы
Служба Samba работает от имени root, поэтому имеет доступ ко всем объектам файловой системы, но при обработке запросов от пользователей самостоятельно выполняет проверку прав, имитируя одну из доступных моделей безопасности. Вы можете выбрать любой из представленных режимов работы в зависимости от поставленной задачи:
Из коробки Samba максимально приближается к тому, как Linux работает с моделями RWX и UGO. Несовместимые атрибуты DOS, с помощью которых в Windows файл отмечается как «архивный», «скрытый» или «системный», можно отбрасывать (что снижает совместимость с Windows), сопоставлять со стандартными битами Execute (что снижает совместимость с Linux) или хранить в расширенных атрибутах файлов, если это поддерживается файловой системой.
Плагин acl_xattr позволяет значительно приблизиться к имитации Windows ACL, сохраняя часть информации в расширенных атрибутах, но продолжая активно использовать POSIX ACL, что дает возможность сохранить пользователям Linux прямой доступ к файлам.
Плагин nfs4acl_xattr переводит файловый сервер в режим максимальной совместимости с Windows ACL, сохраняя всю необходимую информацию в расширенных атрибутах файлов, но это исключает возможность работы с файлами напрямую.
Для подключения плагина в настройках сетевой папки нужно задать параметр vfs objects, например:
[test_share]
...
vfs objects = acl_xattr
Модель безопасности Linux
С моделью безопасности Linux, включающей как права «пользователь – группа – остальные», так и расширенную модель, использующую списки прав доступа POSIX ACL, мы подробно познакомились в курсе «Администратор рабочих мест под управлением ОС Astra Linux», поэтому мы не будем здесь подробно рассматривать этот аспект.
Вспомним только как работает алгоритм определения прав доступа к объекту файловой системы Linux с учетом ACL, см. рис. 301:
Если пользователь является владельцем, он получает права пользователя, и процедура завершается.
Если пользователь не является владельцем, но включен в ACL, то он получает права, указанные в списке доступа с учетом маски, и процедура завершается. Маска — это специальное правило POSIX ACL, которое определяет максимальные права доступа.
Если пользователь не является владельцем и не включен в список ACL, то проверка переходит на группы. Если пользователь является участником группы-владельца или одной из групп ACL, то он получает сумму этих прав с учетом маски, и процедура завершается.
Если пользователь не попал ни в одну из категорий, то он получает права, предназначенные для всех остальных пользователей.
рис. 301 Алгоритм определения прав доступа к объекту файловой системы Linux с учетом ACL
Специфика работы с правами доступа при подключении SMB-ресурса
Общий ресурс можно подключить, например, средствами FUSE в пространстве пользователя. Если требуется временный доступ, то в адресной строке можно просто ввести:
smb://file-1.ald.company.lan/test_share
Где:
smb — указывает на протокол SMB
file-1.ald.company.lan — fqdn файлового сервера
test_share — имя общего ресурса для подключения
Если требуется постоянный доступ к ресурсу, то в меню можно создать именованное подключение к сетевому ресурсу. В появившемся окне нужно задать имя ресурса и его адрес, как было указано выше.
рис. 302 Создание сетевого подключения
Еще один способ – это выполнить монтирование сетевого ресурса из-под привилегированной учетной записи с помощью библиотеки cifs-utils.
admin@dc-1:~$ sudo apt install cifs-utils
admin@dc-1:~$ sudo mount.cifs //file-1.ald.company.lan/test-share /home/admin/test-share/ -o sec=krb5i,cruid=$USER,uid=$UID,gid=$GROUPS,file_mode=0770,dir_mode=0770
Где:
sudo– необходимо, чтобы команда была выполнена с повышенными привилегиями, но в переменных $USER, $UID и $GORUPS были данные из переменных окружения текущего пользователя.//file-1.ald.company.lan/test-share— имя к сетевому ресурсу./home/admin/test-share— точка монтирования, этот каталог должен существовать на момент подключения сетевого ресурса.-o— ключ для определения параметров (options) подключения.sec=krb5i— определяет использование Kerberos-аутентификации с проверкой целостности пакетов.cruid=$USER— определяет владельца учетных данных Kerberos (credentials uid).uid=$UID— определяет, какой пользователь должен быть указан владельцем для объектов общего сетевого ресурса.gid=$GROUPS— определяет, какая группа должна быть указана владельцем для объектов общего сетевого ресурса.file_mode=0770— определяет, какие права доступа должны быть выставлены для файлов общего сетевого ресурса.dir_mode=0770— определяет, какие права доступа должны быть выставлены для каталогов общего сетевого ресурса.
После перезагрузки компьютера монтирование не сохранится. Если требуется постоянный доступ к ресурсу, монтирование можно выполнить с помощью fstab.
Вне зависимости от способа подключения общего ресурса работа с ним будет существенно отличаться от работы с файлами в проводнике Windows или при локальном обращении к файлам, т.к. вы будете видеть не действительные права доступа и владельцев, как они заданы на файловом сервере, а те значения, под которыми этот общий ресурс монтирован на текущем хосте.
При использовании FUSE ресурс монтируется в пользовательском пространстве, поэтому владельцем будет текущий пользователь и его первичная группа, на каталоги будут права «u=rwx,g=rx,o=rx», а на файлы «u=rwx,g=r,o=r». Именно поэтому пользователь сможет запустить любое приложение из общего ресурса, если на сервере у него есть права на чтение этого файла.
При монтировании ресурса с помощью cifs-utils параметры будут определяться значениями опций «uid», «gid», «file_mode» и «dir_mode». Если при подключении к ресурсу использовать Kerberos-аутентификацию, то настоятельно рекомендуется предоставлять права к файлам только владельцу этих учетных данных. Вы также можете выбрать, нужно ли ставить флаг execute и разрешать запуск приложений из монтируемой папки, или это будет излишне.
Модель безопасности из коробки
Из коробки Samba реализует проверку прав доступа к объектам файловой системы в стиле Linux.
Файловый менеджер fly-fm позволяет работать с расширенными ACL, но при добавлении новых пользователей и групп в списке отображаются только локальные пользователи файлового сервера. Чтобы добавить в список доменных пользователей, в настройках sssd.conf нужно включить опцию «enumerate = true»:
admin@dc-1:~$ sudo cat /etc/sssd/sssd.conf
...
[domain/ald.company.lan]
enumerate = true
...
Однако опция enumerate подойдет, только когда в домене несколько сотен пользователей. В больших инсталляциях она вызовет деградацию в работе службы SSSD, поэтому в этом случае для добавления субъектов рекомендуется использовать утилиту setfacl из командной строки. В ближайших релизах появится утилита, которая позволит добавлять пользователей и группы в ACL из графического интерфейса.
Рассмотрим еще несколько важных настроек. Если вы хотите предоставлять пользователям доступ напрямую, а не только по сети, то обязательно нужно отключить сопоставление DOS-атрибута «Аrchive» на флаг Execute владельца файла, иначе при создании файлов они будут иметь права «rwx r– r–». На файловых серверах ALD Pro атрибуты DOS сохраняются в расширенных атрибутах, поэтому сопоставление не требуется и только мешает.
[test_share]
...
map archive = no
Если общий ресурс располагается на диске, который смонтирован без поддержки расширенных атрибутов, то Samba может хранить DOS-атрибуты «Read-only», «Hidden», «Archive» и «System» в обычных битах доступа Linux, как показано на рисунке рис. 303.
рис. 303 Сопоставление DOS-атрибутов на разрешения Linux
Для того чтобы при создании новых файлов на сервере назначать им права доступа по умолчанию, можно воспользоваться параметрами «create mask» и «directory mask» или параметрами «force create mode» и «force directory mode» соответственно. Параметры «force» предпочтительнее, так как позволяют задавать в том числе флаг «Execute».
[test_share]
...
force create mode = 0666
force directory mode = 0777
Фиксированные права доступа выставляются на общую папку в целом и не могут быть переопределены для вложенных каталогов, поэтому в некоторых случаях удобнее будет использовать механизм наследования разрешений, который можно включить параметром «inherit permissions».
[test_share]
...
inherit permissions = yes
Если для параметра «inherit permissions» установлено значение «yes», то параметры «create mask», «directory mask», «force create mode» и «force directory mode» игнорируются. Новые каталоги наследуют те же разрешения, что и родительские каталоги. Новые файлы наследуют от родителя только биты чтения и записи, а биты Execute устанавливаться не будут из соображений безопасности, что подходит для обычных рабочих каталогов.
Модель безопасности ACL XATTR
Плагин acl_xattr имитирует работу Windows ACL, используя расширенные атрибуты в связке с базовыми возможностями POSIX ACL.
[test_share]
...
vfs objects = acl_xattr
Функции Windows ACL будут немного ограничены, но при этом останется частичная совместимость с Linux, поэтому с некоторыми оговорками пользователям можно давать прямой доступ к файлам при выполнении интерактивного входа в графический интерфейс или подключении к серверу по протоколам SSH, XRDP и др.
Администратор сможет управлять правами с помощью файлового менеджера Windows при подключении по SMB и с помощью файлового менеджера fly-fm при прямом обращении к файлам с сервера (не через SMB).
Модель безопасности NFS4 ACLs
Плагин nfs4acl_xattr максимально полно имитирует работу Windows ACL, сохраняя списки доступа NFS4 в виде бинарных объектов в расширенных атрибутах файлов (EAs/xattrs). Такой подход позволяет добиться максимальной совместимости с Windows, но исключает возможность предоставления пользователям прямого доступа к файлам, используя стандартные механизмы проверки прав доступа средствами Linux. Настраивать права доступа к таким общим папкам можно будет только из файлового менеджера Windows.
Практика и тестирование
Заключение
В этом модуле мы познакомились с подсистемой общего доступа к файлам, узнали, как выполнять ее установку и базовую настройку. Далее мы продолжим знакомство с подсистемами, а еще впереди у нас установка резервного контроллера!
Дополнительные источники информации
The Official Samba 3.2.x HOWTO and Reference Guide, Jelmer R. Vernooij, John H. Terpstra, and Gerald (Jerry) Carter (крайней версией Samba является 4, но в ней добавили только функции Active Directory, а код 3-й версии, который отвечал за общий доступ к файлам, был взят без существенных изменений, поэтому материалы предлагаемой книги все еще сохраняют свою актуальность).