Я пытаюсь исправить совершенно незапланированную и неструктурированную иерархию Active Directory. Когда домен был впервые создан в Windows Server 2000, никакие контейнеры или подразделения не создавались для пользователей или компьютеров. Все пользователи были собраны вместе в контейнере «Пользователи» по умолчанию, а все компьютеры - в контейнере «Компьютеры» по умолчанию.
В конечном итоге домен был обновлен, и теперь у меня есть два контроллера домена Windows Server 2008 x64. Но, конечно, текущая структура или ее отсутствие - это кошмар для назначения разрешений и применения групповой политики, поэтому мне нужно реструктурировать все это.
У меня вопрос о том, какого рода прерывание бизнеса мне следует ожидать при переводе пользователей и компьютеров в подразделения и группы, если таковые имеются?
Есть какие-нибудь советы, как это сделать? какие-нибудь указатели на передовой опыт?
На всякий случай остальная часть среды - это файловый сервер Windows Server 2008, сервер печати Windows Server 2003 R2, Windows Server 2003 R2 Exchange 2003 Server и Windows 2003 R2 x64 Server с SQL Server 2005 SP2.
Если все службы, взаимодействующие с Active Directory (или в основном), принадлежат Microsoft, у вас не должно быть никаких перерывов. Продукты Microsoft прекрасно знают, как динамически находить учетные записи, поэтому реструктуризация будет прозрачна для вашей операционной среды. Другие продукты, которые привязываются (например, через LDAP) к высокому уровню вашего каталога и выполняют поиск по поддереву, также не должны быть затронуты, в зависимости от того, на каком уровне они привязаны.
Вам следует искать другие службы, которые могут использовать Active Directory (опять же, через LDAP или аналогичный) и иметь жестко заданные привязки к объектам контейнера нижнего уровня (OU) или объектам конечного уровня (учетные записи, группы и т. Д.) При поиске. для объектов в каталоге. Ваша реструктуризация приведет к сбою этих поисков.
Например, мы используем платформу баз данных, отличную от MS, которая, да, действительно связана с AD для аутентификации пользователей. Однако он поддерживает свою собственную внутреннюю базу данных пользователей, и мы должны связать абсолютный ADsPath с каждой учетной записью пользователя при создании учетных записей для этой системы. Когда учетная запись пользователя перемещается в другое подразделение, аутентификация для этого пользователя прерывается, пока мы не обновим учетную запись с новым ADsPath.
Автоматический поиск этих служб не является тривиальной задачей, поэтому, если они у вас есть, я настоятельно рекомендую вести инвентаризацию приложений / служб, которые подключаются к AD.
Вы не должны ожидать никаких перерывов. Перемещение объектов в разные контейнеры не вызывает сбоев. Поскольку вы не можете применить политику непосредственно к подразделениям по умолчанию, вам даже не нужно беспокоиться о том, чтобы правильная политика применялась и к новым.
В целом, вы готовы пойти на это.
Что касается лучших практик, я стараюсь создать три подразделения верхнего уровня в новой среде. UserAccounts, Groups и Machines (или что-то подобное компьютерам). Оттуда я создаю дочерние подразделения для определенных типов машин (например, серверов / рабочих станций), административных групп / групп рассылки / групп ресурсов и т. Д. Таким образом легко настроить таргетинг на всех пользователей / компьютеры с широкими политиками и по-прежнему связывать более конкретные политики с более конкретные OU.