Одна Active Directory, несколько служб удаленных рабочих столов (решение Server 2012)

То, что я пытаюсь сделать, довольно сложно, поэтому я решил, что я передам это более широкой аудитории, чтобы посмотреть, сможет ли кто-нибудь найти изъян. То, что я пытаюсь сделать (как MSP/VAR), - это разработать решение, которое предоставит нескольким компаниям удаленный рабочий стол на основе сеансов (компании, которые должны быть полностью отделены), используя только несколько серверов. Вот как я это себе представляю на данный момент:

  • CORE SERVER - Центр обработки данных Server 2012 (ниже приведены серверы HyperV)
    Сервер1: Cloud-DC01 (доменные службы Active Directory для mycloud.local)
    Server2: Cloud-EX01 (Exchange Server 2010 работает в мультитенантном режиме)
    Сервер 3: Cloud-SG01 (Шлюз удаленного рабочего стола)
  • CORE SERVER 2 - Центр обработки данных Server 2012 (ниже приведены серверы HyperV)
    Сервер1: Cloud-DC02 (доменные службы Active Directory для mycloud.local)
    Сервер2: Cloud-TS01 (узел сеанса удаленного рабочего стола для компании A)
    Сервер 3: Cloud-TS02 (узел сеанса удаленного рабочего стола для компании B)
    Server4: Cloud-TS03 (узел сеанса удаленного рабочего стола для компании C)

Я подумал о том, чтобы настроить каждую Организацию в своем собственном подразделении (возможно, создать их структуру подразделений на основе структуры подразделений арендаторов Excahnge 2010, чтобы учетные записи были связаны). Каждая компания получит сервер узла сеансов удаленных рабочих столов, который также будет служить файловым сервером. Этот сервер будет отделен от остальных в своем диапазоне. Сервер Cloud-SG01 будет иметь доступ ко всем этим сетям и направлять трафик в соответствующую сеть, когда клиент подключается и проходит проверку подлинности, чтобы они были отправлены на правильный сервер (на основе коллекций сеансов в 2012 году).

Я не буду лгать, это то, что я придумала довольно быстро, поэтому вполне может быть что-то явно очевидное, что я скучаю. Любая обратная связь будет оценена.

Источник

1 ответ

Решение

Это очень похоже на то, что мы делаем. У нас есть единый шлюз TS, через который проходят все наши клиенты. Это имеет политики подключения и ресурсов, которые контролируют, какие группы пользователей могут входить на какие серверы.

Каждая компания имеет свой собственный терминальный сервер. Большинство компаний могут войти только в один TS, но для одного особенно крупного клиента у них есть два. Мы не проводим их кластеризацию, только половина пользователей подключается к TS1, а другая половина подключается к TS2.

Все серверы находятся в одном сегменте сети, и у нас есть очень строгие списки ACL, чтобы определить, кто может пойти куда-то в сети (то есть никто не может никуда идти). Наш объект групповой политики для серверов RDS также значительно ограничивает возможности их размещения на самом сервере.

Самая большая проблема, с которой мы сталкиваемся при этой установке, - это автоматическое развертывание серверов для новых клиентов. Большая часть процесса может быть автоматизирована (мы используем ESXi и vSphere, у которых есть интеграция PowerShell. То же, что и у Hyper-V), но я еще не нашел, как автоматизировать изменение политик шлюза TS.

У нас также есть один очень большой клиент, который использует наши терминальные серверы. Поскольку я не хотел самостоятельно управлять всеми их сбросами паролей и новыми учетными записями, мы предоставили им права делегирования для их собственного подразделения в домене. Когда они начали опережать это по политическим причинам, мы предоставили им свой домен под нашим лесом. Пока все хорошо работает, кроме того, что вы не можете использовать User must change their password on next logon так как это несовместимо с TS Gateway. То же самое происходит, когда истекает срок действия их пароля, они не могут войти в систему, и кто-то должен сбросить свой пароль вручную.

Источник
Другие вопросы по тегам