Я должен предоставить некоторые разрешения определенному пользователю в Windows Server 2003 Active Directory, которые будут активны только для определенной группы пользователей. Первоначальная мысль заключалась в том, чтобы иметь просто OU, на которое мы предоставим этому конкретному пользователю определенные права (создание пользователя, сброс пароля, добавление пользователей в группы и т. Д.). Однако, прочитав дальше, я не уверен, нужно ли OU или нет, и я действительно не уверен, когда OU когда-либо понадобится. Это меня беспокоит, и я действительно хотел бы лучше понять цель OU, прежде чем использовать или не использовать их.
Я довольно много искал в Интернете, и результаты меняются от расплывчатого «Использование организационных единиц для организации AD» до несколько специфический «Добавьте OU в домен, если совершенно отдельной группе нужен особый административный доступ к сегменту пользователей». На данный момент наиболее подходящим здесь является последнее. С технической точки зрения вы можете использовать только мастер делегирования управления в подразделении. Однако я не вижу ничего, что мешало мне вручную назначать разрешения индивидуально для группы домена и фактически иметь то же самое. Что мне здесь не хватает? Спасибо.
Подразделения используются для организации объектов в Active Directory. Типичный пример будет следующим:
myDomain.loc
├─Users
├─Servers
│ ├Domain Controllers
│ └Member Servers
└─Workstations
├New York
├London
└Brisbane
Это упрощает визуальное различение объектов в домене, вместо того, чтобы полагаться на память или копаться в ней. Используя эту структуру, вы также можете применять политики к определенным контейнерам. Вы можете применить общую политику Internet Explorer к подразделению Workstations OU, чтобы она применялась ко всем дочерним объектам в этом дереве. Затем вы можете установить определенные параметры Internet Explorer для дочерних подразделений (например, различные политики, которые устанавливают домашнюю страницу IE для рабочих станций в Лондоне, а не другие политики, устанавливающие другую домашнюю страницу для рабочих станций в Нью-Йорке и т. Д.)
В вашем конкретном примере кажется, что вы хотите делегировать управление AD группе пользователей. В этом случае правильный метод - создать новую группу безопасности и сделать всех целевых пользователей членами этой группы. Затем вы должны открыть AD Users and Computers, щелкнуть правой кнопкой мыши по OU, над которым пользователи / группа должны иметь контроль, и выбрать Delegate Control.
Теперь ... если вы правильно организуете свою AD, у вас будет детальный контроль над тем, что вы хотите, чтобы эта группа пользователей имела контроль. Например, вы можете создать группу под названием NewYork-Admins и делегировать управление этой группой ТОЛЬКО рабочим станциям Нью-Йорка, а не всем рабочим станциям.
Идеальной структурой AD для этого типа делегирования была бы структура, подобная следующей:
myDomain.loc
├─Domain Controllers
├─Special Users
└─Locations
├─New York
│ ├─Users
│ ├─Workstations
│ ├─Servers
│ ├─Contacts
│ ├─Servers
│ └─Groups
├─London
│ ├─Users
│ ├─Workstations
│ ├─Servers
│ ├─Contacts
│ ├─Servers
│ └─Groups
└─Brisbane
├─Users
├─Workstations
├─Servers
├─Contacts
├─Servers
└─Groups
Это позволяет очень детально делегировать управление объектам AD.
Как правило, OU используются для:
Сохранять чистоту и структуру. Ваши пользователи не могут входить в группы, ваши группы - вдали от компьютеров, объекты на сайте A - вдали от объектов на сайте B и т. Д.
Делегирование контроля. Это действительно необходимо, только если у вас есть несколько уровней доступа или несколько сайтов с разными администраторами на каждом. Тем не менее, я бы все спланировал заранее и все бы настроил так, чтобы все равно это было возможно.
Групповые политики. Это не обязательно, так как приложением политики можно управлять с помощью разрешений или фильтров WMI, но все же полезно знать, что если пользователь находится в OU X, он получает политику Y.
Обратите внимание, что выше вы не может примените объект групповой политики к контейнеру, поэтому, если вы не создаете подразделения, вам придется установить все свои объекты групповой политики на верхнем уровне (домен) и отфильтровать их с помощью WMI или безопасности. Это Полегче чтобы вы и все остальные могли просто использовать OU, за исключением случаев, когда у вас есть сценарий, в котором определенные политики, которые вы хотите / нужные, не могут быть выполнены (или могут быть выполнены, но являются беспорядочными) с использованием модели OU.
Помимо очевидных технических требований в моих последних двух пунктах, я думаю, что держать вещи в чистоте и порядке - это достаточная причина. Легче найти нужный объект из списка из 100, чем, например, из списка из 1500. Он также отделяет объекты, которые вы создаете (в основном, пользователи, компьютеры и группы), от встроенных объектов, что может помочь предотвратить неприятные инциденты («ОК, кто удалил учетную запись администратора?»).
Я создал два подразделения, одно для хранения «сотрудников», а другое для хранения клиентов, которым необходимо пройти аутентификацию на наших FTP-серверах.
Причина, по которой я использовал подразделения, заключается в том, что некоторые из моих устройств могут аутентифицироваться по LDAP, но не (кажется?) Распознают только членство в группах. Кроме того, «казалось» лучше оцепить внешние счета. Если бы у меня была более крупная инфраструктура с большим количеством клиентов, я бы создал для них их собственный домен.