Azure MFA for RDG

Двухфакторная аутентификация клиентов Remote Desktop Gateway при помощи Azure Multi-Factor Authentication

Про пользователей и методы защиты

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

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

Решение с использованием терминального сервера и Remote Desktop Gateway (RDG) более гибкое, можно настроить высокий уровень безопасности. Данный способ позволяет предотвратить передачу данных из облака, но накладывает ограничения на работу пользователя и не полностью решает проблему аутентификации, скорее это DLP решение.

Возможно лучшим способом гарантировать, что под учетной записью пользователя не работает злоумышленник, является двухфакторная аутентификация. Настройка MFA от Microsoft и Google для клиентского VPN — способ хороший, но, во-первых, он требует наличия CISCO ASA, что не всегда легко реализуемо, особенно в бюджетных облаках, а во-вторых, работа через VPN неудобна. Работа с терминальной сессией через RDG значительно комфортнее, да и SSL протокол шифрования выглядит более универсальным и надежным, чем VPN от CISCO.

Решений с двухфакторной аутентификацией на самом терминальном сервере много, вот пример настройки бесплатного решения — http://servilon.ru/dvuhfaktornaya-autentifikaciya-otp/. Это решение, к сожалению, не работает через RDG.

Преимущества Microsoft Azure Multi-Factor Authentication Server (MFAS) описаны в вышеупомянутой статье, поэтому приводить повторно я их не буду, а начнём сразу с настроек.

Чтобы не увеличивать объём данной статьи, опустим первоначальную установку и настройку RDG сервера, который авторизует пользователей по логину и паролю.

Для ясности приведем схему аутентификации RDG запроса при использовании Azure MFA. На сервере RDG запущенна роль Network Policy Server (NPS), позволяющая перенаправлять Radius запросы. Сервер MFA будет развернут в отдельной виртуальной машине во внутренней структуре предприятия.

Shema RDG zapros

RDG сервер запрашивает подтверждение авторизации у сервера MFA. MFA в зависимости от выбранного способа аутентификации звонит, отправляет смс или посылает запрос в мобильное приложение. Пользователь подтверждает или отклоняет запрос на предоставление доступа. MFA возвращает результат второго фактора аутентификации на RDG сервер.

Установка и настройка Azure Multi-Factor Authentication Server

Создание поставщика аутентификации в портале Microsoft Azure

Заходим в Microsoft Azure (учетная запись должна иметь подписку или установлена триальная версия) и находим Multi-Factor Authentication (MFA).

На данный момент управление MFA не добавлено в новую версия портала Azure, поэтому откроется старая версия портала.

Для создания нового поставщика многофакторной проверки подлинности необходимо слева внизу нажать «СОЗДАТЬ -> Службы приложений -> Active directory -> Поставщик многофакторной проверки подлинности -> Быстрое создание». Указать имя и модель использования.

От модели использования зависит как будет начисляться оплата, либо по количеству пользователей, либо по количеству аутентификаций.

sozdanie postavshika mpp

После создания MFA отобразится в списке. Далее переходим к управлению, нажав соответствующую кнопку.

azure active directory

Переходим в загрузки и скачиваем MFA сервер

download MFA

Развертывание MFA сервера

Устанавливать MFA сервер необходимо на виртуальную машину отличную от RDG сервера. Поддерживаются ОС старше Windows Server 2008 или Windows 7. Для работы необходим Microsoft .NET Framework 4.0.
Должны быть доступны адреса по 443 порту:

  • https://pfd.phonefactor.net;
  • https://pfd2.phonefactor.net;
  • https://css.phonefactor.net.

Устанавливаем MFA сервер, при установке отказываемся от мастера настроек.

При первом запуске необходимо ввести данные от учетной записи, которые надо сгенерировать на странице загрузки сервера.

dannye ot uchetnoj zapisi

Далее добавляем пользователей. Для этого переходим в раздел Users и нажимаем на Import from Active Directory, выбираем пользователей для импорта.

new MFA users

new MFA users

При необходимости можно настроить автоматическое добавление новых пользователей из АД:

«Directory Integration -> Synchronization -> Add», а т.ж. добавить каталог, который будет автоматически синхронизироваться по указанному интервалу времени.

add synchronization item

