Захист RDP з'єднання за допомогою SSL. Як настроїти віддалений доступ через RDP Rdp вхід по власному сертифікату

Протокол RDP із захистом на рівні мережі (SSL), на жаль, не набув широкого поширення серед системних адміністраторів, які воліють захищати термінальні з'єднання іншим способом. Можливо це пов'язано з складністю способу, проте це не так, в даному матеріалі ми розглянемо як просто і без труднощів організувати такий захист.

Які переваги дає нам захист RDP за допомогою SSL? По-перше, надійне шифрування каналу, автентифікацію сервера на основі сертифіката і автентифікацію користувача на рівні мережі. Остання можливість доступна починаючи з Windows Server 2008. Перевірка автентичності на рівні мережі дозволяє підвищити безпеку сервера терміналів за рахунок того, що перевірка відбувається ще до початку сеансу.

Перевірка автентичності на рівні мережі проводиться до підключення до віддаленого робочого столу та відображення екрана входу в систему, це знижує навантаження на сервер і значно збільшує його захист від зловмисників та шкідливих програм, а також знижує ймовірність атак типу "відмова в обслуговуванні".

Для повноцінного використаннявсіх можливостей RDP через SSL клієнтські ПК повинні працювати під керуванням Windows XP SP3, Windows Vista або Windows 7 і використовувати RDP клієнт версії 6.0 або пізнішої.

При використанні Windows Server 2003 SP1 і пізніших версій, будуть доступні шифрування каналу за допомогою SSL (TLS 1.0) і автентифікація сервера, клієнтські ПК повинні мати версію RDP клієнта 5.2 або пізнішу.

У нашій статті ми будемо розглядати налаштування термінального сервера на базі Windows Server 2008 R2, проте все сказане буде справедливим і для Windows Server 2003 (за винятком відсутніх можливостей).

Для успішної реалізації даного рішення у вашій мережі повинен бути працюючий центр сертифікації, налаштування якого ми розглядали в . Для довіри сертифікатам виданим даним ЦС на термінальний сервер необхідно встановити сертифікат ЦС (або ланцюжок сертифікатів) у сховищі.

Потім слід виконати запит на сертифікат автентичності сервера з наступними параметрами:

Ім'я - повне ім'я термінального сервера (тобто server.domain.com якщо сервер входить до домену domain.com)

Тип сертифікату Сертифікат автентифікації сервера
Встановіть опцію Створити новий набір ключів
CSP - Microsoft RSA SChannel Cryptographic Provider.
Встановіть прапорець Позначити ключ як експортований.
Для ЦС підприємства встановіть прапорець Використовувати локальне сховище для сертифіката. (В автономному ЦС ця опція недоступна).

Надішліть запит центру сертифікації та встановіть виданий сертифікат. Цей сертифікат повинен бути встановлений у локальному сховищі комп'ютера, інакше він не може бути використаний службами терміналів. Щоб перевірити це запустимо консоль MMC (Пуск - Виконати - mmc) і додамо оснастку Сертифікати(Файл - Додати або видалити оснастку) для облікового запису комп'ютера.

У корені консолі виберіть клацніть Вид - Параметрита встановіть режим перегляду Впорядкувати сертифікати за призначенням. Виданий сертифікат повинен перебувати у групі Перевірка автентичності сервера.

Якщо ви отримували сертифікат за допомогою ізольованого (автономного) ЦС (мережа не має доменної структури), то він за замовчуванням буде встановлений у сховищі облікового запису користувача і доведеться виконати ряд додаткових дій.

Відкрийте Internet Explorer- Властивості оглядача - Вміст - Сертифікати, виданий сертифікат повинен бути встановлений у сховищі Особисті.

Виробте його експорт. При експорті вкажіть такі опції:

Так, експортувати закритий ключ
Видалити закритий ключ після успішного експорту

