Действительно ли это - рекомендуемый/допустимый подход для полномочий файлового сервера?

Тот подход не плох. Как правило, никогда не используйте отдельных пользователей, чтобы добавить, что полномочия - используют группу. Группы могут однако использоваться через ресурсы. Например, HR мог бы иметь доступ RW к файлам, в то время как у МЕНЕДЖЕРОВ мог бы быть R. Можно также настроить основанное на доступе Перечисление. Смотрите на следующий вебкаст:

Вебкаст TechNet: ряд администрации Windows Server 2003 (Часть 4 12): управление группы (уровень 200)

Основанное на доступе перечисление может сделать жизнь легче, также см.:

Основанное на доступе перечисление

ABE может помочь сократить количество различных долей, которые необходимо администрировать.

Ваш подход является в основном способом, которым я приблизился бы к нему.
Единственные вещи, которые я добавил бы, являются ими:

1) Я добавил бы к Вашей "ролевой" схеме путем оценки того, в чем они нуждаются через серверы не всего на одном сервере, Вы, вероятно, собираетесь столкнуться с выбросами к этому, но моя теория с теми состоит в том, когда Вы сталкиваетесь с ними, создаете другую группу. по моему опыту, где существует одна изолированная часть существуют многие.

2) Я был бы СИЛЬНО re-evalute потребность в Универсальных группах для всего, поскольку Вы получаете удар репликации с ними, поскольку участники и группы в Универсальной группе копируются в Глобальные серверы Каталога, в то время как с Доменом, Локальным и Глобальным только, группа копируется в глобальные серверы каталога. Таким образом, при внесении изменения в универсальной группе, это начинает репликацию, в то время как с глобальным и доменным, локальным, это не делает.

Ваш метод использования группы ресурсов для каждого уровня доступа корректен. Единственная вещь, которую я рассмотрел бы, использует Domain Local Groups для ресурсов. Необходимо не обязательно использовать Universal Groups при создании определенных для сервера групп ресурсов.

Оборотная сторона использования Domain Local Groups для ресурсов - то, что Вы заканчиваете с большим количеством общих групп. Позитивный аспект - то, что у Вас есть меньше проблемы с репликацией как отмеченный Zypher.

Я смотрю на миграцию от NetWare до Windows Server 2008, таким образом, это было на моем уме много в последнее время. 2008 сервера (и в некоторой степени Сервер 2003R2) имеет некоторые очень хорошие функции, которые действительно упрощают этот переход. Сервер 2008 идет с основанным на доступе Перечислением из поля. Это - очень хорошая функция, которая позволяет пользователям только видеть каталоги, в которые они имеют права. Если Вы принимаете участие как...

\\user-home-srv\homes\

Без ABE конечный пользователь видел бы десятки/сотни/тысячи каталогов. С ABE конечный пользователь видел бы только один. То же сохраняется общих долей. С ABE у Вас может быть единственный огромный объем для всех Ваших ведомственных каталогов, если Вы желаете и не массово рассылаете heck из своих пользователей с каталогами, они не могут войти. В то время как не проблема ACL, это несколько связано так, я поднимаю его.

Другой вещью, что Сервер 2008, кажется, добивается большего успеха, чем его более ранние версии, является наследование ACL. Это просто кажется быстрее при распространении вниз к листу изменение ACL наверху большого дерева.

Из-за нашего наследия Сетевого обеспечения, у нас есть большое количество групп, которые называют на основе того, кто находится в них с некоторыми там названными по имени того, к чему они предоставляют доступ. Для каталогов, которые систематизировали доступ, мы также используем "Полную" номенклатуру "RO".

У нас есть монолитный "общий" объем (все еще на NetWare, но мы планируем иметь его монолитный, когда мы перемещаемся в Windows), который является единственным совместно используемым томом для всех 4 400 рабочих и имеет более чем 3,5 миллиона файлов на нем. Каталоги верхнего уровня являются всеми названиями отдела, и каждый отдел регулирует то, что продолжается в них. Существует несколько исключений для действительно крупных отделов, у этого есть 2-й уровень каталогов с ACLs.

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

Предложенный подход кажется довольно серьезным. Одна вещь высматривать, хотя путь Вы первоначально, настроила доли файла. Методические рекомендации состоят в том, чтобы иметь единственную долю верхнего уровня, содержа подпапки, которым Вы затем присваиваете полномочия группы. NTFS может затем обойти "Файл Папки/Выполнять Пересечения" на высокоуровневой папке и предоставить доступ к подпапке.

