Не так давно внедряли мы решение на терминальном сервере Windows. Как водится, кинули на рабочие столы сотрудникам ярлыки для подключения, и сказали — работайте. Но пользователи оказались зашуганными по части КиберБезопасности. И при подключении к серверу, видя сообщения типа: «Вы доверяете этому серверу? Точно-точно?», пугались и обращались к нам — а все ли хорошо, можно нажимать на ОК? Тогда и было решено сделать все красиво, чтобы никаких вопросов и паники.
Если ваши пользователи все еще приходят к вам с подобными страхами, и вам надоело ставить галочку «Больше не спрашивать» — добро пожаловать под кат.
Шаг нулевой. Подготовка и вопросы доверия
Итак, наш пользователь тыкает на сохраненный файл с расширением .rdp и получает такой вот запрос:
«Зловредное» подключение.
Для избавления от этого окна используется специальная утилита под названием RDPSign.exe. Полная документация доступна, как обычно, на официальном сайте, а мы разберем пример использования.
Для начала нам нужно взять сертификат для подписывания файла. Он может быть:
- Публичным.
- Выданным внутренней службой Certificate Authority.
- Вовсе самоподписанным.
Самое главное, чтобы сертификат имел возможность подписывать (да, можно отобрать
у бухгалтеров ЭЦП), а клиентские ПК ему доверяли. Здесь я буду использовать самоподписанный сертификат.
Напомню, что доверие самоподписанному сертификату можно организовать при помощи групповых политик. Чуть больше подробностей — под спойлером.
Для начала нужно взять имеющийся сертификат без закрытого ключа в формате .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)
Vitaliy-L
29.11.2019 19:20Удобно и безопасно, этотдва разных параметра работы.
Dmitriy_CRusHer
30.11.2019 15:23Сначала всегда должно быть безопасно, потом удобно. Исключительно в этом порядке. Если удобстово на первом месте, таких айтишников надо гнать в момент
avelor
30.11.2019 16:32ИМХО тут важен разумный баланс.
и например вход с прозрачными пакетами и запрет на телефоны с камерами на режимном объекте будет разумен, а в офис конторы, которая покупает в китае шариковые ручки и продает их в ларьках по городу — уже выглядит перебором.
как и не всегда разумны всякие прочие закрутки, типа там доступ в инет только с одного компа по белым спискам\расшифровка SSL-трафика при помощи корпоративного mitm\хранение логов доступа в инет за три года и анализ атмосферы в предприятии по логам переписки в соцсетях и мессенджерах (пишешь что начальник — чудак, уже инцидент в SIEM-системе).Dmitriy_CRusHer
30.11.2019 16:41Соглашусь, однако все равно это не отменяет того факта, что смотреть айтишники должны всегда первоначально с точки зрения безопасности. Если юзеру лениво ввести пароль лишний раз — это проблемы юзера и подобные капризы вообще не должны никак котироваться.
Понятно, что уровень безопасности должен соответствовать компании, но базовые моменты никто не отменял.
Dmitriy_CRusHer
Как-то не секьюрно получается. Если предположить, что юзер забыл заблочить комп, то данные на сервере доступны по двум кликам
avelor
>юзер забыл заблочить комп
тогда он в некоторых компаниях остаётся без годовой премии :) вместе с админом.
>Данные на сервере доступны по двум кликам
так же как если пароль сохранен и не включена политика «всегда запрашивать пароль»…
Dmitriy_CRusHer
не везде есть такие зависимости от не заблоченного компа. А в случае не включенной политики — таки тоже не секьюрно и вот здесь действительно по рукам админу :)
avelor
зависит от бизнес-процессов. бесусловно, сохранять пароли от терминалки админской — ну такое. тут и учётки должны быть разные (одна для работы на локальном компе, другая — для администрирования). а если это пользовательский remoteapp c 1c…