Після чого видаліть сертифікат з даного сховища. У оснащенні Сертифікати ( локальний комп'ютер) виберіть розділ Перевірка автентичності сервера, клацніть на нього правою кнопкою миші Усі завдання - Імпортта імпортуйте сертифікат.

Тепер у Адміністрація - Служби віддалених робочих століввідкрийте Конфігурація вузла сеансів віддалених робочих столів(Windows Server 2003 Адміністрація - Налаштування служб терміналів).

Оберіть необхідне підключеннята відкрийте його властивості. У самому низу натисніть кнопку Вибратиі виберіть сертифікат, отриманий на попередньому кроці (у Windows Server 2003 це вікно виглядає дещо інакше).

Після вибору сертифіката вкажіть решту властивостей:

Рівень безпеки SSL
Рівень шифрування Високийабо FIPS-сумісний
Встановіть прапорець Дозволити підключатися лише з комп'ютерів.(недоступно у Windows Server 2003)

Збережіть введені параметри, на цьому налаштування сервера закінчено.

На клієнтському ПК створіть підключення до віддаленого робочого стола, використовуйте як адресу повне ім'я сервера, зазначене в сертифікаті. Відкрийте властивості підключення та на закладці Підключення - Перевірка автентичності серверавстановіть опцію Попереджати.

Щоб цей ПК довіряв сертифікатам, виданим нашим центром сертифікації, не забудьте встановити на нього сертифікат ЦС у сховищі. Довірені кореневі центри сертифікації.

У Windows 7 (при використанні RDP клієнта версії 7) цей сертифікат потрібно встановити у сховищі облікового запису комп'ютера, для цього імпортуйте його через оснастку Сертифікати (локальний комп'ютер)у консолі MCC, аналогічно тому, як це робили вище. В іншому випадку підключення буде неможливо і ви отримаєте таку помилку:

Встановивши сертифікат ЦС, можете спробувати підключитися, зверніть увагу, що ім'я користувача та пароль буде запропоновано ввести ще до створення RDP сесії. У разі успішного з'єднання зверніть увагу на замок у заголовку вікна, який свідчить про роботу через SSL. Натиснувши на нього, можна переглянути інформацію про сертифікат.

І насамкінець крапля дьогтю в бочці меду. Термінальні служби Windowsне вміють перевіряти справжність клієнтів, тому якщо стоїть така необхідність слід використовувати додаткові методизахисту, такі як тунель SSH або IPSec VPN.

У серверних версіях Windows є чудова можливість використовувати для підключень облікові дані, введені користувачем раніше, при логіні на свій комп'ютер. Таким чином їм не доводиться щоразу вводити логін і пароль при запуску опублікованої програми або просто віддаленого робочого столу. Називається ця штука Single Sign On із використанням технології CredSSP(Credential Security Service Provider).

Опис

Для того, щоб це працювало, мають бути дотримані такі умови:

Термінальний сервер і клієнт, який підключається до нього, повинні перебувати в домені.
Термінальний сервер має бути налаштований на ОС Windows Server 2008, Windows Server 2008 R2або старшої версії .
На клієнтському комп'ютері має бути встановлена ОС: Windows XP SP3, Windows Vista, Windows Server 2008, Windows 7, Windows 8 або Windows Server 2008 R2.

Для Windows XP SP3, будуть потрібні додаткові рухи тіла. Необхідно встановити фікс, який дозволить через групові політики налаштовувати параметри Windows XP SP3.
Цей фікс (MicrosoftFixit50588.msi) можна завантажити як з , так і з нашого сайту:

Спочатку налаштовуємо на сервері терміналів рівень безпеки в режим "Узгодження":

У ній налаштовуємо 2 параметри: Дозволити передачу облікових даних, встановлених за замовчуваннямта Дозволити делегування облікових даних, встановлених за замовчуванням, з автентичністю сервера "тільки NTLM"

Дозволити делегування облікових даних, встановлених за замовчуванням, з автентифікацією сервера "тільки NTLM" - налаштовувати потрібно лише в тому випадку, якщо автентифікація на термінальному сервері не відбувається за допомогою Kerberos або SSL-сертифіката.

Вписуємо туди сервер (сервери), на які ми хочемо пускати користувачів без повторного введення логіну та паролю. Вписувати можна маскою, а можна окремо. Довідково докладно написано.

Після цього застосовуємо політику на потрібному комп'ютері і перевіряємо, щоб користувачів пускало без введення логіну і пароля на зазначені в політиках вище термінальні сервери.

Бувають такі випадки, коли при використанні RDP (Remote Desktop Protocol — протокол віддаленого робочого столу), не видно програм, які встановлені в системному треї, або помилки та сповіщення просто не відображаються. Для того, щоб вирішити цю проблему, до термінальної півночі можна підключитися в консольному режимі через RDP.

Віддалений робочий стіл (Remote Desktop Protocol) або RDP - це технологія дистанційного підключення до комп'ютера (сервера), для безпосереднього керування ним через локальну мережуабо інтернет. Я вже розповідав про цю технологію у відеоуроці «Підключення до комп'ютера через віддалений робочий стіл».

Використання будь-яких програм віддаленого адміністрування для підключення до робочого столу безпосередньо не завжди зручне, наприклад, при нестабільному зв'язку або обмеженні часу сеансу. Так ось у цій статті ми розповімо про нехитру річ, яку деякі колеги можливо не знали.

