Разбираемся с работой SAMBA в корпоративном домене

1. Состав и архитектура подсистемы общего доступа к файлам ALD Pro

2. Настройки файлового сервера Samba

3. Аутентификация по паролю (NTLM)

4. Kerberos-аутентификация на файловом сервере Samba

5. Авторизация на файловом сервере Samba на уровне SMB-подключения

6. Авторизация на уровне ACL файловой системы

7. Специфика работы с правами доступа при подключении SMB-ресурса

8. Настройка ACL в Linux

1. Состав и архитектура подсистемы общего доступа к файлам ALD Pro

В основе службы каталога ALD Pro лежит FreeIPA, а сердцем нашего файлового сервера является служба smbd (Samba), которая обеспечивает доступ к ресурсам по протоколу Server Message Block, SMB. Данный протокол реализует клиент-серверную архитектуру и позволяет предоставить доступ к файлам, которые находятся на удаленных хостах. Но стоит добавить, что протокол SMB - это не только доступ к файлам, так как через общий ресурс IPC$ приложения могут обращаться к именованным каналам, которые позволяют вызывать удаленные процедуры (Remote Procedure Call, RPC) и получать результаты их выполнения. Например, когда мы в Windows открываем свойства папки, чтобы посмотреть список доступа ACL, клиентский компьютер по протоколу SMB обращается к каналу LSARPC на контроллере домена, чтобы с помощью процедуры LookupSids2 преобразовать идентификаторы субъектов безопасности в имена соответствующих пользователей и групп.

История проекта Samba началась, конечно же, с общего доступа к файлам, но, в силу особенностей протокола SMB, в дальнейшем появился доступ к принтерам, и была включена поддержка доменов NT4/AD. С расширением функциональности продукта увеличивалось и количество настроек, поэтому некоторые из них устарели или начали конфликтовать с другими настройками, так как отвечали за несовместимые режимы работы. Поэтому настройка всего этого "разнотравья" является сейчас крайне непростой задачей.

Архитектура подсистемы общего доступа к файлам ALD Pro представлена на следующем рисунке. В качестве основных компонентов Samba можно выделить:

• smbd – служба, реализующая доступ к ресурсам сервера по протоколу SMB, использует порт 445/TCP. Протокол SMB может работать поверх протокола NetBIOS, для этого служба smbd использует ещё и порт 139/TCP.

• nmbd – служба, обеспечивающая поддержку сервера имен NetBIOS (NetBIOS Name Server, NBNS), использует порты 137/UDP и 138/UDP.

• winbind – клиентская часть, которая позволяет Linux-серверу быть участником домена Active Directory. Служба Winbind позволяет выполнять автоматическое обнаружение контроллеров домена (в Windows эта функция называется DC Locator), преобразовывать идентификаторы безопасности Windows (SID) в POSIX-идентификаторы (UID/GID), выполнять исходящую NTLM-аутентификацию. В настоящий момент служба считается устаревшей и часть ее функций, например, преобразование идентификаторов, взяла на себя служба sssd.

• sssd – клиентская часть, которая позволяет хосту быть участником домена, когда на бэкенде находится служба каталога FreeIPA, Active Directory, MIT Kerberos или даже обычный каталог LDAP v3. На серверах с Samba служба sssd не только берет на себя часть функций winbind, но даже иногда ограничивает возможности последней. Например, разработчики sssd из соображений безопасности принципиально против реализации в своем продукте поддержки протокола NTLM, поэтому при установке winbind вместе с sssd возможность исходящей NTLM-аутентификации становится недоступна.

Осталось только в двух словах упомянуть SMB-клиенты, с помощью которых можно получить доступ к общим папкам файлового сервера. С компьютеров Astra Linux вы можете воспользоваться файловым менеджером, который работает через FUSE, утилитами из пакета cifs-utils, чтобы выполнить подключение вручную командой mount или прописать настройки подключения в fstab. А ещё можно воспользоваться довольно простым, но при этом очень функциональным приложением smbclient.

2. Настройки файлового сервера Samba

