Я исследую возможность переноса нашей небольшой (но не крошечной) инфраструктуры хостинга с автономных серверов, каждый из которых имеет уникальные локальные имена пользователей и пароли, на более интегрированную установку активного каталога с целью использования следующих функций:
Я использую половину на Vmware server 2 (в настоящее время мигрирую на Esxi), в основном, на машинах с win2k3, а половина на физических машинах также работает в основном с win2k3.
Серверы: 2x DNS сервера
5 веб-серверов IIS6
5x серверов MSSQL2000 / 2008
10 выделенных серверов IIS6 и MSSQL 2000
2 сервера резервного копирования NAS
2 сервера IIS7 и MSSQL 2008
5 серверов Win2k3x64 с сервером VMware (скоро будут преобразованы)
Разные тестовые серверы
Теперь у меня (благодаря мощности VMware) 2 контроллера домена
Я столкнулся с проблемами при попытке работать с существующим DNS-именем AD (companyname.com), которое существует на существующих DNS-серверах. Следует ли мне настраивать их для приема обновлений от новых контроллеров домена или следует делегировать полномочия другим способом?
Меня больше всего беспокоит лучший способ для примерно 10 пользователей войти в домен в удаленном центре обработки данных из моего офиса. Можно ли мне посоветовать настроить 1-2 контроллера домена в моем офисе для входа в систему? Могу ли я, если настроен правильно, связать пользователей, чтобы упростить вход на мои удаленные серверы? Или мне не нужны контроллеры домена в офисе? Я не хочу, чтобы в случае выхода из строя Интернета пользователи не могли войти в свои машины.
Мое второе беспокойство заключается в том, что если я перейду от общего входа пользователя в систему для удаления серверов, в настоящее время эти пользователи совместно используют сеанс службы терминала и захватывают неактивные сеансы и т. Д. Если у меня есть люди, осуществляющие доступ через уникальные учетные записи, отдельные сеансы будут созданы для каждого пользователя. Как они управляются в среде AD, или они подчиняются лимиту win2k3 в 2 сеанса + консоль по умолчанию? Если бы я должен был приобрести дополнительную лицензию на сервер терминалов, на пользователя или на машину? Я беспокоюсь об этих проблемах, которых в настоящее время нет.
Я планирую пилотное подключение пары серверов каждого типа к новому домену с последующим массовым развертыванием, что кажется правильным путем.
Может ли кто-нибудь ответить на мои вопросы или указать на что-нибудь вопиющее, что я упустил?
Что касается интеграции с DNS, наиболее распространенным решением является использование поддомена. Затем вы должны настроить свои текущие DNS-серверы, чтобы делегировать полномочия для этого поддомена серверам AD.
Например, если ваш сайт - example.com, вы можете преобразовать полное доменное имя домена во что-то вроде ad.example.com. Ваши DNS-серверы для example.com будут иметь заглушку, указывающую на ad.example.com. Убедитесь, что у DHCP есть оба суффикса или хотя бы один суффикс AD.
Есть смысл?
В идеале у вас должен быть хотя бы один контроллер домена, локальный для ваших пользователей, но если у вас достаточно быстрое соединение с тем местом, где они физически расположены, это не имеет большого значения. Даже в этом случае я бы предпочел видеть по крайней мере один DC, который не будет изолирован от ваших пользователей в случае сбоя WAN, это не обязательно должен быть особенно мощный сервер, любого сервера начального уровня, вероятно, будет более чем достаточно для вас.
Если вы временно потеряете доступ к домену, то локальный вход в систему на машинах будет продолжать работать для учетных записей, которые уже вошли в систему ранее - при этом используются локально кэшированные учетные данные так же, как отключенный ноутбук работает, когда он находится вне сети.
Когда вы переходите к правильному сопоставлению учетных записей и пользователей, вам необходимо будет разобраться с лицензированием сервера терминалов для систем, к которым подключаются ваши пользователи, поскольку будет применяться ограничение 2 сеанса + консоли. Есть несколько вариантов - клиентские лицензии на устройство могут быть подходящими, если у вас есть много пользователей, которые используют одни и те же системы, используемые для доступа к сеансам терминала (например, у вас есть пул из (относительно) небольшого количества общих ПК для большого количества пользователей. большее количество пользователей), но лицензирование по количеству пользователей, вероятно, будет лучше, если у большинства ваших пользователей есть выделенный ПК. В Часто задаваемые вопросы о лицензировании служб терминалов есть более подробная информация об этом.