При використанні клієнта віддаленого робочого стола (RDP) Windows, як засіб підключення до комп'ютера з Windows Server 2003/2008/2012 з запущеною службою сервера терміналів, у вас є можливість підключення на консоль сервера. Використовуючи цю опцію, ви можете увійти на сервер, так, якби ви сиділи прямо перед ним, а не створювати нові сесії через мережеве підключення. Справа в тому, що при віддаленій установці деяких програм, можуть виникнути проблеми, які не дозволять вам зробити це з термінальної сесії, тому вам доведеться увійти на сервер через консоль.

Увімкнення віддаленого доступу на комп'ютері.

Для того, щоб налаштувати віддалений доступ на цільовому комп'ютері, власник або адміністратор повинен виконати такі дії (Мій комп'ютер \ Властивості \ Налаштування віддаленого доступу \ Віддалений доступ \ Дозволити підключення від комп'ютерів з будь-якою версією віддаленого робочого столу).

Якщо хочете пускати в свій комп'ютер лише певних користувачів або групи користувачів вашої мережі, необхідно поставити галочку «Дозволити підключення з комп'ютерів, на яких працює віддалений робочий стіл з автентичністю на рівні мережі (рекомендується)».

Як підключитися до віддаленого робочого столу?

Це звичайно ж стандартними засобами Windows (Пуск \ Всі програми \ Стандартні \ Підключення до віддаленого робочого столу)

Або через команду Виконати (Win+ R) та вводимо команду mstsc. Це більше швидкий спосібта його використовують переважно адміни та розробники програм, т.к. часто доводиться підключатися до віддалених робочих столів серверів.

Як підключитися до консолі віддаленого робочого столу?

Для цього у вікні вбиваємо команду:

Windows Server 2003 та Windows XP: mstsc /console

Windows Server 2008/2012 та Windows 7/8/8.1: mstsc /admin

Вводимо ім'я термінальної півночі чи комп'ютера.

І вводимо облікові дані користувача, що має права для віддаленого підключення.

Оскільки RDP за замовчуванням створює віртуальну консоль, то підключення відбувається не до сесії, а безпосередньо до консолі (основна консоль-миша/клавіатура).

Яка різниця між простим підключенням до віддаленого робочого стола та підключенням до консолі?

Підключення через консоль - доступне тільки адміністраторам і практично прирівнюється до звичайного входу в систему. Тоді як просте підключення по rdp - це термінальна сесія, відповідно програмне забезпечення, Що чинить опір запуску під термінальною сесією, під консоллю може цілком успішно працювати.

У першому випадку створюється нова сесія (mstsc), паралельна до існуючої. У другому випадку підключення здійснюється до свого робочого столу (у рамках ліцензій на термінал).

Якщо для доступу до твоїх даних єдиним бар'єром є пароль, ти дуже ризикуєш. Пас можна збрутити, перехопити, потягти трояном, вивудити за допомогою соціальної інженерії. Не використовувати за такого розкладу двофакторну авторизацію - майже злочин.

Ми вже не раз розповідали про одноразові ключі. Сенс дуже простий. Якщо зловмисник якимось чином зможе отримати твій логін-пароль, то без проблем зможе зайти до твоєї пошти або виконати підключення до віддаленому серверу. Але якщо на його шляху буде додатковий фактор, наприклад, одноразовий ключ (його також називають OTP-ключом), то вже нічого не вийде. Навіть якщо такий ключ потрапить до зловмисника, то скористатися ним буде вже не можна, оскільки валідним він лише один раз. Як такий другий фактор може бути додатковий дзвінок, код, отриманий по SMS, ключ, згенерований на телефоні за певними алгоритмами на основі поточного часу (час - спосіб синхронізувати алгоритм на клієнті та сервері). Той же Google вже давно рекомендує своїм користувачам включити двофакторну авторизацію (пара кліків в налаштуванні акаунта). Тепер настала черга додати такий шар захисту і для своїх сервісів!

Що пропонує Duo Security?