За установку и настройку файлового сервера в ALD Pro отвечает автономная служба aldpro-salt-minion, которая самостоятельно извлекает настройки из LDAP-каталога по pull-модели и выполняет конфигурирование системы. В выборе активного контроллера служба полагается на sssd, забирая результаты дискавера через ответчик ifp (infopipe) по dbus. Аутентификация выполняется по безопасному протоколу Kerberos V5 с помощью ключей хоста из файла /etc/krb5.keytab.

Основным конфигурационным файлом для служб smbd и winbind является /etc/samba/smb.conf. С версии 2.4.0 мы с помощью параметра include стали дополнительно подключать конфигурационный файл /etc/samba/share.conf, чтобы отдельно хранить настройки общих папок, и базу данных /var/lib/samba/registry.tdb, чтобы у системных администраторов была возможность переопределить любой параметр, назначаемый через портал управления:

cat /etc/samba/smb.conf
[global]
...
include = registry
include = /etc/samba/share.conf
...

Отметим также, что реестр в Samba можно подключить ещё двумя способами. Если установить параметр "registry shares = yes", то через реестр можно будет определять только параметры общих папок, а если использовать параметр "config backend = registry", то служба начнет использовать настройки только из реестра и будет игнорировать все остальные параметры конфигурационного файла. Мы, как нам кажется, выбрали наиболее универсальный функциональный вариант.

База данных registry.tdb имеет такую же структуру, как реестр Windows. Параметры Samba хранятся в ветке «/HKEY_LOCAL_MACHINE/SOFTWARE/Samba/smbconf/», а для работы с реестром вместо оснастки regedit.exe нужно использовать приложение samba-regedit. С помощью реестра для общей папки ALD Pro вы можете включить, например, параметр "case sensitive = yes", чтобы работать с ней как обычной Linux-папкой, в которой допустимо хранить объекты с одинаковыми именами "Test" и "test", но в разном регистре символов.

Результирующие настройки вы можете увидеть с помощью утилиты testparm. Если добавить ключ -v (verbose), то утилита выведет все параметры, в том числе и те, которые установлены в значении по умолчанию. 

root@pc-1:~# testparm -v
Load smb config files from /etc/samba/smb.conf
...
[test_share]
        case sensitive = Yes
...

3. Аутентификация по паролю (NTLM)

Если подключаться к файловому серверу по IP-адресу или с компьютера, который не является участником домена, то служба smbd попытается выполнить аутентификацию по паролю с использованием протокола NTLMv2, и в сетевом трафике можно будет увидеть пакеты NTLMSSP.

Протокол NTLM предполагает, что есть три участника: клиент, сервер приложения и контроллер домена. Клиент отправляет запрос на сервер и получает в ответ случайное число challenge, которое он должен зашифровать паролем пользователя для подтверждения его аутентичности. Получив от клиента зашифрованное сообщение, сервер пересылает его контроллеру домена вместе с исходным значением challenge, так как не может выполнить проверку аутентичности самостоятельно (серверу неизвестен пароль пользователя). Контроллер домена извлекает пароль пользователя из каталога, выполняет шифрование challenge тем же алгоритмом и сравнивает полученный результат с сообщением от клиента. Если значения совпали, то контроллер сообщит серверу, что проверка аутентичности прошла успешно.

Начиная с версии 2.4.0 мы полностью отказались от NTLM-аутентификации на файловом сервере по нескольким причинам:

• Во-первых, это просто небезопасно, т.к. протокол NTLM подвержен MITM-атакам.

• Во-вторых, в качестве клиентской части мы используем на хостах службу sssd, в которой нет поддержки NTLM, поэтому данный метод аутентификации можно обеспечить только в том случае, если переключить файловый сервер в режим контроллера домена NT4 с помощью параметра "security=user" и дать службе smbd прямой доступ к NTLM-хешам пользователей через модуль ipasam с помощью параметра "passdb backend = ipasam:'ldap://dc-1.company.lan:389,ldap://dc-2.company.lan:389,...'". Как вы понимаете, такой подход допустим только в маленьких организациях, если файловым сервером будут управлять те же сотрудники, которые отвечают за администрирование домена.

