Не так давно внедряли мы решение на терминальном сервере Windows. Как водится, кинули на рабочие столы сотрудникам ярлыки для подключения, и сказали — работайте. Но пользователи оказались зашуганными по части КиберБезопасности. И при подключении к серверу, видя сообщения типа: «Вы доверяете этому серверу? Точно-точно?», пугались и обращались к нам — а все ли хорошо, можно нажимать на ОК? Тогда и было решено сделать все красиво, чтобы никаких вопросов и паники.
Если ваши пользователи все еще приходят к вам с подобными страхами, и вам надоело ставить галочку «Больше не спрашивать» — добро пожаловать под кат.
Пробовал подключаться с двух разных компьютеров, которые территориально находятся совсем в разных местах (разные провайдер, IP и пр.). На обеих стоит Windows 7 x64 uk-UA (без SP, без обновлений), оба настраивались и используются мной. Нет даже предположений, в чём проблема. Какой-то софт, либо сделанные мной настройки, или ещё что.
Ну и, собственно, вопрос. Что не так и что делать? Как локализовать проблему? Чем мои компьютеры так уникальны и не нравятся шлюзу?
В данном разделе предполагается, что пользователь имеет некоторое представление о работе цепочек доверия сертификатов, процессе подписания сертификатов, об инфраструктуре открытого ключа и общих принципов конфигурации сертификатов. Сведения о конфигурации инфраструктуры открытого ключа в Windows Server 2008 см. на странице «ITPROADD-204: расширенные возможности инфраструктуры открытых ключей в операционных системах Windows Vista и Windows Server 2008 (страница может быть на английском языке) (https://go.microsoft.com/fwlink/?LinkId=93995). Сведения о конфигурации инфраструктуры открытого ключа в Windows Server 2003 см. в разделе «Инфраструктура открытого ключа» (страница может быть на английском языке) (https://go.microsoft.com/fwlink/?LinkID=54917).
Для шифрования соединений между клиентами Службы удаленных рабочих столов и серверами Шлюз удаленных рабочих столов при подключениях через Интернет по умолчанию применяется протокол TLS 1.0. Протокол TLS является стандартным протоколом, который используется для организации безопасных веб-соединений в интрасетях и в Интернете. Данный протокол представляет собой самую последнюю и наиболее защищенную версию протокола SSL. Дополнительные сведения о протоколе TLS см. в разделах:
Пишите нам!
Архитектурная мастерская.
Продвижение сайтов от optimism.ru
Page generation time: 0.0856s (PHP: 56% — SQL: 44%) — SQL queries: 33 — GZIP disabled — Debug off
В этом разделе описывается порядок использования Диспетчер шлюза удаленных рабочих столов для создания самозаверяющего сертификата, если в процессе установки службы роли шлюза удаленных рабочих столов такой сертификат не был создан при помощи мастера добавления ролей.
Об этом я уже слышал, но я пробовал именно с IP сервера и ничего не получил. И тогда также напрашивается вопрос как быть если доступ на сервер идет с нескольких сетей? На входе то IP разные, а в настройках шлюза можно указать только один сертификат. Ну это ладно, хоть с одним бы заработал. »
Это очень просто, в файле host на клиенте прописываете, то DNS имя которое указано в сертификате.
Если клиентов не много — эт овполне приемлемо.
Если клиентов много, тогда танцы с DNS, например DynDNS или регистрация своего домена, либо получение имени у провайдера. Вам же по сути всего имя для одного узла нужно
В случае самозаверенного сертификата его копия передается на сторону клиента и по идее должно и так работать (так гласит microsoft)! А вот в случае доменного сертификата так действительно не получиться! »
Вы, путаете сертификат и для чего он нужен.
Самозаверенность это способ подтверждения валидности (действительности) сертификата в дереве CA (центров сертификации).
Например сертификаты выпущеные корневыми CA всегда самоподписанные, т. к. нет более высокого уровня центров сертификации.
С самоподписанными сертификатами одна морока — ими тяжело управлять, однако если клиентов мало, можно и руками (как вы и сделали).
Кстати, если имя сервера разрешаемое (при помощи DNS) на стороне клиента, не совпадает с именем в предъявлямом сертификате, то и домен вам не поможет.
Домен хорош когда все, и клиенты и серверы в нем находятся ,т.е. распознавание имен у них происходит при помощи одного механизма — серверов имен домена.
Т. е. заранее есть гарантия, что имя под которым себя осознает сервер будет таким же на клиенте.
Списибо конечно за ссылку, но там немного не о том, а именно к Windows Server 2008 отношения не имеет. Да и если честно во всех этих книгах много теории и 0 практики. Меня интересует всего лишь один вопрос. Как правильно создать и потом использовать сертификат для доступа к шлюзу RDP на сервере не являющемся контроллером домена. Инет перерыл и нигде толковой информации не нашел. Инструкции есть только для домена, где соответственно используют доменный сертификат, чего у меня нет! Может я конечно чего-то не понял и может можно как-то создать доменный сертификат для моего случая (хотя он требует сервер сертификации), но как это сделать я не знаю.
Поэтому и прошу помочь. »
Ваша беда, что вы пытаетесь использовать технологию, не понимая ее сути — итого у вас все выливается в шаманские камлания, а именно тыканье кнопочек по инструкции не понимая, что вы именно делаете.
Сертифкаты везеде одинаковые.
В той же MS можно развернуть центр сертифкации интегрированный в домен и не интегрированный.
Интегрированным в домент просто гораздо проще управлять (например с помощью групповых политик), выпускать и отзывать сертификаты.
По рекомендации той же MS корневой CA всегда автономен, т.е. не интегрируется в домен.
Если сертификат не установлен, после его получения следуйте приведенным далее инструкциям для его установки в требуемом месте на сервере Шлюз удаленных рабочих столов. По завершении этой процедуры сертификат устанавливается в соответствующее хранилище сертификатов и импортируется на сервер Шлюз удаленных рабочих столов.
Шаг второй. И снова вопросы доверия
Для избавления от этого сообщения нам снова понадобится групповая политика. На этот раз дорога лежит в раздел Конфигурация компьютера — Политики — Административные шаблоны — Компоненты Windows — Службы удаленных рабочих столов — Клиент подключения к удаленному рабочему столу — Указать отпечатки SHA1 сертификатов, представляющих доверенных издателей RDP.
Нужная нам политика.
В политике достаточно добавить уже знакомый нам отпечаток с предыдущего шага.
Стоит отметить, что эта политика перекрывает политику «Разрешать RDP-файлы от допустимых издателей и пользовательские параметры RDP, заданные по умолчанию».
Шаг третий. Прозрачный вход на сервер
Идем в раздел: Конфигурация компьютера — Политики — Административные шаблоны — Система — Передача учетных данных — Разрешить передачу учетных данных, установленных по умолчанию.
Здесь в список можно добавить нужные серверы или использовать wildcard. Выглядеть это будет как TERMSRV/trm.contoso.com или TERMSRV/*.contoso.com.
Теперь, если посмотреть на наш ярлык, то выглядеть он будет примерно так:
Имя пользователя не поменять.
В случае если используется RDS Gateway, понадобится еще и разрешить на нем передачу данных. Для этого в диспетчере IIS нужно в «Методах проверки подлинности» отключить анонимную проверку и включить проверку подлинности Windows.
Не забываем по завершении перезапустить веб-сервисы командой:
Вот теперь все хорошо, никаких вопросов и запросов.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Расскажите, а вы подписываете ярлыки RDP своим пользователям?
Не, они приучены жать на «ОК» в сообщениях не читая, некоторые даже сами галки ставят «Больше не спрашивать».
Сам аккуратно руками кладу ярлычок и первый вход на сервер делаю вместе с каждым пользователем.
Конечно, я люблю во всем порядок.
Не использую терминальные серверы.
Проголосовали 103 пользователя.
Воздержались 20 пользователей.
Шаг первый. Размашисто подписываем файл
Сертификат есть, теперь нужно узнать его отпечаток. Просто откроем его в оснастке «Сертификаты» и скопируем на вкладке «Состав».
Нужный нам отпечаток.
Лучше сразу его привести к должному виду — только большие буквы и без пробелов, если они есть. Это удобно сделать в консоли PowerShell командой:
Получив отпечаток в нужном формате, можно смело подписывать файл rdp:
rdpsign.exe /sha256 6B142D74CA7EB9F3D34A2FE16D1B949839DBA8FA .contoso.rdp
Где .contoso.rdp — абсолютный или относительный путь к нашему файлу.
После того как файл подписан, уже не получится изменить часть параметров через графический интерфейс вроде имени сервера (действительно, иначе смысл подписывать?) А если поменять настройки текстовым редактором, то подпись «слетает».
Теперь при двойном клике по ярлыку сообщение будет другим:
Новое сообщение. Цвет менее опасный, уже прогресс.
Избавимся же и от него.
Обзор процесса установки и настройки сертификата
Процесс получения, установки и настройки сертификата для сервера Шлюз удаленных рабочих столов состоит из трех шагов.
Шаг 1. Получение сертификата для сервера шлюза удаленных рабочих столов
Получить сертификат для сервера Шлюз удаленных рабочих столов можно одним из следующих способов.Если используемый автономный ЦС либо ЦС предприятия настроен на выдачу SSL-совместимых сертификатов X.509, удовлетворяющих требованиям сервера Шлюз удаленных рабочих столов, можно создать и предоставить запрос на сертификат несколькими способами, в зависимости от политик и настройки ЦС организации. Способы получения сертификата перечислены ниже. Отправка заявки из оснастки «Сертификаты».Запрос сертификатов с помощью мастера запроса сертификата.Запрос сертификата через Интернет. Использование средства командной строки Certreq.
Дополнительные сведения об использовании перечисленных методов получения сертификатов для Windows Server 2008 R2 см. в разделе «Получение сертификата» в справке оснастки «Сертификаты», а также в разделе «Certreq» справочника по командам Windows Server 2008 R2. Для просмотра разделов справки оснастки «Сертификаты» нажмите кнопку Пуск, выберите пункт Выполнить, введите команду hh certmgr.chm и нажмите кнопку ОК. Дополнительные сведения о запросе сертификатов для Windows Server 2003 см. в разделе «Запрос сертификатов» (https://go.microsoft.com/fwlink/?LinkID=19638) (на английском языке).
Сертификат, выданный автономным ЦС либо ЦС предприятия, также должен быть подписан открытым доверенным ЦС, являющимся членом программы корневых сертификатов Майкрософт (https://go.microsoft.com/fwlink/?LinkID=59547) (на английском языке). В противном случае пользователи домашних компьютеров или киосков, вероятно, не смогут подключиться к серверам Шлюз служб терминалов или Шлюз удаленных рабочих столов. Невозможность подключения вызвана тем, что корень ЦС может не быть доверенным для домашних и прочих компьютеров, не являющихся членами домена.Если организация не имеет собственного автономного ЦС или ЦС предприятия, настроенного на выдачу SSL-совместимых сертификатов X.509, сертификат можно приобрести у доверенного открытого ЦС, являющегося участником программы корневых сертификатов корпорации Майкрософт (https://go.microsoft.com/fwlink/?LinkID=59547) (на английском языке). Некоторые из таких открытых ЦС могут бесплатно предоставлять сертификаты в целях тестирования.Кроме того, если организация не имеет собственного автономного ЦС или ЦС предприятия, а совместимый сертификат от доверенного открытого ЦС отсутствует, то для технической оценки и тестирования можно создать и импортировать самозаверяющий сертификат для сервера Шлюз удаленных рабочих столов. Дополнительные сведения см. в разделе Создание самозаверяющего сертификата для сервера шлюза удаленных рабочих столов.
Обратите внимание, что в хранилище доверенных корневых центров сертификации клиентов Службы удаленных рабочих столов должен присутствовать сертификат ЦС, выдавшего сертификат сервера. Пошаговые инструкции по установке сертификата на клиентском компьютере см. в разделе Установка корневого сертификата сервера шлюза удаленных рабочих столов на клиенте служб удаленных рабочих столов.
Если используется один из первых двух способов получения сертификата и клиентский компьютер Службы удаленных рабочих столов доверяет ЦС, выдавшему сертификат, не требуется устанавливать сертификат ЦС, выдавшего сертификат сервера, в хранилище сертификатов клиентского компьютера. Например, не требуется устанавливать сертификат ЦС, выдавшего сертификат, в хранилище сертификатов клиентского компьютера, если на сервере Шлюз удаленных рабочих столов установлен сертификат компании VeriSign либо любого другого открытого доверенного ЦС. Если для получения сертификата используется третий способ (то есть, если создается самозаверяющий сертификат), не требуется устанавливать сертификат ЦС, который выдал сертификат сервера в хранилище доверенных корневых центров сертификации на клиентском компьютере. Дополнительные сведения см. в разделе Установка корневого сертификата сервера шлюза удаленных рабочих столов на клиенте служб удаленных рабочих столов.
Шаг 2. Импорт сертификата
Итак, наш пользователь тыкает на сохраненный файл с расширением .rdp и получает такой вот запрос:
Для избавления от этого окна используется специальная утилита под названием RDPSign.exe. Полная документация доступна, как обычно, на официальном сайте, а мы разберем пример использования.
Для начала нам нужно взять сертификат для подписывания файла. Он может быть:
- Публичным.
- Выданным внутренней службой Certificate Authority.
- Вовсе самоподписанным.
Самое главное, чтобы сертификат имел возможность подписывать (да, можно отобрать
у бухгалтеров ЭЦП), а клиентские ПК ему доверяли. Здесь я буду использовать самоподписанный сертификат.
Напомню, что доверие самоподписанному сертификату можно организовать при помощи групповых политик. Чуть больше подробностей — под спойлером.
Как сделать сертификат доверенным при помощи магии GPO
Для начала нужно взять имеющийся сертификат без закрытого ключа в формате .cer (это можно сделать, экспортировав сертификат из оснастки «Сертификаты») и положить его в сетевую папку, доступную пользователям для чтения. После этого можно настроить групповую политику.
Импорт сертификата настраивается в разделе: Конфигурация компьютера — Политики — Конфигурация Windows — Параметры безопасности — Политики открытого ключа — Доверенные корневые центры сертификации. Далее правой кнопкой мыши импортируем сертификат.
Теперь клиентские ПК будут доверять самоподписанному сертификату.
Если проблемы с доверием решены, переходим непосредственно к вопросу подписи.