Банальний приклад. У моєму комп'ютері "назовні" відкритий RDP-порт для віддаленого підключення до робочого столу. Якщо логін-пароль втече, зловмисник одразу отримає повний доступ до машини. Тому про посилення захисту OTP-паролем питання навіть не стояло - це потрібно було просто зробити. Нерозумно було винаходити велосипед і намагатися реалізувати все самотужки, тому я просто переглянув рішення, які є на ринку. Більшість із них виявилися комерційними (докладніше у врізанні), проте для незначної кількості користувачів їх можна юзати безкоштовно. Для дому якраз те, що потрібне. Одним з найуспішніших сервісів, що дозволяють організувати двофакторну авторизацію практично для чого завгодно (включаючи VPN, SSH і RDP), виявився Duo Security (www.duosecurity.com). Привабливості йому додавало те, що розробником та фаундером проекту є Джон Оберхайд, відомий спеціаліст з інформаційної безпеки. Він, наприклад, розколупав протокол спілкування Google з смартфонами Android, за допомогою якого можна встановити або видалити довільні програми. Така база дається взнаки: щоб показати важливість двофакторної авторизації, хлопці запустили сервіс VPN Hunter (www.vpnhunter.com), який за дві секунди може знайти незаховані VPN-сервери компанії (і заодно визначити тип обладнання, на яких вони працюють), сервіси для віддаленого доступу (OpenVPN, RDP, SSH) та інші елементи інфраструктури, що дозволяють зловмиснику потрапити у внутрішню мережу, просто знаючи логін та пароль. Цікаво, що в офіційному Твіттері сервісу власники почали щодня публікувати звіти про сканування відомих компаній, після чого обліковий запис був забанений:). Сервіс Duo Security, само собою, націлений насамперед на впровадження двофакторної аутентифікаціїу компаніях з великою кількістю користувачів. На щастя для нас, є можливість створити безкоштовний Personal-обліковий запис, що дозволяє організувати двофакторну автентифікацію для десяти користувачів безкоштовно.

Що може бути другим фактором?

Далі ми розглянемо, як буквально за десять хвилин посилити безпеку підключення до віддаленого робочого столу, а також SSH на сервері. Але спочатку хочу розповісти про той додатковий етап, який вводить Duo Security як другий фактор авторизації. Варіантів кілька: телефонний дзвінок, СМС із паскодами, Duo Mobile паскоди, Duo Push, електронний ключ. Про кожного трохи докладніше.

Чи довго можна користуватися безкоштовно?

Як уже було сказано, Duo Security пропонує спеціальний тарифний план"Personal". Він абсолютно безкоштовний, але кількість користувачів має бути не більше десяти. Підтримує додавання необмеженої кількості інтеграцій, всі доступні методи автентифікації. Надає тисячі безкоштовних кредитів на послуги телефонії. Кредити - це як би внутрішня валюта, яка списується з твого облікового запису щоразу, коли відбувається аутентифікація за допомогою дзвінка або СМС. У налаштуваннях облікового запису можна виставити, щоб при досягненні заданої кількості кредитів тобі на мило надійшло повідомлення і ти встиг поповнити баланс. Тисяча кредитів коштує лише 30 доларів. Ціна на дзвінки та СМС для різних країн відрізняється. Для Росії дзвінок коштуватиме від 5 до 20 кредитів, СМС – 5 кредитів. Проте за дзвінок, що відбувається під час аутентифікації на сайті Duo Security, нічого не списується. Про кредити можна зовсім забути, якщо використовувати для аутентифікації програму Duo Mobile - за неї нічого не стягується.

Проста реєстрація

Для захисту свого сервера за допомогою Duo Security необхідно завантажити та встановити спеціальний клієнт, який взаємодіятиме з автентифікаційним сервером Duo Security та забезпечуватиме другий шар захисту. Відповідно цей клієнт у кожній ситуації буде різним: залежно від того, де саме необхідно реалізувати двофакторну авторизацію. Про це ми поговоримо нижче. Перше ж, що необхідно зробити, - зареєструватися в системі та отримати обліковий запис. Тому відкриваємо головну сторінкусайту, натискаємо «Free Trial», на сторінці, що натискаємо кнопку «Sing up» під типом акаунта Personal. Після чого нас просять ввести ім'я, прізвище, адресу електронної пошти та назву компанії. На пошту має прийти лист, який містить посилання на підтвердження реєстрації. При цьому система обов'язково виконає автоматичний дзвінок за вказаним телефоном: для активації облікового запису треба відповісти на дзвінок і натиснути на телефоні кнопку #. Після цього обліковий запис буде активним і можна приступати до бойових випробувань.

Захищаємо RDP

Вище я казав, що починав з великого бажання убезпечити віддалені підключення до свого робочого столу. Тому як перший приклад опишу, як посилити безпеку RDP.

