- 1. Шесть бездисковых серверов IBM Blade Server HS22 с подключением к SAN и удалённой загрузкой с системы хранения IBM DS5300.
- 2. Первый сервер имеет два камня и 12Гб мозгов, на нём работает Session Broker и он является членом фермы с коэффициентом участия 30.
- 3. Три сервера имеют по два камня и 24Гб мозгов, два из них являются членами фермы с коэффициентом участия 100, третий - сервер RemoteApp (в т.ч. и установленных на виртуальных машинах, поэтому на нём поднята роль Hyper-V)
- 4. Пятый сервер имеет один камень и 6Гб мозгов, выполняет роль выделенного принт-сервера в системе печати Thinprint
- 5. Шестой сервер имеет два камня и 6Гб мозгов, является хранилищем пользовательских профилей.
Терминальные сервера имеют имена terminal-01 - terminal-03, сервер RemoteApp - termapp1, сервер печати - termdps, хранилище профилей - tprofile. Ферма терминальных серверов имеет имя terminal. (О назначении имени ферме можно почитать тут) Все сервера являются членами одного домена.
Из состава оборудования следует, что алгоритм работы пользователя в данной схеме может выглядеть так:
В клиенте RDP пользователь набирает имя terminal и выполняет подключение. Session Broker перенаправляет пользователя на соответствующий терминальный сервер. Предположим, на рабочем столе в сессии пользователя есть два ярлыка - один на удалённое приложение, развёрнутое на сервере termapp1, второй - на 16-разрядное приложение DOS, развёрнутое на виртуальной машине, работающей на сервере termapp1.
Таким образом, в случае, если мы вообще ничего не трогаем, для того, чтобы добраться до своего DOS-приложения (в независимости от того, какая ОС стоит у клиента), клиент должен будет вводить свои учётные данные четыре раза: для доступа к Session Broker, для доступа к тому терминальному серверу, на который его отправит Session Broker, для доступа к серверу RemoteApp и наконец для доступа к виртуальной машине, на которой работает его DOS-приложение.
Для того, чтобы избежать этого ужаса, существует механизм сквозной аутентификации. При его использовании пользователь вводит пароль только один раз, подключаясь к Session Broker.
Опишу процесс реализации этого механизма.
Начальные условия для реализации:
1. В домене должна быть развёрнута структура PKI.
2. На все компьютеры домена должны быть распространены два сертификата: сертификат корневого центра должен находиться в доверенных центрах сертификации компьютера (не пользователя, а именно компьютера), сертификат промежуточного центра (обычно это контроллер домена) - в промежуточных центрах сертификации. Сделать это можно по разному, в нашем случае это сделано при помощи GPO.
Комментариев нет:
Отправить комментарий