В крайнем случае: клиенту необходимо протестировать CRM-систему с поддержкой Active Directory, которая состоит из SQL 2008 Server и Windows 2008 Standard Server (сервер приложений). Насколько мне известно, Active Directory требуется для аутентификации конечного пользователя и для аутентификации приложения в SQL.
Нам нужно вытащить эти два сервера из их текущей доменной среды и настроить в испытательном центре, который имеет подключение к Интернету, но не находится в домене (foo.local) или любой домен в этом отношении; на данный момент это просто набор рабочих станций в рабочей группе.
Моя первоначальная мысль заключалась в том, чтобы настроить туннель IPSec для местоположения клиента в / из объекта тестирования, но мне интересно, будет ли проблема с перекрытием подсети LAN (здесь брандмауэры pfSense) для управления и / или при изменении IP-адресов два сервера (FOOAPP и FOOSQL) в другую подсеть, чтобы избежать перекрытия, это вызовет некоторые проблемы в области AD (т.е. контроллер домена не будет "знать", кто эти серверы).
Другой моей мыслью было настроить контроллер домена только для чтения и доставить его на объект в центр тестирования, но, судя по моему беглому чтению технической документации, похоже, что он должен иметь возможность разговаривать с контроллером домена местоположения клиента (s ).
Наконец, я знаю, что вы можете аутентифицировать рабочую станцию в автономном режиме с использованием кэшированных учетных данных: будет ли это работать с рядовым сервером? Я предполагаю, что не как аутентификация SQL, которая происходит между FOOAPP и FOOSQL вероятно, вообще не использует кеширование, но, пожалуйста, просветите меня, если нет.
Есть другие варианты?
РАЗЪЯСНЕНИЕ
Эти серверы сейчас не используются в производстве. Пока они присоединены к домену клиента, в нем нет данных и никто ими не пользуется; на данный момент они просто бездействующие рядовые серверы. База данных SQL будет загружена с тестовыми данными, а затем будет использоваться для обучения, но мы вернем их обратно в местоположение клиента и, таким образом, в производство после завершения периода принятия пользователя / обучения конечного пользователя (с удалением тестовых данных). .
Мы не можем проводить тестирование / обучение на месте, потому что это было бы слишком разрушительно для офиса клиента, и у них нет большого зала заседаний для размещения групп тестирования / обучения.
РЕДАКТИРОВАТЬ
Думаю, все это можно разделить на два вопроса:
Что происходит с контроллером домена (только для чтения | с возможностью записи), когда он изолирован от других контроллеров домена?
«Заботится» ли Active Directory об IP-адресах? то есть, возможно, я могу временно разместить эти два сервера в другой подсети и настроить туннель IPSec, чтобы эти серверы и рабочие станции на испытательном объекте могли связываться с доменом в офисе клиента.
Active Directory по умолчанию функционирует в многомастерная репликация режим, в котором каждый контроллер домена независимо является полномочным для домена (ов), которым он управляет. Таким образом, тестовые контроллеры домена по-прежнему смогут обрабатывать входы в систему и получать обновления (изменение пароля и т.п.) даже при отключении. Два набора контроллеров домена (действующие и те, что находятся на тестовом сайте) со временем будут медленно расходиться, но это проблема только в том случае, если вы собираетесь потом их объединить.
Вот мое предложение по работе с этим сценарием:
Поскольку это только для тестирования, рассматривали ли вы возможность запустить виртуальную машину на одной из машин и настроить ее как DC? Что-то вроде Virtualbox, несмотря на то, что он не является хорошим выбором для производственного использования, в этом случае подойдет.
1) Когда стандартный DC изолирован от других DC в домене, он будет продолжать выполнять все свои функции, потому что каждый AD DC может работать самостоятельно; вы столкнетесь с проблемами только в том случае, если вам нужен доступ к одной из ролей FSMO (например, выполнение расширения схемы или исчерпание RID для новых пользователей), но это происходит только в некоторых очень специфических ситуациях, которые вы вряд ли будете запускать в тестовой среде. Конечно, если вы внесете какие-либо изменения в AD в одном из двух сегментов (например, создадите учетную запись пользователя или даже измените пароль), это не будет реплицировано на другой ... и если вы когда-нибудь планируете переподключить их , вы, скорее всего, столкнетесь с конфликтами репликации.
Это не относится к контроллерам домена только для чтения: если один из них изолирован от остальной сети и у вас нет доступного контроллера домена с возможностью записи (даже через канал WAN), большинство функций AD будет недоступно; вы не сможете создавать / изменять что-нибудь, и это, конечно же, включает в себя присоединение компьютеров к домену, управление учетными записями пользователей и группами и т. д.
2) AD заботится об IP-адресах для двух вещей: репликации данных и определения «ближайшего» доступного контроллера домена, чтобы избежать ненужного трафика WAN; обе функции полагаются на определение сайтов, подсетей и ссылок сайтов. Если вы хотите настроить WAN-ссылку на место с IP-адресом, отличным от вашей основной LAN, и разместить там DC, вам нужно будет определить сайт и подсеть в консоли Active Directory Sites and Services; это позволит AD управлять репликацией между контроллерами домена в основном и удаленном, а также сообщит серверам и клиентам в этом месте о необходимости взаимодействия с локальным контроллером домена.
Вот что я бы предложил:
Настройте изолированную сеть на текущем хосте ESXi. Клонируйте существующие серверы, необходимые для теста, и подключите их к изолированной сети. При необходимости вы можете захватить роли FSMO на изолированном контроллере домена, поскольку он изолирован от производственной сети, это не будет иметь никаких разветвлений для производственной сети. Присоедините тестового клиента к изолированному домену и проведите тестирование.
Мне это кажется самым простым решением.
Одна проблема, которую вы обязательно должны учитывать при переводе контроллера домена в автономный режим (что касается производственной сети), заключается в том, что если он находится вне производственной сети дольше, чем время захоронения, он может содержать объекты, которые были удалены из производственной сети ( известные как устаревшие объекты), и при повторном подключении к производственной сети могут возникнуть проблемы с согласованностью. У меня были такие проблемы, и это было некрасиво.
Это не должно быть проблемой, если вы просто решите пару проблем в процессе. Если домен изначально был Windows 2000 и обновлен до 2003, возраст захоронения составляет 60 дней, а если он начинался как домен Windows 2003, возраст захоронения составляет 180 дней. Вы можете изменить возраст надгробия, но для этого потребуется использование ADSIedit или другого инструмента для непосредственного изменения раздела службы каталогов Active Directory, и я не знаю, будет ли вам это удобно или нет. (путь: CN = Directory Services, CN = Windows NT, CN = Services, CN = Configuration, DC = yourdomain, DC = yourdomainsuffix) Это приведет к тому, что Active Directory займет больше места на ваших контроллерах домена, поскольку они будут удерживать все удалял объекты дольше, прежде чем полностью удалить их.
Перед отключением внешнего контроллера домена вы должны выполнить синхронизацию времени, чтобы свести к минимуму любой дрейф времени, когда он находится за пределами площадки. Важная часть заключается в том, что при повторном подключении вы должны сначала настроить строгую согласованность репликации на контроллерах домена производственной сети. предшествующий к повторное введение то выключен сайт ОКРУГ КОЛУМБИЯ (используя инструмент Repadm с переключателем / regkey) и не забудьте настроить внешний контроллер домена для неавторизованного восстановления, а также предшествующий к повторному подключению, поэтому он как можно скорее скопирует новый SYSVOL.