Итак, вот сценарий -
Мы находимся в процессе централизации ИТ в центре обработки данных в одном месте. В настоящее время у меня есть 12 различных операционных компаний, которым нужны общие функции безопасности и обмена. В нынешнем виде все они представляют собой отдельные отдельные области разного уровня. Существует система бухгалтерского учета всей компании, которую необходимо интегрировать с AD, которая в настоящее время работает в совершенно отдельном домене, и я хотел бы, чтобы люди использовали свою собственную информацию для входа в AD.
Вот мой вопрос-
Зная, что необходимо затронуть все домены Active Directory независимо от того, чтобы довести их все до единообразного функционального уровня, и что в любом случае предстоит проделать значительную работу, какая конфигурация будет лучше? Я знаю, что у каждого есть несколько точек, но я хочу убедиться, что сейчас покрываю свои базы, прежде чем выбирать путь. Я выбираю один лес \ родительский домен? Или разделите домены, используя доверительные отношения между корпоративным доменом и операционными компаниями, например конфигурацию луча и концентратора? Каковы плюсы и минусы каждого из них?
Спасибо-
Дополнительные сведения: Существует некоторая потребность в делегировании административных функций ... она работает скорее как среда франчайзинга, чем отдельная компания. Администрация будет отвечать только за свою компанию и не более того. Накладные расходы на оборудование и программное обеспечение не являются проблемой, каждая компания в любом случае использует свой набор политик, поэтому часть политики не дает никаких реальных преимуществ или недостатков.
Если операционные компании разбросаны по США, меняет ли это вообще ваши рекомендации?
Самая веская причина не использовать один домен (и лес) - это необходимость иметь отдельных администраторов в каждом лесу. Это граница безопасности. Если у одних и тех же людей будет полный набор ключей, упростите им задачу. Чтобы быть ясным, я не говорю о делегировании для определенных задач - это группа людей, которые будут администраторами предприятия.
Это не сильно меняет мои рекомендации, потому что вы можете делегировать вещи по мере необходимости, как я сказал выше. Если у части организации есть локальные администраторы, которым необходимо иметь возможность редактировать объект групповой политики, назначенный их подразделению, вы можете дать им это в качестве примера. Однако, если им нужен полный контроль над своей частью домена до такой степени, что они должны иметь возможность заблокировать вас, тогда вам понадобятся отдельные леса, и могут возникнуть трудности при обмене временем. Так что, поскольку вы разделяете «безопасность и обмен», похоже, что единый домен - все еще правильный путь.
Лично, если это проект централизации, я бы использовал один домен и использовал бы подразделения для разделения вещей. Это избавляет от необходимости иметь полное резервирование для каждого дочернего домена, упрощает роуминг и перемещение, а также значительно сокращает конфигурацию и сложность.
При правильной настройке сайтов и сервисов недостатков практически нет.
Структура родительского / дочернего домена - артефакт 20 века. В какой-то момент было разумное объяснение, возможно, при приобретении / выделении компаний имело смысл разделить бизнес-единицы в их собственной сфере.
У нас есть в значительной степени родительский корневой домен с 13 дочерними доменами. У всех этих доменов есть трасты, и если трасты ломаются, то и все остальное. По моему опыту, эти поломки обычно происходят сами по себе, но последствия очень сильные. О, и они могут разорваться в двух направлениях, поэтому, если вы пойдете по этому маршруту, убедитесь, что вы знаете, как использовать nltest для проверки доверия на всех доменах в обоих направлениях, если у вас есть проблема.
Есть и другие последствия. Все эти домены имеют несколько разделов, которые реплицируются в глобальный каталог. В нашем GC около 40+ разделов. Репликация более сложна, и ее нужно сломать. Как репадмин? Лучше, если вы пойдете с отдельными доменами.
Я бы не стал следовать стратегии родительского / дочернего домена, если в этом не было настоятельной необходимости.
Еще одна вещь: если домен, в котором находится бухгалтерское приложение, должен взаимодействовать с другими серверами (например, интерфейсными веб-серверами), и вы используете олицетворение, эти серверы должны находиться в том же домене. Конечно, если у вас плоский домен, это не проблема, но некоторые большие распределенные реализации AD от этого сгорают. Учетные записи пользователей могут находиться в любом домене, но серверы ресурсов, такие как интерфейсные веб-серверы и внутренние базы данных, должны находиться в одном домене при использовании олицетворения.