Rdp вход по личному сертификату. Подключаемся к консоли терминального сервера через удаленный рабочий стол (RDP)

Протокол RDP с защитой на уровне сети (SSL), к сожалению, не получил широкого распространения среди системных администраторов, предпочитающих защищать терминальные соединения другим способом. Возможно это связано с кажущейся сложностью способа, однако это не так, в данном материале мы рассмотрим как просто и без затруднений организовать такую защиту.

Какие преимущества дает нам защита RDP при помощи SSL? Во первых надежное шифрование канала, проверку подлинности сервера на основании сертификата и проверку подлинности пользователя на уровне сети. Последняя возможность доступна начиная с Windows Server 2008. Проверка подлинности на уровне сети позволяет повысить безопасность сервера терминалов за счет того, что проверка происходит еще до начала сеанса.

Проверка подлинности на уровне сети производится до подключения к удаленному рабочему столу и отображения экрана входа в систему, это снижает нагрузку на сервер и значительно увеличивает его защиту от злоумышленников и вредоносных программ, а также снижает вероятность атак типа "отказ в обслуживании".

Для полноценного использования всех возможностей RDP через SSL клиентские ПК должны работать под управлением Windows XP SP3, Windows Vista или Windows 7 и использовать RDP клиент версии 6.0 или более поздней.

При использовании Windows Server 2003 SP1 и более поздних версий, будут доступны шифрование канала при помощи SSL (TLS 1.0) и проверка подлинности сервера, клиентские ПК должны иметь версию RDP клиента 5.2 или более позднюю.

В нашей статье мы будем рассматривать настройку терминального сервера на базе Windows Server 2008 R2, однако все сказанное будет справедливо и для Windows Server 2003 (за исключением отсутствующих возможностей).

Для успешной реализации данного решения в вашей сети должен находиться работающий центр сертификации, настройку которого мы рассматривали в . Для доверия сертификатам выданным данным ЦС на терминальный сервер необходимо установить сертификат ЦС (или цепочку сертификатов) в хранилище .

Затем следует выполнить запрос сертификата подлинности сервера со следующими параметрами:

Имя - полное имя терминального сервера (т.е. server.domain.com если сервер входит в домен domain.com)

Тип сертификата - Сертификат проверки подлинности сервера
Установите опцию Создать новый набор ключей
CSP - Microsoft RSA SChannel Cryptographic Provider .
Установите флажок Пометить ключ как экспортируемый .
Для ЦС предприятия установите флажок Использовать локальное хранилище компьютера для сертификата . (В автономном ЦС данная опция недоступна).

Отправьте запрос центру сертификации и установите выданный сертификат. Данный сертификат должен быть установлен в локальное хранилище компьютера, иначе он не сможет быть использован службами терминалов. Чтобы проверить это запустим консоль MMC (Пуск - Выполнить - mmc ) и добавим оснастку Сертификаты (Файл - Добавить или удалить оснастку ) для учетной записи компьютера.

В корне консоли выберите нажмите Вид - Параметры и установите режим просмотра Упорядочить сертификаты по назначению . Выданный сертификат должен находиться в группе Проверка подлинности сервера .

Если вы получали сертификат с помощью изолированного (автономного) ЦС (сеть не имеет доменной структуры) то он по умолчанию будет установлен в хранилище учетной записи пользователя и придется выполнить ряд дополнительных действий.

Откройте Internet Explorer - Свойства обозревателя - Содержимое - Сертификаты , выданный сертификат должен быть установлен в хранилище Личные .

Произведите его экспорт. При экспорте укажите следующие опции:

Да, экспортировать закрытый ключ
Удалить закрытый ключ после успешного экспорта

После чего удалите сертификат из данного хранилища. В оснастке Сертификаты (локальный компьютер) выберите раздел Проверка подлинности сервера , щелкните на него правой кнопкой мыши Все задачи - Импорт и импортируйте сертификат.

Теперь в Администрирование - Службы удаленных рабочих столов откройте Конфигурация узла сеансов удаленных рабочих столов (в Windows Server 2003 Администрирование - Настройка служб терминалов).