Структура была бы затем похожа на \servername\sharename\group-папку с полномочиями доли, только бывшими должными быть установленными на "sharename" папке и фактическом наборе полномочий NTFS на папке "папки группы".

Ваш файловый сервер сможет работать лучше с этим видом установки также.

Общие другие вещи, которые я сделал бы, имеют соглашение о присвоении имен для групп, таким образом, что название группы совпадает с именем папки группы (с FC/RW/RO, добавленным при желании), и прикрепите UNC к папке в описание группы (так, чтобы Ваш сценарий входа в систему мог считать его назад и установить диск, отображающий тот путь, и также так, чтобы можно было более легко видеть то, к чему совместно используемые папки относятся который группы).

Лучшему варианту развития событий нужно было добавить каждого пользователя ко всего одной группе безопасности для должностной роли пользователя. Роль затем является делегированным доступом при необходимости.

Аналогичным образом, совместно используемой папке нужно предоставить доступ с помощью групп безопасности "ресурса", как "FILE01-тестовый пример" Результатов-RW. Это будет содержать должностные роли, роли отдела или другие применимые группы.

Позитивный аспект этого дизайна - то, что Вы делегируете доступ на основе на группу (команда, отдел, и т.д.), и не одноразовый доступ, который может быть трудно отследить. Когда пользователь передает другому отделу, необходимо очистить весь старый доступ.

Оборотная сторона - то, что группы могут неправильно использоваться. Сделайте ясные различия относительно того, для чего используются группы, так, чтобы группы ресурсов, присвоенные доле, не были снова использованы, как будто они были ведомственными группами, создавая запутанную путаницу доступа.

Общепринятая практика, которую я использовал для файлового сервера Windows начиная с Windows 2000 (размеченный в серии Mastering Windows Server Mark Minasi, поэтому там ищите больше информации), должен использовать группы, которые локальны для самого файлового сервера для вложения.

Например, рассмотрите файловый сервер под названием KERMIT в домене под названием МАППЕТЫ.

Скажите, что KERMIT имеет несколько долей файла:

\\KERMIT\Applications
\\KERMIT\Finance
\\KERMIT\Sales
\\KERMIT\Manufacturing

Создайте группы, локальные для KERMIT для доступа, и дайте им полномочия в файловой системе точно, поскольку Вы указали (т.е. одна группа на уровень доступа на долю)

KERMIT\Applications-RO
KERMIT\Applications-RW
KERMIT\Applications-FC
KERMIT\Finance-RO
[...]

Поскольку это локальные группы, можно поместить то, что другие группы или пользователей Вы хотите в них - доменные локальные группы, глобальные группы, универсальные группы, учетные записи пользователей от любого домена в Вашем лесу. Управление правами теперь локально для групп файлового сервера, а не файловой системы или AD.

Это действительно добавляет дополнительный слой к Вашему управлению групп, но оно обладает преимуществом разрешения (говорят) что локальные для сайта администраторы для управления их собственными файловыми серверами, не нуждаясь в чем-то большем чем правах администратора к тому файловому серверу. Если у Вас есть федеративный вид структуры филиала, где каждый офис отчасти делает свою собственную вещь с его серверами, это может быть реальной выгодой. Вы не можете хотеть должными быть давать AD права администратора нескольким дюжинам локальных администраторов сайта.

Это также мешает Вашему AD быть нарушенным большим количеством групп (одна группа на уровень доступа на долю на сервер может сложить очень быстро), и минимизирует репликацию группы между GCs. Это позволяет Вам резервировать свои AD группы для ролей вместо полномочий.

Если Ваша среда строго стандартизирована, и все файловые серверы идентичные и дублируемыми, то это - очевидно, еще один слой групп, в которых Вы не нуждаетесь. Кроме того, если Вы знаете о необходимости в конкретной AD группе для имения тех же прав на доле, которая существует на каждом файловом сервере, Вы испытываете необходимость в некоторой автоматизации для поддержания этого.

Короче говоря чем более отличающиеся Ваши файловые серверы друг от друга, тем больше машины использования локальные группы имеют смысл. Чем больше они подобны, тем больше Вы хотите использовать систему, Вы в настоящее время используете.