• В-третьих, если какие-то LDAP-серверы из списка passdb backend окажутся недоступны, то Samba становится крайне нерасторопной и начинает обижаться большими задержками вплоть до полного отказа в обслуживании.

Учитывая все вышесказанное, на своих файловых серверах мы настраиваем Samba в режиме безопасности ads, т.е. делаем сервер обычным рядовым участником домена, чего и вам желаем:

[global]
...
security = ads
...

Для работы Kerberos-аутентификации на сервере параметра security = ads недостаточно, но об этом будет далее.

4. Kerberos-аутентификация на файловом сервере Samba

Для настройки Kerberos-аутентификации на файловом сервере Samba наши скрипты автоматизации выполняют следующие действия:

• Создают учетную запись сервиса «krbprincipalname=cifs/fs-1.ald.company.lan@ALD.COMPANY.LAN» в контейнере «cn=services,cn=accounts,dc=ald,dc=company,dc=lan».

• Выгружают ключи этой учетной записи в keytab-файл /etc/samba/samba.keytab, содержимое которого можно посмотреть с помощью утилиты klist. Ключи нужны службе Samba для расшифровки Kerberos-билетов пользователей.

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)

• Настраивают в конфигурационном файле smb.conf параметры «kerberos method» и «dedicated keytab», чтобы переключить Samba-сервер на Kerberos-аутентификацию:

sudo cat /etc/samba/smb.conf

[global]
...
dedicated keytab file = FILE:/etc/samba/samba.keytab
kerberos method = dedicated keytab
...

Кстати, служба Samba может работать ещё в двух режимах: параметр system keytab настраивает службу на использование системного keytab-файла /etc/krb5.keytab, а параметр secrets only переключает ее на локальную базу secrets.tdb.

Теперь забежим немного вперед и затронем тему авторизации. Несмотря на то, что Kerberos является протоколом аутентификации, в его билетах есть поле Authorization Data, которое позволяет передавать в том числе авторизационную информацию об участии пользователя в группах. Для совместимости с MS Active Directory служба каталога FreeIPA использует так называемый PAC-сертификат (Privilege Attribute Certificate), в котором указан собственный идентификатор пользователя и идентификаторы всех его групп.

При формировании сертификата используются значения атрибута ipaNTSecurityIdentifier, в котором хранится SID в формате MS Windows. Для просмотра PAC-сертификата вы можете воспользоваться утилитой net из пакета samba-common-bin. В следующем примере мы запрашиваем сервисный билет на доступ к службе host/dc-1.ald.company.lan@ALD.COMPANY.LAN для пользователя admin@ALD.COMPANY.LAN и расшифровываем билет с помощью ключей из файла /etc/krb5.keytab. Запускать эту команду следует на хосте dc-1.

admin@dc-1:~$ sudo net ads kerberos pac dump -U admin@ALD.COMPANY.LAN local_service=host/dc-1.ald.company.lan@ALD.COMPANY.LAN --option='kerberos method = dedicated keytab' --option='dedicated keytab file = FILE:/etc/krb5.keytab' -s /dev/null --option='realm = ALD.COMPANY.LAN'

Password for [admin@ALD.COMPANY.LAN]:
The Pac:     pac_data_ctr->pac_dаta: struct PAC_DATA
...
                                                        rid                      : 0x00000200 (512)
...
                                                        rid                      : 0x000003eb (1003)
...

Значение ipaNTSecurityIdentifier рассчитывается службой каталога FreeIPA "автомагически" в момент создания субъекта безопасности в соответствии с настройками текущего диапазона идентификаторов, за что отвечает плагин sidgen. Сложность этих расчетов состоит в том, что SID-идентификаторы Windows и POSIX-идентификаторы Linux имеют несколько существенных отличий:

1. В идентификаторе Windows S-1-5-21-1491017894-2377586105-2170988794-500 последнее значение 500 идентифицирует субъект относительно домена (и называется относительным идентификатором RID), а предшествующие ему три числа 1491017894-2377586105-2170988794 предназначены для идентификации домена или компьютера и совпадают для всех пользователей и групп. В POSIX мы имеем дело с обычными целыми числами от 0 до 2³² (4 294 967 296), т. е. нет уникальной доменной части, поэтому для идентификации доменов в этом пространстве чисел выделяют просто отдельные диапазоны (т.н. ID Ranges).