Проведем тест работоспособности MFA сервера. Переходим в раздел Users. Для своей учетной записи указываем номер телефона (если еще не задан) и выбираем способ аутентификации «Звонок телефона». Нажимаем кнопку Test и вводим логин, пароль. На телефон должен прийти вызов. Отвечаем на него и нажимаем #.

test users MFA

Настройка MFA сервера на работу с Radius запросами

Переходим в раздел Radius Authentication и ставим галочку «Enable RADIUS Authentication».

Добавляем нового клиента, указывая IP адрес NPS сервера и общий секретный ключ. Если аутентификация должна проводиться для всех пользователей, ставим соответствующую галочку (в данном случае все пользователи должны быть добавлены на MFA сервер).

Так же необходимо убедиться, что указанные для соединения порты соответствуют портам, указанным на NPS сервере и их не блокирует брандмауэр.

radius authentication

Переходим на вкладку Target и добавляем Radius сервер.

radius authentication target

Примечание: Если в сети нет центрального NPS сервера, IP адреса Radius клиента и сервера будут одинаковыми.

Настройка RDG и NPS сервера на работу совместно с MFA

Шлюз удаленных рабочих столов необходимо настроить на отправку Radius запросов на сервер MFA. Для этого открываем свойства шлюза и переходим на вкладку «RDG CAP Store», выбираем «NPS работает на центральном сервере» и указываем адрес MFA сервера и общий секретный ключ.

RDG CAP store

Далее производим настройку NPS сервера. Разворачиваем раздел «Клиенты и серверы Radius -> Удаленные группы серверов Radius». Открываем свойства группы «TS gateway server group» (группа создаётся при настройке RDG) и добавляем наш MFA сервер.

При добавлении, на вкладке «Load Balancing» увеличиваем лимиты времени ожидания сервера. Выставляем «Число секунд без ответа, после которого запрос считается отброшенным» и «Число секунд между запросами, после которого сервер считается недоступным» в диапазоне 30—60 секунд.

На вкладке «Authentication/Accounting» проверяем правильность указанных портов и задаем общий секретный ключ.

RDG Authentication/Accounting

RDG Authentication/Accounting

Теперь перейдем в раздел «Клиенты и серверы Radius -> Клиенты Radius» и добавим MFA сервер, указав «Friendly name», адрес и общий секрет.

Radius Friendly name

Переходим в раздел «Политики -> Политики запросов на подключение». В данном разделе должна быть политика, созданная при настройке RDG. Эта политика направляет запросы Radius на MFA сервер.

Дублируем политику и заходим в ее свойства. Добавляем условие сопоставляющее «Client Friendly Name» c «Friendly name», заданным в предыдущем шаге.

Radius policy properties

На вкладке «Settings» меняем поставщика услуг аутентификации на локальный сервер.

Radius policy properties settings

Данная политика будет гарантировать то, что при получении Radius запроса от MFA сервера, запрос будет обработан локально, что избавит от зацикливания запросов.

Проверяем что данная политика размещена над исходной.

NPS policy

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

Установка SDK, веб-службы мобильного приложения и пользовательского портала

Подключение к данным компонентам производиться по HTTPS протоколу. Поэтому, на сервера где они будут развернуты, необходимо установить SSL сертификат.

Пользовательский портал и веб-служба мобильного приложения используют пакет SDK для связи с сервером MFA.

Установка SDK

SDK устанавливается на сервер MFA и требует наличия IIS, ASP.NET, Basic Authentication, которые необходимо предварительно установить, используя Server Manager.

Для установки SDK переходим в раздел Web Service SDK в Multi-Factor Authentication Server и нажимаем кнопку установить, следуем мастеру установки.

Web Service SDK в Multi-Factor Authentication Server

Установка веб-службы мобильного приложения

Данная служба необходима для взаимодействия мобильного приложения с сервером MFA. Для корректной работы службы, компьютер, на который она будет установлена, должен иметь выход в интернет и открыт 443 порт для подключения из интернета.

Файл установки службы находиться в папке C:\Program Files\Azure Multi-Factor Authentication на компьютере с установленным MFA. Запускаем установщик и следуем мастеру установки. Для удобства пользователей можно заменить имя виртуального каталога «MultiFactorAuthMobileAppWebService» на более короткое.

