Мне нужно настроить план для организации разрешений для системных администраторов в 200-серверной сети Windows 2003/2008. Серверы существуют в 5 отдельных лесах, которые связаны через двусторонние доверительные отношения.
На данный момент я в основном сосредоточен на том, как лучше организовать группы. Все системные администраторы имеют одну учетную запись администратора в одном из лесов (лес A), и я хочу, чтобы они использовали эту учетную запись для управления всем.
Насколько я понимаю, обычно лучше всего:
Предоставьте доступ к ресурсам локальным группам домена в локальном лесу, где они существуют. Я сделал это, создав группы, такие как ForestB \ MemberServerAdmins, ForestB \ DCDNSAdmins, ForestC \ ExchangeReadOnlyAdmins и т. Д., И делегировал доступ к этим группам из различных приложений.
Организуйте пользователей по ролям в глобальные группы в лесу A, а затем поместите эти глобальные группы в локальные группы домена по мере необходимости. Я предполагаю, что это может быть сделано, например, отделом, в котором у вас есть группа, такая как ForestA \ Operations, и они получают доступ к некоторым, но не всем группам ресурсов, и другой группе, такой как ForestA \ Admins, и они получают доступ ко всем ресурсам. группы. Это просто пример.
Проблема в том, что нам действительно нужно назначать эти разрешения для ресурсов на индивидуальной основе. Мы небольшая компания, и у меня нет групп пользователей, которым обязательно нужны одинаковые разрешения. Из-за этого шаг № 2, описанный выше, кажется, не работает для нас. Решение, которое у меня осталось, - создать глобальные группы в ForestA, которые будут иметь в основном те же имена, что и различные группы ресурсов, например:
Администраторы ForestA \ ForestB MemberServer
ForestA \ ForestB DCDNSAdmins
ForestA \ ForestC ExchangeReadOnlyAdmins
а затем поместите отдельные учетные записи администратора в эти группы.
Я получаю гибкость, которую имеет это двухгрупповое решение для распределения ресурсов, но имеет ли смысл настраивать вещи таким образом? Мне это нравится, потому что тогда я могу управлять всеми разрешениями в ForestA и легко просматривать любую учетную запись администратора, чтобы увидеть, в какие группы они входят, чтобы определить, к чему у них есть доступ. Тем не менее, я не уверен, что это лучший маршрут?
Одна выгода от такого поведения приходит, когда у вас происходят кадровые изменения. Поскольку все настроено с помощью групп, вы создаете новую учетную запись, заполняете глобальные группы в Домене A, и все готово.
Я не уверен, что вы думали об альтернативах, но если вы думали просто напрямую помещать объекты пользователей из домена A в локальные группы домена в других доменах, вы теряете некоторую видимость, делая это. Если вы посмотрите на объект пользователя в Домене A, который находится непосредственно в локальной группе домена, скажем, в домене B, вы не обязательно увидите эту локальную группу домена на вкладке «Член» для пользователя. Итак, чтобы узнать, какой доступ имеет пользователь, вам нужно пройтись по различным локальным группам домена в поисках объекта пользователя. Если вы используете упомянутый здесь стиль Global / Local, вы можете просто взглянуть на членство пользователя в глобальной группе, чтобы быстро узнать, какой доступ у него есть.
Кроме того, использование групповой структуры облегчает рост. Если вы не создадите группы с самого начала, в конечном итоге рост может побудить вас захотеть их, и возвращение к группам позже может быть болезненным. (Не обязательно, но можно ...)
Пару мыслей, надеюсь, поможет.