2. В системе Windows пользователи и группы находятся в одном пространстве идентификаторов SID, а в модели POSIX это два разных непересекающихся множества: идентификаторы пользователей называют UID (User Identifier), а идентификаторы групп — GID (Group Identifier). Поэтому пользователь root с идентификатором 0 и его первичная группа root с идентификатором 0 — это два совершенно разных субъекта безопасности. По этой причине в службе каталога FreeIPA диапазоны идентификаторов имеют так называемый вторичный диапазон RID, идентификаторы которого используются для первичных групп пользователей, если при создании пользователя с предопределенным значением идентификатора UID в домене по какой-либо причине уже будет существовать группа с таким же значением идентификатора. Соотношение диапазонов ID Range и DNA ID Range показано на следующем рисунке:

5. Авторизация на файловом сервере Samba на уровне SMB-подключения

Авторизация – это предоставление субъектам доступа к ресурсам на основе разрешений. В случае SMB-сервера ресурсами являются файлы и папки, в роли субъектов выступают пользователи, а разрешения могут быть заданы на уровне SMB-подключения или через списки доступа объектов файловой системы (Access Control Lists, ACL).

Интерфейс Windows для настройки SMB-разрешений отображает шесть флажков, и может показаться, что их допустимо устанавливать в любом сочетании, как показано на нижеследующем рисунке. Однако, если вы кликнете по флажку Allow Full Control, то увидите, что флажки Allow Change и Allow Read будут включены автоматически. То есть мы имеем дело, фактически, с одним выпадающим списком из трех значений, каждое из которых вбирает в себя разрешения предыдущих уровней.

С флажками Deny ещё интереснее: они точно так же, как флажки Allow, представляют из себя один выпадающий список с тремя значениями. При этом пользователь потеряет право на подключение к общему ресурсу вне зависимости от того, какой из флажков вы установите — Deny Read, Deny Change или Deny Full Control.

В системе Windows разрешения SMB предоставляют следующие права:

В службе Samba для настройки SMB-разрешений предназначены две группы параметров:

• одна группа определяет права на подключение;

• вторая отвечает за уровень разрешений в рамках установленного подключения.

Права на подключение к общему ресурсу задаются двумя параметрами valid users и invalid users как показано на рисунке «Алгоритм определения прав на подключение к общему ресурсу» ниже.

При проверке прав доступа служба smbd конвертирует имена групп в идентификаторы SID и сверяет их с содержимым PAC-сертификата из Kerberos-билета пользователя. Преобразование идентификаторов служба smbd выполняет через службу winbind, но в конечном итоге эту задачу берет на себя служба sssd, которая встраивается в цепочку обработки этих запросов.

Если по результатам предварительной проверки служба smbd разрешит пользователю установить SMB-подключение, то далее уровень доступа может быть ограничен правами на "чтение" или "запись". Эти права определяются параметрами read list, write list, read only и writable как показано далее на рисунке «Алгоритм определения прав доступа к общему ресурсу».

Учитывая особенность алгоритма, для разграничения прав доступа используют одну из следующих стратегий:

1. Разрешают всем пользователям «чтение» и далее расширяют кому-то из них права до уровня «запись» с помощью write list.

writable = no
write list = editor_user_1 editor_user_2

2. Разрешают всем пользователям «запись» по умолчанию и далее урезают права до уровня «чтение» для определенных пользователей с помощью read list (так сделано в ALD Pro).

writable = yes
read list = reader_user_1 reader_user_2

Схемы предоставления прав доступа Windows и Samba немного отличаются, поэтому можно привести только частичное соответствие:

На файловом сервере Samba есть так же список «admin users», у которого нет полного аналога в Windows. Если пользователь будет администратором общего ресурса, то он сможет действовать в общей папке от имени суперпользователя root в обход ACL файловой системы. В настройках общей папки ALD Pro такой уровень называется «Полный доступ». Но стоит заметить, что для возможности использования прав администратора пользователь должен быть также включен в списки «valid users» и «write list». Ранее для этого уровня доступа мы не добавляли пользователей в «write list», поэтому они могли лишиться полных прав, если становились участником другой группы, которой назначены права "Чтение". Но с версии 2.4.0 мы изменили эту настройку, чтобы поведение системы стало ближе к ожиданиям наших пользователей.

6. Авторизация на уровне ACL файловой системы

Если пользователь не входит в список «admin users», то после установления SMB-подключения его права будут дополнительно ограничиваться настройками списков доступа, которые хранятся в расширенных атрибутах объектов файловой системы.

Служба Samba работает от имени суперпользователя root, поэтому имеет доступ ко всем объектам файловой системы и при обработке запросов от пользователей может имитировать любую модель проверки прав доступа. В настройках общей папки ALD Pro вы можете выбрать один из следующих режимов работы в зависимости от поставленной задачи:

• POSIX ACL - это штатный режим работы Samba, который не требует подключения каких-либо дополнительных модулей виртуальной файловой системы (Virtual File System, VFS). В этом режиме служба smbd в момент обращения к файловой системе подменяет эффективные идентификаторы пользователя и группы, чтобы делегировать проверку прав доступа функциям операционной системы Linux. Проверка выполняется как обычно с использованием прав RWX (read, write, execute) по модели UGO (user, group, others), которая расширяется списками доступа POSIX. Настраивать права доступа можно напрямую из Linux с использованием файлового менеджера fly-fm.

• ACL XATTR - в этом режиме мы подключаем vfs-модуль acl_xattr, который позволяет чуть лучше имитировать Windows ACL, используя те же POSIX ACL, но часть информации уже сохраняется в расширенных атрибутах, поэтому уровень совместимости с Linux становится ниже.

• NFS4 ACLs - в этом режиме мы подключаем vfs-модуль nfs4acl_xattr, который переводит файловый сервер в режим максимальной совместимости с Windows ACL, сохраняя всю необходимую информацию в расширенных атрибутах файлов. Но следует понимать, что данный режим исключает возможность работы с файлами напрямую, и настраивать права доступа можно будет только с Windows-машин.

Мы рекомендуем использовать POSIX ACL, поэтому далее будем рассматривать только этот режим работы.

Система Linux позаимствовала у UNIX модель дискреционного разграничения доступа UGO (от англ. User — Group — Others, т.е. пользователь — группа — остальные), в соответствии с которой у каждого объекта файловой системы есть три категории пользователей:

• Пользователь — это пользователь, который считается владельцем объекта. Владелец объекта не только получает права, определенные для этой категории пользователей, но и может изменять права доступа с помощью команды chmod (от англ. change mode). Именно поэтому модель называется дискреционной от лат. discretio — решение должностным лицом какого-либо вопроса по собственному усмотрению. Изменить владельца может только суперпользователь root или другой пользователь, которому назначена привилегия CAP_CHOWN.

• Группа — это группа, которая тоже считается владельцем объекта, но ее участники не могут изменять права доступа к объекту, им можно только назначить специфичные права доступа. Изменить группу может как суперпользователь root, так и владелец объекта с помощью команды chown (от англ. change owner), но по соображениям безопасности владелец может назначить только ту группу, участником которой является сам.

• Остальные — это все остальные пользователи, которые не вошли в предыдущие две категории.

Права доступа UGO проверяются строго «слева направо», о чем (к величайшему сожалению) не догадывается подавляющее большинство начинающих Linux-администраторов:

1. Если пользователь является владельцем объекта, он получает права пользователя, и процедура проверки прав доступа завершается.

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

3. Если пользователь не является ни владельцем, ни участником группы-владельца, то он получает права, предназначенные для всех остальных пользователей.

Базовая модель безопасности очень проста, но не обладает достаточной гибкостью, чтобы с ее помощью можно было эффективно решать задачи по организации совместного доступа сотрудников к файлам, поэтому в ядро Linux с оглядкой на Windows была включена поддержка расширенных списков доступа POSIX ACL. Учитывая, что информация о владельцах и правах доступа UGO хранится непосредственно в inode, а списки доступа ACL находятся в расширенных атрибутах, для возможности использования ACL файловая система должна быть смонтирована с поддержкой расширенных атрибутов.