Выберите необходимое подключение и откройте его свойства. В самом низу нажмите кнопку Выбрать и выберите полученный на предыдущем шаге сертификат (в Windows Server 2003 это окно выглядит несколько по другому).

После выбора сертификата укажите остальные свойства:

Уровень безопасности SSL
Уровень шифрования Высокий или FIPS -совместимый
Установите флажок Разрешить подключаться только с компьютеров... (недоступно в Windows Server 2003)

Сохраните введенный параметры, на этом настройка сервера закончена.

На клиентском ПК создайте подключение к удаленному рабочему столу, в качестве адреса используйте полное имя сервера, которое указано в сертификате. Откройте свойства подключения и на закладке Подключение - Проверка подлинности сервера установите опцию Предупреждать .

Чтобы данный ПК доверял сертификатам выданным нашим центром сертификации не забудьте установить на него сертификат ЦС в хранилище Доверенные корневые центры сертификации .

В Windows 7 (при использовании RDP клиента версии 7) данный сертификат требуется установить в хранилище учетной записи компьютера , для этого импортируйте его через оснастку Сертификаты (локальный компьютер) в консоли MCC, аналогично тому, как это делали выше. В противном случае подключение будет невозможно и вы получите следующую ошибку:

Установив сертификат ЦС можете пробовать подключиться, обратите внимание, что имя пользователя и пароль будет предложено ввести еще до создания RDP сессии. При успешном соединении обратите внимание на замок в заголовке окна, который свидетельствует о работе через SSL. Нажав на него можно просмотреть информацию о сертификате.

И напоследок капля дегтя в бочке меда. Терминальные службы Windows не умеют проверять подлинность подключающихся клиентов, поэтому если стоит такая необходимость следует использовать дополнительные методы защиты, такие как SSH туннель или IPSec VPN.

Бытует мнение, что подключение по удаленному рабочему столу Windows (RDP) очень небезопасно в сравнении с аналогами (VNC, TeamViewer, пр). Как следствие, открывать доступ из вне к любому компьютеру или серверу локальной сети очень опрометчивое решение - обязательно взломают. Второй аргумент против RDP как правило звучит так - «жрет трафик, для медленного интернета не вариант». Чаще всего эти доводы ничем не аргументированы.

Протокол RDP существует не первый день, его дебют состоялся еще на Windows NT 4.0 более 20 лет назад и с тех пор утекло много воды. На данный момент RDP не менее безопасен, чем любое другое решение для удаленного доступа. Что касается требуемой полосы пропускания, так в этом плане есть куча настроек, с помощью которых можно добиться отличной отзывчивости и экономии полосы пропускания.

Короче говоря, если знать что, как и где настроить, то RDP будет очень хорошим средством удаленного доступа. Вопрос в другом, а много ли админов пытались вникнуть в настройки, которые спрятаны чуть глубже, чем на поверхности?

Сейчас расскажу как защитить RDP и настроить его на оптимальную производительность.

Во-первых, версий RDP протокола существует много. Все дальнейшее описание будет применимо к RDP 7.0 и выше. Это значит, что у вас как минимум Windows Vista SP1. Для любителей ретро есть специальный апдейт для Windows XP SP3 KB 969084 который добавляет RDP 7.0 в эту операционку.

Настройка №1 - шифрование

На компьютере, к которому вы собираетесь подключаться открываем gpedit.msc Идем в Конфигурация компьютера - Административные шаблоны - Компоненты Windows - Службы удаленных рабочих столов - Безопасность

Устанавливаем параметр «Требовать использования специального уровня безопасности для удаленных подключений по методу RDP» в значение «Включено» и Уровень безопасности в значение «SSL TLS 1.0»

Этой настройкой мы включили шифрование как таковое. Теперь нам нужно сделать так, чтобы применялись только стойкие алгоритмы шифрования, а не какой-нибудь DES 56-bit или RC2.

Поэтому в этой же ветке открываем параметр «Установить уровень шифрования для клиентских подключений». Включаем и выбираем «Высокий» уровень. Это нам даст 128-битное шифрование.