Будь-яке впровадження двофакторної авторизації починається з простої дії: створення у профілі Duo Security так званої інтеграції. Переходимо до розділу «Integrations  New Integration», вказуємо ім'я інтеграції (наприклад, «Home RDP»), вибираємо її тип «Microsoft RDP» та натискаємо «Add Integration».
У вікні виводяться параметри інтеграції: Integration key, Secret key, API hostname. Вони нам знадобляться пізніше, коли ми налаштовуватимемо клієнтську частину. Важливо розуміти: знати їх ніхто не має.
Далі необхідно поставити на машину спеціальний клієнт, який встановить все необхідне в Windows-систему. Його можна завантажити з офіційного сайту або взяти з нашого диска. Все його налаштування зводиться до того, що в процесі установки необхідно буде ввести згадані вище Integration key, Secret key, API hostname.
Ось, власне, і все. Тепер при наступному заході на сервер RDP на екрані буде три поля: ім'я користувача, пароль і одноразовий ключ Duo. Відповідно, з одним лише логіном-паролем виконати вхід у систему вже не можна.

При першій спробі заходу в систему новому користувачеві необхідно одного разу пройти процедуру перевірки Duo Security. Сервіс буде видавати йому спеціальне посилання, перейшовши по якому необхідно ввести свій номер телефону і чекати на дзвінок, що перевіряє. Щоб отримати додаткові ключі (або отримати їх вперше), можна ввести ключове слово"sms". Якщо ти хочеш пройти аутентифікацію за допомогою телефонного дзвінка - введи "phone", якщо за допомогою Duo Push - "push". Історію всіх спроб підключення (як вдалих, так і невдалих) до сервера можна подивитися у своєму обліковому записі на сайті Duo Security, попередньо обравши потрібну інтеграцію і зайшовши в її "Authentication Log".

Підключаємо Duo Security будь-де!

За допомогою двофакторної авторизації можна захищати не лише RDP або SSH, а й VPN, RADIUS-сервери, будь-які веб-сервіси. Наприклад, існують готові клієнти, які додають додатковий шар аутентифікації в популярні двигуни Drupal та WordPress. Якщо готового клієнта немає, засмучуватися не варто: ти завжди можеш самостійно додати двофакторну автентифікацію для своєї програми або сайту за допомогою API, що надається системою. Логіка роботи з API проста - ти робиш запит на URL певного методу і парсиш відповідь, що повертається, який може прийти в форматі JSON(або BSON, XML). Повна документація з Duo REST API доступна на офіційному сайті. Я лише скажу, що існують методи ping, check, preauth, auth, status, з назви яких нескладно здогадатися, навіщо вони призначені.

Захищаємо SSH

Розглянемо ще один тип інтеграції - UNIX Integration, щоб реалізувати безпечну автентифікацію. Додаємо ще одну інтеграцію у своєму профілі Duo Security та приступаємо до встановлення клієнта в системі.

Вихідники останнього ти можеш завантажити на адресу bit.ly/IcGgk0 або взяти з нашого диска. Я використовував останню версію– 1.8. До речі, клієнт працює на більшості nix-платформ, тому його можна буде спокійно встановити на FreeBSD, NetBSD, OpenBSD, Mac OS X, Solaris/Illumos, HP-UX та AIX. Процес складання стандартний - configure && make && sudo make install. Єдине, я рекомендував би використовувати configure з опцією --prefix=/usr, інакше при запуску клієнт може не знайти необхідних бібліотек. Після успішної установки йдеморедагувати файл конфігурації /etc/duo/login_duo.conf. Це потрібно робити з-під рута. Всі зміни, які необхідно внести для успішної роботи, - це встановити значення Integration key, Secret key, API hostname, які можна дізнатися на сторінці інтеграції.

; Duo integration keyikey = INTEGRATION_KEY; Duo secret keyskey=SECRET_KEY; Duo API hostnamehost = API_HOSTNAME

Щоб змусити всіх користувачів, що заходять на твій сервер по SSH, використовувати двофакторну автентифікацію, достатньо додати наступний рядок у файл /etc/ssh/sshd_config:

> ForceCommand /usr/local/sbin/login_duo

Існує також можливість організувати двофакторну авторизацію лише для окремих користувачів, об'єднавши їх у групу та вказавши цю групу у файлі login_duo.conf:

> group = wheel

Для набуття змін чинності залишається лише перезапустити ssh-демон. З цього моменту після успішного введення логіна-паролю користувачеві буде запропоновано пройти додаткову аутентифікацію. Слід окремо відзначити одну тонкість налаштування ssh - рекомендується відключити в конфігураційному файлі опції PermitTunnel і AllowTcpForwarding, тому що демон застосовує їх до того, як запустити другий етап аутентифікації. Таким чином, якщо зловмисник правильно вводить пароль, він може отримати доступ до внутрішньої мережі до завершення другого етапу аутентифікації завдяки порт-форвардингу. Щоб уникнути такого ефекту, додай наступні опції у sshd_config:

PermitTunnel noAllowTcpForwarding no

Тепер твій сервер знаходиться за подвійною стіною і потрапити на нього зловмиснику значно складніше.

Додаткові налаштування

Якщо зайти до свого облікового запису Duo Security і перейти до розділу «Settings», можна підкрутити під себе деякі налаштування. Перший важливий розділ – це «Phone calls». Тут вказуються параметри, що діяти, коли підтвердження аутентифікації буде задіяний телефонний дзвінок. Пункт Voice callback keys дозволяє задати, на яку клавішу телефону потрібно буде натиснути для підтвердження аутентифікації. За замовчуванням там стоїть значення "Press any key to authenticate" - тобто можна натискати на будь-яку. Якщо ж встановити значення «Press different keys to authenticate or report fraud», потрібно буде задати дві клавіші: натискання на першу підтверджує аутентифікацію (Key to authenticate), натискання на другу (Key to report fraud) означає, що процес аутентифікації ініціювали не ми , тобто хтось отримав наш пароль і намагається за допомогою його зайти на сервер. Пункт «SMS passcodes» дозволяє задати кількість паскодів, що міститиме одна есемеска, та час їхнього життя (валідності). Параметр «Lockout and fraud» дозволяє задати адресу електронної пошти, на яку надходитиме оповіщення у разі певної кількості невдалих спроб авторизуватися на сервері.

Використовуй!

Дивно, але багато хто, як і раніше, ігнорують двофакторну авторизацію. Не розумію, чому. Це справді дуже серйозно посилює безпеку. Реалізувати її можна практично для всього, а гідні рішення доступні безкоштовно. Так чому? Від лінощів або від безтурботності.

Сервіси-аналоги

Signify(www.signify.net) Сервіс надає три варіанти для організації двофакторної автентифікації. Перший – використання електронних ключів. Другий спосіб - використання пасських, які посилаються користувачеві на телефон за допомогою СМС або приходять на електронну пошту. Третій варіант - мобільний додатокдля телефонів Android, iPhone, BlackBerry, що генерує одноразові паролі (по суті, аналог Duo Mobile). Сервіс націлений на великі компаніїтому повністю платний.

SecurEnvoy(www.securenvoy.com) Також дозволяє використовувати мобільний телефоняк другий захисний шар. Пасскеї надсилаються користувачеві СМС або електронною поштою. Кожне повідомлення містить три пасські, тобто користувач може тричі авторизуватися, перед тим як запросить нову порцію. Сервіс також платний, але надає безкоштовний 30-денний період. Істотним плюсом є велика кількість як рідних, і сторонніх інтеграцій.

PhoneFactor(www.phonefactor.com) Цей сервісдозволяє безкоштовно організувати двофакторну аутентифікацію до 25 користувачів, надаючи 500 безкоштовних аутентифікацій на місяць. Для організації захисту необхідно буде завантажити та встановити спеціальний клієнт. У разі необхідності додавання двофакторної автентифікації на сайт можна скористатись офіційним SDK, що надає докладну документацію та приклади для наступних мов програмування: ASP.NET C#, ASP.NET VB, Java, Perl, Ruby, PHP.

Alexander Antipov

Однією з основних незручностей для користувача при запуску віддаленого робочого стола або опублікованого на термінальному сервері програми є необхідність введення облікових даних. Раніше для вирішення цієї проблеми використовувався механізм збереження облікових даних у налаштуваннях клієнта віддаленого робочого столу. Проте даний спосібмає кілька суттєвих недоліків. Наприклад, за періодичної зміни пароля доводилося змінювати його вручну в налаштуваннях термінального клієнта.

У зв'язку з цим для спрощення роботи з віддаленим робочим столом у Windows Server 2008 з'явилася можливість використання технології прозорої авторизації Single Sign-on (SSO). Завдяки їй користувач при вході на термінальний сервер може використовувати облікові дані, введені ним за логіни на свій локальний комп'ютер, з якого відбувається запуск клієнта віддаленого робочого столу.

У статті наведено огляд алгоритму роботи технології прозорої авторизації Single Sign-On та постачальника послуг безпеки Credential Security Service Provider (CredSSP). Розглянуто спосіб налаштування клієнтської та серверної частин. Також висвітлено низку практичних питань пов'язаних із прозорою авторизацією для служб віддалених робочих столів.

Теоретична інформація