При добавлении POSIX ACL алгоритм немного усложняется, но логика остается прежней, чтобы стандартная проверка UGO была частным случаем, когда POSIX ACL не заданы:

• Если пользователь является владельцем объекта, он получает права владельца, и процедура завершается.

• Если пользователь включен в ACL, то он получает права из ACL с учетом маски (если она определена), и процедура завершается. Маска — это специальное правило POSIX ACL, которое определяет максимально допустимые права доступа.

• Если пользователь является участником группы-владельца и/или одной из групп ACL, то он получает сумму всех этих прав с учетом маски (если она определена), и процедура завершается.

• Если пользователь не попал ни в одну из описанных выше категорий, то он получает права, предназначенные для всех остальных пользователей.

Теперь перейдем к разрешениям, которые определяют действия, допустимые по отношению к объектам. В соответствии с базовой моделью безопасности существует три разрешения: чтение (Read), запись (Write) и выполнение (eXecute), значение которых зависит от типа объектов.

• Применительно к файлам все очень просто:

  • Чтение (r) — дает разрешение на чтение содержимого файла.

  • Запись (w) — разрешает полностью переопределить содержимое файла или добавить новые данные в конец. При этом иметь разрешение на чтение необязательно.

  • Выполнение (x) —разрешает запускать исполняемые файлы. Если файл является скриптом, то для его запуска интерпретатором достаточно, чтобы файл был доступен для чтения. Но чтобы запустить скрипт напрямую по имени ./test.sh, вам потребуется установить на файл флаг execute.

• Применительно к каталогам все немного сложнее, но можно значительно упростить понимание, если вспомнить, что в Linux папки - это просто специальные файлы, внутри которых записаны ссылки на айноды. Назначение разрешений для каталогов следующее:

  • Чтение (r) — дает разрешение на чтение специального файла каталога, в котором содержится список файлов с номерами айнод. При этом нужно понимать, что этого разрешения недостаточно, чтобы обращаться к айнодам, поэтому посмотреть права доступа к файлам не получится.

  • Запись (w) — имеет силу, только если у пользователя будет разрешение на выполнение, о чем забывают рассказать в подавляющем большинстве источников. Таким образом, разрешение на запись дополняет разрешение на выполнение, позволяя создавать новые записи, переименовывать и удалять уже существующие записи в специальном файле каталога.

  • Выполнение (x) — дает разрешение на вход в папку (cd), чтение метаинформации по дочерним объектам и доступ к ним в соответствии с установленными правами доступа. Другими словами, если у пользователя есть разрешение на чтение дочернего файла, то для того чтобы он смог воспользоваться этим правом, ему нужны разрешения на выполнение для всех вышестоящих каталогов.

Разрешения rwx группируются по три бита в восьмеричное число от 0 до 7, причем биты следуют в обратном порядке:

• 2⁰ = 1 — Исполнение (execute)

• 2¹ = 2 — Запись (write)

• 2² = 4 — Чтение (read)

Учитывая отличия в файловых системах Windows и Linux, при сохранении файлов c Windows-компьютеров сервер Samba по умолчанию пытается сопоставлять DOS-атрибуты с флагами UGO, что приводит к неожиданному появлению флагов eXecute на файлах и снижает совместимость с Linux. Для того чтобы у нас оставалась возможность предоставить доступ к файлам Linux-пользователям напрямую, мы отключаем такое сопоставление для всех общих папок с помощью параметра "map archive = no". Если вам потребуется включить это сопоставление, вы можете сделать это с помощью ключа в реестре Samba.

Ещё одним крайне важным аспектом в части авторизации на уровне ACL являются права доступа для новых файлов и папок, создаваемых на файловом сервере. С версии 2.4.0 мы позволяем управлять этими настройками с помощью следующих параметров:

• "force create mode" и "force directory mode" - позволяют повысить права доступа, которые устанавливаются на новые объекты файловой системы, до уровня 0777. Эти значения будут складываться с помощью логического ИЛИ с правами доступа по умолчанию, которые для каталогов  устанавливаются на уровне 0755 (rwx r-x r-x), а для файлов 0644 (rw- r-- r--). Обратите внимание, что ведущий ноль в этих числах означает, что это просто число в восьмеричной системе счисления.

• inherit permissions - позволяет переопределять предыдущие два параметра, устанавливая наследование прав от родительского каталога.

Мы рекомендуем управлять правами с помощью ACL, поэтому на уровне настроек общей папки для каталогов можно установить права 0770, для файлов 0660 и отключить наследование разрешений:

[test_share]
force directory mode = 0770
force create mode  = 0660
inherit permissions = no

Тогда на уровне ACL на папки отделов вам нужно будет установить права, как на нижеследующем скриншоте:

7. Специфика работы с правами доступа при подключении SMB-ресурса

Общий ресурс можно подключить, например, средствами FUSE в пространстве пользователя. Если требуется временный доступ, то в адресной строке можно просто вбить адрес smb://file-1.ald.company.lan/test_share, где:

• smb — указывает на SMB-протокол;

• file-1.ald.company.lan — полное имя файлового сервера;

• test-share — имя общего ресурса для подключения.

Если вм нужно будет обеспечить постоянный доступ к ресурсу, то в меню «Сеть» можно выполнить команду «Новое сетевое место...» и создать именованное подключение. В открывшемся окне нужно задать имя ресурса и его адрес.

Ещё можно выполнить монтирование сетевого ресурса с помощью библиотеки cifs-utils из командной строки:

sudo apt install cifs-utils
sudo mount -t cifs -o sec=krb5,cruid=$USER,uid=$UID,gid=$GROUPS,file_mode=0770,dir_mode=0770 //file-1.ald.company.lan/test-share /home/admin/test-share/

где:

• sudo – команду нужно вызывать из-под sudo, чтобы команда была выполнена с повышенными привилегиями, но в переменных $USER, $UID и $GROUPS были данные из переменных окружения текущего пользователя.

• -t – параметр определяет тип файловой системы.

• -o — ключ позволяет задать набор опций для подключения общей папки.

  • sec=krb5 — определяет, что при подключении к серверу клиент должен будет использовать аутентификацию по протоколу Kerberos V5 без цифровых подписей (англ. integrity). Подписи не требуются, т.к. сервер будет требовать шифрование.

  • cruid=$USER — определяет владельца учетных данных Kerberos (credentials uid). При монтировании папки из-под sudo эффективный UID подменяется на 0 (root), поэтому данный параметр нужно задать явно cruid=my_user, либо использовать переменную окружения $USER, которая при выполнении команд из-под sudo не изменяет своего значения и продолжает хранить имя текущего пользователя.

  • uid, gid, file_mode и dir_mode — определяют владельцев и дискреционные права доступа, под которыми файлы и папки должны быть смонтированы в файловой системе. Служба cifsd по умолчанию использует эффективные идентификаторы процесса, который ее запустил, поэтому при монтировании из-под sudo значения uid/gid нужно задать явно.

• //file-1.ald.company.lan/test-share — путь к общей папке на файловом сервере.

• /home/admin/test-share — точка монтирования. Этот каталог должен существовать на момент подключения сетевого ресурса.

А чтобы пользователю не требовались права sudo, правило монтирования можно описать в файле /etc/fstab следующим образом:

#общая папка                           точка монтирования              тип    параметры
//file-1.ald.company.lan/test-share    /home/admin/test-share          cifs   user,noauto,sec=krb5,file_mode=0770,dir_mode=0770

Где:

• noauto — параметр указывает, что диск не требуется монтировать автоматически при загрузке системы.

• user — параметр указывает, что монтировать папку cможет обычный пользователь без прав суперпользователя. Есть также параметр multiuser, который позволяет использовать одну и ту же точку монтирования для нескольких пользователей сразу. В этом случае SMB-клиент создает одно общее подключение, а файловый сервер Samba авторизует входящие запросы, в зависимости от того, от какого из пользователей они поступают.

