Если для доступа к твоим данным единственным барьером является пароль, ты сильно рискуешь. Пасс можно сбрутить, перехватить, утащить трояном, выудить с помощью социальной инженерии. Не использовать при таком раскладе двухфакторную авторизацию - почти преступление.
Мы уже не раз рассказывали об одноразовых ключах. Смысл очень простой. Если злоумышленник каким-то образом сможет получить твой логин-пароль, то без проблем сможет зайти в твою почту или выполнить подключение к удаленному серверу. Но если на его пути будет дополнительный фактор, например одноразовый ключ (его также называют 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. Сервис будет выдавать ему специальную ссылку, перейдя по которой необходимо ввести свой номер телефона и ждать проверяющего звонка. Чтобы получить дополнительные ключи (или получить их в первый раз), можно ввести ключевое слово «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.
Протокол 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.
Наверняка, многие из вас уже слышали и видели эту аббревиатуру - дословно переводится она, как Протокол удалённого рабочего стола (Remote Desktop Protocol) . Если кого-то интересуют технические тонкости работы этого протокола прикладного уровня - могут почитать литературу, начиная с той же самой википедии. Мы же рассмотрим чисто практические аспекты. А именно тот, что данный протокол позволяет удалённо подключаться к компьютерам, под управлением Windows различных версий с использованием встроенного в Windows инструмента «Подключение к удалённому рабочему столу».
Какие плюсы и минусы в использовании протокола RDP?Начнём с приятного - с плюсов. Плюс состоит в том, что этот инструмент, который правильней называть Клиентом RDP , доступен любому пользователю Windows как на компьютере, с которого предстоит управлять удалённым, так и тому, кто хочет к своему компьютеру удалённый доступ открыть.
Через подключение к удалённому рабочему столу возможно не только видеть удалённый рабочий стол и пользоваться ресурсами удалённого компьютера, так и подключать к нему локальные диски, принтеры, смарткарты и т.п. Конечно, если вы захотите посмотреть видео или послушать музыку через RDP - вряд ли этот процесс доставит вам удовольствие, т.к. в большинстве случаев вы увидите слайд шоу, и звук скорей всего будет прерываться. Но, не под эти задачи разрабатывалась служба RDP.
Ещё одним несомненным плюсом является то, что подключение к компьютеру осуществляется безо всяких дополнительных программок, которые в большинстве своём платные, хотя и имеют свои достоинства. Время доступа к RDP-серверу (которым и является ваш удалённый компьютер) ограничивается лишь вашим желанием.
Минусов всего два. Один существенный, другой - не очень. Первый и существенный - для работы с RDP компьютер, к которому осуществляется подключение, должен иметь белый (внешний) IP, либо на этот компьютер должна быть возможность «пробросить» порт с маршрутизатора, который опять же должен иметь внешний IP. Статическим он будет или динамическим - значения не имеет, но он должен быть.
Второй минус - не такой существенный - последние версии клиента перестали поддерживать 16-цветную цветовую схему. Минимум - 15бит. Это сильно замедляет работу по RDP, когда вы подключаетесь по чахлому-дохлому интернету со скоростью, не превышающей 64 килобита в секунду.
Для чего можно использовать удалённый доступ по RDP?Организации, как правило, используют RDP-сервера для совместной работы в программе 1С. А некоторые, даже, разворачивают на них рабочие места пользователей. Таким образом, пользователь, особенно, если у него разъездная работа, может при наличии 3G интернета или отельного/кафешного Wi-Fi - подключаться к своему рабочему месту удалённо и решать все вопросы.
В некоторых случаях домашние пользователи могут использовать удалённый доступ к своему домашнему компьютеру, чтобы получить какие-то данные с домашних ресурсов. В принципе, служба удалённого рабочего стола позволяет полноценно работать с текстовыми, инженерными и графическими приложениями. С обработкой видео и звука по вышеприведённым причинам - работать не получится, но всё равно - это очень существенный плюс. А ещё можно на работе просматривать закрытые политикой компании ресурсы, подключившись к домашнему компьютеру безо всяких анонимайзеров, vpn и прочей нечисти.
Подготавливаем интернетВ предыдущем разделе мы говорили о том, что для обеспечения возможности удалённого доступа по протоколу RDP нам необходим внешний IP-адрес. Этот сервис может обеспечить провайдер, поэтому звоним или пишем, или заходим в личный кабинет и организовываем предоставление этого адреса. В идеале он должен быть статический, но и с динамическим, в принципе, можно жить.
Если кому-то не понятна терминология, то статический адрес - это постоянный, а динамический - время от времени меняется. Для того, чтобы полноценно работать с динамическими IP-адресами придумали различные сервисы, которые обеспечивают привязку динамического домена. Что и как, скоро будет статья на эту тему.
Подготавливаем роутерЕсли ваш компьютер подключен не напрямую к провайдерскому проводу к интернету, а через роутер - с этим устройством нам придётся тоже совершить некоторые манипуляции. А именно - пробросить порт сервиса - 3389 . В противном случае NAT вашего роутера попросту не будет пускать вас внутрь домашней сети. Тоже относится к настройке RDP-сервера в организации. Если вы не знаете, как пробросить порт - читайте статью про то, Как пробросить порты на маршрутизаторе (откроется в новой вкладке), потом возвращайтесь сюда.
Подготавливаем компьютерДля того, чтобы создать возможность удалённого подключения к компьютеру, необходимо сделать ровно две вещи:
Разрешить подключение в Свойствах Системы;
- задать пароль для текущего пользователя (если он не имеет пароля), либо создать нового пользователя с паролем специально для подключения по RDP.
Как поступать с пользователем - решайте сами. Однако, имейте ввиду, что штатно не серверные операционные системы не поддерживают множественный вход. Т.е. если вы залогинились под собой локально (консольно), а потом зайдёте под тем же пользователем удалённо - локальный экран заблокируется и сеанс на том же самом месте откроется в окне Подключения к удалённому рабочему столу. Введёте пароль локально, не выйдя из RDP - вас выкинет из удалённого доступа, и вы увидите текущий экран на своём локальном мониторе. Тоже самое вас ждёт, если вы зайдёте консольно под одним пользователем, а удалённо попытаетесь зайти под другим. В этом случае система предложит завершить сеанс локального пользователя, что не всегда может быть удобно.
Итак, заходим в Пуск , щёлкаем правой кнопкой по меню Компьютер и нажимаем Свойства .
В свойствах Системы выбираем Дополнительные параметры системы
В открывшемся окне переходим на вкладку Удалённый доступ …
…нажимаем Дополнительно …
И ставим единственную галку на этой странице.
Это «домашняя» версия Windows 7 - у кого Pro и выше, будет больше флажков и возможно сделать разграничение доступа.
Нажимаем ОК везде.
Теперь, вы можете зайти в Подключение к удалённому рабочему столу (Пуск>Все программы>Стандартные), вбить туда IP-адрес компьютера, либо имя, если хотите подключиться к нему из своей домашней сети и пользоваться всеми ресурсами.
Вот так. В принципе, всё просто. Если вдруг будут какие-то вопросы или что-то останется непонятным - добро пожаловать в комментарии.
В серверных версиях ОС 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-сертификата.
Вписываем туда сервер (серверы), на которые мы хотим пускать пользователей без повторного ввода логина и пароля. Вписывать можно по маске, а можно и по отдельности. В справке подробно написано.
После этого, применяем политику на нужном компьютере(-ах) и проверяем, чтобы пользователей пускало без ввода логина и пароля на указанные в политиках выше терминальные серверы.
Alexander Antipov
В статье приведен обзор алгоритма работы технологии прозрачной авторизации Single Sign-On и поставщика услуг безопасности Credential Security Service Provider (CredSSP). Рассмотрен способ настройки клиентской и серверной частей.
Одним из основных неудобств для пользователя при запуске удаленного рабочего стола или опубликованного на терминальном сервере приложения является необходимость ввода своих учетных данных. Ранее для решения этой проблемы использовался механизм сохранения учетных данных в настройках клиента удаленного рабочего стола. Однако данный способ имеет несколько существенных недостатков. Например, при периодической смене пароля приходилось изменять его вручную в настройках терминального клиента.
В связи с этим, для упрощения работы с удаленным рабочим столом в 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 ускоряет процесс установки соединения, т.к. терминальный сервер определяет пользователя без установки полноценного соединения (по аналогии c NLA).
Процесс аутентификации происходит по следующему алгоритму:
Таким образом, передача учетных данных происходит по зашифрованному каналу с защитой от перехвата.
НастройкаПоставщик услуг безопасности 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 к ключу Security Packages
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 на терминальном сервере необходимо выполнить следующие действия.
Рис. 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: «When you enable SSO for a terminal server from a Windows XP SP3-based client computer, you are still prompted for user credentials when you log on to the terminal server ».
В некоторых случаях возможна ситуация когда на одном и том же терминальном клиенте технология прозрачной авторизации может работать или не работать в зависимости от профиля подключающегося пользователя. Проблема решается пересозданием профиля пользователя. Если это является слишком трудоемкой задачей можно попробовать воспользоваться советами из обсуждения: «RemoteApp Single Sign On (SSO) from a Windows 7 client » форумов 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. Её использование позволяет сократить время, затрачиваемое пользователем для входа на терминальный сервер и запуск удаленных приложений. Кроме того, с её помощью достаточно единожды вводить учетные данные при входе на локальный компьютер и затем использовать их при соединении с терминальными серверами домена. Механизм передачи учетных данных достаточно безопасен, а настройка серверной и клиентской части предельно проста.