Но и это еще не предел. Самый максимальный уровень шифрования обеспечивается стандартом FIPS 140-1. При этом все RC2/RC4 автоматически идут лесом.

Чтобы включить использование FIPS 140-1, нужно в этой же оснастке пойти в Конфигурация компьютера - Конфигурация Windows - Параметры безопасности - Локальные политики - Параметры безопасности.

Ищем параметр «Системная криптография: использовать FIPS-совместимые алгоритмы для шифрования, хэширования и подписывания» и включаем его.

И в завершении в обязательном порядке включаем параметр «Требовать безопасное RPC-подключение» по пути Конфигурация компьютера - Административные шаблоны - Компоненты Windows - Службы удаленных рабочих столов - Безопасность.

Этот параметр требует от подключающихся клиентов обязательное шифрование согласно тем установкам, которые мы настроили выше.

Теперь с шифрованием полный порядок, можно двигаться дальше.

Настройка №2 - смена порта

По умолчанию протокол RDP висит на порту TCP 3389. Для разнообразия его можно изменить, для этого в реестре нужно изменить ключик PortNumber по адресу

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Настройка №3 - сетевая аутентификация (NLA)

По умолчанию, вы можете подключиться по RDP не вводя логин и пароль и увидеть Welcome-скрин удаленного рабочего стола, где уже от вас попросят залогиниться. Это как раз совсем не безопасно в том плане, что такой удаленный комп можно легко заDDoSить.

Поэтому, всё в той же ветке включаем параметр «Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети»

Настройка №4 - что еще проверить

Во-первых проверьте, что параметр «Учетные записи: разрешать использование пустых паролей только при консольном входе» включен. Параметр можно найти в Конфигурация компьютера - Административные шаблоны - Компоненты Windows - Службы удаленных рабочих столов - Безопасность.

Во-вторых, не забудьте проверить список пользователей, которые могут подключаться по RDP

Настройка №5 - оптимизация скорости

Идем в раздел Конфигурация компьютера - Административные шаблоны - Компоненты Windows - Службы удаленных рабочих столов - Среда удаленных сеансов.

Здесь можно и нужно отрегулировать несколько параметров:

Наибольшая глубина цвета - можно ограничиться 16 битами. Это позволит сэкономить трафик больше чем в 2 раза по сравнению с 32х битной глубиной.
Принудительная отмена фонового рисунка удаленного стола - для работы он не нужен.
Задание алгоритма сжатия RDP - лучше установить значение Оптимизация использования полосы пропускания. В этом случае RDP будет жрать памяти чуть больше, но сжимать будет эффективнее.
Оптимизировать визуальные эффекты для сеансов служб удаленных рабочих столов - ставим значение «Текст». Для работы то что нужно.

В остальном при подключении к удаленному компу со стороны клиента дополнительно можно отключить:

Сглаживание шрифтов. Это сильно уменьшит время отклика. (Если у вас полноценный терминальный сервер, то этот параметр так же можно задать на стороне сервера)
Композицию рабочего стола - отвечает за Aero и пр
Отображение окна при перетаскивании
Визуальные эффекты
Стили оформления - если хочется хардкора

Остальные параметры типа фона рабочего стола, глубины цвета мы уже предопределили на стороне сервера.

Дополнительно на стороне клиента можно увеличить размер кэша изображений, делается это в реестре. По адресу HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\ нужно создать два ключа типа DWORD 32 BitmapPersistCacheSize и BitmapCacheSize

BitmapPersistCacheSize можно установить равным 10000 (10 Мб) По умолчанию этот параметр берет значение 10, что соответствует 10 Кб.
BitmapCacheSize так же можно установить равным 10000 (10 Мб). Вы вряд ли заметите, если RDP-подключение съест лишних 10 Мб от вашей оперативной памяти

Про проброс всяких принтеров и пр говорить ничего не буду. Кому что нужно, тот то и пробрасывает.

На этом основная часть настройки заканчивается. В следующих обзорах расскажу, как можно еще улучшить и обезопасить RDP. Используйте RDP правильно, всем стабильного коннекта! Как сделать RDP терминал сервер на любой версии Windows смотрите .

