То, что я пытаюсь сделать, довольно сложно, поэтому я решил рассказать об этом более широкой аудитории, чтобы посмотреть, сможет ли кто-нибудь найти недостаток. Что я пытаюсь сделать (как MSP / VAR), так это разработать решение, которое предоставит нескольким компаниям удаленный рабочий стол на основе сеансов (компании, которые должны быть полностью отделены), используя только несколько серверов. Вот как я это себе сейчас представляю:
Я думал о том, чтобы создать каждую организацию в отдельном организационном подразделении (возможно, создать структуру организационного подразделения на основе структуры клиентского подразделения Excahnge 2010, чтобы учетные записи были связаны). Каждая компания получит сервер узла сеанса удаленного рабочего стола, который также будет выполнять роль файлового сервера. Этот сервер будет отделен от остальных на своем собственном диапазоне. Сервер Cloud-SG01 будет иметь доступ ко всем этим сетям и направлять трафик в соответствующую сеть, когда клиент подключается и аутентифицируется, чтобы они были отправлены на правильный сервер (на основе коллекций сеансов в 2012 году).
Я не буду лгать, это то, что я придумал довольно быстро, так что вполне может быть что-то очевидное, чего я упускаю. Любая обратная связь будет оценена.
Это очень похоже на то, что делаем мы. У нас есть единый шлюз TS, все наши клиенты проходят через. У этого есть политики соединений и ресурсов, которые определяют, какие группы пользователей могут подключаться к каким серверам.
У каждой компании есть собственный автономный терминальный сервер. Большинство компаний могут войти только в одну TS, но для одного особенно крупного клиента их два. Мы не производим их кластеризацию, только половина пользователей подключается к TS1, а другая половина подключается к TS2.
Все серверы находятся в одном сегменте сети, и у нас есть очень строгие списки контроля доступа, чтобы определить, кто и где может идти в сети (то есть никто не может никуда идти). Наш объект групповой политики для серверов RDS также сильно ограничивает их доступ к серверу.
В самый большой Проблема, с которой мы сталкиваемся с этой настройкой, - это автоматическое развертывание серверов для новых клиентов. Большую часть процесса можно автоматизировать (мы используем ESXi и vSphere, которые имеют интеграцию с PowerShell. То же, что и Hyper-V), но я еще не узнал, как автоматизировать изменение политик TS Gateway.
У нас также есть один очень большой клиент, который использует наши размещенные терминальные серверы. Поскольку я не хотел сам беспокоиться об управлении сбросом всех их паролей и новыми учетными записями, мы предоставили им права делегирования через их собственное подразделение в домене. Когда они начали расти, по политическим причинам мы предоставили им их собственные владения под нашим лесом. Все это пока работало довольно хорошо, за исключением того, что вы не можете использовать User must change their password on next logon так как это несовместимо со шлюзом TS. То же самое, когда срок действия их пароля истекает, они не могут войти в систему, и кому-то нужно вручную сбросить свой пароль.