Назад | Перейти на главную страницу

Несколько тестовых сред Active Directory вместе с производственными контроллерами домена

Как лучше всего иметь несколько тестовых сред рядом с производственной?

У нас есть несколько команд программирования, которые создают решения, очень часто использующие Active Directory. Мы пробовали разные подходы, начиная с их собственных контроллеров домена (в той же подсети) или дополнительных подразделений в нашей производственной AD, над которыми команда получает контроль и может создавать / удалять учетные записи в этом одном подразделении.

Мы подумали о возможных 4 решениях:

  1. Создание отдельных подразделений в производственной среде.
  2. Создание поддоменов для наших contoso.com домен как test.contoso.com, something.contoso.com и делегирование управления командам (нужны ли нам дополнительные DC или двух, которые у нас уже есть, будет достаточно, чтобы провести это?
  3. Настройка дополнительного контроллера тестового домена, который доверяет нашему основному домену, и все команды могут использовать контроллер тестового домена по своему усмотрению.
  4. Настройка единого контроллера домена для каждой команды / проекта.

Мы принимаем во внимание количество необходимых ресурсов, безопасность (например, наличие нескольких контроллеров домена с несколькими паролями может побудить пользователей использовать более простые пароли) и общие передовые практики для этого сценария.

Обновление: в 90% случаев это будет аутентификация для SharePoint, BizTalk, CRM и т. Д. В других случаях это может быть SPN, аутентификация Kerberos и тесты с центром сертификации.

Это зависит от того, что вы тестируете, и от того, что нужно делать в AD. Мои мысли о ваших решениях:

  1. Это нормально, если вы просто тестируете создание / удаление учетной записи, как вы сказали в своем вопросе. Пока это все или большинство того, что делают ваши продукты.
  2. Да, каждому домену нужен хотя бы один DC - лучше два в случае отказа одного. Даже для тестовой среды. Это позволяет им возиться со всем, что они хотят.
  3. Это ужасная идея. Неважно, к какому DC в вашем домене они подключаются - AD - это база данных с несколькими главными серверами, поэтому изменение, внесенное в одном месте, будет реплицировано повсюду. Вы ничего не защитили - если вы позволите им добавлять / удалять учетные записи в любом месте, они могут случайно удалить все учетные записи или совершить другую херню в вашей производственной сети. Первой задачей после восстановления вашей сети будет куча розовых промахов, и, вероятно, для ваших системных администраторов, а не для команды разработчиков.
  4. В сегодняшнюю эпоху простой виртуализации вам, вероятно, лучше всего создать хотя бы один тестовый домен (без доверительных отношений в / из домена prod) для всех и, в зависимости от вашей корпоративной и сетевой схемы, создать дополнительные тестовые домены для взаимодействия всех с помощью по мере необходимости, или пусть каждый из ваших разработчиков имеет DC (или несколько), работающих в виртуальной машине на их собственном компьютере или на втором рабочем столе в своем кубе. Там тоже есть много других архитектурных вариантов; в зависимости от вашего бюджета и потребностей.