Вне зависимости от способа подключения общего ресурса работа с ним будет существенно отличаться от работы с файлами в проводнике Windows или при локальном обращении к файлам, так как вы будете видеть не те дискреционные права доступа, которые заданы на файловом сервере, а те значения, под которыми этот общий ресурс примонтирован на текущем хосте. В Linux для SMBv1, конечно, была реализована поддержка получения дискреционных прав доступа с сервера, но этот протокол использовать небезопасно, поэтому придется немного подождать поддержки этого механизма для SMBv3.

8. Настройка ACL в Linux

Сложность настройки списков доступа в Linux заключается в том, что подавляющее большинство файловых менеджеров позволяет редактировать только базовые права UGO, и для настройки ACL приходится обращаться к утилитам getfacl и setfacl, что довольно непросто, даже когда четко понимаешь, что именно нужно настроить. Операционная система Astra Linux в этом смысле является приятным исключением, т.к. ее файловый менеджер fly-fm позволяет настроить все, что нужно, полностью из графики.

Единственный момент - при добавлении новых субъектов в ACL приложение позволяет выполнить поиск только по тем записям, которые могут быть перечислены с помощью стандартных функций операционной системы, а в настройках sssd эта функция по умолчанию отключена. Конечно, никто не мешает включить параметр "enumerate = true", но такой способ подойдет только для очень небольших организаций, в которых не более тысячи сотрудников, т.к. загрузка всех пользователей из домена в локальный кеш будет создавать большие задержки в работе системы. Мы уже договорились с разработчиками операционной системы, чтобы они реализовали возможность прямого поиска в LDAP-каталоге без использования enumerate, но пока эти изменения ещё не появились в составе ОС, мы создали для своих заказчиков вспомогательную утилиту aldpro-setfacl, в разработке которой принял участие и ваш покорный слуга.

Утилита aldpro-setfacl встраивается в файловый менеджер через меню "Действия", позволяет выполнить поиск субъектов в домене, добавить их в ACL и перейти к настройке прав доступа. Уже совсем скоро deb-пакет с этим приложением можно будет загрузить из личного кабинета, а в дальнейшем мы обязательно включим его в состав нашего официального репозитория. Буду крайне признателен за любую обратную связь.

Уверен, что вам понравятся нововведения, которые мы реализовали в версии 2.4.0, а если ещё и статья приглянется, то обязательно не забудьте оставить за неё свой голос )))

В  качестве финального аккорда приведу примеры основных конфигурационных файлов Samba-сервера из поставки ALD Pro 2.4.0. 

[test_share]
path = /opt/samba_shares/test_share
force directory mode = 0770
force create mode  = 0660
writable = yes
map archive = no
valid users = @employees
invalid users =
read list =
write list = @employees
admin users =

[global]
workgroup = ALD
realm = ALD.COMPANY.LAN
dedicated keytab file = FILE:/etc/samba/samba.keytab
kerberos method = dedicated keytab
security = ads
idmap config ALD : range = 1584000000-1584199999
idmap config ALD : backend = sss
idmap config * : range = 0-0
idmap config * : backend = tdb
restrict anonymous = 2
usershare allow guests = no
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

[domain/ald.company.lan]
use_fully_qualified_names = False
id_provider = ipa
ipa_server = _srv_, dc-1.ald.company.lan
ipa_domain = ald.company.lan
ipa_hostname = file-1.ald.company.lan
auth_provider = ipa
chpass_provider = ipa
access_provider = ipa
cache_credentials = True
ldap_tls_cacert = /etc/ipa/ca.crt
krb5_store_password_if_offline = True

[sssd]
services = ifp
domains = ald.company.lan

[nss]
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]
allowed_uids = 0, 33, 114, fly-dm, ipaapi

[secrets]

[session_recording]

passwd:         files sss
group:          files sss
shadow:         files sss
gshadow:        files

hosts:          files dns
networks:       files

protocols:      db files
services:       db files sss
ethers:         db files
rpc:            db files

netgroup:       nis sss
sudoers:        files sss

automount:      sss