Смарт-карты и службы удаленных рабочих столов

В этом разделе для ИТ-специалистов описывается поведение служб удаленных рабочих столов при реализации интеллектуального карта входа.

Интеллектуальная карта логика перенаправления и API WinSCard объединяются для поддержки нескольких перенаправленных сеансов в одном процессе.

Поддержка смарт-карта необходима для реализации многих сценариев служб удаленных рабочих столов. К ним можно отнести следующие.

  • Использование быстрого переключения пользователей или служб удаленных рабочих столов. Пользователь не может установить перенаправленное подключение к удаленному рабочему столу на основе смарт-карта. То есть попытка подключения не выполняется при быстром переключении пользователей или из сеанса служб удаленных рабочих столов.
  • Включение шифруемой файловой системы (EFS) для поиска средства чтения интеллектуальной карта пользователя из процесса локального центра безопасности (LSA) при быстром переключении пользователей или в сеансе служб удаленных рабочих столов. Если EFS не может найти средство чтения или сертификата смарт-карта, EFS не может расшифровать файлы пользователей.

Перенаправление служб удаленных рабочих столов

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

Служба интеллектуальной карта перенаправляется в средство чтения интеллектуальной карта.

Перенаправление удаленного рабочего стола

Примечания о модели перенаправления:

  1. Этот сценарий представляет собой сеанс удаленного входа на компьютере со службами удаленных рабочих столов. В удаленном сеансе (помеченном как сеанс клиента) пользователь запускается net use /smartcard
  2. Стрелки представляют поток ПИН-кода после ввода ПИН-кода в командной строке, пока он не достигнет смарт-карта пользователя в средстве чтения смарт-карта, подключенном к клиентскому компьютеру подключения к удаленному рабочему столу (RDC)
  3. Проверка подлинности выполняется LSA в сеансе 0.
  4. Обработка CryptoAPI выполняется в LSA (lsass.exe). Это возможно, так как перенаправление RDP (rdpdr.sys) разрешает контекст для каждого сеанса, а не для процесса.
  5. Библиотека ScHelper — это оболочка CryptoAPI, относяющаяся к протоколу Kerberos.
  6. Решение о перенаправлении принимается для каждого интеллектуального карта контексте на основе сеанса потока, выполняющего SCardEstablishContext вызов.

Единый вход сервера узла сеансов удаленных рабочих стола

В рамках соответствия общим критериям клиент RDC должен быть настроен на использование диспетчера учетных данных для получения и сохранения пароля пользователя или смарт-карта ПИН-кода. Соответствие common criteria требует, чтобы у приложений не было прямого доступа к паролю или ПИН-коду пользователя.

Соответствие общим критериям требует, в частности, чтобы пароль или ПИН-код не оставляли LSA незашифрованными. Распределенный сценарий должен разрешать передачу пароля или ПИН-кода между одним доверенным LSA и другим, и они не могут быть незашифрованы во время передачи.

Если для сеансов служб удаленных рабочих столов используется единый вход с поддержкой смарт-карта, пользователям по-прежнему необходимо выполнять вход для каждого нового сеанса служб удаленных рабочих столов. Однако пользователю не предлагается ввести ПИН-код более одного раза для создания сеанса служб удаленных рабочих столов. Например, когда пользователь дважды щелкает значок документа Microsoft Word, который находится на удаленном компьютере, пользователю будет предложено ввести ПИН-код. Этот ПИН-код отправляется с помощью безопасного канала, установленного поставщиком учетных данных SSP. ПИН-код направляется обратно в клиент RDC по безопасному каналу и отправляется в Winlogon. Пользователь не получает никаких дополнительных запросов на ввод ПИН-кода, если только пин-код не является неправильным или нет ошибок, связанных с интеллектуальными карта.

Вход в службы удаленных рабочих столов и смарт-карта

Службы удаленных рабочих столов позволяют пользователям выполнять вход с помощью интеллектуальной карта, вводя ПИН-код на клиентском компьютере RDC и отправляя его на сервер узла сеансов удаленных рабочих столов таким образом, как проверка подлинности на основе имени пользователя и пароля.

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

Чтобы включить интеллектуальный карта вход на сервер узла сеансов удаленных рабочих столов (узел сеансов удаленных рабочих столов), на клиентском компьютере RDC должен присутствовать сертификат центра распространения ключей (KDC). Если компьютер не в том же домене или рабочей группе, для развертывания сертификата можно использовать следующую команду:

certutil.exe -dspublish NTAuthCA "DSCDPContainer"

Общее DSCDPContainer имя (CN) обычно является именем центра сертификации.

Пример.

certutil -dspublish NTAuthCA <CertFile> "CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=engineering,DC=contoso,DC=com"

Сведения об этом параметре для программы командной строки см. в разделе -dsPublish.

Службы удаленных рабочих столов и интеллектуальные карта входа в разных доменах

Чтобы разрешить удаленный доступ к ресурсам на предприятии, корневой сертификат для домена должен быть подготовлен на смарт-карта. На компьютере, присоединенном к домену, выполните следующую команду в командной строке:

certutil.exe -scroots update

Сведения об этом параметре для программы командной строки см. в разделе -SCRoots.

Для служб удаленных рабочих столов в разных доменах сертификат KDC сервера узла сеансов удаленных рабочих столов также должен присутствовать в хранилище NTAUTH клиентского компьютера. Чтобы добавить хранилище, выполните следующую команду в командной строке:

certutil -addstore -enterprise NTAUTH <CertFile>

Где CertFile — это корневой сертификат издателя сертификата KDC.

Сведения об этом параметре для программы командной строки см. в разделе -addstore.

Примечание.

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

Вход в службы удаленных рабочих столов в домене работает только в том случае, если имя участника-пользователя в сертификате использует следующую форму: <ClientName>@<DomainDNSName>.

Имя участника-пользователя в сертификате должно содержать домен, который можно разрешить. В противном случае протокол Kerberos не может определить, к какому домену следует обращаться. Эту проблему можно устранить, включив указания домена GPO X509. Дополнительные сведения об этом параметре см. в разделе Параметры групповая политика смарт-карты и реестра.