Кратко: позволяет настроить двухфакторную авторизацию для доступа на терминальный сервер. C помощью утилиты MS Remote Desktop Connection либо Remote Desktop Web Connection позволяет вам легко подключаться на Удаленный Рабочий Стол с помощью USB-Ключа (токена).

Как работает Rohos Logon Key с Remote Desktop.

Rohos Logon Key интегрируется в процедуру авторизации Windows Terminal Services и добавляет уровень двухфакторной авторизации в существующую инфраструктуру контроля доступа в систему. После настройки Rohos Logon Key пользователи смогут входить на Удаленный Рабочий Стол либо только при помощи USB-Ключа, либо при помощи USB-Ключа и пароля.

Преимущества защиты Терминального Сервера.

Метод позволяет ограничить удаленный доступ для некоторых пользователей или списка пользователей.
Такие пользователи обязаны каждый раз вставлять USB ключ или вводить код OTP.
Каждый ключ уникален и не может быть подделан
Нет необходимости подключать USB ключ непосредственно к серверу при его настройке.
Не нужно устанавливать программу на каждый компьютер, с которого осуществляется доступ*.
Администратору всего лишь необходимо предварительно настроить и выдать пользователю USB-Ключ для доступа.

Повышенная безопасность посредством электронного USB-Ключа либо Одноразовых паролей:

Пароль Windows+ USB ключ, например SafeNet, eToken, iKey, ePass и другие с поддержкой PKCS#11.
Пароль Windows + USB flash носитель.
Пароль Windows + OTP код, пришедший по SMS на мобильный телефон пользователя.
Пароль Window + OTP код с программы Google Authenticator, установленной на смартфоне пользователя.
Только зашифрованный пароль на USB ключе.
электронный USB-Ключ + PIN-код ключа;
электронный USB-Ключ + PIN-код ключа + Windows Пароль;

Перед тем как приступить к настройке Rohos Logon key необходимо определиться:

какой тип USB-Ключа будет использован для авторизации;
какой тип аутентификации вы хотите использовать:
1) двухфакторный = USB-Ключ + Windows Пароль,
2) однофакторный = USB-Ключ (сюда также входит вариант USB-Ключ + PIN-код ключа если таковой имеется),
3) использовать USB-Ключ только на локальном ПК. При этом Терминальный сервер не будет проверять наличие USB-Ключ у клиента.

Способ аутентификации на Терминальный сервер	Тип USB-Ключа	Установка ПО Rohos Logon Key на клиент и терминальный сервер
Способ аутентификации на Терминальный сервер	Тип USB-Ключа	Клиент Windows Vista/7/8	TS Server Сервер Windows 2008/2012
1) Двухфакторная авторизация (USB-Ключ и Windows пароль).	USB-токены (PKCS#11) Смарт-карты Google Authenticator Yubikey USB flash drive*
2) Однофакторная аутентификация (только USB-Ключ)	USB flash drive USB-токены (PKCS#11) Смарт-карты++3)
3) USB-Ключ используется для удобства. Терминальный сервер не проверяет наличие USB-Ключа.	Любой тип USB-Ключа

* В случае использования USB flash drive в качестве ключа доступа, на компьютер клиента необходимо установить одну из двух программ: либо программу , либо . В процессе создания ключа на сервере, на USB — накопитель будет скопирован , обеспечивающий использование USB диска в качестве ключа для подключения к Remote Desktop. Этот портативный компонент можно будет запустить на других рабочих станциях, используемых для удаленного подключения к серверу.

После того как вы определились с типом USB-Ключа и способом двухфакторной авторизации вы можете приступить к установке Rohos Logon Key .

Типы USB ключей и технологии, подходящие для аутентификации через Remote desktop с программой Rohos Logon Key:

Smart-карты, Java Cards (Mifare 1K)
Токены на основе PKCS11. Например SafeNet eToken, Securetoken ST3/4, senseLock trueToken, RuToken, uaToken, iKey.
Yubikey и OTP токены, например Google Authenticator
USB Flash накопители. В этом случае после создания ключа на USB диск будет скопирован портативный компонент программы.

