Клиент RDP не считает смарт-карту допустимой для аутентификации

Клиент RDP не считает смарт-карту допустимой для аутентификации

У меня есть:

  • Клиентская машина с Windows 7. Я не являюсь администратором этой машины.
  • Сервер Windows 2008R2, на котором я хочу открыть сеанс с использованием удаленного рабочего стола.
  • АШлюз удаленного рабочего стола, также работающий под управлением Windows 2008R2.
  • Смарт-карта.

Сервер настроен на разрешение входа с помощью смарт-карты. Шлюз также требует аутентификации с помощью смарт-карты. Все клиенты и серверы знают и доверяют всем соответствующим сертификатам CA, ни один сертификат не просрочен, все CRL опубликованы там, где им следует.

Решающе важно, сертификат на смарт-карте имеетРасширенное использование ключарасширение (EKU), которое НЕ содержит OID "входа со смарт-карты". Однако оно включает "проверку подлинности клиента". Сервер и шлюз были настроены на то, чтобы тем не менее принимать сертификат: это параметр политики, называемый "Разрешить сертификаты без атрибута сертификата расширенного использования ключа", как описанотам.

Проблема

Клиент использует файл .rdp, в котором указано имя сервераиимя шлюза. Поскольку шлюз является шлюзом, а не фактическим сервером удаленного рабочего стола, у него нет "экрана входа" для отображения. Вместо этого аутентификация смарт-карты основана на графическом интерфейсе, обрабатываемом клиентом ( mstsc.exeстандартный клиент RD в Windows), чтобы позволить пользователю выбрать свою смарт-карту и ввести свой PIN-код. Вот как должно выглядеть всплывающее окно:

Всплывающее окно для аутентификации с помощью смарт-карты

(Извините за всплывающее окно на французском языке; у меня нет под рукой Windows 7 на британском языке.)

К сожалению, это всплывающее окно не отображается таким образом. Вместо этого я получаю это:

Всплывающее окно аутентификации с помощью смарт-карты

Анализ

Как описаноздесь, клиентское приложение (mstsc.exe) позволит ОС (Windows 7) «перечислить» смарт-карты. ОС будет искать смарт-карты, содержащие сертификаты, которые соответствуют некоторым критериям, в частности, что любое расширение EKU, найденное в любом таком сертификате, содержит OID «входа со смарт-карты». Это делается до фактической попытки связаться со шлюзом, не говоря уже о конечном целевом сервере. Шлюз и сервер были бы вполне довольны моим сертификатом; они были настроены таким образом. Однако клиентская ОСобеспечивает соблюдениете же правила, согласно его собственной конфигурации. В моем случае Windows 7 отказывается разрешить мне использовать мою смарт-карту, потому что ее локальная политика отклонила бы ее для открытия локального сеанса (хотя я вообще не пытаюсь открыть локальный сеанс).

Раньше это работало с клиентом Windows XP, поскольку «всплывающее окно выбора смарт-карты» в Windows XP не обеспечивает эти проверки (Windows XP проверяет EKU еще более строгим образом, поскольку не допускает отсутствия расширения EKU, но обеспечивает эти проверки только при фактической попытке открыть локальный сеанс, а не при выборе сертификата для удаленного сеанса).

Решение, которое я не могу использовать

«Нормальное» решение — настроить локального клиента (Windows 7) с тем же «Разрешить сертификаты без атрибута сертификата расширенного использования ключа», что и сервер. Таким образом, всплывающее окно выбора смарт-карты теперь принимает отображение смарт-карты, и все в порядке. Я протестировал это на другой системе. Однако я не могу сделать это на моих целевых системах, потому что изменение локальной политики требует прав администратора, которых у меня нет. Аналогично, для клиентов, которые являются частью домена, настройка может быть передана из GPO на сервере AD, что снова запрещено для меня из-за отсутствия соответствующих привилегий.

Можно также сказать, что этот параметр политики фактически позволяет войти на клиентскую машину с сертификатом, который не имеет надлежащего OID в своем EKU, и это можно считать нежелательным побочным эффектом. Я пытаюсь открыть сеанс наудаленный сервер; Мне не следовало бы менять условия открытия сессии наместный клиент.

Более старые версии mstsc.exe (из Windows XP) могли, по-видимому, подключаться к серверу без необходимости какой-либо аутентификации клиента; в этом случае удаленный сервер отображал свой экран входа в систему («большой сине-зеленый экран») и сам выполнял перечисление смарт-карт. Поскольку на сервере есть соответствующая политика, то это сработало бы. Однако я не могу использовать такое решение по двум причинам:

  • mstsc.exe из Windows 7, по-видимому, настаивает на проведении аутентификации с помощью собственных всплывающих окон.
  • Eстьшлюз, который, в отличие от конечного целевого сервера, не имеет "экрана входа" для отображения. При использовании шлюза, требующего аутентификации смарт-карты клиента, выбор смарт-карты клиентадолженуправляться клиентским программным обеспечением.

Вопрос

Итак, вот мой вопрос: есть ли выход из этой проблемы? В идеале, какой-то параметр конфигурации в mstsc.exe (переключатель командной строки или пункт в файле .rdp), который бы указал mstsc.exeНЕТиспользовать всплывающее окно выбора смарт-карты ОС, но выполнять перечисление самостоятельно,безпытаюсь навязать что-либо по поводу EKU. Я не нашел никаких следов такой функции, но отсутствие доказательств не является доказательством отсутствия. Я мог просто пропустить это.

решение1

Создайте файл .rdp для подключения, установите enablecredsspsupport:i:0 внутри файла .rdp и убедитесь, что у вас включена опция смарт-карты для локального сопоставления ресурсов (по умолчанию она включена, так что это должно быть так, если вы явно не изменили эту настройку).

Более подробную информацию смотрите в следующей записи: http://blogs.msdn.com/b/rds/archive/2007/01/22/vista-remote-desktop-connection-authentication-faq.aspx#_Когда_использовать

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

Связанный контент