Не так давно внедряли мы решение на терминальном сервере Windows. Как водится, кинули на рабочие столы сотрудникам ярлыки для подключения, и сказали — работайте. Но пользователи оказались зашуганными по части КиберБезопасности. И при подключении к серверу, видя сообщения типа: «Вы доверяете этому серверу? Точно-точно?», пугались и обращались к нам — а все ли хорошо, можно нажимать на ОК? Тогда и было решено сделать все красиво, чтобы никаких вопросов и паники.


Если ваши пользователи все еще приходят к вам с подобными страхами, и вам надоело ставить галочку «Больше не спрашивать» — добро пожаловать под кат.


Шаг нулевой. Подготовка и вопросы доверия


Итак, наш пользователь тыкает на сохраненный файл с расширением .rdp и получает такой вот запрос:



«Зловредное» подключение.


Для избавления от этого окна используется специальная утилита под названием RDPSign.exe. Полная документация доступна, как обычно, на официальном сайте, а мы разберем пример использования.


Для начала нам нужно взять сертификат для подписывания файла. Он может быть:


  • Публичным.
  • Выданным внутренней службой Certificate Authority.
  • Вовсе самоподписанным.

Самое главное, чтобы сертификат имел возможность подписывать (да, можно отобрать
у бухгалтеров ЭЦП), а клиентские ПК ему доверяли. Здесь я буду использовать самоподписанный сертификат.


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


Как сделать сертификат доверенным при помощи магии GPO

Для начала нужно взять имеющийся сертификат без закрытого ключа в формате .cer (это можно сделать, экспортировав сертификат из оснастки «Сертификаты») и положить его в сетевую папку, доступную пользователям для чтения. После этого можно настроить групповую политику.


Импорт сертификата настраивается в разделе: Конфигурация компьютера — Политики — Конфигурация Windows — Параметры безопасности — Политики открытого ключа — Доверенные корневые центры сертификации. Далее правой кнопкой мыши импортируем сертификат.



Настроенная политика.


Теперь клиентские ПК будут доверять самоподписанному сертификату.


Если проблемы с доверием решены, переходим непосредственно к вопросу подписи.


Шаг первый. Размашисто подписываем файл


Сертификат есть, теперь нужно узнать его отпечаток. Просто откроем его в оснастке «Сертификаты» и скопируем на вкладке «Состав».



Нужный нам отпечаток.


Лучше сразу его привести к должному виду — только большие буквы и без пробелов, если они есть. Это удобно сделать в консоли PowerShell командой:


("6b142d74ca7eb9f3d34a2fe16d1b949839dba8fa").ToUpper().Replace(" ","")

Получив отпечаток в нужном формате, можно смело подписывать файл rdp:


rdpsign.exe /sha256 6B142D74CA7EB9F3D34A2FE16D1B949839DBA8FA .\contoso.rdp

Где .\contoso.rdp — абсолютный или относительный путь к нашему файлу.


После того как файл подписан, уже не получится изменить часть параметров через графический интерфейс вроде имени сервера (действительно, иначе смысл подписывать?) А если поменять настройки текстовым редактором, то подпись «слетает».

Теперь при двойном клике по ярлыку сообщение будет другим:



Новое сообщение. Цвет менее опасный, уже прогресс.


Избавимся же и от него.


Шаг второй. И снова вопросы доверия


Для избавления от этого сообщения нам снова понадобится групповая политика. На этот раз дорога лежит в раздел Конфигурация компьютера — Политики — Административные шаблоны — Компоненты Windows — Службы удаленных рабочих столов — Клиент подключения к удаленному рабочему столу — Указать отпечатки SHA1 сертификатов, представляющих доверенных издателей RDP.



Нужная нам политика.


В политике достаточно добавить уже знакомый нам отпечаток с предыдущего шага.


Стоит отметить, что эта политика перекрывает политику «Разрешать RDP-файлы от допустимых издателей и пользовательские параметры RDP, заданные по умолчанию».


Настроенная политика.


Вуаля, теперь никаких странных вопросов — только запрос логина-пароля. Хм…


Шаг третий. Прозрачный вход на сервер


Действительно, если мы уже авторизовались при входе на доменный компьютер, то зачем нам вводить повторно тот же логин и пароль? Передадим же учетные данные на сервер «прозрачно». В случае с простым RDP (без использования RDS Gateway) на помощь нам придет… Правильно, групповая политика.


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


Здесь в список можно добавить нужные серверы или использовать wildcard. Выглядеть это будет как TERMSRV/trm.contoso.com или TERMSRV/*.contoso.com.



Настроенная политика.


Теперь, если посмотреть на наш ярлык, то выглядеть он будет примерно так:



Имя пользователя не поменять.


В случае если используется RDS Gateway, понадобится еще и разрешить на нем передачу данных. Для этого в диспетчере IIS нужно в «Методах проверки подлинности» отключить анонимную проверку и включить проверку подлинности Windows.



Настроенный IIS.


Не забываем по завершении перезапустить веб-сервисы командой:


iisreset /noforce

Вот теперь все хорошо, никаких вопросов и запросов.

Комментарии (10)


  1. Dmitriy_CRusHer
    29.11.2019 13:42
    +1

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


    1. avelor
      29.11.2019 15:24

      >юзер забыл заблочить комп
      тогда он в некоторых компаниях остаётся без годовой премии :) вместе с админом.
      >Данные на сервере доступны по двум кликам
      так же как если пароль сохранен и не включена политика «всегда запрашивать пароль»…


      1. Dmitriy_CRusHer
        29.11.2019 15:34

        не везде есть такие зависимости от не заблоченного компа. А в случае не включенной политики — таки тоже не секьюрно и вот здесь действительно по рукам админу :)


        1. avelor
          29.11.2019 19:31

          зависит от бизнес-процессов. бесусловно, сохранять пароли от терминалки админской — ну такое. тут и учётки должны быть разные (одна для работы на локальном компе, другая — для администрирования). а если это пользовательский remoteapp c 1c…


  1. savostin
    29.11.2019 16:15

    RDPsign на Python (если кому понадобится подписать из-под *nix).


  1. Vitaliy-L
    29.11.2019 19:20

    Удобно и безопасно, этотдва разных параметра работы.


    1. Dmitriy_CRusHer
      30.11.2019 15:23

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


      1. avelor
        30.11.2019 16:32

        ИМХО тут важен разумный баланс.
        и например вход с прозрачными пакетами и запрет на телефоны с камерами на режимном объекте будет разумен, а в офис конторы, которая покупает в китае шариковые ручки и продает их в ларьках по городу — уже выглядит перебором.
        как и не всегда разумны всякие прочие закрутки, типа там доступ в инет только с одного компа по белым спискам\расшифровка SSL-трафика при помощи корпоративного mitm\хранение логов доступа в инет за три года и анализ атмосферы в предприятии по логам переписки в соцсетях и мессенджерах (пишешь что начальник — чудак, уже инцидент в SIEM-системе).


        1. Dmitriy_CRusHer
          30.11.2019 16:41

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


  1. sergey-b
    01.12.2019 12:04

    Интересно, в windows можно что-нибудь сделать без правой кнопки мыши?