После установки заходим в папку C:\inetpub\wwwroot\MultiFactorAuthMobileAppWebService и изменяем файл web.config. В данном файле необходимо задать ключи WEB_SERVICE_SDK_AUTHENTICATION_USERNAME и WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD, отвечающие за учетную запись, входящую в группу безопасности PhoneFactor Admins. Эта учетная запись будет использоваться для подключения к SDK.

edit web.config

В этом же файле необходимо указать URL адрес по которому доступен SDK.

Примечание: Соединение с SDK производиться по SSL протоколу, поэтому необходимо ссылаться на SDK по имени сервера (указанному в SSL сертификате), а не по IP адресу. Если обращение осуществляется по локальному имени, нужно добавить в hosts файл соответствующую запись, чтобы использовать SSL сертификат.

edit web.config

Добавляем URL, по которому доступна веб-служба мобильного приложения, в приложение Multi-Factor Authentication Server в раздел Mobile App. Это необходимо для правильной генерации QR кода в пользовательском портале для подключения мобильных приложений.

Также в этом разделе можно установить галочку «Enable OATH tokens», что позволить использовать мобильное приложения как Software token, для генерации одноразовых паролей на основании времени.

Установка пользовательского портала

Для установки требуется IIS, ASP.NET и роль совместимости мета базы IIS 6 (для IIS 7 или более поздней версии).

Если портал устанавливается на сервере MFA, достаточно в Multi-Factor Authentication Server перейти в раздел User Portal, нажать кнопку установить и следовать мастеру установки. Если компьютер присоединен к домену, то при установке будет создан пользователь, входящий в группу безопасности PhoneFactor Admins. Этот пользователь необходим для защищённого соединения с SDK.

MFA UserPortal

При установке на отдельный сервер, необходимо скопировать файл установки с сервера MFA (файл установки располагается в папке C:\Program Files\Multi-Factor Authentication Server). Произвести установку и отредактировать файл web.config в расположение C:\inetpub\wwwroot\MultiFactorAuth. В данном файле необходимо изменить ключ USE_WEB_SERVICE_SDK со значения false на true. Указать данные учетной записи, входящей в группу PhoneFactor Admins в ключах WEB_SERVICE_SDK_AUTHENTICATION_USERNAME и WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD. И указать URL адрес SDK службы, не забывая при необходимости поправить hosts файл, чтобы работал SSL протокол.

Добавляем URL, по которому доступен пользовательский портал в приложение Multi-Factor Authentication Server в раздел User Portal.

Демонстрация работы Azure MFA для аутентификации RDG подключений

Рассматривать работу MFA будем со стороны пользователя. В нашем случае вторым фактором аутентификации будет мобильное приложение, так как сотовая сеть имеет ряд уязвимостей, позволяющих при должной подготовке перехватывать звонки и SMS.

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

MFA UserPortal test

Далее выбираем метод аутентификации, в нашем случае мобильное приложение и нажимаем кнопку «Создать код активации». Будет сгенерирован QR код, который надо отсканировать в мобильном приложении.

MFA UserPortal test

Так как при импортировании пользователей на MFA сервер была выставлена аутентификация с помощью PIN кода, нам будет предложено создать его. Вводим желаемый PIN код и нажимаем «Проверить мою подлинность». В мобильном приложении необходимо подтвердить появившийся запрос. После данных действий мы имеем привязанное к аккаунту приложение и полноценный доступ к порталу для изменения личных настроек.

MFA UserPortal test

Примечание: Список настроек, которые может менять пользователь через портал, задаётся администратором в приложении Multi-Factor Authentication Server.

Далее рассмотрим подключение через RDG.

Создаем RDP подключение, указываем наш шлюз и подключаемся.

RDP connection

RDP connection

Вводим данные учетной записи для авторизации на RDG сервере.

RDP connection

Подтверждаем запрос в мобильном приложении

RDP connection

Вводим данные учетной записи для авторизации на подключаемой машине и ожидаем подключения.

RDP connection

RDP connection

Примечание: Если телефон оснащен датчиком отпечатка пальца, приложение Authenticator предложит связать PIN код с отпечатком пальца, чтобы в последующем подтверждать аутентификацию простым прикосновением к телефону.