Этапы подготовки соединения с использованием программы Rohos Logon Key:

1. Установите программу Rohos Logon Key на терминальном сервере . В настройках программы укажите тип USB ключа.

2. Установите пакет Rohos Management Tools на компьютер, с которого будет осуществляться доступ на удаленный рабочий стол для создания ключей.

3. Создание ключей для доступа через RDC:

Подключите к локальному компьютеру ваш будущий USB ключ. Подключитесь к терминальному серверу через RDC. В настройках программы Remote Desktop укажите, какие локальные ресурсы (USB диски или смарт-карты) следует предоставить удаленному компьютеру.

Запустите программу Rohos Logon Key на терминальном сервере. Воспользуйтесь командой Setup a key , укажите пользователя, для которого вы создаете ключ и, если необходимо, впишите его пароль.

Замечание : Некоторые типы USB ключей можно создать в программе USB key manager из пакета Rohos Managment tools . Этот пакет устанавливается на компьютере администратора. После создания всех ключей в этой программе необходимо экспортировать их список на терминальный сервер. . В этой же программе есть кнопка, копирующая на USB накопитель программы.

4. Настройка Rohos Logon Key на Терминальном Сервере:

После создания всех ключей вы можете усилить безопасность сервера, запретив определенным пользователям доступ к нему без USB ключа. Откройте настройки программы Rohos Logon Key, список Разрешить доступ только с помощью USB-Ключа.

Варианты выбора:

None
Все пользователи могут входить как по паролю, так и с использованием USB ключа. Такая настройка для терминального сервера не рекомендуется.
For any user
Эта опция аналогична старой опции Allow login only by USB Key . Все пользователи обязаны использовать USB ключ для входа или разблокировки Windows.
For listed users
Только пользователи из списка обязаны использовать USB ключ для входа. Все остальные пользователи могут входить по паролю. Список создается автоматически, когда USB ключ создается для какого-либо пользователя. Имя пользователя с USB ключа заносится в этот список. Кроме того, список пользователей и ключей можно импортировать с другого компьютера. Разумеется, это может сделать только администратор.
For ‘rohos’ user group in Active Directory
Каждый пользователь из группы rohos обязан использовать USB ключ.
Внимание : группа пользователей rohos должна быть создана администратором Active Directory.
For Remote desktop login
Локальные пользователи могут входить как с ключом, так и без USB ключа. Удаленный вход возможен только с USB ключом. Этот вариант идеально подходит для усиления безопасности терминального сервера.
For Remote desktop login outside LAN
Пользователи в локальной сети могут входить на терминальный сервер и без ключа . Только пользователи, входящие через dial-up, DSL соединения, а также из других сетей, обязаны использовать ключи USB.

Подключение к удаленному рабочему столу

При подключении мы увидим вот такое диалоговое окно сетевой идентификации.

Следует выбрать имя пользователя и ввести пароль учетной записи на TS.

Если проверка подлинности пароля прошла успешно, то происходит подключение к Удаленному Рабочему Столу. На этом этапе Rohos Logon Key проверяет наличие USB-Ключа пользователя.

Rohos Logon Key может остановить доступ, если USB-Ключ не подключен:

Если используется токен с одноразовым паролем, появится окно для его ввода.

Портативный Rohos Logon Key

Программа поможет вам, если вы используете USB flash drivе, но не можете или не желаете устанавливать на локальный компьютер ни Rohos Logon Key, ни Rohos Management tools . Этот компонент автоматически копируется на флешку во время создания ключа на терминальном сервере. Кроме того его можно получить, запустив программу USB key manager Pro лицензия — для доступа через Remote desktop к сетевому компьютеру(не терминальный сервер), а также для использования в условиях домена.

Серверная лицензия — специально предназначена для Терминального Сервера(Windows 2003, 2008,2012 с доступом через Remote Desktop)

Попробовать Rohos Logon Key бесплатно в течении 15-дней. Rohos Logon Key.

По истечении этого периода программа также будет работать, но будет напоминать зарегистрироваться.

