Настройка двухфакторной аутентификации Windows VPN с Routing and Remote Access Service (RRAS)

В статье описывается настройка службы Microsoft Routing and Remote Access Service (RRAS) для подключения к VPN c двухфакторной аутентификацией.

Применимо к версиям:

• Windows Server 2012 R2
• Windows Server 2016
• Windows Server 2019

Возможные способы аутентификации:

• Мобильное приложение MultiFactor
• Telegram
• Звонок (нужно принять вызов и нажать #)

Для настройки второго фактора аутентификации вам потребуется установить и настроить MultiFactor Radius Adapter.

1. Клиент VPN подключается к RRAS серверу, указывает логин и пароль;
2. RRAS сервер переадресовывает запрос компоненту MultiFactor Radius Adapter;
3. Компонент проверяет логин и пароль пользователя в домене ActiveDirectory и отправляет на телефон пользователя запрос подтверждения входа;
4. Пользователь подтверждает запрос в телефоне и подключается к VPN.

Установка и настройка Routing and Remote Access Service (RRAS)

1. Откройте Server Manager, в меню Manage выберите «Add Roles and Features Wizard».
2. В разделе Server Roles отметьте «Remote Access» -> «Direct Access and VPN (RAS)»
3. Завершите установку.

1. В Server Manager, в меню Tools выберите «Routing and Remote Access»
2. Правой кнопкой на имени сервера, далее «Configure and Enable Routing and Remote Access»

1. Выберите пункт «Custom Configuration»

RRAS предлагает несколько протоколов для VPN соединений: PPTP, L2TP/IPSec и SSTP:

• PPTP является устаревшим и небезопасным;
• L2TP/IPSec и IKEv2 безопасны, но используют нестандартные порты и ваши пользователи могут испытывать проблемы при подключении из домашних и публичных сетей;
• SSTP — безопасный протокол, который использует TCP порт 443 (TLS) и является наиболее удачным вариантом.

Для того, чтоб убрать ненужные протоколы, нажмите правой кнопкой на Ports и выберите Properties. Далее нажмите Configure для каждого типа порта кроме SSTP и снимите все флажки.

Нажмите правой кнопкой на имени сервера, выберите Properties. Далее на вкладке «Security» в качестве Authentication Provider укажите «RADIUS Authentication» и нажмите «Configure». В список RADIUS серверов добавьте новый сервер:

• Server name: IP адрес компонета MultiFactor Radius Adapter
• Shared Secret: общий секрет с компонентом
• Timout: 60 секунд
• Port: 1812
• Поставьте флажок «Always use message authenticator»

Сохраните и закройте.

Далее нажмите на кнопку «Authentication methods» и оставьте один вариант — «Unencrypted password (PAP)».

Сохраните и закройте.

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

Выбор сертификата сервера

Для шифрования трафика между клиентом и севером, а также аутентификации сервера, необходим сертификат, выданный публичным удостоверяющем центром сертификации. Вы можете купить такой сертификат или получить бесплатно в Let’s Encrypt. Как это сделать за 5 минут — читайте в нашей статье.

Выберите сертификат в разделе SSL Certificate Binding

Откройте Параметры -> Сеть и интернет -> VPN.

Добавьте новое VPN подключение:

• Поставщик услуг: Windows (встроенные);
• Имя подключения: произвольное;
• Имя или адрес сервера: адрес вашего сервера;
• Тип VPN: Протокол SSTP

Далее перейдите в настройки параметров адаптера, и откройте свойства подключения. На вкладке Безопасность выберите «Разрешить следующие протоколы»: Незашифрованный пароль (PAP).

Сохраните и закройте.

Запустите соединение, введите логин и пароль. От Мультифактора придет запрос на телефон с подтверждением

Настройка двухфакторной аутентификации на сервере Windows со службой RD Gateway

В статье описывается настройка Windows сервера для включения двухфакторной аутентификации при подключении удаленного рабочего стола (RDP) со службой RD Gateway.

RD Gateway — компонент Windows сервера, позволяющий подключаться к рабочему столу через шлюз, который выполняет функции VPN, а именно создает зашифрованное подключение по протоколу TLS.

Применимо к версиям:

• Windows Server 2012 R2
• Windows Server 2016
• Windows Server 2019

Возможные способы аутентификации:

• Мобильное приложение MultiFactor
• Telegram
• Звонок (нужно принять вызов и нажать #)

1. Пользователь подключается к удаленному рабочему столу через шлюз RD Gateway;
2. RD Gateway проверяет логин, пароль, политику авторизации ресурсов (RAP) и переадресовывает запрос в Network Policy Server (NPS);
3. NPS получает запрос от RD Gateway, запрашивает второй фактор аутентификации по RADIUS протоколу в компоненте MultiFactor Radius Adapter;
4. Мультифактор отправляет на телефон пользователя запрос подтверждения входа;
5. Пользователь подтверждает запрос в телефоне и подключается к VPN.

• настройка доступа на основе принадлежности пользователя к группе в Active Directory;
• избирательное включение второго фактора на основе принадлежности пользователя к группе в Active Directory;
• использование телефона пользователя из профиля Active Directory для звонка на мобильный телефон;

Требования к серверу

1. На сервере должны быть установлены и настроены компоненты Remote Desktop Gateway и Network Policy and Access Service.
2. На сервере с NPS необходимо установить компонент MultiFactor Radius Adapter.
3. Для работы Мультифактора серверу необходим доступ к хосту api.multifactor.ru по порту 443 (TLS).

Настройка MultiFactor Radius Adapter

Разверните компонент MultiFactor Radius Adapter, настройте файл конфигурации следующим образом:

Придумайте сложное значение SHARED_SECRET и запишите в конфигурационный файл.

1. В разделе Remote RADIUS Server Groups создайте новую группу:
   • Group name: MFA
   • Нажмите Add:
     • Server: 127.0.0.1
     • Shared secret: ранее придуманный SHARED_SECRET
     • Load Balancing: поставьте таймауты по 60 секунд

1. В разделе Connection Requests Policies, откройте свойства политики TS GATEWAY AUTHORIZATION POLICY:
   • На вкладке Settings:
     • в разделе Authentication выберите вариант Forward requests to the following remote RADIUS server group for authentication: MFA

Двухфакторная аутентификация windows server

Настройка двухфакторной аутентификации на сервере Windows со службой RD Gateway

В статье описывается настройка Windows сервера для включения двухфакторной аутентификации при подключении удаленного рабочего стола (RDP) со службой RD Gateway.

RD Gateway — компонент Windows сервера, позволяющий подключаться к рабочему столу через шлюз, который выполняет функции VPN, а именно создает зашифрованное подключение по протоколу TLS.

Применимо к версиям:

• Windows Server 2012 R2
• Windows Server 2016
• Windows Server 2019

Возможные способы аутентификации:

• Telegram
• Звонок (нужно принять вызов и нажать #)
• Мобильное приложение (скоро)

1. Пользователь подключается к удаленному рабочему столу через шлюз RD Gateway;
2. RD Gateway проверяет логин, пароль, политику авторизации ресурсов (RAP) и переадресовывает запрос в Network Policy Server (NPS);
3. NPS получает запрос от RD Gateway, запрашивает второй фактор аутентфикации по RADIUS протоколу в компоненте MultiFactor Radius Adapter;
4. Мультифактор отправляет на телефон пользователя запрос подтверждения входа;
5. Пользователь подтверждает запрос в телефоне и подключается к VPN.

Требования к серверу

1. На сервере должны быть установлены и настроены компоненты Remote Desktop Gateway и Network Policy and Access Service.
2. На сервере с NPS необходимо установить компонент MultiFactor Radius Adapter.
3. Для работы Мультифактора серверу необходим доступ к хосту api.multifactor.ru по порту 443 (TLS).

Настройка MultiFactor Radius Adapter

Разверните компонент MultiFactor Radius Adapter, настройте файл конфигурации следующим образом:

Придумайте сложное значение SHARED_SECRET и запишите в конфигурационный файл.

1. В разделе Remote RADIUS Server Groups создайте новую группу:
   • Group name: MFA
   • Нажмите Add:
     • Server: 127.0.0.1
     • Shared secret: ранее придуманный SHARED_SECRET
     • Load Balancing: поставьте таймауты по 60 секунд

1. В разделе Connection Requests Policies, откройте свойства политики TS GATEWAY AUTHORIZATION POLICY:
   • На вкладке Settings:
     • в разделе Authentication выберите вариант Forward requests to the following remote RADIUS server group for authentication: MFA

Двухфакторная аутентификация для терминальных серверов

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

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

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

Одноразовый пароль (англ. one time password, OTP) это пароль, действительный только для одного сеанса аутентификации.

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

Используемые продукты

В качестве примера, рассмотрим реализацию внедрения OTP пароля, основанном на проекте multiOTP – опенсорсовом софте PHP, умеющим работать на стандартных алгоритмах, которые хорошо себя зарекомендовали в индустрии обеспечения многофакторной аутентификации (HOTP, TOTP, OCRA).

Для обеспечения дополнительного поля ввода OTP пароля в окне входа в систему Windows будем использовать плагин MultiOneTimePassword-CredentialProvider.

Пользователь будет генерировать одноразовые пароли у себя на мобильном устройстве с помощью Google Authenticator.

Установка multiOTP

Скачиваем продукт multiOTP и размещаем содержимое папки windows (из скачанной директории) в корень системного диска: C:\multiotp.

Вся настройка происходит через командную строку. Запускаем CMD от имени администратора и переходим в нашу директорию:

Далее приводится список команд для настройки и синхронизации сервиса multiOTP с Active Directory:

1. C:\multiotp>multiotp -config default-request-prefix-pin=0

Ввод ПИН-кода по умолчанию, при создании новых пользователей (1 | 0)

1. C:\multiotp>multiotp -config default-request-ldap-pwd=0

Использование пароля Active Directory вместо ПИН-кода по умолчанию(1 | 0)

1. C:\multiotp>multiotp -config ldap-server-type=1

Выбор сервер AD/LDAP (1=Active Directory | 2=standart LDAP )

1. C:\multiotp>multiotp -config ldap-cn-identifier=»sAMAccountName»

CN идентификатор пользователя (sAMAccountName, eventually userPrincipalName)

1. C:\multiotp>multiotp -config ldap-group-cn-identifier=»sAMAccountName»

CN идентификатор группы (sAMAccountName for Active Directory)

1. C:\multiotp>multiotp -config ldap-group-attribute=»memberOf»

Атрибут, определяющий принадлежность к группе

Использование SSL соединения по умолчанию (0 | 1)

1. C:\multiotp>multiotp -config ldap-port=389

Порт подключения (389 = standart | 636 = SSL connection)

1. C:\multiotp>multiotp -config ldap-domain-controllers=servilon.com,ldaps://192.168.254.10:389

Указываем сервер(а) Active Directory

1. C:\multiotp>multiotp -config ldap-base-dn=»DC=SERVILON,DC=COM»

Указываем суффикс домена

1. C:\multiotp>multiotp -config ldap-bind-dn=»CN=Administrator,CN=Users,DC=servilon,DC=com»

Аккаунт, под которым подключаемся к AD DS.

1. C:\multiotp>multiotp -config ldap-server-password=»P@$$w0rd»

Пароль, под которым подключаемся к AD DS.

1. C:\multiotp>multiotp -config ldap-in-group=»OTP»

Группа, пользователи которой будут использовать OTP для входа на сервер.

1. C:\multiotp>multiotp -config ldap-network-timeout=10

Таймаут ожидания синхронизации в секундах.

1. C:\multiotp>multiotp -config ldap-time-limit=30

Таймаут смены OTP пароля на новый.

1. C:\multiotp>multiotp -config ldap-activated=1

Включение поддержки AD/LDAP сервисом multiotp.

1. C:\multiotp>multiotp -debug -display-log -ldap-users-sync

Синхронизация пользователей с AD/LDAP. Последнюю команду необходимо запускать каждый раз при добавлении новых пользователей или настроить в виде запуска скрипта по расписанию.

Если все команды введены корректно и сервер AD/LDAP доступен, то последняя команда должна показать синхронизацию и создание новых пользователей для сервиса multiotp:

Настройка Google Authenticator

Теперь необходимо передать уникальный ключ пользователя на устройство пользователя. Удобней всего это сделать через QR код. Для этого нам необходимо установить web-server который нам поможет в просмотре и регистрации пользователей. Просто заходим в папку multiotp и запускаем webservice_install.cmd, после чего должен открыться браузер с консолью администрирования. После входа, мы можем создать нового локального пользователя или просмотреть список существующих, что весьма полезно:

Но самое главное, вэб-консоль поможет нам зарегистрировать пользователя на мобильном устройстве. Нажимаем “Print” в строке необходимого пользователя и на новой вкладке мы видим QR код, сгенерированный для данного пользователя:

Сканируем полученный QR код с помощью Google Authenticator. Регистрация завершена.

Как видите все просто, можно например, переслать QR код пользователю почтой и он сам справится с регистрацией. Если все прошло успешно, та на экране мобильного устройства будет доступен OTP пароль, который обновляется каждые 30 секунд:

Установка MultiOneTimePassword-CredentialProvider

Теперь необходимо указать нашему серверу Terminal дополнительно использовать OTP пароль при аутентификации пользователя. Для этого запускаем ранее скачанный установщик MultiOneTimePassword-CredentialProvider, где нам требуется лишь указать установку Default Provider и папку с сервисом multiotp:

Важно! После установки CredentialProvider, пользователи, которые не получили настройку OTP не смогут зайти на сервер. Поэтому необходимо позаботится чтобы у учетной записи администратора был также настроен OTP пароль.

Результаты

Теперь наш сервер Terminal получил дополнительный уровень безопасности в виде внедрения OTP пароля на базе бесплатного решения проекта multiOTP и multiOTP-Credential Provider.

Данное решение вполне можно развернуть и на самом ПК пользователя, выставив барьер для злоумышленника при попытке входа на рабочем месте сотрудника.

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

Защита удаленного терминального сервера или двухфакторная аутентификация клиентов RDG при помощи Azure MFA

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

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

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

Некоторые компании для контроля доступа к данным в облаке устанавливают туннели между облаком и офисом, запрещают удаленный доступ https://habrahabr.ru/company/pc-administrator/blog/320016/. На наш взгляд — это не совсем оптимальное решение, во-первых, теряется часть преимуществ облачного решения, а во-вторых есть проблемы с производительностью, отмеченные в статье.

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

Возможно лучшим способом гарантировать, что под учетной записью пользователя не работает злоумышленник, является двухфакторная аутентификация. В статьях моего коллеги https://habrahabr.ru/post/271259/ https://habrahabr.ru/post/271113/ описывается настройка MFA от Microsoft и Google для клиентского VPN. Способ хороший, но, во-первых, он требует наличия CISCO ASA, что не всегда легко реализуемо, особенно в бюджетных облаках, а во-вторых, работа через VPN неудобна. Работа с терминальной сессией через RDG значительно комфортнее, да и SSL протокол шифрования выглядит более универсальным и надежным, чем VPN от CISCO.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Должны быть доступны адреса по 443 порту:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На данном этапе связка 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 и нажимаем кнопку установить, следуем мастеру установки.

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

Данная служба необходима для взаимодействия мобильного приложения с сервером 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.

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

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

Добавляем 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 (файл установки располагается в папке 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) и привязать к аккаунту мобильное приложение. Заходим на портал под своей учетной записью и вводим ответы на секретные вопросы (они нам понадобятся в случае восстановления доступа к аккаунту).

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

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

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

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

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

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

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

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

Примечание: Если телефон оснащен датчиком отпечатка пальца, приложение 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 уведомления службе поддержки.

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

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

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