Технологія SSO дозволяє зберегти облікові дані користувача та автоматичну передачу їх при з'єднанні з термінальним сервером. За допомогою групових політик можна визначити сервери, для яких використовуватиметься цей спосіб авторизації. У цьому випадку для всіх інших термінальних серверів вхід буде здійснюватися традиційним чином: за допомогою введення логіну та пароля.

Вперше механізми прозорої авторизації з'явилися у Windows Server 2008 та Windows Vista. завдяки новому постачальнику послуг безпеки CredSSP. З його допомогою кешовані облікові дані передавалися через безпечний канал (використовуючи Transport Layer Security (TLS)). Згодом Microsoft випустила відповідні оновлення для Windows XP SP3.

Розглянемо це докладніше. CredSSP може використовуватись у таких сценаріях:

для мережного рівня аутентифікації (NLA), дозволяючи користувачеві дізнатися до повної установки з'єднання;
для SSO, зберігаючи облікові дані користувача та передаючи їх на термінальний.

При відновленні сеансу всередині ферми CredSSP прискорює процес установки з'єднання, т.к. термінальний сервер визначає користувача без встановлення повноцінного з'єднання (за аналогією з NLA).

Процес аутентифікації відбувається за наступним алгоритмом:

Клієнт ініціює встановлення безпечного каналу з сервером, використовуючи TLS. Сервер передає йому сертифікат, що містить ім'я, що засвідчує центр і публічний ключ. Сертифікат сервера може бути самопідписаним.
Між сервером та клієнтом встановлюється сесія. Для неї створюється відповідний ключ, який надалі братиме участь у шифруванні. CredSSP використовує протокол Simple and Protected Negotiate (SPNEGO) для взаємної автентифікації сервера та клієнта так, щоб кожен з них міг довіряти одне одному. Цей механізм дозволяє клієнту та серверу вибрати механізм автентифікації (наприклад, Kerberos або NTLM).
Для захисту від перехоплення клієнт і сервер по черзі шифрують сертифікат сервера, використовуючи ключ сесії, і передають його один одному.
Якщо результати обміну та вихідний сертифікат збігаються, CredSSP на клієнті надсилає облікові дані користувача на сервер.

Таким чином, передача облікових даних відбувається зашифрованим каналом із захистом від перехоплення.

Налаштування

Постачальник послуг безпеки CredSSP є частиною операційної системи та входить до складу Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2. Крім того, він може бути встановлений як окреме оновлення на Windows XP SP3. Цей процес докладно описаний у статті "Description of the Credential Security Support Provider (CredSSP) in Windows XP Service Pack 3". Для встановлення та увімкнення CredSSP на Windows XP SP3 необхідно виконати такі дії.

1. Запустити редактор реєстру regedit і перейти у гілку: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.

2. Додати значення tspkgдо ключа SecurityPackages

3. Перейтивгілкуреєстру: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders.

4. Додати значення credssp.dllдо ключа SecurityProviders(Інші значення цього ключа слід залишити незмінними).

Після того, як CredSSP увімкнено, необхідно налаштувати його використання за допомогою групових політик або відповідних ним ключів реєстру. Для налаштування SSO на клієнтських комп'ютерах використовуються групові політики з розділу:

Computer Configuration\Administrative Templates\System\Credentials Delegation.

У російськомовних версіях операційних систем це так (рис. 1).

Рис. 1. Управління передачею облікових даних за допомогою групових політик

Для використання SSO слід увімкнути політику:

Дозволити передачу облікових даних, встановлених за замовчуванням.

Крім того, після включення слід встановити для яких саме серверів буде використовуватися даний спосіб авторизації. Для цього потрібно виконати такі дії.

У вікні редагування політики (мал. 2) натиснути кнопку « Показати»

Рис. 2. Вікно редагування групової політики

Додати перелік термінальних серверів (рис. 3).

Рис. 3. Додавання термінального сервера для прозорої авторизації

Рядок додавання сервера має такий формат:

TERMSRV/ім'я_сервера.

Також можна встановити сервера за маскою домену. У цьому випадку рядок набуває вигляду:

TERMSRV/*.ім'я_домену.

Якщо немає можливості використовувати групові політики, можна настроїти відповідні налаштування за допомогою редактора реєстру. Наприклад, для налаштування Windows XP Sp3 можна використовувати наступний файл реєстру:

Windows Registry Editor Version 5.00

"Security Packages"=hex (7):6b,00,65,00,72,00,62,00,65,00,72,00,6f,00,73,00,00,\

00,6d,00,73,00,76,00,31,00,5f,00,30,00,00,00,73,00,63,00,68,00,61,00,6e,00, \

6e,00,65,00,6c,00,00,00,77,00,64,00,69,00,67,00,65,00,73,00,74,00,00,00,74, \

00,73,00,70,00,6b,00,67,00,00,00,00,00

"SecurityProviders"="msapsspc.dll, schannel.dll, digest.dll, msnsspc.dll, credssp.dll"

"AllowDefaultCredentials"=dword:00000001

"ConcatenateDefaults_AllowDefault"=dword:00000001

"1"="termsrv/*.mydomain.com"

Тут замість mydomain.com слід підставити ім'я домену. У цьому випадку, при підключенні до термінальних серверів по повному доменного імені(наприклад, termserver1.mydomain.com) використовуватиметься прозора авторизація.

Для використання технології Single Sign-On на термінальному сервері необхідно виконати такі дії.

Відкрити консоль налаштування служб терміналів ( tsconfig.msc).
У розділі підключення перейти до властивостей RDP-Tcp.
На вкладці « Загальні» встановити рівень безпеки « Узгодження» або « SSL (TLS 1.0)»(Рис. 4).

Рис. 4. Налаштування рівня безпеки на термінальному сервері

На цьому налаштування клієнтської та серверної частини можна вважати закінченим.

Практична інформація

У цьому розділі розглянемо обмеження щодо використання технології прозорої авторизації та проблеми, які можуть виникнути при її застосуванні.

Технологія Single Sign-On працює лише при з'єднанні з комп'ютерами під керуванням операційної системи не Windows XP SP3 і старших версій. Як термінальний сервер можуть бути використані комп'ютери з операційною системою Windows Vista, Windows Server 2008, Windows 7 та Windows Server 2008 R2.
Якщо термінальний сервер, до якого встановлюється з'єднання, не може бути автентифікований через Kerberos або SSL-сертифікат, SSO не працюватиме. Це обмеження можна обійти за допомогою політики:
Дозволити делегування облікових даних, встановлених за замовчуванням з автентичністю сервера «тільки NTLM».
Алгоритм включення та налаштування цієї групової політики аналогічний представленому вище. Файл реєстру, що відповідає даному настроюванню, має такий вигляд.

"AllowDefCredentialsWhenNTLMOnly"=dword:00000001

"ConcatenateDefaults_AllowDefNTLMOnly"=dword:00000001

"1"="termsrv/*.mydomain.com"

Аутентифікація таким способом є менш безпечною, ніж при використанні сертифікатів або Kerberos.

Якщо для сервера збережено облікові дані в налаштуваннях термінального клієнта, то вони мають більш високий пріоритет, ніж поточні облікові дані.
Single Sign-On працює лише при використанні доменних облікових записів.
Якщо підключення до термінального сервера відбувається через TS Gateway, у деяких випадках можливий пріоритет налаштувань сервера TS Gateway над налаштуваннями SSO термінального клієнта.
Якщо термінальний сервер налаштований щоразу запитувати облікові дані користувачів, SSO не працюватиме.
Технологія прозорої авторизації працює лише з паролями. У разі використання смарт-карток вона не працюватиме.

Для коректної роботи SSO на Windows XP SP рекомендується встановити два виправлення з KB953760: «Коли Ви маєте можливість SSO для terminal server від Windows XP SP3-based client computer, ви будете налаштовані для user credentials, коли ви напишіть на terminal server » .

У деяких випадках можлива ситуація коли на одному і тому ж термінальному клієнті технологія прозорої авторизації може працювати або не працювати залежно від профілю користувача, що підключається. Проблема вирішується перестворенням профілю користувача. Якщо це є занадто трудомістким завданням можна спробувати скористатися порадами з обговорення: Microsoft Technet форумів Microsoft Technet. Зокрема, рекомендується скинути налаштування Internet Explorer або схвалити відповідну надбудову для нього.

Ще одним серйозним обмеженням технології SSO і те, що вона працює при запуску опублікованих додатків через TS Web Access. При цьому користувач змушений двічі вводити облікові дані: при вході на веб-інтерфейс та авторизації на термінальному сервері.

У Windows Server 2008 R2 ситуація змінилася на краще. Більш детальну інформацію про це можна отримати у статті: "Introducing Web Single Sign-On for RemoteApp and Desktop Connections"".

Висновок

У статті розглянуто технологію прозорої авторизації на термінальних серверах Single Sign-On. Її використання дозволяє скоротити час, що витрачається користувачем для входу на термінальний сервер та запуск віддалених програм. Крім того, з її допомогою досить один раз вводити облікові дані при вході на локальний комп'ютер і потім використовувати їх при з'єднанні з термінальними серверами домену. Механізм передачі облікових даних досить безпечний, а налаштування серверної та клієнтської частини гранично просте.