В серверных версиях ОС Windows есть замечательная возможность использовать для подключений учетные данные, введенные пользователем ранее, при логине на свой компьютер. Таким образом им не приходится каждый раз вводить логин и пароль при запуске опубликованного приложения или же просто удаленного рабочего стола. Называется эта штука Single Sign On с использованием технологии CredSSP (Credential Security Service Provider).

Описание

Для того, чтобы это работало, должны быть соблюдены следующие условия:

Терминальный сервер и клиент, который к нему подключается, должны находится в домене.
Терминальный сервер должен быть сконфигурирован на ОС Windows Server 2008 , Windows Server 2008 R2 или более старшей версии.
На клиентском компьютере должна быть установлена ОС: Windows XP SP3 , Windows Vista , Windows Server 2008 , Windows 7 , Windows 8 или Windows Server 2008 R2 .

Для Windows XP SP3 , потребуются дополнительные телодвижения. Необходимо установить фикс, который позволит через групповые политики настраивать параметры и для Windows XP SP3 .
Этот фикс (MicrosoftFixit50588.msi) можно скачать, как с , так и с нашего сайта:

Сначала настраиваем на сервере терминалов уровень безопасности в режим "Согласование":

В ней настраиваем 2 параметра: Разрешить передачу учетных данных, установленных по умолчанию и Разрешить делегирование учетных данных, установленных по умолчанию, с проверкой подлинности сервера "только NTLM"

Разрешить делегирование учетных данных, установленных по умолчанию, с проверкой подлинности сервера "только NTLM" - настраивать нужно только в том случае, если аутентификация на терминальном сервере не происходит с помощью Kerberos или SSL-сертификата.

Вписываем туда сервер (серверы), на которые мы хотим пускать пользователей без повторного ввода логина и пароля. Вписывать можно по маске, а можно и по отдельности. В справке подробно написано.

После этого, применяем политику на нужном компьютере(-ах) и проверяем, чтобы пользователей пускало без ввода логина и пароля на указанные в политиках выше терминальные серверы.

Alexander Antipov

Одним из основных неудобств для пользователя при запуске удаленного рабочего стола или опубликованного на терминальном сервере приложения является необходимость ввода своих учетных данных. Ранее для решения этой проблемы использовался механизм сохранения учетных данных в настройках клиента удаленного рабочего стола. Однако данный способ имеет несколько существенных недостатков. Например, при периодической смене пароля приходилось изменять его вручную в настройках терминального клиента.

В связи с этим, для упрощения работы с удаленным рабочим столом в Windows Server 2008 появилась возможность использования технологии прозрачной авторизации Single Sign-on (SSO). Благодаря ей пользователь при входе на терминальный сервер может использовать учетные данные, введенные им при логине на свой локальный компьютер, с которого происходит запуск клиента удаленного рабочего стола.

В статье приведен обзор алгоритма работы технологии прозрачной авторизации Single Sign-On и поставщика услуг безопасности Credential Security Service Provider (CredSSP). Рассмотрен способ настройки клиентской и серверной частей. Также освещен ряд практических вопросов связанных с прозрачной авторизацией для служб удаленных рабочих столов.

Теоретическая информация

Технология SSO позволяет сохранение учетных данных пользователя и автоматическую передачу их при соединении с терминальным сервером. С помощью групповых политик можно определить сервера, для которых будет использоваться данный способ авторизации. В этом случае, для всех остальных терминальных серверов вход будет осуществляться традиционным образом: посредством ввода логина и пароля.

Впервые механизмы прозрачной авторизации появились в Windows Server 2008 и Windows Vista. благодаря новому поставщику услуг безопасности CredSSP. С его помощью кэшированные учетные данные передавались через безопасный канал (используя Transport Layer Security (TLS)). Впоследствии Microsoft выпустила соответствующие обновления для Windows XP SP3.

Рассмотрим это более подробно. CredSSP может использоваться в следующих сценариях:

для сетевого уровня аутентификации (NLA), позволяя пользователю быть узнанным до полной установки соединения;
для SSO, сохраняя учетные данные пользователя и передавая их на терминальный.

