Модуль 7. Дополнительные подсистемы ALD Pro
Введение
Из этого модуля вы узнаете о том, как с помощью штатных подсистем ALD Pro закрыть базовые потребности предприятий по обеспечению общего доступа к файлам. Мы рассмотрим не только процесс установки и настройки подсистемы через портал управления, но и разберем, как работают лежащие в ее основе компоненты, поэтому материал будет полезен даже в том случае, если вам потребуется настроить все врукопашную.
Процедура развертывания подсистем
Давайте сравним процесс установки ролей Windows и подсистем ALD Pro.
Установка ролей в Windows Server
Операционная система Windows из соображений безопасности по умолчанию устанавливается в минимальной комплектации, что позволяет администраторам настраивать сервера, которые будут выполнять только строго возложенные на них функции без чего бы то ни было лишнего. Процедура установки дополнительного программного обеспечения из состава операционной системы называется добавлением роли или компонентов (Add Roles and Features).
Серверные роли определяют основную функцию сервера в инфраструктуре предприятия, какие услуги он предоставляет пользователям или другим серверам в сети, например, контроллер домена, файловый сервер, принт-сервер, веб-сервер и т.д. Компоненты системы — это дополнительные приложения, которые устанавливаются вместе с ролями для расширения функциональности. Например, для роли веб-сервера можно дополнительно включить службу FTP или функцию публикации WebDAV.
Установка выполняется из Диспетчера сервера (англ. Server Manager) с помощью Мастера добавления ролей и компонентов (англ. Add Roles and Features Wizard), см. рис. 329.
рис. 329 Установка ролей из диспетчера сервера
Запустить приложение можно как непосредственно с того сервера, которым планируется управлять, так и с любого другого рабочего места. В этом случае Мастер установки будет выполнять PowerShell-командлеты удаленно по протоколу Windows Remote Management (WinRM), который является частной реализацией SOAP-протокола WS-Management, см. рис. 330. По умолчанию протокол WinRM должен быть включен на всех серверах Windows.
рис. 330 Удаленная установка ролей через 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, одна из которых нужна для установки контроллера, а семь оставшихся вы можете использовать для установки любых подсистем.
Процедура установки подсистемы предполагает два шага: сначала сервер вводится в домен, а затем на него через портал управления назначается необходимая роль. До вресии ALDPro 2.4.0 повышение роли сервера, передача команд на установку и обновление подсистем выполнялась через шины данных ZeroMQ от SaltStack. Это удобный механизм централизованного управления, который отлично подходит для оркестрации приложений в датацентрах с хорошей сетевой связанностью. Однако, в ИТ-инфраструктуре крупных предприятий с высокой географической распределенностью его производительность в ряде случаев падает:
По мере роста в домене количества рабочих станций нагрузка на серверы со стороны SaltStack становилась слишком высокой. Это вызывало проблемы с аутентификацией пользователей: они не могли войти в домен.
После перезагрузки salt-master все клиенты (миньоны) одновременно пытались подключиться к нему, что создавало высокую нагрузку на контроллер домена. В результате к контроллеру подключалась лишь часть клиентов, а остальные прекращали попытки по истечении таймаута.
На основе опыта и обратной связи от пользователей в версии ALDPro 2.4.0 процесс установки, обновления, удаления и конфигурирования подсистем был изменен. Разворачивание, обновление, управление подсистемами и репликация КД теперь работает по pull-модели.
Общая схема
Учитывая, что репликация LDAP работает не мгновенно и обеспечивает целостность данных только в конечном итоге, в версии ALDPro 2.4.0 перешли от «заданий автоматизации» к концепции настройки через «целевое состояние». В каталог будет записана метаинформация, описывающая желаемое конечное состояние, а не конкретные шаги по его достижению.
Мета-информация хранится в атрибутах учетной записи хоста, т. к. она имеет прямое отношение к конкретному хосту. Такое решение позволяет задействовать ролевую модель для управления правами доступа на конфигурирование подсистем — если у пользователя нет прав на изменение атрибутов учетной записи хоста, то он не сможет управлять этой подсистемой.
Пример потока данных при установке на PC_32 реплики контроллера домена отображен на рис. 331:
В панели управления контроллера домена DC_1 администратор как обычно назначает хосту PC_32 роль контроллера домена в сайте головного офиса hq. Логин/пароль привилегированной учетной записи для продвижения сервера до контроллера домена не требуется.
Бэкенд портала управления контроллера DC_1 создает для компьютера индивидуальную пользовательскую учетную запись с ограниченным сроком действия (например, в один день), назначает на нее необходимые роли и записывает данные этой учетной записи в защищенный атрибут компьютера rbta_subsystem_credentions. Метаинформацию о целевом состоянии хоста бэкенд вписывает в атрибут rbta_subsystem_metainfo.
Контроллер DC_1 передает изменения в учетной записи компьютера на контроллер DC_2 в порядке штатной репликации.
Хост PC_32 извлекает метаинформацию из LDAP каталога контроллера DC_2 в рамках процедуры применения групповых политик каждые полчаса и начинает установку подсистемы в соответствии с указанным целевым состоянием. Выполнение процедуры может быть форсировано по требованию администратора путем выполнения команды aldpro-gpupdate –pm.
Хост PC_32 после установки подсистемы записывает в LDAP каталог контроллера DC_2 результаты установки путем изменения метаинформации в атрибуте своей учетной записи.
Контроллер DC_2 передает информацию на контроллер DC_1 в порядке штатной репликации
Бэкенд портала управления контроллера DC_1 вычитывает информацию из каталога через бэкенд при обновлении страницы.
рис. 331 Поток данных при установке реплики контроллера
Жизненный цикл подсистем
Учитывая сложность изменений, которые нужно вносить на целевом хосте при установке, обновлении и настройке подсистем, далеко не все изменения принципиально возможны и должны быть разрешены. Например, не следует разрешать установку двух подсистем на один хост или установку контроллера домена после удаления роли файлового сервера. Поэтому для управления подсистемами определен конечный набор состояний и допустимых переходов между ними, например, см. рис. рис. 332
рис. 332 Жизненный цикл подсистем
рис. 333 Машина состояний подсистем
Контроль допустимых переходов должен выполняться как на портале управления так и на самой подсистеме. Интерфейс портала управления должен исключать возможность внесения конфликтующих изменений, например, если на целевой хост уже назначена роль файлового сервера, такой хост должен быть недоступен для продвижения до контроллера домена.
Однако, механизмов контроля на портале управления недостаточно, т. к. контроллер домена может не обладать актуальной информацией о состоянии системы, поэтому конечную проверку непротиворечивости состояний выполняет сам целевой хост. Получив новое состояние хост должен сам принять решение, является ли такое состояние допустимым или нет. Если состояние допустимо, то хост начинает переход в новое состояние. Если перейти в указанное состояние невозможно, то хост записывает в каталог текущее состояние. Журнал с информацией о принятых и отклоненных состояниях храниться также в 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 на файловом сервере:
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-сокету, но и по сети.
После успешной установки подсистемы, администратор может приступить к настройке сетевых папок на файловом сервере. Информация хранится и передается через LDAP каталог. В этот каталог включаются только те атрибуты, которые можно изменять через интерфейс портала управления.
рис. 334 Поток данных при установке файлового сервера
Установка подсистемы
Диаграмма состояний файлового сервера соответствует диаграмме состояний на рисунке рис. 333, за исключением того, что после удаления файлового сервера, мы не можем использовать машину повторно в качестве любой подсистемы, не переустанавливая ОС.
рис. 335 Жизненный цикл файлового сервера
Ранее мы уже создавали виртуальные машины для установки подсистем, но если вы этого не сделали, давайте напомним основные моменты:
Клонируйте машину Стенд ALD Pro — file-1.ald.company.lan из снимка, см. Не забывайте сгенерировать новый MAC-адрес для сетевого интерфейса, см. рис. 336.
рис. 336 Клонирование виртуальной машины
рис. 337 Генерация нового 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 'Pa$$w0rd' --host file-1 --gui --force
$ set -o history
Перезагрузите машину:
$ sudo reboot
Теперь в портале управления на странице на вкладке назначьте эту роль новому серверу file-1. Для этого нажмите на кнопку и заполните карточку.
рис. 338 Добавление нового сервера общего доступа к файлам
Выберите сервер file-1.ald.company.lan из списка и укажите сайт «Головной офис». Чтобы применить изменения, нажмите на кнопку .
Привязка к сайту будет использоваться в будущих релизах для настройки гранулярного доступа. Планируется реализовать возможность делегирования прав на администрирование серверов в соответствии с их положением в иерархии структурных подразделений.
рис. 339 Назначение роли общего доступа к файлам на сервер file-1
Проверить выполнение скрипта автоматизации можно на странице , вкладка «Основное».
рис. 340 Журнал заданий автоматизации
Установка начнется в течении 30 минут. В ALD Pro версии 2.4.0 после применения политики обновления необходимо выполнить команду:
sudo aldpro-gpupdate --pm
В версии 2.2.0 мы перешли на автономную службу salt-minion. Она обеспечила высокую производительность механизма групповых политик. В версии 2.4.0 мы закрепили этот успех и перевели на этот механизм управление подсистемами. Вместе с тем у этого решения есть недостаток - невозможность форсировать применение политик и настроек по инициативе сервера. Работа над улучшением ведется, но пока приходится ждать или форсировать применение изменений вручную.
Следующая команда собирает pillar на основе переменных окружения из ldap и запускает установку/обновление/удаление;
sudo aldpro-roles --iud --action [install, update, remove]
Чтобы немедленно применить новые параметры заданные через портал управления, требуется выполнить команду:
sudo aldpro-roles --subsystem_settings smb
Эта команда собирает pillar переменных окружения из ldap и применяет параметры для указанной подсистемы.
Внимание
Командой aldpro-roles нельзя одновременно установить подсистему и обновить для нее настройки из LDAP-каталога. Следующая команда вызовет ошибку: aldpro-roles --iud --action install --subsystem_settings smb.
В случае успешной установки в портале управления в разделе « на вкладке появится новый сервер:
рис. 341 Файловый сервер, готовый к настройке
Работа с сервером общего доступа к файлам
Просмотр общих папок
На странице откройте карточку сервера и перейдите на вкладку .
рис. 342 Общие папки файлового сервера
Если после установки подсистемы на сервере создать общую папку shared, она будет доступна по протоколу smb по адресу smb://file-1.ald.company.lan/shared. Вы можете открыть эту папку с любого компьютера в домене с аутентификацией по Kerberos, см. рис. 343. Если у вас не сработает Kerberos-аутентификация, проверьте, что пользователю назначены права доступа на эту папку и в связке ключей у него есть действительный TGT-билет.
рис. 343 Доступ к папке shared
Управление общей папкой
Откройте общую папку для того, чтобы перейти к ее настройкам. Перед вами будет три вкладки:
Основное – на этой вкладке вы можете изменить название папки, а также:
выбрать тип виртуальной файловой системы,
указать будет ли эта папка доступна для просмотра в браузерах сетевых ресурсов (Browsable = yes - папка будет доступна для просмотра).
можно ли создавать правила доступа к папке на основе пользователей и групп (Access based share enum = yes - можно)
установить права доступа для новых файлов и каталогов
включить или отключить наследование прав доступа от родительской папки
Внизу справа расположена кнопка «Удалить папку» для выполнения соответствующего действия.
рис. 344 Основные настройки общей папки
Доступ пользователей – на вкладке представлен список пользователей, которым предоставлен доступ к папке на уровне SMB-подключения, с указанием типа предоставляемого права допуска (чтение/полный доступ). Для изменения прав доступа необходимо нажать на кнопку «Редактировать доступ». По умолчанию список пуст.
рис. 345 Права доступа для пользователей
Доступ групп – на вкладке представлен список групп, которым предоставлен доступ на уровне SMB-подключения.
Так как по умолчанию списки прав доступа для пользователей и групп пустые, то никто не имеет прав на общую папку. В этом можно убедиться, попробовав создать файл. Перейдем в окно менеджера файлов на pc-1, где мы открывали эту папку и попробуем создать файл.
рис. 346 Ошибка при создании файлов в случае отсутствия прав доступа
Назначение прав на общую папку
Предоставим полные права пользователю admin на общую папку. Для этого в карточке общей папки на вкладке «Доступ пользователей» кликнем на кнопку «редактировать доступ».
На карточке «Редактирование доступа пользователей» можно выбрать:
Чтение – доступ на просмотр.
Полный доступ – доступ на просмотр, добавление, изменение и удаление.
Выберем вариант «Полный доступ» и добавим пользователя «Administrator». Для применения не забудем нажать кнопку «Сохранить».
рис. 347 Назначение прав доступа на пользователя
После назначения прав доступа вы можете убедиться, что никаких ошибок при создании файлов больше не возникает.
Попробуйте отредактировать этот файл в текстовом редакторе Kate, после чего откройте сетевую папку из-под учетной записи другого пользователя, например, iivanov, и убедитесь, что файл ему недоступен. Предоставим права пользователю iivanov на чтение общей папки shared через портал управления, используя группу «moscow-office-employee-it».
рис. 348 Назначение прав доступа на группу
Обновите окно менеджера файлов и убедитесь, что пользователь iivanov получил право на просмотр файлов из общей папки, но у него нет прав на запись.
рис. 349 Проверка прав доступа на файлы
Создание общей папки
Для создания общей папки на карточке сервера общего доступа к файлам перейдем на вкладку «Общие папки» и кликнем по кнопке «+ Новая папка».
рис. 350 Создание новой общей папки
После создания новой общей папки вам нужно будет настроить права доступа на вкладках «Доступ пользователей» и «Доступ групп».
Если планируется, что общая папка будет занимать очень много места, вы можете разместить ее физически на другом диске и примонтировать через fstab. Физически она находится на сервере по адресу /opt/samba_shares/test_share.
Конфигурационный файл Samba-сервера
До вресии 2.4.0 все настройки при создании и изменении общих папок, выполняемых через портал управления сохраняются в конфигурационном файле 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] – раздел с параметрами общей папки, которая в версии до 2.4.0 создавалась по умолчанию. Её путь указывает на
/home/share.[test_share] – раздел с параметрами общей папки, которую создали вручную.
Начиная с версии 2.4.0 часть настроек перенесена в LDAP, а passdb backend больше не используется. Теперь конфигурация Samba генерируется по шаблону:
[global]
workgroup = ALD
realm = ALD.COMPANY.LAN
dedicated keytab file = FILE:/etc/samba/samba.keytab
kerberos method = dedicated keytab
idmap config ALD : 1457400000-1457599999
idmap config ALD : backend = sss
idmap config * : range = 0-0
log file = /var/log/samba/log.%m
include = registry
include = /etc/samba/share.conf
[homes]
browsable = yes
writable = yes
create mask = 0600
directory mask = 0700
valid users = %S
read only = No
guest ok = no
Здесь:
ALD - это значение до первой точке в имени домена в верхнем регистре.
1457400000-1457599999 - это диапазон id. Он расчитывается по формуле из атрибутов записи cn=ALD.COMPANY.LAN_id_range,cn=ranges,cn=etc,dc=ald,dc=company,dc=lan:
первое число -
ipaBaseIDвторое число -
ipaBaseID + ipaIDRangeSize - 1
include = /etc/samba/share.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/file-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 байт и попросить Клиента зашифровать его своим паролем. Полученное от Клиента сообщение вместе с исходным числом Сервер должен передать для проверки Контроллеру, который проверяет аутентичность Клиента и сообщает о своем решении Серверу, см. рис. 351.
рис. 351 Поток данных при 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, см. рис. 352.
рис. 352 Просмотр 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.
До версии 2.4.0 в журналах 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-разрешений отображает шесть флажков, и может показаться, что их допустимо устанавливать в любом сочетании, см. рис. 353. Однако, если вы кликните по флажку «Allow Full Control», то увидите, что флажки «Allow Change» и «Allow Read» будут включены автоматически, то есть мы имеем дело фактически с одним выпадающим списком из трех значений, каждое из которых вбирает в себя разрешения предыдущих уровней.
рис. 353 Настройка 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» по алгоритму, который представлен на рисунке рис. 354.
Параметр |
Описание |
|---|---|
valid users |
Позволяет ограничить доступ к общей папке указанному списку пользователей и групп пользователей. Если параметр не задан, то по умолчанию доступ предоставляется всем пользователям. Служба Samba может работать с разными источниками групп, порядок обращения к которым задается специальными символами в начале имени группы:
Технология сетевых групп NIS уже устарела, но служба каталога FreeIPA ее поддерживает, и при установке клиента freeipa в конфигурационном файле |
invalid users |
Позволяет запретить доступ к общей папке указанному списку пользователей и групп пользователей. Если пользователь входит сразу в оба списка, и в «valid users» и в «invalid users», то доступ к общей папке этому пользователю будет запрещен. По умолчанию параметр не задан. |
рис. 354 Алгоритм определения прав на подключение к общему ресурсу
Если подключение разрешено, то доступ может быть либо на чтение, либо на запись. Права доступа определяются параметрами «read list», «write list», «read only» и «writable» по алгоритму, который представлен на рисунке рис. 355.
Параметр |
Описание |
|---|---|
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». Если параметры заданы несколько раз, то силу имеет последнее из указанных значений. |
рис. 355 Алгоритм определения прав доступа к общему ресурсу
Учитывая особенность алгоритма, для разграничения прав доступа используют одну из следующих стратегий:
Разрешают всем пользователям «чтение» и далее расширяют кому-то из них права до уровня «изменение» с помощью «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» вручную. |
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, см. рис. 356:
Если пользователь является владельцем, он получает права пользователя, и процедура завершается.
Если пользователь не является владельцем, но включен в ACL, то он получает права, указанные в списке доступа с учетом маски, и процедура завершается. Маска — это специальное правило POSIX ACL, которое определяет максимальные права доступа.
Если пользователь не является владельцем и не включен в список ACL, то проверка переходит на группы. Если пользователь является участником группы-владельца или одной из групп ACL, то он получает сумму этих прав с учетом маски, и процедура завершается.
Если пользователь не попал ни в одну из категорий, то он получает права, предназначенные для всех остальных пользователей.
рис. 356 Алгоритм определения прав доступа к объекту файловой системы Linux с учетом ACL
Специфика работы с правами доступа при подключении SMB-ресурса
Общий ресурс можно подключить, например, средствами FUSE в пространстве пользователя. Если требуется временный доступ, то в адресной строке можно просто ввести:
smb://file-1.ald.company.lan/test_share
Где:
smb — указывает на протокол SMB
file-1.ald.company.lan — fqdn файлового сервера
test_share — имя общего ресурса для подключения
Если требуется постоянный доступ к ресурсу, то в меню можно создать именованное подключение к сетевому ресурсу. В появившемся окне нужно задать имя ресурса и его адрес, как было указано выше.
рис. 357 Создание сетевого подключения
Еще один способ – это выполнить монтирование сетевого ресурса из-под привилегированной учетной записи с помощью библиотеки 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, как показано на рисунке рис. 358.
рис. 358 Сопоставление 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-й версии, который отвечал за общий доступ к файлам, был взят без существенных изменений, поэтому материалы предлагаемой книги все еще сохраняют свою актуальность).
Обратная связь
Если остались вопросы, то их всегда можно задать в специальной теме.