Несъмнено, неотдавна внедрихме решение на терминален сървър 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
Ето сега всичко е наред, без въпроси и запитвания.
Само регистрирани потребители могат да участват в анкетата. , моля.
Кажете ми, подписвате ли ярлиците RDP на вашите потребители?
43%Не, те са свикнали да натискат "ОК" в съобщенията, без да четат, някои дори слагат сами отметка "Не питай отново".
29.2%Аз внимателно слагам ярлыка и правя първия достъп до сървъра заедно с всеки потребител.
6.1%Разбира се, аз обичам всичко да е подредено.
21.5%Не използвам терминални сървъри.
Гласували са 65 потребители. Въздържали са се 14 потребители.
Източник: habr.com
