Включить поддержку windows acl
Обновлено: 06.07.2024
Резюме: Человек стремится к привычным вещам, и является ли привычный метод решения проблемы лучшим или нет - уже неважно, если это стало нормой. Зубной техник использует свои инструменты для решения любой проблемы, и не так уж необычно увидеть в зубном кабинете кресло, которое держится на протезном пластике.
Аналогично этому администратор, работающий в Windows решает все проблемы доступа с помощью Windows ACL, а Unix-администратор находит это странным и неудобным. Несмотря на совершенно разные подходы к проблеме, необходимо использовать их оба, когда используется файловый сервер Samba для предоставления ресурсов в сети Windows.
В этой статье обсуждаются соответствия между файлами и директориями в мирах Windows и Unix, приводится информация, необходимая для понимания проблем прозрачного взаимодействия и предлагаются некоторые простые решения часто встречающихся проблем. Часто кажущееся естественным решение не является самым удобным или вообще подходящим.
---=Управление доступом к файлам и директориям в UNIX=---
Когда в Unix впервые появилась необходимость многопользовательского использования, возникла также требование создать окружение в котором действуют строгие ограничения доступа, чтобы адресное пространство памяти могло быть использовано одновременно несколькими приложениями, защищенными друг от друга. Такая же потребность возникла и для файловых систем, как требование к безопасной работе. Создатели Unix были простыми людьми, которым нравилась элегантность простых, но эффективных решений.
Было решено, что могут существовать три пути управления доступом к файлу или директории. Определили, что каждый файл должен иметь владельца(owner), группового владельца (group owner) и может потребоваться доступ для всех остальных пользователей (everyone). Эти названия обычно приводятся как пользователь/группа/остальные (user/group/others) или коротко ugo. Реализация управления доступом к файлам и папкам в Unix позволяет или запрещает доступ по трем флагам: флаг чтения (Read), флаг записи (Write), флаг выполнения (eXecute). Они представляются следующим образом:
Флаг типа (type) может быть одним из следующих:
l = символическая ссылка (symbolic link)
d = директория (directory)
b = блочное устройство (block device)
c = символьное устройство (character device)
p = канал, устройство fifo (fifo device)
s = Unix сокет (unix domain socket)
Права доступа к файлам и папкам в Unix устанавливаются с помощью системной утилиты 'chmod', например:
chmod 0640 a_file
Права доступа могут быть установлены, используя восьмеричные значения: r=4,w=2,x=1 (восьмеричные числа начинаются с 0)
Те же самые права могут быть установлены таким способом:
chmod u=rw,g=r,o-rwx a_file
Примечание: между u и x не должно содержаться пробелов.
«r» означает, что объекты «владелец», «группа» или «другие пользователи» имеют право чтения. «w» означает, что объекты имеют право записи и удаления файла, а «x» - что объекты имеют право исполнения (скрипта или бинарного файла: прим. перев.) Те же самые права применяются и к директории, за исключением того, что «x» дает объектам право просмотра содержимого директории.
В Unix директория это файл, который содержит ссылки на файлы «внутри» себя. Директория имеет особый тип файла: «d».
Следует упомянуть еще о трех битах: SUID, SGID и «sticky bit» - бит привязки.
В Samba-HOWTO-Collection (The Official Samba-3 HOWTO and Reference guide)
описывается, что они означают и как их использовать.
****** Существует перевод этого огромнейшего документа на русский язык, к сожалению не могу отыскать ссылку
Средства Unix для управления доступом к файлам просты, но эффективны. Каждому пользователь Unix соответствуют UID (идентификатор пользователя), первичный(primary) GID (идентификатор группы), установленная домашняя папка и командная оболочка (shell). Пользователи также могут входить в несколько групп, хотя в некоторых старых Unix системах количество групп, в которые может входить пользователь, ограничено. Например в Solaris установлено ограничение в 16 групп, а в некоторых реализациях Unix существует ограничение в 8 групп. Группы отличные от первичной в которые входит пользователь, называются вторичными (secondary). Использование вторичных групп вызвает некоторые трудности со старыми версиями Samba. Более свежие версии позволяют использование нескольких вторичных групп, вплоть до лимита базовой операционной системы.
В окружении Unix создаваемый файл всегда принадлежит пользователю и его первичной группе, которые установлены в базе данных пользовательских аккаунтов (обычно /etc/passwd)
в последнее время часто для этих целей используется nss_ldap: прим. перев.
В Unix невозможно создать группу, принадлежащую другой группе.
---=POSIX списки контроля доступа (ACL)=---
Существует мнение, что «ugo» метод управления доступом недостаточно гибок для хорошего Unix администратора. Это привело к разработке и внедрению возможнонстей списков контроля доступа (ACL) POSIX (portable operating system interoperability standards).
К сожалению, не существует общепринятых стандартов для списков контроля доступа в Unix. Тот стандарт который используется в Samba – это проект стандарта 1003.1e 17 редакция (POSIX 1003.1e revision 17). В нем описывается API (интерфейс прикладного программирования). Поскольку реализации POSIX ACL от разных производителей отличаются друг от друга, Samba должна поддерживать свой собственный механизм отображения, который преобразует обращения к POSIX ACL в корректные системные вызовы для базовой операционной системы. Давление на Samba в целях поддержки ACL Windows ускоряет стандартизацию POSIX ACL.
POSIX ACL преоставляет мета-файловое расширение прав доступа «ugo». Несмотря на то, что разработчики старались сделать ACL простыми, они могут легко привести к больщим затруднениям. ACL могут быть установлены для файлов и директорий. Режимы доступа в каждом элементе списка контроля доступа (ACE – Access Control Entry) это: чтение, запись, выполнение (rwx).
Так же как и разрешения «ugo», не установленное значение «-» означает запрет доступа, а установленное значение – разрешение. ACL добавляет возможности установки наследования и маски контроля на файлы и директории. Маски переопределяют групповые разрешения.
Существует два и только два условия, которые гарантируют создание POSIX ACL для файла или директории:
1) Чтобы предоставить доступ для пользователей, не входящих в группу владельца, а также чтобы предоставить доступ группе, отличной от группы владельца.
2) Чтобы предоставить специальные права доступа для отдельных пользователей, которые входят в группу владельца.
Одна из трудностей при использовании POSIX ACL это резервное копирование и восстановление резервной копии. Команды UNIX tar и cpio не сохраняют POSIX ACL. Команды pax, star и dump позволяют делать это, но они известны не многим Unix-администраторам. Некоторые UNIX-системы с поддержкой POSIX ACL не включают в поставку эти команды, или администраторы не пользуются ими. Потенциально возможная потери важных мета-данных файловой системы может считаться помехой в испольовании.
POSIX ACL для файла может быть получена при помощи команды getfacl a_file. Она имеет такой вид:
user::rwx <-- разрешения для владельца (user)
user:tpot:r-x <-- разрешения для допольнительного пользователя tpot
group::r-- <-- разрешения для группы владельца (group)
group:engrs:r-- <-- разрешения для дополнительной группы engineers
mask:rwx <-- Маска, которая накладывается на разрешения групп по правилам логического «И»
other::--- <-- разрешения для не указанных явно объектов (other)
ACL для директории получается тем же способом и имеет такую структуру:
user::rwx <-- разрешения для владельца директории (user)
group::rwx <-- разрешения для группы владельца директории (group)
mask::rwx <-- Маска, которая накладывается на разрешения групп по правилам логического «И»
other:r-x <-- разрешения для не указанных явно объектов (other)
default:user::rwx <-- наследуемые разрешения владельца
default:user:tpot:rwx <-- дополнительные наследуемые разрешения для пользователя tpot
default:group::r-x <-- наследуемые разрешения группы владельца
default:mask:rwx <-- наследуемая маска по умолчанию
default:other:--- <-- наследуемые разрешния для не указанных явно объектов (other)
---=Условия, которые влияют на доступность ACL в Samba/UNIX=---
Те, кто подпишется на список рассылки Samba, скорее всего собственными глазами увидят недоумение администраторов, которые не могут создать ACL на сервере Samba с помощью Windows Explorer. Эта проблема всегда возникает из-за небольшой оплошности: либо из-за незнания, либо из-за невнимательности при установке системы.
Следующие 5 условий должны быть выполнены, чтобы Windows ACL работали с сервером Samba:
поддержка в ядре
поддержка в файловой системе
поддержка в библиотеках
файловая система примонтирована с параметром acl
Samba откомпилирована и собрана с поддержкой ACL
Эти настройки взяты из файла /usr/src/linux/.config и показывают типы файловых систем, для которых может быть включена или выключена поддержка ACL.
(b) Файловая система должна поддерживать ACL
В Linux поддержка ACL может быть включена для файловых систем ext2fs, ext3fs, reiserfs, jfs, xfs, и nfs. Включить ее можно, как показано выше при компилировании ядра. Пользователи Unix должны удостоверится, что поддержка ACL доступна для файловой системы, которую они собираются использовать.
(c) Доступность системных библиотек с поддержкой ACL и включение ACL в Samba
В Linux системах требуется установка специальных системных библиотек. Например ядро Linux 2.6.x для поддержки ACL требует библиотеки libacl.so и libattr.so. RPM-пакеты, которые устанавливают эти библиотеки называются соответственно libacl-2.2.25 и libattr-2.4.16. Для компилирования Samba на Linux системе также должны быть предварительно установлены некоторые библиотеки разработчиков (development libraries). Поддержка ACL в запускаемых файлах Samba может быть проверена таким способом:
(d) Файловая система примонтирована с включенной поддержкой ACL
Unix/Linux системы с поддержкой ACL могут иметь файловые системы, для которых поддержка ACL не включена при монтировании. Лучший способ удостоверится, что эта поддержка включена это запуск команды:
/dev/mapper/system-ROOT on / type reiserfs (rw,acl,user_xattr)
/dev/hda1 on /boot type reiserfs (rw,acl,user_xattr)
/dev/sda5 on /data type reiserfs (rw,acl,user_xattr)
/dev/mapper/system-VAR on /var type reiserfs (rw,acl,user_xattr)
/dev/hdb1 on /data2 type reiserfs (rw,acl,user_xattr)
frodo:/home on /home type nfs (rw,soft,rsize=8192,wsize=8192,posix,acl,addr=192.168.1.1)
frodo:/home2 on /home2 type nfs (rw,soft,rsize=8192,wsize=8192,posix,acl,addr=192.168.1.1)
nfsd on /proc/fs/nfsd type nfsd (rw)
В приведенном примере показано, что поддержка ACL включена на всех примонтированных файловых системах, включая сетевые диски NFS.
Если все указанные условия проверены простой тест может показать, что поддержка ACL работает:
user:bin:rwx <==== Эта запись показывает, что ACL включены.
Поскольку Samba использует те же самые системные вызовы, управление доступом при помощи ACL теперь может производится и через Samba. Дальнейшее обсуждение использования ACL Windows NT/200X клиентскими операционными системами требует понимания того, как они преобразуются в POSIX ACL.
---=Windows NT/200X ACL=---
В следующей таблице приведены все 14 основных флагов ACE, которые поддерживаются в Windows 2000 и более поздних продуктов (например Windows XP Professional):
Windows ACE Флаг файловых атрибутов
Traverse Folder/Execute File x
List Folder/Read Data r
Read Attributes r
Read Extended Attributes r
Create Files/Write Data w
Create Folders/Append Data w
Write Attributes w
Write Extended Attributes w
Delete Subfolders and Files w
Read Permissions Все (all)
Как видно из этой таблицы, многие флаги Windows ACE не имеют эквивалента в ОС UNIX. Таким образом разработчики Samba были вынуждены отображать флаги таким образом, чтобы стало возможным копировать по сети файлы и директории, сохраняя Windows ACL. Однако, в итоге при копировании файлов на сервер Samba некоторая информация об ACL теряется. Это не играет роли, пока те же самые файлы не копируются назад на сервер Windows 200X.
Windws ACL хорошо знакомы сетевым администраторам Windows, поскольку они являются единственным методом управления доступом к файлам, папкам и разделяемым ресурсам. В Windows NT/200X не используется концепция наследственной схемы владения триплетом пользователь/группа/все. В Windows существует концепция владельца, но не группы владельцев. Управление доступом реализовано полностью с помощью ACL.
Фактически, в Windows возможно полностью удалить все ACE из ACL. В предыдущих версиях Windows (3.10) администратор Windows мог проделать это, получив в результате файлы, к которым даже администратор не имел никаких прав доступа. Восстановить эти файлы было возможно только дав администратору соответствующие права на восстановление доступа к таким файлам. Подобная проблема невозможна в окружении операционной системы UNIX. К счастью, начиная c Windows NT4 у администратора по умолчанию
присутствуют права на восстановление файлов, лишенных доступа.
Windows ACL ужасно сложны по сравнению с простотой разрешений UNIX и расширенных POSIX ACL. Windows ACL были разработаны с учетом перспективы таким образом, чтобы давать очень гибкие возможности, которые большинство администраторов Windows не понимают и не умеют правильно использовать. Помимо этого, лишь немногие Windows программисты знают, как правильно использовать API Windows ACL, и большинство приложений под Windows не используют ACL так, как могли бы.
Windows ACL обладают очень сложными и специфичными правилами приоритетов. Одна из часто встречающихся ошибок совершается неопытными пользователями, когда им нужно установить подобные права доступа:
Запретить всем доступ к файлам и директории XYZ
Дать доступ только для чтения Инженерам
Дать доступ для записи Менеджерам
Everyone (No Access)
Engineers (read only)
Managers (Full Control)
Проблема заключается в том, что группы Engineers и Managers тоже принадлежат группе Everyone (все пользователи), и доступ для них также будет запрещен, поскольку глобальная ACE, запрещающая доступ имеет более высокий приоритет, чем разрешающие ACE. Необходимо было определить только ACE для групп Engineers и Managers. Сложности таких ACL не существуют в POSIX ACL в UNIX, а следовательно и в Samba, поскольку она прозрачно передает все управление доступом базовой операционной системе.
Руководство по использованию Windows ACL на файловом сервере Samba.
Будет полезно узнать, что происходит, когда Windows копирует файл на сервер Samba, поддерживающий ACL.
Представим, что файл со следующим ACL копируется пользователем «root» с сервера Windows на сервер Samba. Необходимо, чтобы доменный пользователь «root» имел относительный идентификатор (RID) равный 500, чтобы эта учетная запись опознавалась Windows, как администратор домена.
ACL этого гипотетического файла имеет следующие ACE:
jht обладает полным доступом (Full Control)
группа Domain users обладает доступом для чтения (read control)
группа Accountants обладает доступом для чтения и записи (read and write control)
группа Technicians обладает полным доступом (Full Control)
После копирования на сервер Samba (например с помощью утилиты robocopy) файловые атрибуты в UNIX будут такими:
группа владельца:Domain Admins:rw-
Если пользователь jht не существовал в то время, когда файл был скопирован, то файл будет принадлежать учетной записи «root» (существующей учетной записи, создавшей файл)
Указанная выше информация сохраняется в расширенных POSIX ACL. Теперь, должно быть, понятно, что использования расширенных POSIX ACL можно было полностью избежать таким образом:
Установить разрешения владельца/группы/остальных: -rw-rw-r-- jht Technicians
Создав с помощью консоли MMC на клиенте Windows настройки безопасности, можно открыть доступ к разделяемому ресурсу только для групп Accountants и Technicians. Полученное в результате решение не требует использования POSIX ACL, сохраняя в то же время такие же права доступа, что и в оригинальном Windows ACL, но с преимуществами файлового сервера UNIX: нагрузка, связанная с обработкой прав доступа намного ниже по сравнению с нагрузкой обработки сложного ACL, который был создан простым копированием файла с помощью robocopy.
Фактор, который часто не учитывают неопытные администраторы Windows (и о котором не знают многие пользователи), это то, что копирование файла с помощью Windows Explorer не копирует ACL исходного файла, а создает новый ACL, в котором права доступа наследуются от директории в которую копируется файл. Это происходит как в чистом Windows-окружении, так и на сервере Samba.
При продуманном использовании Windows ACL в окружении сервера Samba возможно значительно упростить и упорядочить управление системой прав доступа, повысить быстродействие за счет более простых правил доступа. Результатом станет более быстрая сеть, которая обладает также большими возможностями по восстановлению в случае сбоев.
Усилия, требуемые для приобретения необходимых навыков работы с ACL будут хорошо вознаграждены и помогут администратору Samba избежать многих потенциально запутанных и критичных для работы проблем.
Мы продолжаем серию статей про взаимодействие Linux и Windows. Эта статья посвящена управлению доступом к серверам Samba из домена AD.
Про сеть МЭИ
Информационно-вычислительная сеть Московского энергетического института (ИВС МЭИ) использует доменную структуру Windows на базе AD. Наша сеть поддерживает несколько доменов. Доменом верхнего уровня является домен mpei.local. Домен public.mpei.local предназначен для пользователей МЭИ, домен init.mpei.local предназначен для сотрудников Информационно-вычислительного центра МЭИ.
Сервер, который мы настраиваем, представляет собой кластерное файловое хранилище и предназначен для размещения каталогов пользователей — сотрудников ИВЦ МЭИ и сотрудников МЭИ (пользователи домена INIT и PUBLIC) и общих каталогов. Операционная система сервера — Ubuntu Linux 12.04 LTS.
•Backups Предназначен для хранения резервных копий. Доступ к каталогу имеют администраторы доменов.
•Каталоги ISOs и Software Предназначены для хранения образов дисков дистрибутивов операционных систем и другого программного обеспечения, используемого в ИВС МЭИ. Информация, размещенная в этих каталогах, доступна всем пользователям, но запись разрешена только администраторам доменов.
•Каталог VMImages Предназначен для хранения образов виртуальных машин, применяемых в ИВС МЭИ. Этот каталог доступен всем пользователям, запись разрешена только администраторам доменов.
•Каталоги пользователей Предназначены для размещения файлов пользователей.
Способ организации кластерного файлового хранилища не является определяющим для решения задачи управления доступом. Для создания такого хранилища могут быть использованы самые различные технологии и их реализации.
Способ включения сервера Samba на базе Ubuntu Linux уже рассматривался раньше. Мы включаем наш сервер в домен верхнего уровня mpei.local. Для авторизации пользователей мы будем использовать winbind.
Поскольку у нас используется несколько доменов, то целесообразно в разделе глобальной конфигурации Samba в файле smb.conf указать:
Отключив эту опцию, мы поясняем Samba, что пользователи без указания доменного имени будут рассматриваться как локальные пользователи сервера, а для остальных случаев необходимо указывать доменное имя. Это необходимо сделать, поскольку пользователи могут иметь совпадающие имена в различных доменах.
При правильном включении сервера filer в домен в ответ на запрос getent passwd мы должны увидеть список пользователей всех доменов, а в ответ на запрос getent group — список групп всех доменов. Если это не так, следует проверить содержимое файла /etc/nsswitch.conf, который должен выглядеть так:
Следует проверить, как авторизуются пользователи Samba. Для этого посмотрим содержимое файла /etc/pam.d/samba:
Поля соответствуют полям файла /etc/passwd, стандартного места хранения данных о пользователях в системах Linux и Unix. Поля именуются так:
•login name
•optional encrypted password
•numerical user ID
•numerical group ID
•user name or comment field
•user home directory
•optional user command interpreter
При подключении к домену Windows на базе AD поле login name представляет собой комбинацию имени домена и имени пользователя, где разделителем является либо обратный слэш (\), либо символ, определенный в опции winbind separator.
Поле password представляется символом *, что означает внешний источник паролей.
Значения полей UID и GID формируются на основе опций idmap uid и idmap gid (или idmap config) файла конфигурации Samba.
Поле user home directory формируется на основе опции template homedir файла конфигурации Samba. А поле user command interpreter — на основе значения опции template shell файла конфигурации Samba.
На основании этого вывода мы можем сказать, что домашний каталог для пользователя khorkov в домене PUBLIC будет /ceph/home/PUBLIC/khorkov. Именно этот каталог и должен автоматически создаваться. Таким образом, наш файл /etc/samba/smb.conf в разделах global и homes выглядит следующим образом:
Опция obey pam restrictions = yes дает директиву серверу Samba подчиняться указаниям, изложенным в директивах pam для учетных записей пользователей и сессий. В нашем случае — мы согласны с командой на создание домашнего каталога.
Опции acl compatibility = auto и map acl inherit = yes разрешают серверу Samba устанавливать режим совместимости списков доступа к файлам и наследование списков доступа. Эти параметры имеют важное значения для поддержки Samba управления доступом от Windows-клиентов. Для корректной работы необходимо, чтобы файловая система, на которой размещен разделяемый ресурс Samba, поддерживала POSIX ACL. Для этого необходимо установить соответствующие пакеты в Linux (для Ubuntu это acl и attr).
Далее, в секции [homes] определяются каталоги пользователей. Путь к каталогам определяется опцией path. В файле конфигурации Samba действуют правила подстановки. В частности, %D заменяется на краткое имя домена, %U — на имя пользователя, %S — на имя сессии (совпадает с именем пользователя). Доступ к каталогам определяется для чтения-записи, о чем говорит опция read only = no. Опция valid users описывает список пользователей, которым разрешен доступ (регистрация) к этому каталогу. Важное значение имеют опции create mask (маска прав при создании файла) и directory mask (права при создании каталога). В любом случае владельцем домашнего каталога, создаваемых файлов и каталогов будет пользователь, соединившийся с ресурсом. При этом uid и gid пользователя определяются в соответствии с результатом команды getent passwd.
Учтите, что в 99% случаев имя группы будет \Domain users. Указанные значения 0700 дают пользователю полные права на доступ к файлам или каталогам и запрещают доступ всем остальным (в том числе и группе). Для разрешения доступа группе на чтение третий октет должен быть равен либо 4 (чтение), либо 5 (чтение и исполнение). Об определении прав доступа в Linux можно прочесть в любой книге по этой операционной системе.
Значения опции valid users ограничивает список пользователей, имеющих доступ к каталогу, пользователями доменов INIT и PUBLIC.
Описание пути к разделяемому каталогу и ограничения для пользователей мы уже рассматривали. Опция nt acl support = yes дает директиву Samba отображать права доступа Windows на права доступа Linux. Опции inherit acls = yes, inherit owner = yes, inherit permissions = yes и map acl inherit = yes указывает на поддержку Samba наследования прав и списков доступа. Опция hide unreadable = yes скрывает от пользователя нечитаемые каталоги и файлы.
Опция admin users задает список пользователей, имеющих административные права (права суперпользователя). Опция write list задает список пользователей, имеющих права записи в этот каталог. При создании каталога следует определить его принадлежность. Большей частью достаточно владельцем назначить root, а группу определить как Domain users (в нашем случае — как MPEILOCAL\Domain users). Списки пользователей могут задаваться как в виде DOMAIN\user (пользователи домена), так и в виде user (пользователи самого сервера). Можно задавать их и в виде наименований групп, предваряя имя группы символом @. В списке поля разделяются пробелами. Имена групп Windows, в случае, когда они состоят из более чем одного слова, следует заключать в кавычки. В нашем примере мы дали разрешение на чтение каталога Software всем пользователям доменов MPEILOCAL, INIT и PUBLIC, а право на запись — для администраторов доменов. Остальные каталоги (Backups, ISOs и VMimages) настраиваются аналогично вышеприведенному примеру.
Подключимся к серверу filer (рис. 1).
Рис. 1. Доступ к серверу Samba.
Проверим доступ к домашнему каталогу (рис. 2).
Рис. 2. Доступ к домашнему каталогу.
Можно проверить права доступа на создание и удаление файлов и каталогов. Домашний каталог с точки зрения Linux выглядит следующим образом:
Как видим, права на любые действия с файлами принадлежат только владельцу. Если сейчас попытаться внести изменения в настройки доступа средствами Windows, то мы получим ошибку о запрете записи (рис. 3).
Рис. 3. Ошибка задания прав.
Эта ошибка задания прав на каталог, к которому пользователь имеет все права, возникает потому, что файловая система, где размещен каталог, не поддерживает списки доступа. На файловой системе с поддержкой списков доступа такой ошибки не возникает. Проверить наличие этой поддержки можно командой:
Здесь мы видим, что файловая система на устройстве /dev/sda1 поддерживает управление доступом. Включение поддержки acl возможно при монтировании файловой системы Linux, либо через утилиту tune2fs. Список файловых систем, поддерживающих acl, можно узнать в справочном руководстве (man) по команде mount в разделе FILESYSTEM SPECIFIC MOUNT OPTIONS.
Можно посмотреть и сами списки доступа, командой
Для задания списков доступа из командной строки Linux можно воспользоваться командой setfacl или командой smbcacls. Правда, интерфейс этих команд достаточно сложный, и целесообразнее использовать окно настроек доступа Windows.
Мы предоставляли управление доступом к серверу Samba в основном через редактирование файла /etc/samba/smb.conf. Это один из самых простых и эффективных способов. Существует масса графических приложений для настройки Samba, поставляемых вместе с дистрибутивом Linux. Можно также использовать web-средства управления, такие как swat или webmin. Достоинством swat, например, является встроенная документация — не нужно постоянно переключаться между настройками и справочным руководством. Но и swat, и webmin грешат ошибками в настройках.
Заключение
Таким образом, мы успешно выполнили задачу по настройке доступа к файловому серверу Samba в домене Windows на базе AD.
Работа выполнена на базе Информационно-вычислительного центра МЭИ.
Мы будем рады вашим замечаниям и предложениям. У нас есть возможности собрать тестовую сеть, на которой отладить различные варианты и конфигурации систем для обеспечения их взаимодействия.
Для управления доступом к файлам и папкам в Windows на каждый объект файловой системы NTFS (каталог или файл) назначается специальный ACL (Access Control List, список контроля доступа). В ACL объекта задаются доступные операции (разрешения), которые может совершать с этим объектом пользователь и/или группы . В большинстве случаев администраторы Window для управления NFTS разрешениями на файлы и папки используют графический интерфейс File Explorer (свойства папки/файла -> вкладка Security/Безопасность) или консольную утилиту icacls. В этой статье мы рассмотрим способы управления разрешениями на объекты файловой системы NTFS из PowerShell. Вы можете использовать эти команды в скриптах и для автоматизации управлением NTFS разрешениями на файловых серверах Windows.
Встроенные командлеты для управления ACL в NTFS: Get-Acl и Set-Acl
В PowerShell v5 (Windows 10 / Windows Server 2016) для управления ACL имеется два отдельных встроенных командлета (входят в модуль Microsoft.PowerShell.Security):
Мы не будем подробно останавливаться на этих встроенных командлетах, т.к. их функционал в большинстве случае недостаточен для управления NTFS разрешениями в реальных задачах. Рассмотрим лишь несколько типовых примеров их использования.
Выведем текущего владельца папки (файла) и список назначенных NTFS разрешений:
get-acl C:\Drivers\ |fl
Path : Microsoft.PowerShell.Core\FileSystem::C:\Drivers\
Owner : WORKSTAT1\root
Access : NT AUTHORITY\Authenticated Users Allow Modify, Synchronize
NT AUTHORITY\SYSTEM Allow FullControl
BUILTIN\Администраторы Allow FullControl
BUILTIN\Пользователи Allow ReadAndExecute, Synchronize
WORKSTAT1\root Allow Modify, Synchronize
Audit :
Sddl : O:S-1-5-21-3650440056-3766451173-3310994491-1001G:S-1-5-21-3650440056-766451173-3310994491-513D:PAI(A;OICI;0x 1301bf;;;AU)(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a9;;;BU)(A;OICI;0x1301bf;;;S-1-5-21-3650440056-37664 51173-3310994491-1001) Как вы видите, текущие разрешения также представлены в виде SDDL строки – мы вкратце рассматривали этот формат описания доступа в статье Управление правами на службы Windows.
Можно вывести только списки NTFS разрешений в более понятном формате:
С помощью следящей команды можно скопировать NTFS разрешения с одной папки и применить их на другую:
Get-Acl C:\Drivers | Set-Acl C:\Distr
Для выполнения этой операции учетная запись должна быть владельцем ресурса (Owner) и обладать правами Take Ownership.Главная проблема при использовании Set-ACL – командлет всегда пытается сменить владельца ресурса, даже если вы просто хотите изменить NTFS разрешения. В результате, чтобы добавить права на объект нужно использовать такую конструкцию:
$path = "c:\drivers"
$user = "WORKSTAT1\user1"
$Rights = "Read, ReadAndExecute, ListDirectory"
$InheritSettings = "Containerinherit, ObjectInherit"
$PropogationSettings = "None"
$RuleType = "Allow"
$acl = Get-Acl $path
$perm = $user, $Rights, $InheritSettings, $PropogationSettings, $RuleType
$rule = New-Object -TypeName System.Security.AccessControl.FileSystemAccessRule -ArgumentList $perm
$acl.SetAccessRule($rule)
$acl | Set-Acl -Path $path
Чтобы убрать NTFS доступ к папке для пользователя или группы:
$path = "c:\drivers"
$acl = Get-Acl $path
$rules = $acl.Access | where IsInherited -eq $false
$targetrule = $rules | where IdentityReference -eq "WORKSTAT1\user1"
$acl.RemoveAccessRule($targetrule)
$acl | Set-Acl -Path $path
Чтобы отключить наследование для папки из PowerShell:
Также с помощью Get-acl и Set-Acl можно управлять параметрами NTFS-аудита объектов (см. статью Кто удалил файл на сервере?), либо информацией о текущих разрешениях на OU в AD.Используем модуль NTFSSecurity для управления разрешениями из PowerShell
Как я уже говорил, встроенный модуль для управления ACL на объекты в PowerShell не самый удобный. Для управления NTFS правами на файлы и папки в Windows лучше использовать отдельный модуль их галереи PowerShell – NTFSSecurity. Последнюю версию модуля NTFSSecurity (4.2.4 на данный момент) можно установить командой Install-Module -Name NTFSSecurity , или скачать вручную (линк). При ручной установке достаточно распаковать содержимое архива модуля в каталог C:\Windows\System32\WindowsPowerShell\v1.0\Modules\NTFSSecurity (не забудьте разблокировать скачанные файлы).
Импортируйте модуль NTFSSecurity в сессию PowerShell:
Выведем список команд, доступных в модуле (доступно 36 командлетов):
Get-Command -Module NTFSSecurity
Выведем текущие NTFS разрешения на каталог:
Get-Item 'c:\distr' | Get-NTFSAccess
Как вы видите, текущие разрешения представлены в более удобной форме.
Чтобы предоставить конкретному пользователю и группе группе полные права на папку, выполните команду:
Add-NTFSAccess -Path C:\distr -Account 'WORKSTAT1\confroom','BUILTIN\Администраторы' -AccessRights 'Fullcontrol' -PassThru
Чтобы предоставить права только на верхнем уровне и не изменять разрешения на вложенные объекты (только на папку), используйте команду:
Add-NTFSAccess c:\data\public -Account corp\aaivanov -AccessRights Modify -AppliesTo ThisFolderOnly
Удалить назначенные NTFS разрешения:
Remove-NTFSAccess -Path C:\distr -Account 'WORKSTAT1\confroom' -AccessRights FullControl -PassThru
Следующей командой можно лишить указанную учетную прав на все вложенные объекты в указанной папке (наследованные разрешения будут пропущены):
Get-ChildItem -Path C:\distr -Recurse | Get-NTFSAccess -Account 'WORKSTAT1\confroom' -ExcludeInherited |Remove-NTFSAccess -PassThru
Следующей командой можно назначить учетную запись Administrator владельцем всех вложенных объектов в каталоге:
Get-ChildItem -Path C:\distr -Recurse -Force | Set-NTFSOwner -Account 'Administrator'
Чтобы очистить все разрешения, назначенные на объекты каталога вручную (не будет удалены унаследованные разрешения):
Get-ChildItem -Path C:\distr -Recurse -Force | Clear-NTFSAccess
Включить NTFS наследование для всех объектов в каталоге:
Get-ChildItem -Path C:\distr -Recurse -Force | Enable-NTFSAccessInheritance
Чтобы вывести все разрешения, которые назначены вручную, исключая унаследованные разрешения:
dir C:\distr | Get-NTFSAccess –ExcludeInherited
Можно вывести разрешения, назначенные для определенного аккаунта (не путайте с эффективными разрешениями, речь о них ниже):
dir C:\distr | Get-NTFSAccess -Account corp\aaivanov
Проверка эффективных NTFS разрешений на объекты из PowerShell
Вы можете проверить эффективные NTFS разрешения на конкретный файл или папку с помощью командлета Get-EffectiveAccess . Допустим вы предоставили доступ на некоторую папку нескольким группам безопасности AD и теперь хотите понять, есть ли у конкретного аккаунта (SID) доступ к данной папке или нет. Как это сделать, не выводя состав групп AD, в которых входит его учетная запись? В этой ситуации как раз поможет функция проверки эффективные NTFS разрешений. Допустим, нужно проверить эффективные права на все вложенные папки в каталоге для пользователя confroom.
Get-ChildItem -Path c:\distr -Recurse -Directory | Get-NTFSEffectiveAccess -Account 'WORKSTAT1\confroom' | select Account, AccessControlType, AccessRights, FullName
В предыдущих статьях был рассмотрен способ установки файлового сервера Samba в кластере и установка прав доступа на отдельные папки используя "классический" метод. Но данный метод не всегда удобен, особенно если папок на сервере много и требуется весьма разветвленная структура доступа. Весьма затруднительно вносить каждую папку, на которую требуется наложить какие-либо ограничения, в файл конфигурации сервера. Да и делегировать административные права на управление доступом гораздо проще используя другой метод. Таким методом является ACL.
Как обычно все работы будут проводиться на ОС Rosa Enterprise Linux Server 7.3 (RELS 7.3), он же CentOS 7.3, он же RedHat 7.3.
- smb.rpn.int - файловый сервер Samba
- otd1 - первое подразделение компании
- otd2 - второе подразделение компании
- unit1 - папка первого подразделения
- unit2 - папка второго подразделения
- share - общая папка всех подразделений.
Задача: организовать доступ к папкам таким образом:
- Пользователи из otd1 имели полный доступ к папке unit1, но не имели доступ к папке unit2
- Пользователи из otd2 имели полный доступ к папке unit2, но не имели доступ к папке unit1
- Все пользователи имеют полный доступ к папке share
- Все пользователи имеют право просматривать структуру корневой папки
В предыдущей статье рассказывалось о том, как организовать такой доступ, используя стандартные настройки Samba. Сейчас же рассмотрим более "продвинутый" метод - ACL.
Стандартные команды работы с ACL - setfacl и getfacl - подробно описаны в руководстве, поэтому здесь мы ограничимся примерами.
Для работы ACL необходимо включить поддержку этого функционала при монтировании файловой системы. Когда мы подключали кластерную файловую систему к кластеру, мы это предусмотрели:
Т.е. в параметре монтирования указываем опцию acl . Если мы не используем кластерную файловую систему, а работаем с выделенным сервером, то эта опция указывается в файле, описывающим смонтированные устройства ( /etc/fstab ). Например:
Проверить поддерживает ли раздел работу с ACL можно попыткой установить список доступа на этот раздел. Например:
Operation not supported говорит о том, что поддержка ACL не была включена и необходимо ее задействовать.
Т.к. сервер в данном примере работает в домене FreeIPA, то в первую очередь создаем несколько групп:
- fs_users - в данную группу будут входить все пользователи, имеющие право заходить на файловый сервер, и которым будет доступен листинг корневых папок ресурса
- fs_admins - группа пользователей, которым будут доступны все папки на сервере и которые смогут редактировать (настраивать) ACL непосредственно из файлового менеджера без доступа в консоль сервера.
- otd1 - пользователи первого подразделения
- otd2 - пользователи второго подразделения
Далее на диске, который будет использоваться для файлового сервера создаем структуру папок:
Где FS_Share - точка монтирования диска. Далее назначаем хозяина папок и раздаем права:
Т.е. мы назначаем группу владельца файлов и папок fs_admins и разрешаем доступ с правом чтения-записи всем пользователям, принадлежащим этой группе.
Права 2770 гарантируют, что все файлы и подпапки, находящиеся в них, будут всегда создаваться с соответствующими подгруппами этих родительских папок. Немного изменим права доступа на корневую папку:
Далее настраиваем доступ к корневой общей папке и включаем ACL в конфигурации Samba:
Перезапускаем сервер Samba с новыми настройками:
В итоге на сервере появилась общая папка SHARE , в которую имеют доступ пользователи, входящие в группу fs_admins .
Остается настроить права доступа на все папки общего ресурса. Для этого переходим в консоль сервера и начинаем настройку.
Устанавливаем права просмотра содержимого корневого каталога для всех пользователей, входящих в группу fs_users (в отличии от групп Samba в группы домена FreeIPA могут входить другие группы. Т.е. в нашем случае в группу fs_admins входят группы подразделений otd1 и otd2 ):
Устанавливаем полный доступ для пользователей группы otd1 на папку и все последующие папки unit1 :
Устанавливаем полный доступ для пользователей группы otd2 на папку и все последующие папки unit2 :
Посмотреть права доступа можно выполнив следующую команду:
Т.е. мы видим, что в данную папку разрешен полный доступ группе otd2. Всем остальным доступ запрещен.
То же самое можно посмотреть для остальных папок.
В итоге мы добились поставленной цели: все пользователи могут читать структуру корневого каталога. Пользователь имеет полный доступ в папку своего подразделения. Доступ пользователю в папку чужого подразделения запрещен.
Читайте также: