Настройка двухфакторной аутентификации на сервере 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

My Blog

Немного об ИТ и ИБ

Свежие записи

Свежие комментарии

• Denis к записи Zabbix 5.0 на Centos 8 с TimescaleDB и PostgreSQL
• evgen к записи Zabbix 5.0 на Centos 8 с TimescaleDB и PostgreSQL
• Denis к записи Zabbix 5.0 на Centos 8 с TimescaleDB и PostgreSQL
• Denis к записи Zabbix 5.0 на Centos 8 с TimescaleDB и PostgreSQL
• Александр к записи Zabbix 5.0 на Centos 8 с TimescaleDB и PostgreSQL

Архивы

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

Пароль является не очень надежным средством защиты. Очень часто используются простые, легко подбираемые пароли или же пользователи не особо следят за сохранностью своих паролей (раздают коллегам, пишут на бумажках и т.д.). В Microsoft уже давно реализована технология, позволяющая для входа в систему использовать SmartCard, т.е. аутентифицироваться в системе по сертификату. Но не обязательно использовать непосредственно смарт-карты, ведь для них нужны еще и считыватели, поэтому проще их заменить на usb токены. Они позволят реализовать двухфакторную аутентификацию: первый фактор — это пароль от токена, второй фактор — это сертификат на токене. Далее на примере usb токена JaCarta и домена Windows я расскажу как внедрить этот механизм аутентификации.

Первым делом в AD создадим группу «g_EtokenAdmin» и уч. запись «Enrollment Agent», входящую в эту группу. Эта группа и пользователь будут рулить центром сертификации.

Далее добавим серверу роль AD CA (центр сертификации).

Дополнительно установим Web службу для запроса сертификатов.

Далее выбираем вариант для предприятия. Выбираем Корневой ЦС (если у нас это первый центр сертификации в домене)
Создаем новый закрытый ключ. Длину ключа можно оставить туже, а вот алгоритм хеширования лучше выбрать SHA2 (SHA256).

Введем имя CA и выберем срок действия основного сертификата.
Остальные параметры оставляем по умолчанию и запускаем процесс установки.

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

Нас будут интересовать два шаблона: Агент регистрации (Enrollment Agent) и Вход со смарт-картой (Smartcard logon).
Зайдем в свойства этих шаблонов и на вкладке безопасность добавим группу «g_EtokenAdmin» с правами чтение и заявка.

Далее включим эти шаблоны.

И они появятся у нас в общем списке.

Следующим шагом настроим групповые политики:
Первым делом расскажем всем компьютерам домена о корневом центре сертификации, для этого изменим Default Domain Policy.
Конфигурация компьютера -> Политики -> Конфигурация Windows -> Параметры безопасности -> Политики открытого ключа -> Доверенные корневые центры сертификации -> Импорт

Выберем наш корневой сертификат, расположенный по пути: C:\Windows\System32\certsrv\CertEnroll. Закрываем Default Domain Policy.
На следующем шаге создадим политику для контейнера, в котором будут находится компьютеры с аутентификацией по токену (Смарт-карте).

По пути Конфигурация компьютера -> Политики -> Конфигурация Windows -> Параметры безопасности -> Локальные политики -> Параметры безопасности. Настроим два параметра «Интерактивный вход в систему: требовать смарт-карту» и «Интерактивный вход в систему: поведение при извлечении смарт-карты».

На этом с настройками все, теперь можно генерировать клиентский сертификат и проверять аутентификацию по токену.
Залогинемся на компьютере под учетной записью «Enrollment Agent» и откроем браузер, перейдя по ссылке http://Имя_сервера_MS_CA/certsrv

Выбираем пункт Запрос сертификата -> Расширенный запрос сертификата -> Создать и выдать запрос к этому ЦС
Если возникнет ошибка вида «Чтобы завершить подачу заявки на сертификат, следует настроить веб-узел для ЦС на использование проверки подлинности по протоколу HTTPS», то нужно на сервере IIS, на котором установлен MS CA, сделать привязку сайта к протоколу https.

Продолжим получение сертификата, для этого на открывшейся странице выберем шаблон: «Агент регистрации» и нажмем кнопку выдать и установить сертификат.

Теперь пользователь Enrollment Agent может выписывать сертификаты для других пользователей. К примеру запросим сертификат для пользователя test. Для этого откроем консоль управления сертификатами certmgr.msc, т.к. через web интерфейс не получится записать сертификат на usb токен.
В этой консоли на папке личное сделаем запрос от имени другого пользователя

В качестве подписи выбираем единственный сертификат «Enrollment Agent» и переходим к следующему шагу, на котором выбираем пункт «Вход со смарт-картой» и нажимаем подробности для выбора криптопровайдера.
В моем случае я использую токены JaCarta, поэтому вместе с драйверами был установлен криптопровайдер «Athena…»:

На следующем шаге выбираем доменного пользователя, для которого выписываем сертификат и нажимаем на кнопку «Заявка».

Вставляем токен, вводим пин код и начинается процесс генерации. В итоге мы должны увидеть диалоговое окно с надписью «Успешно».
Если процесс окончился неудачно, возможно дело в шаблоне получения сертификата, в моем случае его надо было немного подправить.

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

P.s.
1) Если не работает автоматическая блокировка компьютера или выход из системы, после вытаскивания токена, смотрите запущена ли служба «Политика удаления смарт-карт»
2) На токен можно записать (сгенерировать сертификат) только локально, через RDP не получится.
3) Если не получается запустить процесс генерации сертификата по стандартному шаблону «Вход с смарт-картой», создайте его копию с такими параметрами.

На этом все, если будут вопросы, задавайте, постараюсь помочь.

Protectimus DSPA

Двухфакторная аутентификация для
Active Directory, LDAP, баз данных

Что такое Protectimus DSPA?

Protectimus DSPA (Dynamic Strong Password Authentication) — это первое решение двухфакторной аутентификации для защиты учетных записей непосредственно в Active Directory и других хранилищах пользователей (LDAP, базы данных).

Смена паролей по расписанию

Компонент Protectimus DSPA для двухфакторной аутентификации в Active Directory меняет пароли пользователей в AD по расписанию. Интервал смены паролей задает администратор. При этом пароли Active Directory состоят из двух частей — статической (задается пользователем) и переменной (одноразовый пароль, сгенерированный по алгоритму TOTP). Такой пароль имеет вид: P@ssw0rd!459812.

On-premise платформа

Компонент Protectimus DSPA и платформа двухфакторной аутентификации Protectimus устанавливаются в окружении клиента. Вы можете контролировать все данные и процессы и обеспечить максимальный уровень защиты инфраструктуры от взлома. В on-premise платформе Protectimus предусмотрены мультидоменность, а также функционал кластера, репликаций и бэкапа.

Удобное администрирование

В отличие от традиционных решений MFA, Protectimus DSPA освобождает администратора от необходимости устанавливать на клиентские машины дополнительное ПО и периодически его обновлять. После интеграции компонента Protectimus DSPA с Active Directory, пароли пользователей с динамической частью будут автоматически запрашиваться для логина во все системы, связанные с AD (Winlogon, RDP, OWA и т.д.).

Какую проблему решает Protectimus DSPA?

1. Существующие решения MFA позволяют защитить только часть инфраструктуры

Все стандартные решения MFA добавляют двухфакторную аутентификацию только на конечных точках. Так у злоумышленника остается возможность атаковать вашу инфраструктуру, минуя двухфакторную аутентификацию и обращаясь к каталогу пользователей напрямую. Например, можно инициировать запрос прямо в Active Directory через командную строку Windows, и достаточно знать логин и пароль пользователя, чтобы выполнить операцию от его имени. Используя Protectimus DSPA, вы можете быть уверены, что из какой бы точки не приходил запрос в AD, без динамического пароля войти в учетную запись пользователя невозможно.

2. Необходимость установки и поддержки 2FA плагинов на различных платформах

Сейчас, чтобы настроить двухфакторную аутентификацию для всех сотрудников во всех сервисах, которые использует компания, администратор должен внедрить несколько 2FA плагинов для разных платформ и установить дополнительное ПО на каждой клиентской машине. Более того, все это ПО нужно постоянно обновлять. После интеграции компонента Protectimus DSPA с Active Directory, авторизация и аутентификация станет безопасной сразу во всех службах Microsoft. Динамические пароли будут запрашиваться во всех сервисах, которые обращаются к AD (Winlogon, RDP, ADFS, OWA и т.д.).

Как это работает?

Protectimus интегрируется прямо с хранилищем пользователей, как пример рассматривается двухфакторная аутентификация через Active Directory, и добавляет к статическим паролям приставку в виде 6 цифр — одноразовый пароль, который генерируется по алгоритму TOTP и постоянно меняется. Теперь чтобы получить доступ к Active Directory нужно ввести пароль вида: P@ssw0rd!459812, где P@ssw0rd! — постоянная часть, а 459812 — одноразовый пароль. Active Directory безопасность обеспечена.

Администратор задает интервал смены одноразовых паролей — от 30 секунд и более. Этот интервал должен быть кратным 30 секундам. Частоту смены пароля можно задать индивидуально для каждого пользователя. Также можно выбрать для какой группы пользователей будет применена строгая аутентификация на базе динамических паролей, а для какой нет. Компонент Protectimus DSPA регулярно производит изменения паролей пользователей, следуя заданному администратором расписанию. При этом меняются только последние 6 цифр.

Пользователи получают доступ к своим учетным записям, вводя в одну строку свой постоянный пароль и одноразовый код. Для генерации OTP пароля в данном случае можно использовать приложение Protectimus SMART, чат-бот в мессенджере Telegram, Viber, Facebook или специальные аппаратные токены для Protectimus DSPA.

OTP токены на выбор

Компонент Protectimus DSPA позволяет администратору задать любой интервал смены паролей, кратный 30 секундам, такой же функционал доступен в токенах Protectimus Smart OTP, Protectimus Bot и некоторых аппаратных токенах

Приложение Protectimus Smart OTP

Бесплатное приложение для двухфакторной аутентификации Protectimus Smart OTP, доступное на iOS и Android. При создании нового TOTP токена, пользователь может установить желаемый интервал времени кратный 30 секундам. Это позволяет использовать программный токен Protectimus Smart для двухфакторной аутентификации в Active Directory c помощью Protectimus DSPA.

Аппаратные токены

На данный момент клиентам Protectimus доступны аппаратные TOTP токены с интервалом генерации одноразовых паролей 30 и 60 секунд. Также разрабатываются классические TOTP токены с расширенным временным интервалом (600 секунд) и программируемые TOTP токены с возможностью задать любой секретный ключ и любой интервал времени (более 60 секунд).

Чат-боты в мессенджерах

Доставка одноразовых паролей через чат-боты Protectimus Bot в мессенджерах Telegram, Viber, Facebook Messenger. Этот вид программных токенов также доступен бесплатно и позволяет администратору настроить генерацию одноразовых паролей по алгоритму TOTP с любым интервалом времени. А значит, чат-боты — отличное средство аутентификации для Protectimus DSPA.

On-premise платформа или Частное облако

Перед внедрением компонента Protectimus Dynamic Strong Password Authentication, клиенту необходимо установить платформу двухфакторной аутентификации Protectimus в своем окружении или в частном облаке

On-premise платформа

On-premise платформа Protectimus поддерживает мультидоменность, доступен функционал кластера, репликаций и бэкапа. Использование on-premise платформы позволит вам полностью контролировать все данные, процессы, отказоустойчивость системы и уровень защиты сервера от взлома. Вы сможете выстроить систему защиты сервера аутентификации по своему усмотрению, использовать любые файерволы, полностью закрыть систему от внешнего доступа, использовать любые другие средства защиты. Перед развертыванием платформы аутентификации Protectimus на сервере должна быть установлена Java, JDK версии 8, а также установлена СУБД PostgreSQL, начиная с версии 10.

Частное облако

Сервер двухфакторной аутентификации Protectimus может быть развернут в частном облаке клиента. Независимо от того, где установлена платформа, в вашем окружении или в частном облаке, она поддерживает мультидоменность, функционал кластера, репликаций и бэкапа, а также позволяет вам полностью контролировать чувствительные данные и процессы. Перед развертыванием платформы аутентификации Protectimus в частном облаке, убедитесь, что настроенная вами облачная инфраструктура соответствует следующим техническим характеристикам: 2 Core (СPU), 8 GB (MEM); OS на всех Instance: Linux; Cloud Disk: 100GB; Load Balancer.

Как настроить?

Двухфакторная аутентификация в Active Directory с помощью Protectimus DSPA — инструкция по настройке

Установите ПО

Платформа аутентификации Protectimus и компонент Protectimus DSPA для Active Directory Security предоставляются по индивидуальному запросу по адресу support@protectimus.com

Создайте пользователя

Во вкладке “Пользователи” выберите «Добавить пользователя». Отметьте пользователя как «LDAP пользователь». Логин пользователя должен совпадать с CN пользователя в службе каталогов.

Создайте ресурс

Во вкладке “Ресурсы” выберите «Добавить ресурс». Отметьте ресурс как LDAP ресурс.

Назначьте пользователя

Во вкладке “Ресурсы” необходимо нажать “Назначить” -> “Пользователь”. На LDAP ресурс можно назначить только LDAP пользователя.

Активируйте Selfservice

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

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