Способы аутентификации, которые предлагает Azure MFA:

    • Звонок телефона

    • нажатие #
    • ввод PIN кода и нажатие #
    • SMS – можно использовать OTP или OTP + PIN

    • One-Way – полученный код необходимо ввести в дополнительное поле при авторизации
    • Two-Way – полученный код необходимо отправить обратно SMS сообщением
    • Мобильное приложение

    • Простое подтверждение
    • Для подтверждения необходимо ввести PIN код
  • OATH token – при авторизации необходимо будет ввести в дополнительное поле код с экрана токена. В качестве токена можно использовать мобильное приложение.

Способы SMS One-Way и OATH token не являются универсальными, так как требуют дополнительного поля для ввода кода при авторизации.

В заключении расскажем о функции MFA, позволяющей отслеживать и защищаться от злоумышленников, пытающихся получить доступ, не имея второго фактора аутентификации.

На портале Azure в панели управления MFA можно включить возможность, позволяющую пользователям отмечать пришедший запрос на аутентификацию как мошеннический. Также возможна автоматическая блокировка пользователя при получении данного сообщения и отправка email уведомления службе поддержки.

MFA portal

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

MFA portal

MFA portal

В панели управления Azure MFA есть отчет отображающий уведомления о мошенничестве:

Report Azure MFA

Если необходимо узнать IP адрес, с которого была инициализирована RDP сессия, можно посмотреть логи RDG сервера в Event Viewer. Если второй фактор аутентификации не был пройден, событие будет иметь статус Error, а в описании будет указан IP адрес, с которого устанавливалось RDP соединение.

MFA error 23003

Обсуждение статьи доступно здесь.

Ссылки по статье:

Remote Desktop Gateway and Azure Multi-Factor Authentication Server using RADIUS
User Portal
Mobile App Web Service

C уважением коллектив компании Servilon

Другие статьи на тему двуфакторной аутентификации

safe internet connection

Безопасный и комфортный доступ в интернет или как защитить свою сеть от интернет угроз без неудобств

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

Практика полного разделения локальной сети и доступа в интернет достаточно правильная и, по мнению многих ИТ специалистов, является единственным 100% способом защиты корпоративных данных. Однако, данный способ, помимо больших затрат на его реализацию, имеет еще один весьма существенный недостаток, а именно неудобство использования интернета. Отсутствие комфортного доступа к интернету влечет за собой не только прямые потери в виде снижения эффективности работы сотрудников, но и косвенные, такие как снижение лояльности сотрудников и престижа работы, что является прямой причиной роста затрат компании.

Типичная схема подобной сети выглядит так:

LAN

Данная схема полностью отделяет рабочие места от сети интернет и даже в случае попадания трояна на компьютер сотрудника он не сможет передать украденную информацию в интернет. Также сеть, построенная по такой схеме, предотвращает несанкционированное распространение конфиденциальной информации сотрудником компании через интернет.

И все же, при всей безопасности данная схема имеет существенный недостаток – это отсутствие гибкости и комфортной работы, так как возможны только два состояния: у сотрудника или совсем нет доступа в интернет, или он есть на отдельной машине.

Чтобы решить эти проблемы и позволить сотруднику полноценно работать, есть интересное решение в виде виртуализации приложений, у Microsoft данная технология называется App-V.

Microsoft Application Virtualization (App-V) технлогия позволяющая сделать программы доступными для пользовательских компьютеров без необходимости устанавливать их непосредственно на эти компьютеры. Благодаря процессу, называемому виртуализацией приложений, который позволяет каждому приложению работать в собственной автономной виртуальной среде на клиентском компьютере. Виртуализированные приложения изолированы друг от друга. Это позволяет избежать конфликтов между приложениями, но они по-прежнему могут взаимодействовать с клиентским компьютером.

Осуществляется это следующим образом: в DMZ устанавливаем терминальный сервер, на который разрешаем интернет-трафик, настраиваем интернет-браузер как виртуальное приложение, запрещаем использование буфера и использование локальных ресурсов через RDP. Также в DMZ настраиваем Remote Desktop Gateway и разрешаем доступ к нему по https из сети компании.

Примерная схема:

Microsoft Application Virtualization

Итак, что мы имеем в итоге:

Пользователи компании, изолированные внутренней сетью от интернета, заходят на внутреннюю веб-страницу сервиса RDG, на которой опубликован интернет–браузер или запускают RDP файл.

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

Задать вопрос или комментарий вы можете здесь.

Ссылки по статье:
Application Virtualization
Remote Desktop Gateway

C уважением коллектив компании Servilon