При восстановлении сеанса внутри фермы, CredSSP ускоряет процесс установки соединения, т.к. терминальный сервер определяет пользователя без установки полноценного соединения (по аналогии c NLA).

Процесс аутентификации происходит по следующему алгоритму:

Клиент инициирует установку безопасного канал с сервером, используя TLS. Сервер передает ему свой сертификат, содержащий имя, удостоверяющий центр и публичный ключ. Сертификат сервера может быть самоподписанным.
Между сервером и клиентом устанавливается сессия. Для неё создается соответствующий ключ, который в дальнейшем будет участвовать в шифровании. CredSSP использует протокол Simple and Protected Negotiate (SPNEGO) для взаимной аутентификации сервера и клиента так, чтобы каждый из них мог доверять друг другу. Этот механизм позволяет клиенту и серверу выбрать механизм аутентификации (например, Kerberos или NTLM).
Для защиты от перехвата, клиент и сервер поочередно шифруют сертификат сервера, используя ключ сессии, и передают его друг другу.
Если результаты обмена и исходный сертификат совпадают, CredSSP на клиенте посылает учетные данные пользователя на сервер.

Таким образом, передача учетных данных происходит по зашифрованному каналу с защитой от перехвата.

Настройка

Поставщик услуг безопасности CredSSP является частью операционной системы и входит в состав Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2. Кроме того, он может быть установлен в качестве отдельного обновления на Windows XP SP3. Этот процесс подробно описан в статье «Description of the Credential Security Support Provider (CredSSP) in Windows XP Service Pack 3 ». Для установки и включения CredSSP на Windows XP SP3 необходимо выполнить следующие действия.

1. Запустить редактор реестра regedit и перейти в ветку: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.

2. Добавить значение tspkg к ключу Security Packages

3. Перейти в ветку реестра : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders .

4. Добавить значение credssp.dll к ключу SecurityProviders (остальные значения этого ключа следует оставить неизменными).

После того как CredSSP включен, необходимо настроить его использование с помощью групповых политик или соответствующих им ключей реестра. Для настройки SSO на клиентских компьютерах используются групповые политики из раздела:

Computer Configuration\Administrative Templates\System\Credentials Delegation .

В русскоязычных версиях операционных систем это выглядит следующим образом (рис. 1).

Рис. 1. Управление передачей учетных данных при помощи групповых политик

Для использования SSO следует включить политику:

Разрешить передачу учетных данных, установленных по умолчанию .

Кроме того, после включения, следует установить для каких именно серверов будет использоваться данный способ авторизации. Для этого необходимо выполнить следующие действия.

В окне редактирования политики (рис. 2) нажать кнопку «Показать »

Рис. 2. Окно редактирования групповой политики

Добавить список терминальных серверов (рис. 3).

Рис. 3. Добавление терминального сервера для прозрачной авторизации

Строка добавления сервера имеет следующий формат:

TERMSRV/имя_сервера .

Также можно задать сервера по маске домена. В этом случае строка приобретает вид:

TERMSRV/*.имя_домена .

Если нет возможности использовать групповые политики, соответствующие настройки можно установить при помощи редактора реестра. Например, для настройки Windows XP Sp3 можно использовать следующий файл реестра:

Windows Registry Editor Version 5.00

«Security Packages»=hex (7):6b,00,65,00,72,00,62,00,65,00,72,00,6f,00,73,00,00,\

00,6d,00,73,00,76,00,31,00,5f,00,30,00,00,00,73,00,63,00,68,00,61,00,6e,00,\

6e,00,65,00,6c,00,00,00,77,00,64,00,69,00,67,00,65,00,73,00,74,00,00,00,74,\

00,73,00,70,00,6b,00,67,00,00,00,00,00

«SecurityProviders»="msapsspc.dll, schannel.dll, digest.dll, msnsspc.dll, credssp.dll"

«AllowDefaultCredentials»=dword:00000001

«ConcatenateDefaults_AllowDefault»=dword:00000001

«1»="termsrv/*.mydomain.com"

Здесь вместо mydomain.com следует подставить имя домена. В этом случае при подключении к терминальным серверам по полному доменному имени (например, termserver1.mydomain.com) будет использоваться прозрачная авторизация.

Для использования технологии Single Sign-On на терминальном сервере необходимо выполнить следующие действия.

Открыть консоль настройки служб терминалов (tsconfig.msc ).
В разделе подключения перейти в свойства RDP-Tcp .
На вкладке «Общие » установить уровень безопасности «Согласование » или «SSL (TLS 1.0) » (рис. 4).

Рис. 4. Настройка уровня безопасности на терминальном сервере

На этом настройку клиентской и серверной части можно считать законченной.

Практическая информация

В этом разделе рассмотрим ограничения на использование технологии прозрачной авторизации и проблемы, которые могут возникнуть при её применении.

Технология Single Sign-On работает только при соединении с компьютеров под управлением операционной системы не Windows XP SP3 и более старших версий. В качестве терминального сервера могут быть использованы компьютеры с операционной системой Windows Vista, Windows Server 2008, Windows 7 и Windows Server 2008 R2.
Если терминальный сервер, к которому устанавливается соединение, не может быть аутентифицирован через Kerberos или SSL-сертификат, SSO работать не будет. Это ограничение можно обойти с помощью политики:
Разрешить делегирование учетных данных, установленных по умолчанию с проверкой подлинности сервера «только NTLM» .
Алгоритм включения и настройки данной групповой политики аналогичен представленному выше. Файл реестра, соответствующей данной настройке имеет следующий вид.

«AllowDefCredentialsWhenNTLMOnly»=dword:00000001

«ConcatenateDefaults_AllowDefNTLMOnly»=dword:00000001

«1»="termsrv/*.mydomain.com"

Аутентификация данным способом менее безопасна, чем при использовании сертификатов или Kerberos.

Если для какого-либо сервера сохранены учетные данные в настройках терминального клиента, то они имеют более высокий приоритет, чем текущие учетные данные.
Single Sign-On работает только при использовании доменных аккаунтов.
Если подключение к терминальному серверу идет через TS Gateway, в некоторых случаях возможен приоритет настроек сервера TS Gateway над настройками SSO терминального клиента.
Если терминальный сервер настроен каждый раз запрашивать учетные данные пользователей, SSO работать не будет.
Технология прозрачной авторизации работает только с паролями. В случае использования смарт-карт, она работать не будет.

Для корректной работы SSO на Windows XP SP рекомендуется установить два исправления из KB953760: «When you enable SSO for a terminal server from a Windows XP SP3-based client computer, you are still prompted for user credentials when you log on to the terminal server ».

В некоторых случаях возможна ситуация когда на одном и том же терминальном клиенте технология прозрачной авторизации может работать или не работать в зависимости от профиля подключающегося пользователя. Проблема решается пересозданием профиля пользователя. Если это является слишком трудоемкой задачей можно попробовать воспользоваться советами из обсуждения: «RemoteApp Single Sign On (SSO) from a Windows 7 client » форумов Microsoft Technet. В частности, рекомендуется сбросить настройки Internet Explorer или одобрить соответствующую надстройку для него.

Еще одним серьезным ограничением технологии SSO является то, что она не работает при запуске опубликованных приложений через TS Web Access. При этом пользователь вынужден дважды вводить учетные данные: при входе на веб-интерфейс и при авторизации на терминальном сервере.

В Windows Server 2008 R2 ситуация изменилась в лучшую сторону. Более подробную информацию об этом можно получить в статье: «Introducing Web Single Sign-On for RemoteApp and Desktop Connections" ».

Заключение

В статье рассмотрена технология прозрачной авторизации на терминальных серверах Single Sign-On. Её использование позволяет сократить время, затрачиваемое пользователем для входа на терминальный сервер и запуск удаленных приложений. Кроме того, с её помощью достаточно единожды вводить учетные данные при входе на локальный компьютер и затем использовать их при соединении с терминальными серверами домена. Механизм передачи учетных данных достаточно безопасен, а настройка серверной и клиентской части предельно проста.