Файловый сервер – что это? При разговоре многие IT специалисты отвечают очень просто: “шара” она и в Африке “шара”. Задаешь следующий вопрос, как ты считаешь у файлового сервера может быть логика функционирования? И в ответ получаешь, что-то подобное ответу на первый вопрос. Ну и в заключении просишь показать скриншот рабочего файлового сервера компании со стороны обычного пользователя, результат обычно такой…
И еще пару-тройку десяток папок своих и не своих, которые видит пользователь.
А как ты предоставляешь доступ пользователю?
Захожу на файловый сервер, открываю свойства конкретной папки далее вкладка Security и добавляю требуемые разрешения конкретному пользователю.
А ты слышал, что в Active Directory есть группы?
Да конечно, но я так привык делать.
А если тебе придётся администрировать файловый сервер к примеру на одну тыс. человек, как ты считаешь твоя модель будет эффективной?
Ответ зависит от креативности конкретной личности)))
Недавно мне попался такой файловый сервер который нужно было оптимизировать и продумать новую логику работы с учетом роста компании.
Какие проблемы будут решены после оптимизации файлового сервера:
1) Зайдя на файловый сервер человек будет видеть только “свои” папки.
2) Доступ к папкам будет предоставляться через ролевые группы на базе групп Active Directory.
При таком подходе предоставление доступа к ресурсу осуществляется лишь добавлением определенного пользователя в требуемую группу через оснастку Active Directory Administrative Center.
Цитата из книги “Эффективное Администрирование. Windows Server 2008.” Автор: Холме Дэн.:
Ролевая группа определяет набор компьютеров или пользователей, ориентируясь на их общие черты с точки зрения бизнеса. Это помогает установить, кем является данный пользователь или компьютер
В книге очень подробно описано как грамотно организовать файловый север. Советую.
3) Файловый сервер будет работать на базе технологии Distributed File System.
4) Будет активирована технология Data Deduplication.
К примеру в моем случаи Deduplication rate (при дефолтовых настройках) составляет 43%:
Устанавливаем роли:
Создаем папку самого верхнего уровня:
Когда создаем папку или папки верхнего уровня лучше избежать русских букв в названии и пробелов. Если этим пренебречь, то к примеру некоторые Linux клиенты могу при монтирование этой папки испытывать дополнительные проблемы.
Далее заходим в свойства этой папки на вкладку Security –> Advanced и выключаем наследование прав:
Далее приводим группы в такое соответствие:
Если группе Domain Users не сделать This folder Only, то технология ABE не отработает. Плюс мы выключи наследование прав.
Далее открываем Server Manager переходим:
Выбираем нашу папку верхнего уровня:
На следующем шаге включаем технологию ABE:
Permissions мы уже указали. Management Properties и Quota мы конфигурировать так же не будем.
В конечном итоге доходим до конца мастера и нажимаем Create и получаем такие результаты:
На этом этапе стоит пояснить одну фундаментальную вещь.
Цитата из блога Vadims Podans (ссылка на статью):
Как известно, при доступе к общим ресурсам (сетевым папкам) мы различаем 2 типа прав:
Share Permissions
NTFS RightsОба типа прав влияют на результирующие (эффективные) права пользователя при доступе к сетевому ресурсу. В общем смысле эффективные права будут являть собой наиболее ограничивающее разрешение из обоих типов прав. Например, на ресурс установлено право Share Permissions = Read, а NTFS = Full Control, то исходя из наиболее ограничивающего разрешения эффективным будет Read. Если Share Permissions = FullControl, а NTFS = Modify, то эффективным правом для пользователя будет Modify. Вот такая несложная схема. Т.е. там, где прав меньше, те и будут ваши :-) Как известно, эта проблема редко кого касается, т.к. обычно на уровне Share Permissions выдают FullControl на ресурс и дальше уже права регулируют за счёт NTFS
Теперь запускаем DFS Management и создадим New NameSpace…:
Практически всегда ваш файловый сервер должен “жить” в пространстве DFS. При таком подходе доступ к файловому серверу или серверам осуществляется через единый NameSpace в нашем случае \\Contoso.com\FileServer
Запускаем мастер вводим Name, далее Edit Settings и выбираем нашу первую папку в иерархии:
Далее кнопка Customize и поправим права иначе мастер нам их сбросит:
Нажимаем Next и получаем предупреждение:
Так как для папки мы уже заранее все настроили отвечаем на вопрос - Yes.
На следующем шаге оставляем все как есть:
Конечный результат:
Теперь на клиенте можно создавать такие ярлыки (удобно это делать через групповую политику):
Теперь если мы захотим добавить к нашему файловому серверу еще один сервер и начнем уже там размещать новые данные, то конечный пользователь даже не поймет, что был добавлен второй файловый сервер:
Папка “Кадровая служба” физически располагается на втором файловом сервере, но путь ко всем папкам один \\Contoso.com\FileServer:
Как это реализовать в этой заметке рассказано не будет.
Если на данном этапе реализации файлового сервера взять обычного пользователя и попытаться открыть наш файл сервер, то никаких файлов и папок мы не увидим, хотя они там есть:
Отрабатывает технология Access-based enumeration:
Скрин со стороны сервера:
Нашему тестовому вновь созданному пользователю не предоставлено по умолчанию никаких прав, а мы помним если задействована технология ABE и пользователь не имеет хотя бы права Read на файл или папку то ему этот файл или папка не видны.
Пришло время создать ролевые группы, вначале этой заметке я уже приводил цитату из книги, но хочу добавить еще одну:
Цитата из книги “Эффективное Администрирование. Windows Server 2008.” Автор: Холме Дэн:
Ролевые группы определяют набор компьютеров или пользователей на основе сходства, которым обладают объекты в бизнесе, их территориального размещения, подразделений, функций, трудового стажа или статуса, команд, проектов или любых других связанных с бизнесом характеристик
Я создал типичную структуру отделов-подразделений компании (предыдущий скриншот).
На основании этой структуры мы создадим первые ролевые группы (отмечены стрелочками):
Так как в AD DS я никогда не использую русский язык кроме поля Description в названиях групп мы используем английские аналоги, но для удобства в поле Description можно вписать русское название.
Имя_Группы к примеру Accounting (ролевая группа) – глобальная группа в этот тип групп у нас входят пользователи.
Группа Accounting входит в состав (Member Of) группы ACL_Accounting_FC или RW или RO
Еще раз:
User –> Accounting –> ACL_Accounting_RO (Read Only) –> Папка Бухгалтерии
User –> Accounting –> ACL_Accounting_RW (Read and Write) –> Папка Бухгалтерии
User –> Accounting –> ACL_Accounting_FC (Full Control) –> Папка Бухгалтерии
ACL_Имя_Группы_FC или RW или RO - это доменно локальная группа которая регулируют уровень доступа к файлам и папкам.
Теперь раздаем разрешения:
ACL_Accounting_RO – доменно локальная группа. NTFS разрешения на папку или файл Read Only
Доменно локальная группа это:
ACL_Accounting_RW - доменно локальная группа. NTFS разрешения на папку или файл Read and Write
ACL_Accounting_FC - доменно локальная группа. NTFS разрешения на папку или файл Full Control
Кто задается вопрос о модели вложенности групп в Active Directory статья Дмитрия Буланова
Сценарий 1:
Предоставить право на чтение и запись в папку Бухгалтерия пользователю User2.
”Вложить” пользователя User2 в группу ACL_Accounting_RW - это решит поставленную задачу, но противоречит нашей логике ролевого доступа.
“Вложить” пользователя User2 в ролевую группу Accounting, в свою очередь группа Accounting должна входить в группу доступа ACL_Accounting_RW – это решит поставленную задачу, но при таком подходе встает вопрос, а если части сотрудников отдела Бухгалтерия нужно дать доступ типа Read Only или Full Control на папку Бухгалтерия? В какую ролевую группу мы должны включить этого сотрудника?
Создаем ролевую группу Accounting_RO в которую будет входить наш пользователь, а сама группа будет входит в группу доступа ACL_Accounting_RO
Можно сразу пойти по такому пути и создавать группы по такой логике:
Accounting_FC --> ACL_Accounting_FC
Accounting_RW --> ACL_Accounting_RW
Accounting_RO --> ACL_Accounting_RO
Такой подход требует больших первоначальных трудозатрат, но когда дело касается практики он себя оправдает.
Вернемся к нашему вопросу:
Предоставить права на чтение и запись в папку Бухгалтерия пользователю User2.
Решение:
Ответственный инженер добавит пользователя User2 в ролевую группу Accounting_RW.
Результат:
В итоге пользователь видит только свою папку. Так же в корневой папке он не имеет никаких прав:
Идем в папку бухгалтерия и видим, что уже в папке бухгалтерия пользователь User2 имеет права Read and Write:
Сценарий 2:
Предоставить права Read Only в папку Бухгалтерия пользователю User3.
Решение:
Ответственный инженер добавит пользователя User3 в ролевую группу Accounting_RO
Так же как и User2, User3 увидит на файловом сервере только папку Бухгалтерия, но уже записать и удалить какие либо файлы не сможет:
Сценарий 3:
Предоставить права Read and Write в папку Бухгалтерия для User7 , но при увольнении User7 захочет удалить все файлы из папки Бухгалтерия.
Решение:
Ответственный инженер добавит пользователя User7 в ролевую группу Accounting_RW.
По легенде в папку бухгалтерия складывают свою данные еще четыре бухгалтера – это User2,4,5,6, но User7 при увольнении решил удалить все бухгалтерские документы, к счастью удаление файлов у которых пользователь не является владельцем удалить нельзя.
Но если у пользователя права Full Control, то в конечной папке он может делать все что ему вздумается.
Сценарий 4:
В папке Бухгалтерия должна быть создана подпапка Документы_Клиент_Банк. Этa папка будет использовать ответственными сотрудниками для хранения документов экспортируемые из клиент банков. Эту папку должны видеть только ответственные сотрудники.
Решение:
Первым делом выключаем наследовании этой подпапки Документы_Клиент_Банк:
Удаляем все унаследованные группы кроме:
Итог, на файловом сервере папка есть, но пользователь с правами которая предоставляет ролевая группа Accounting_RW или Accounting_FC или Accounting_RO ее не видит:
Дальше создаем ролевую группу к примеру ClientBank_RW (глобальаня) –> ALC_ClientBank_RW (доменно локальная) и назначаем разрешения:
Но так как папка Документы клиент банк вложена в папку Бухгалтерия и если просто добавить пользователя в группу ClientBank_RW, то пользователь увидит такую картину:
Почему? У пользователя нет никаких прав на папку верхнего уровня Бухгалтерия.
К примеру если он взаимодействует только с папкой Документы клиент банк то ему достаточно будет дать права Accounting_RO и ClientBank_RW после этого он сможет без проблем добраться до папки Документы клиент банк.
И в заключении включаем Data Dedeuplication:
Подведем итоги:
Мы создали файл сервер с ролевым типом доступа. Каждый пользователь файлового сервера видит только свои папки. Наш файловый сервер “живет” в пространстве DFS, что позволяет в будущем при необходимости масштабировать. Задействовали технологию Data Deduplication.
Соблюли вложенность групп в AD DS.
Будет интересно узнать о ваших мыслях о правильных, на ваш взгляд, практиках развёртывания и настройки файлового сервера на базе Windows Server.
RSS - Записи
Жду пост про "чудеса" ДФСа при больших кол-вах юзеров/филиалов/серверов :)
Если не страдать фигнёй и не делать active-active реплики, то всё отлично работает. ))
Более того, файло реально тянется не через DFS сервер, а с шары "поблизости".
а первый синк при овер 100500 файлах ? :)
Ну да, есть такое. Hint: Создавать пустые папки, потом заливать. А не подключать уже захламленные. )
а если файл открыт разными юзерами с разных серверов ? :)
Ну тут как бы статья о том, как сделать правильно, а не как исправить старые косяки? Надеюсь, автор раскроет и эту тему, начало у ж больно хорошее.
Нет опыта работы с DFS в таком окружении:
>ДФСа при больших кол-вах юзеров/филиалов/серверов
FileServer - не лучшее имя для пространства имён DFS. Лучший вариант - вообще одна буква. )))
Я не раз спотыкался о слишком длинные пути при таком подходе.
Поясню почему: даже если Вы даёте ссылку файл на маппированном, как буква диске, например так: S: = \\domain.com\FileShare , ссылка на файл в папке на этом диске всё равно будет "длинной", т.е.
не S:\SubFolderLevel1\SubFolderLevel2\FileName.ext .
а \\domain.com\FileShare\SubFolderLevel1\SubFolderLevel2\FileName.ext . От имена длинного имени домена понятно уже не избавиться, но хоть на длине имени пространства имён съэкономить стоит. Особенно при "наведении" порядка, т.е. переносе уже имеющихся шар в одну DFS структуру.
И ещё момент. До сих пор актуальный для многих, кстати. Не поленитесь избавиться от контроллеров домена на Win 2003, и поднять версию схемы AD, т.к. только при версии схемы домена от 2008 и выше появляется возможность включить ABE и для ссылок на корневые папки. Иначе папки, растущие от корня пространства имён не скрыть от лишних глаз.
Подключить DFS всем в домене политикой как единая буква диска - тоже здравая идея. Для Windows 8 и выше будет нужен маленький патч реестра, чтобы GPO отработал:
Простой скрипт на PowerShell из одной строки, прописанный на автозагрузку компьютера:
New-ItemProperty -Path "registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -Name "EnableLinkedConnections" -Value 1 -PropertyType "DWord"
про "возможность включить ABE и для ссылок на корневые папки" не знал - мерси за тайное знание ;)
- Не за что. )
Ещё момент: Everyone - FullAcces для Share Permission - явный перебор. Эдак юзеры себе "ноги отрезать смогут". Read + Write достаточно. Full Access - для группы админов only. IMHO
Опс. Full Control, а не Full Access, конечно. Опечатался.
Спасибо, ещё бы объяснить бизнесу что доступ делается для групп, а не нарезать каждому по подпапочке...
Предпочитаю удалять Creator Owner, иначе внутри одной папки со сходным доступом при ротации сотрудников будет каша из разрешений на файлы.
А удаление и восстановление уже решается методами РК.
Думал об этом. Надо смоделировать ситуацию.
Антон,
"Так как в AD DS я никогда не использую русский язык кроме поля Description в названиях групп мы используем английские аналоги, но для удобства в поле Description можно вписать русское название."
был печальный опыт?
Не помню уже, если есть опыт прошу поделиться.
Еще как был. пока не поняли, что проблема была с кириллицей. у разного оборудования (и к нему ПО) не всегда адекватно воспринимает кириллицу. А сохранять пресеты требуется. Особенно, если оборудование китайское.
Может я не уловил магию или придираюсь, но что мешает пользователю обратится не по DFS пути, а по имени сервера (как и раньше заходил) и увидеть туже картинку, что и в начале, с принтерами и списком доступных ему шар?
"Если на данном этапе реализации файлового сервера взять обычного пользователя и попытаться открыть наш файл сервер, то никаких файлов и папок мы не увидим, хотя они там есть:"
Понятно что внутри шары он увидит только что разрешено, но изначальная картина не изменится
"Ну и в заключении просишь показать скриншот рабочего файлового сервера компании со стороны обычного пользователя, результат обычно такой"
Так же, при объемах " к примеру на одну тыс. человек" имхо,порочная практика снимать наследование на вложенных уровнях, лучше такие папки выносить наверх, иначе при разделении ответственности администратор сервера vs администратор файлов (а при таких объемах организация серьезная и значит безопасность требует соблюдение норм и практик) вылезут такие грабли ....
И да, забыл еще одну группу сделать - ACL_Accounting_L (List Directory), что бы решить задачу когда в недрах папки Accounting, будет папка с файлами доступная другому отделу к примеру, эти люди должны будут дойти до необходимой инфы, но не видеть всего остального (папок и файлов). Это при условии "к примеру на одну тыс. человек" и как следствие вложенности больше двух уровней описанных в данной статье.
Интересно было бы увидеть более подробное описание настройки Data Deduplication и ее влияние на работу в реальных условиях с большим кол-во обращений к файлам в режиме 24x7.
P.S. AWE можно и на 2003 сделать, необходимо поставить патч-надстройку (за AWE на DFS 2003 не скажу, давно это было.)
>Может я не уловил магию или придираюсь, но что мешает пользователю обратится не по DFS пути, а по имени сервера
А если сервер будет упразднен?
>Так же, при объемах » к примеру на одну тыс. человек» имхо,порочная практика снимать наследование на вложенных уровнях
Все зависит от конкретной ситуации, я описал всего лишь небольшой опыт в решении задачи.
>Интересно было бы увидеть более подробное описание настройки Data Deduplication
Нет такого опыта.
Группу Все (Everyone) лучше вообще никогда не использовать, потому что группа Все включает в себя и гостевые учетные записи (ранее включала так же мерзкого NULL). Лучше использовать хотя бы Прошедшие проверку (Authenticated Users). Правильнее же использовать группу Пользователи домена (Domain Users). Кратко можно прочитать здесь: https://technet.microsoft.com/ru-ru/magazine/2009.01.securitywatch.aspx
Проблема с саботажем должна решаться не применением ACL для владельца файлов (Creator Owner), а аудитом, теневыми копиями и резервным копированием. Кстати, теневые копии (shadow copy) для файлового сервера почти обязательная вещь - позволяет быстро восстанавливать испорченные или случайно удаленные пользователями файлы. Из минусов теневого копирования: большая нагрузка на диски и расход места.
Относительно групп: считаю использование нескольких групп с разными уровнями доступа избыточным и сложным для контроля. Отловить неправильно назначенные права, например FC, на папку на для группы, которая должна иметь доступ RW может быть весьма непросто, пока кто-нибудь не нашкодит.
Сам я пришел к модели, при которой для каждой должности (скорее даже набору функциональных обязанностей) создана своя группа, для которой и назначаются права на папки. А пользователи добавляются уже в эти группы.
Не ясно как вы в будущем собираетесь реплицировать корень DFS между серверами? DFS-R не понимает точки повторной обработки (Reparse Points), которые создаются для папок, содержащих конечные объекты. И, если вы попробуете таким образом выполнить репликацию, то, скорее всего, вам будет проще пересоздать корень DFS. Вообще DFS-R и Reparse Points почти не дружат: https://blogs.technet.microsoft.com/filecab/2013/02/14/dfsr-reparse-point-support-or-avoiding-schrdingers-file/
Кстати, DFS-R, конечно, намного лучше FRS, но проблем с ним хватает. Недавно добрые люди накидали с десяток файлов по 4-6 ГБ в реплицируемую папку при промежуточной квоте (Staging area) в 4 ГБ и репликация остановилась до момента увеличения квоты.
Сергей, спасибо за советы. Будет еще задача по файловому серверу буду проверять Ваши утверждения и обновлять информацию в статье.
А будет продолжение ?
Интересно про квоты ;)
Есть папка \\fs\share\otdel\papka как можна задать квоты:
1) для группы ААА в 10 гб
2) для всех остальных 1 гб ??
На своём опыте пришли к модели, только одноуровневых папок, т.е. есть общая папка с папками, на которые в своё время нарезаны группы RO и RW. Далее ABE уже показывает каждому пользователю свой набор папок. Такая модель предоставления доступа легко автоматизируется и полнятна, даже самому отбитому юзеру.
т.е. у вас в \\dfs\shara\ размещено 100500 папок ?
Для ленивых создание папки File Server сделал скриптом PowerShell. Может кому пригодится.
$FolderPath = "d:\FileServer"New-Item -ItemType directory -Path $FolderPath
$acl = Get-Acl $FolderPath
$acl.SetAccessRuleProtection($True, $False)
$acl.Access | % { $acl.RemoveAccessRule($_) } # Удаляем настройки безопасности
#Задаем настройки безопасности (Domain Admins, Full Control, This Folder,Subfolders and Files)
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule('Domain Admins','FullControl', 'ContainerInherit, ObjectInherit', 'None', 'Allow') # I set my admin account as also having access
$acl.AddAccessRule($rule)
(Get-Item $FolderPath).SetAccessControl($acl)
#Задаем настройки безопасности (System, Full Control, This Folder,Subfolders and Files)
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule('System','FullControl', 'ContainerInherit, ObjectInherit', 'None', 'Allow') # I set my admin account as also having access
$acl.AddAccessRule($rule)
(Get-Item $FolderPath).SetAccessControl($acl)
#Задаем настройки безопасности (Creator Owner, Full Control, Subfolders and Files)
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule('Creator Owner','FullControl', 'ContainerInherit, ObjectInherit', 'InheritOnly', 'Allow') # I set my admin account as also having access
$acl.AddAccessRule($rule)
(Get-Item $FolderPath).SetAccessControl($acl)
#Задаем настройки безопасности (Domain Users, Read, This folder only)
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule('Domain Users','Read', 'none', 'none', 'Allow') # I set my admin account as also having access
$acl.AddAccessRule($rule)
(Get-Item $FolderPath).SetAccessControl($acl)
У меня диск - это по iscsi полка dell и на кластере... вопрос как Data Dedeuplication: будет жить) включить дает, как жить будет незнаю...
Коллеги, вопрос про квоты.
Есть шара \\fs\users$\ в ней каждому %username% создана папка с таким же именем. Эта папка мапится юзеру как приватный диск.
Таких папок 100500.
Вопрос: как каждой папке в \\fs\users$\ задать квоту в 1 Гб ??
я думаю нужно подумать в сторону скрипта на powershell
По поводу : "Accounting_RO и ClientBank_RW после этого он сможет без проблем добраться до папки Документы клиент банк." в конце поста. Тогда получается пользователь дойдет до своей личной и за одно почитает файлы в папке Accounting
Есть глубоко_вложенная папка \\fs\departament\otdel\papka-1\docs\
Как правильно организовать доступ для юзера только к этой папке? Технология АВЕ включена.
Ищу "автоматический" вариант :)
т.е. нужно что б заходя на \\fs (он мапится всем ) юзер мог спокойно проломится в docs не видя ничего другого...
Такое реально?
Как раз для этого ABE нужно использовать.
Не очень подходит для больших файловых серверов с большим количеством вложенных папок с особым доступом, который не наследуется от вышестоящей папки. У нас в конторе таких папок более 100. Получается помимо более чем 300 групп NTFS_ACL придется создавать еще более 300 ролевых групп. Поэтому в таком случае на обособленные папки создаются только группы NTFS_ACL и туда сразу включаются пользователи.
Далее, по поводу ABE. У нас юзеры привыкли прикликивать пути до своей обособленной вложенной папки сами, но в случае с ABE, они этого сделать не смогут, а смогут заходить туда только по прямым ссылкам.
Ну вобще нет. Вы на вышестоящие папки вешаете транзитные группы с folder only и правом read. Транзитные группы вкладываете друг в друга.
Описанный способ управления файловыми ресурсами через группы это считается best practices. Но вместо OU , нужно создавать Containers, чтобы к нему не было возможности применить групповые политики.
Есть ситуация. Есть путь до папки \\domen.local\fs\folderA\folderB\folderC у определенных лиц есть определенные права на папку А и последующие, но теперь одному человеку из другого отдела понадобилась папка С, как правильно организовать доступ?