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

В этой заметке будет рассмотрен пример настройки VPN-сервиса на базе Windows Server 2012 R2 с ролью Remote Access. Для повышения доступности VPN-сервиса в рассматриваемой далее конфигурации будет использоваться два виртуальных сервера (на базе Hyper-V) объединённых в NLB-кластер. Для повышения гибкости правил предоставления доступа к разным ресурсам локальной сети для VPN-клиентов на стороне VPN-серверов будет выполнена привязка схемы аутентификации к расположенным в локальной сети RADIUS серверам (на базе Network Policy Server). Для повышения безопасности VPN-соединений в качестве основного протокола будет использоваться L2TP/Ipsec с использованием цифровых сертификатов. Двухфакторная аутентификация будет основана на проверке сертификата и доменной учетной записи пользователя

Среда исполнения

В рассматриваемом примере будет создан Windows NLB кластер из двух виртуальных серверов одинаковой конфигурации на базе Hyper-V из Windows Server 2012 R2 Datacenter EN. На виртуальных серверах устанавливается Windows Server 2012 R2 Standard EN.

Каждый из виртуальных серверов будет иметь по два сетевых интерфейса, настройка которых будет рассмотрена далее.

Серверам присвоены имена – KOM-AD01-VPN01 и KOM-AD01-VPN02.

Создаваемый в процессе описания NLB-кластер будет использовать имя KOM-AD01-VPNCL.

В качестве поставщика аутентификации будут использоваться два отдельных сервера внутри локальной сети с заранее установленной и настроенной ролью Network Policy and Access Services (RADIUS) с именами KOM-AD01-NPS01 и KOM-AD01-NPS02.

Аутентификация для протокола L2TP/IPsec с использованием сертификатов потребует наличия Доменного или Автономного Центра сертификации (ЦС) для создания цифровых сертификатов для VPN-клиентов. В рассматриваемой конфигурации а качестве Автономного ЦС будет использоваться отдельный сервер внутри локальной сети с именем KOM-AD01-CA01  

Упрощённая схема взаимодействия компонент конфигурации будет выглядеть следующим образом:

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

Так как планируемая конфигурация получается многокомпонентной, то во избежание лишних сложностей, мы не будем пытаться настроить весь функционал сразу. Вместо этого мы сначала настроим базовый функционал PPTP VPN и протестируем его. Если на этом этапе проблем выявлено не будет, следующим этапом приступим к связке сервера VPN c RADIUS, и снова проверим результат. В случае успешной проверки авторизации через RADIUS перейдём к настройке VPN-сервера и VPN-клиентов для поддержки протокола L2TP/IPsec. Снова проверим результат, и в случае успеха перейдём к окончательному этапу – созданию второго VPN-сервера аналогичной конфигурации и построению NLB-кластера из двух VPN-серверов. Таким образом, план развёртывания конфигурации будет следующим:

1. Настройка первого VPN-сервера (KOM-AD01-VPN01)
1.1. Настройка виртуальной машины
1.2. Установка роли Remote Access
1.3. Настройка службы Routing and Remote Access
1.4. Настройка правил Windows Firewall
2. Проверка подключения по протоколу PPTP
3. Создание доменных групп доступа
4. Работа с серверами NPS/RADIUS
4.1. Создание основной сетевой политики на сервере NPS
4.2. Создание дополнительной сетевой политики NPS для PPTP-подключений
4.3. Добавление информации о VPN-сервере на сервер RADIUS
5. Привязка VPN-сервера к серверам RADIUS
6. Проверка подключения по протоколу PPTP с использованием RADIUS
7. Работа с сертификатами
7.1. Установка корневого сертификата ЦС на VPN-сервере и клиенте.
7.2. Создание сертификата VPN-сервера
7.3. Создание сертификата VPN-клиента
8. Проверка подключения VPN-клиента из Интернет по протоколу L2TP/IPSec
9. Настройка второго VPN-сервера (KOM-AD01-VPN02)
10. Создание NLB-кластера из двух VPN-серверов
11. Проверка работы NLB-кластера
12. Разработка инструкций для пользователей.

1. Настройка первого VPN-сервера (KOM-AD01-VPN01)

1.1 Настройка виртуальной машины

Устанавливаем на виртуальный сервер ОС Windows Server 2012 R2 Standard EN и все последние обновления Windows Update.

Виртуальный сервер имеет два сетевых контроллера. В ОС условно назовём относящиеся к этим контроллерам сетевые интерфейсы — LAN и WAN. Интерфейс LAN будет смотреть в локальную сеть (либо в DMZ) и настроен следующим образом:

Шлюз по умолчанию на интерфейсе LAN не указываем.

Интерфейс WAN будет направлен в Интернет. В свойствах интерфейса желательно выключить все компоненты кроме TCP/IPv4. Шлюз по умолчанию задан. 

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

route -p ADD 10.0.0.0 MASK 255.0.0.0 10.160.20.1
route PRINT

1.2. Установка роли Remote Access

Открываем оснастку Server Manager, выбираем область настроек Local Server, в верхнем меню выбираем Manage > Add Roles and Features. В мастере добавления ролей выбираем тип установки на основе ролей — Role-based or feature-based installation

Далее выбираем сервер из пула серверов…

На шаге выбора ролей включаем роль Remote Access

Шаг Features пропускаем без внесения изменений.
На шаге выбора служб включаемой роли выберем службу DirectAccess and VPN (RAS)

При этом откроется окно добавления дополнительных компонент связанных с выбранной службой. Согласимся с их установкой нажав Add Features

Роль Web Server Role (IIS) будет при этом добавлена в мастер добавления ролей. Соответствующий появившийся шаг мастера  Web Server Role (IIS) и зависимые опции Role Services пропускаем с предложенными по умолчанию настройками и запускаем процесс установки, по окончании которого будет доступна ссылка на мастер первоначальной настройки служб Remote Access – Open the Getting Started Wizard

Можно вызвать мастер настройки RAS щёлкнув по соответствующей ссылке здесь, либо позже из оснастки Server Manager:

Так как настройка DirectAccess в контексте нашей задачи не нужна, в окне мастера выбираем вариант конфигурирования только VPN – Deploy VPN only

1.3. Настройка службы Routing and Remote Access

Из Панели управления открываем оснастку Administrative Tools Routing and Remote Access, выбираем в дереве навигации имя сервера и открываем контекстное меню. Выбираем пункт Configure and Enable Routing and Remote Access

Откроется окно мастера Routing and Remote Access Server Setup Wizard, в котором мы выбираем пункт Custom configuration 

На следующем экране мастера включаем службу VPN access.

На следующем экране нажимаем кнопку Finish и соглашаемся с предложением запуска службы – нажимаем кнопку Start service

После этого в консоли Routing and Remote Access снова выбираем наш сервер и, открыв контекстное меню, выбираем пункт Properties

В открывшемся окне свойств на закладке General убеждаемся в том, что включена маршрутизация IPv4 Router – LAN and demand-dial routing, а также активен функционал сервера удалённого доступа – IPv4 Remote access server  

Переключимся на закладку Security и посмотрим настройки аутентификации по умолчанию. Не будем их пока менять (вернёмся к ним позже). Использование провайдера аутентификации Windows Authentication в доменной среде подразумевает то, что к серверу удалённого доступа смогут подключиться любые доменные пользователи, у которых в свойствах учетной записи включено право удалённого доступа (проверить это можно в оснастке Active Directory — Users and Computers для учетной записи доменного пользователя на закладке Dial-In параметр Network Access Permission должен быть определён как Allow access)

Далее переключимся на закладку IPv4 и включим опцию пересылки трафика – Enable IPv4 Forwarding, чтобы наш VPN-сервер смог пересылать трафик VPN-клиентов в локальную сеть и обратно.

В свойстве назначения IP адресов подключающимся VPN-клиентам выберем использование статического пула — Static address pool (это рекомендуемая конфигурация в случае если мы планируем использовать несколько VPN-серверов в кластере NLB). Выделим для VPN-клиентов отдельную подсеть класса “C”, например 10.160.50.0/24. Так как мы планируем использовать два VPN-сервера, разделим эту подсеть на две непересекающихся части. Первую половину сети пропишем на этом VPN-сервере, вторую в дальнейшем на втором VPN-сервере.

Отключим опцию Enable broadcast name resolution, чтобы отбросить широковещательные запросы VPN-клиентов. В нижнем параметре Adapter (сетевой интерфейс, с которого клиентам будут выдаваться настройки DNS) выберем интерфейс LAN.

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

Весть трафик предназначенный для сети 10.160.50.0/25 отправлять на хост 10.160.20.11

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

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

Вернёмся в консоль, выберем узел Ports и в контекстном меню выберем Properties. Здесь мы сможем выполнить настройку допустимого количества портов, на которые смогут подключаться VPN-клиенты для каждого отдельно взятого протокола.

Как видим, в конфигурации по умолчанию создано множество портов для разных VPN-протоколов. В нашем примере будет использоваться только 2 протокола – PPTP и L2TP. Основным протоколом для VPN-соединений будет L2TP с количеством портов не более, чем количество ранее выделенных в статическом пуле IP адресов. Вспомогательным протоколом будет PPTP с ограниченным количеством портов, например от 1 до 3. Протокол PPTP будет использоваться исключительно для разовых кратковременных соединений, необходимых VPN-клиентам для подключения к серверу Центра сертификации и получения сертификата компьютера, необходимого для дальнейшей настройки L2TP/Ipsec подключения. Для начала настроим протокол PPTP, выбрав его из списка и нажав кнопку Configure   

В открывшемся окне в параметре Maximum ports введём ограниченное количество портов.

По аналогии настроим порты для протокола L2TP указав максимально возможное количество  клиентских подключений, например 125, исходя из того, что на данный сервер ранее нами выделена половина сети класса “C”. Для всех других протоколов, которые мы не планируем настраивать и использовать, например SSTP или IKEv2, лучше вообще обнулить значение количества портов.

В конечном итоге мы получим примерно такую настройку портов:

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

1.4. Настройка правил Windows Firewall

Так как в нашем случае сервер имеет прямое подключение к сети Интернет, очень важно выполнить максимально строгую настройку правил Windows Firewall. Выключаем бОльшую массу правил включённых по умолчанию. Оставляем включёнными лишь правила относящиеся к службам RAS по портам, которые будут нами использоваться. Правила удалённого доступа к серверу по таким протоколам как WinRM и RDP ограничиваем профилем Domain и диапазоном локальной сети, из которого разрешается удалённый доступ к серверу.

Описание правил фаервола необходимых для работы того или иного VPN-трафика можно найти в документе Configure a Firewall for VPN Traffic, а также в блоге  Routing and Remote Access Blog —  Which ports to unblock for VPN traffic to pass-through?. Согласно этим документам, к представленным по умолчанию в системе правилам, которые появляются после установки роли Remote Access, нам нужно ещё дополнительно открыть порты UDP 500 и 4500. Добавим два разрешающих правила для фаервола с помощью PowerShell:

New-NetFirewallRule -DisplayName "Routing and Remote Access (Allows IKE traffic to the VPN server)" -Direction "Inbound" -Protocol "UDP" -Action "Allow" -LocalPort "500"

New-NetFirewallRule -DisplayName "Routing and Remote Access (Allows IPsec NAT-T traffic from the VPN client to the VPN server.)" -Direction "Inbound" -Protocol "UDP" -Action "Allow" -LocalPort "4500"

2. Проверка подключения VPN-клиента по протоколу PPTP

На данном этапе первоначальная настройка первого VPN-сервера выполнена и он уже готов принимать клиентские подключения. Поэтому теперь можно проверить подключение по протоколу PPTP. Согласно описанной нами конфигурации, сделать это можно в том числе и с клиентского компьютера внутри локальной сети. Пошаговое описание процесса создания VPN-подключения на клиенте под управлением Windows можно найти в п.12 данной статьи. После того как на клиентском компьютере VPN-подключение создано, откроем его свойства и на закладке “Безопасность” выберем тип VPN – PPTP 

На закладке “Сеть” выберем протокол TCP/IPv4 и откроем его “Свойства”

В окне свойств нажмём кнопку “Дополнительно” и отключим опцию “Использовать основной шлюз в удалённой сети”. Это нужно сделать для того, чтобы при подключении с клиента локальной сети у нас не возникло проблем с уже работающими сетевыми приложениями на клиентском компьютере во время проведения теста подключения.

Сохраним изменения и попробуем выполнить подключение к VPN-серверу.

Если проверка подключения из локальной сети прошла успешно, можно протестировать подключение с внешнего VPN-клиента из Интернет также по протоколу PPTP. Таким образом мы убедимся в том, что правила Windows Firewall на VPN-сервере настроены правильно и служба RAS успешно выполняет подключение VPN-клиентов, выдаёт им при этом правильные настройки IP, и корректно маршрутизирует трафик от VPN-клиента в локальную сеть и обратно. Если все указанные проверки прошли успешно, можно продолжить работу по плану и перейти к настройке интеграции VPN-сервера с сервером RADIUS.

3. Создание доменных групп доступа

Для дальнейшей настройки аутентификации VPN-клиентов через RADIUS нам потребуется создать в домене Active Directory (AD) группу безопасности, в которую будут включены учетные записи пользователей, которым мы хотим предоставить доступ к VPN. В нашем примере это будет доменная локальная группа безопасности KOM-AD01-SRV-NPS-VPN-Users 

В дальнейшем, для предоставления какому-либо пользователю домена доступа к VPN, его учетную запись будет достаточно включить в эту группу безопасности. При этом мы настроим сервер RADIUS таким образом, что пользователь сможет подключаться к VPN вне зависимости от того, каким образом выставлены ранее упомянутые настройки в свойствах его учетной записи в AD на закладке Dial-In.

4. Работа с серверами NPS/RADIUS

Как уже отмечалось в самом начале, мы будем использовать возможности служб Network Policy Server (NPS) для того, чтобы более гибко управлять параметрами подключения VPN-клиентов. Для этой цели на каждом RADIUS-сервере мы создадим по две сетевые политики (Network Policy). Первая политика будет использоваться как основная для всех клиентов. Вторая политика будет применяться к клиентам в том случае, если они используют подключение по протоколу PPTP и будет иметь ряд настроек, которые будут жёстко ограничивать VPN-сессии такого рода. Далее мы рассмотрим соответствующую настройку RADUS сервера на примере сервера KOM-AD01-NPS01. На втором сервере KOM-AD01-NPS02 вся настройка должна быть выполнена абсолютно также как и на первом.

4.1. Создание основной сетевой политики на сервере NPS

На сервере KOM-AD01-NPS01 открываем оснастку Administrative Tools Network Policy Server. В дереве навигации оснастки выбираем пункты NPS >  Policies > Network Policies. Открываем контекстное меню (либо меню действий Action в главном меню) и выбираем пункт New.

Откроется мастер создания новой сетевой политики New Network Policy

Вводим имя политики, например KOM-AD01-SRV-NPS-VPN-Users Policy, и выбираем тип соединения Type of network access server — Remote Access Server (VPN-Dial up)

На следующем шаге мастера Specify Conditions нажимаем Add, чтобы добавить новое условие для применения политики. В открывшемся окне выбора условий найдём User Groups и нажмём Add.

Затем нажмём Add Groups и введём имя доменной группы безопасности, которую мы создали ранее в п.3 (KOMKOM-AD01-SRV-NPS-VPN-Users).

Перейдём к следующему шагу мастера Specify Access Permission где определим, что данная политика является разрешающей доступ, выбрав пункт Access granted

Параметр Access is determined by User Dial-in properties (which override NPS policy) оставим без изменений, так как работает он в этом мастере как-то не совсем вменяемо. Заметил это не только я один, но есть тому и другие свидетельства, например NPS new Network Policy wizard incorrectly sets «Ignore User Dial-In Properties». После создания политики мы вернёмся в её свойства и выполним дополнительную соответствующую настройку.

На следующем шаге Configure Authentication Methods обозначим методы аутентификации доступные для подключающихся VPN-клиентов, подпадающих под правила обозначенные ранее (в нашем случае это пока только членство в доменной группе безопасности).

Убедимся в том, что включён метод MS-CHAP-v2 и отключим прочие устаревшие и менее безопасные методы аутентификации, такие как MS-CHAP

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

На следующем шаге мастера Configure Settings в разделе настроек Encryption оставим включенным шифрование MPPE 128-bit и MPPE 56-bit (при необходимости). В большинстве случаев рекомендуется оставлять включённым только шифрование максимально возможной силы (MPPE 128-bit), но если будут проблемы с подключением каких-то устаревших клиентов, то возможно потребуется включить и менее слабые методы шифрования. Например, если планируется подключение клиентов на базе Windows XP, то при использовании протокола L2TP/Ipsec возможно потребуется включение поддержки 56-битного шифрования. Практические эксперименты с VPN-клиентом на базе Windows XP, настроенным в конфигурации по умолчанию подтвердили это.

На финальном шаге Completing New Network Policy ещё раз проверим все настройки, которые будут включены в создаваемую политику, и нажмём Finish

Открываем свойства только что созданной политики и на первой закладке Overview включим опцию Ignore user account dial-in properties

Таким образом, возможность удалённого подключения будет регулироваться условиями данной политики NPS, даже несмотря на то, как настроены параметры удалённого входа в свойствах учётной записи пользователя в AD на закладке Dial-in

То есть, в данном примере, пользователь Петя Резинкин сможет подключиться в VPN, даже не смотря на то, что в свойствах его доменной учетной записи выбрана опция Deny access, при условии, что эта учетная запись включена в ранее указанную в политике доменную группу безопасности KOMKOM-AD01-SRV-NPS-VPN-Users.

***

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

4.2. Создание дополнительной сетевой политики NPS для PPTP-подключений

Созданная ранее сетевая политика будет использоваться как основная политика “по умолчанию” для всех подключающихся VPN клиентов. Как уже было сказано ранее, наша конфигурация подразумевает то, что VPN-клиенты в качестве основного протокола будут использовать L2TP/Ipsec, а для его первоначальной настройки каждому клиенту хотя бы один раз потребуется кратковременная PPTP-сессия. PPTP-сессия в нашем случае нужна для того, чтобы подключиться клиенту к одному единственному ресурсу локальной сети – Центру сертификации для получения сертификата для клиентского компьютера. Так как протокол PPTP является более устаревшим и менее защищённым чем L2TP/Ipsec, нам нужно на сервере NPS (RADIUS) создать ещё одну сетевую политику, с помощью которой будут заданы жёсткие ограничения для PPTP соединений. То есть, в рамках нашей задачи, любая PPTP-сессия будет разрешать трафик исключительно до нескольких хостов локальной сети (Сервер ЦС и DNS-серверы) и будет при этом ограничена по времени, которого достаточно для того, чтобы сформировать запрос на получение сертификата в ЦС и получение автоматически выданного цифрового сертификата клиентского компьютера.

Итак, создадим дополнительную сетевую политику и присвоим ей имя, например KOM-AD01-SRV-NPS-VPN-Users Policy (PPTP). При создании политики в качестве дополнительного условия на шаге мастера Specify Conditions добавим условие по типу туннеля Tunnel Type равное значению Point-to-Point Tunneling Protocol (PPTP).

На шаге мастера Configure Constraints в разделе Session Timeout включим признак разрыва сессии по истечении определённого времени — Disconnect after the following maximum time. Укажем значение, например, в 30 минут. Этого времени более чем достаточно для получения сертификата из ЦС.

Далее, на следующем шаге мастера Configure Settings в разделе настроек IP Filters нажмём кнопку Input Filters, чтобы настроить фильтрацию трафика поступающего от VPN-клиента в сторону локальной сети

В открывшемся окне создадим правила, согласно которых мы разрешаем доступ VPN-клиента по всем портам к серверу ЦС (для запроса и получения сертификата), а также трафик по протоколу UDP и порту 53 к DNS-серверам локальной сети (для работы механизма разрешения имён хостов локальной сети).

После того, как политика создана, настроим приоритет обработки политик таким образом, чтобы только что созданная политика для PPTP соединений (KOM-AD01-SRV-NPS-VPN-Users Policy (PPTP)) имела более высокий приоритет, то есть обрабатывалась бы RADIUS-сервером раньше, чем основная политика для VPN-клиентов по умолчанию (KOM-AD01-SRV-NPS-VPN-Users Policy).

Таким образом, если любой VPN-клиент подключится по протоколу PPTP, то его сессия будет иметь выше-обозначенные ограничения и будет пригодна только для процедуры получения цифрового сертификата, необходимого для последующих полноценных L2TP/Ipsec подключений.

4.3. Добавление информации о VPN-сервере на сервер RADIUS

Политики сетевого доступа для VPN-клиентов на сервере NPS созданы, но для того, чтобы VPN-серверы могли обращаться к серверам RADIUS как поставщику аутентификации и обрабатываться созданными политиками, нам необходимо прописать эти VPN-серверы в качестве клиентов RADUIS. Для этого в консоли Network Policy Server в дереве навигации откроем узел NPS >  RADIUS Clients and Servers > RADIUS Clients. В меню действий выберем New.

В окне добавления нового клиента RADIUS на закладке Settings укажем полное доменное имя нашего VPN-сервера (тут же проверим, что оно успешно разрешается в IP с помощью кнопки Verify) и в ручную укажем пароль Shared secret для установления безопасного соединения между клиентом и сервером RADIUS. Запомним этот пароль, так как он понадобиться нам на следующем этапе настройки VPN-сервера.

На закладке Advanced оставим настройки предложенные по умолчанию.

Аналогичный образом создадим на RADIUS сервере запись о втором VPN-сервере…

Если у нас более одного сервера RADIUS, дублируем информацию о клиентах RADIUS (VPN-серверах) с идентичными настройками на дополнительных серверах.

5. Привязка VPN-сервера к серверам RADIUS

Теперь нам нужно выполнить настройку наших VPN-серверов для использования RADIUS аутентификации выполнив привязку к ранее настроенным RADIUS-серверам. Возвращаемся на VPN-сервер в консоль Routing and Remote Access, снова выбираем наш сервер и, открыв контекстное меню, выбираем пункт Properties. На закладке Security меняем поставщиков Authentication provider и Accounting provider на RADIUS Authentication и RADIUS Accounting соответственно. Чтобы задать параметры соединения с серверами RADIUS нажимаем кнопку Configure

Добавляем информацию о серверах RADIUS. Как минимум, указываем для каждого из них имя Server name и Shared secret заданным нами ранее в п.4.3

Закрываем все окна сохранив изменения.

6. Проверка подключения по протоколу PPTP с использованием RADIUS

На данном этапе можно проверить подключение VPN-клиента по протоколу PPTP, но теперь уже с  использованием аутентификации и авторизации на сервере RADIUS. Информацию о событиях подключения VPN-клиентов теперь можно будет увидеть в event-log серверов RADIUS. Если подключение и аутентификация VPN-клиента проходит успешно, переходим к следующему этапу.

7. Работа с сертификатами

Следующим этапом настройки мы приступим к подготовке нашего VPN-сервера и VPN-клиентов к использованию протокола L2TP/IPSec. Создадим цифровые сертификаты, которые будут использоваться для установления безопасного шифрованного соединения между клиентом и сервером. Как на VPN-сервер, так и на VPN-клиента нам нужно будет установить сертификат компьютера, выпущенный одним и тем же доверенным Центром сертификации. В нашем случае будет использоваться автономный (Standalone) Центр сертификации.

7.1. Установка корневого сертификата ЦС на VPN-сервере и VPN-клиенте

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

Скачиваем файл корневого сертификата ЦС во временный каталог на текущий компьютер (VPN-клиент или VPN-сервер):

certutil -f -config "kom-ad01-ca01.holding.comKOMI Root CA" -ca.cert "C:TempCertificateRootCA.cer"

В ответ мы должны получить содержимое сертификата примерно в следующем виде:

Сертификат ЦС[1]: 3 -- Действителен
Сертификат ЦС[1]:
-----BEGIN CERTIFICATE-----
MIIERzCCAy+gAwIBAgQEy0HgbIqB4Z5XG5qXCjlcDANBgkqhkiG9w0BAQUFADBh
...
jxwM6bUY8kB3SvzBxQX1FZiPb+n219qJwq3gWeu6MysXrfShENeqFpgfyCaSpFy
UdGgqkXUdNZ1R/rc3g8KowOYfWFn8928QuQo2Up7KneEIsZZne6k5Mqjg==
-----END CERTIFICATE-----

CertUtil: -ca.cert — команда успешно выполнена.

Устанавливаем загруженный файл корневого сертификата в хранилище Доверенные корневые центра сертификации (Trusted Root Certification Authorities) хранилища Локальный компьютер (эту операцию нужно выполнять с правами администратора):

certutil -addstore Root  "C:TempCertificateRootCA.cer"

В ответ мы должны получить информацию об успешной установке сертификата ЦС

Root "Доверенные корневые центры сертификации"
Подпись соответствует открытому ключу
Сертификат "KOMI Root CA" добавлен в хранилище.
CertUtil: -addstore — команда успешно выполнена.

Запускаем консоль mmc.exe, и загружаем оснастку управления сертификатами. Для этого выбираем в меню File > Add/Remove Snap-In. В списке оснасток выбираем Certificates > нажимаем Add > выбираем Computer account > выбираем Local computer

Убеждаемся в том, что в контейнере Trusted Root Certification AuthoritiesCertificates отображается корневой сертификат нашего ЦС.

7.2. Создание сертификата VPN-сервера

Сертификат, который мы будем создавать для каждого VPN-сервера, должен содержать в расширениях «Улучшенный ключ» цели «Проверка подлинности сервера» (OID — 1.3.6.1.5.5.7.3.1) и «Проверка подлинности клиента» (OID — 1.3.6.1.5.5.7.3.2)

Нижеописанные манипуляции нужно проводить непосредственно с сервера VPN.

Для генерации запроса на получение сертификата от ЦС, создаём во временном каталоге, например C:Temp, конфигурационный файл RequestConfigVPNServer.inf со следующим содержимым:

[Version]
Signature="$Windows NT$"

[NewRequest] 
Subject = "CN=KOM-AD01-VPNCL.holding.com"
Exportable = TRUE; Private key is exportable
KeyLength = 2048
KeySpec = 1
KeyUsage = 0xf0; Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment
MachineKeySet = TRUE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
RequestType = PKCS10

[EnhancedKeyUsageExtension] 
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
OID=1.3.6.1.5.5.7.3.2 ; Client Authentication
OID=1.3.6.1.5.5.8.2.2 ; IP Security IKE intermediate
  
[RequestAttributes] 
SAN  = "dns=KOM-AD01-VPNCL.holding.com&" 
_continue_ = "dns=KOM-AD01-VPN01.holding.com&" 
_continue_ = "dns=KOM-AD01-VPN02.holding.com&"  

Параметр Exportable = TRUE определяет то, что для генерируемого сертификата возможен будет экспорт закрытого ключа. В таком виде этот параметр стоит использовать лишь в том случае, если вы хотите использовать один сертификат на нескольких VPN-серверах, во всех остальных случаях желательно использовать значение вида Exportable = FALSE. 

Генерируем файл запроса на основе конфигурационного файла:

certreq -new -f "C:TempRequestConfigVPNServer.inf" "C:TempRequestBinaryVPNServer.req"

Получаем ответ, что запрос создан и сразу отправляем этот запрос в ЦС. В зависимости от того, как настроен ЦС на автоматическое одобрение, можно использовать один из описанных далее вариантов отправки в ЦС запроса и получения сертификата…

***

Вариант А (в случае если автоматическая выдача сертификатов в ЦС выключена)

Выполняем отправку запроса сертификата в ЦС:

certreq –submit –f -config "kom-ad01-ca01.holding.comKOMI Root CA" "C:TempRequestBinaryVPNServer.req"

В ответ мы получим примерно следующее:

Код запроса (RequestId): 31
Код запроса: "31"
Запрос сертификата в ожидании: Taken Under Submission (0)

Как видим, RequestId выведен нам на консоль с сообщением, означающим то, что наш запрос переведён в ожидание одобрения администратором ЦС. Запомним номер RequestId.
На этом этапе администратор ЦС выполняет одобрение на генерацию сертификата по полученному запросу. После этого мы можем выполнить загрузку сертификата из ЦС (31 в данном примере это и есть RequestID):

certreq -retrieve -f -config "kom-ad01-ca01.holding.comKOMI Root CA" 31 "C:TempCertificateVPNServer.cer"

В ответ мы должны получить сообщение об успешной загрузке сертификата:

Код запроса (RequestId): 31
Код запроса: "31"
Получен сертификат(Выдан) Issued  Resubmitted by KOMadm-artur

***

Вариант Б (в случае если автоматическая выдача сертификатов в ЦС включена)

Выполняем отправку запроса сертификата в ЦС и сразу указываем куда будет сохранён автоматически полученный готовый сертификат:

certreq –submit –f -config "kom-ad01-ca01.holding.comKOMI Root CA" "C:TempRequestBinaryVPNServer.req" "C:TempCertificateVPNServer.cer"

В ответ мы получим примерно следующее сообщение говорящее об успешной автоматической выдаче сертификата:

Код запроса (RequestId): 31
Код запроса: "31"
Получен сертификат(Выдан) Issued

Как видим, с включённым механизмом автоматической выдачи сертификатов в ЦС процесс намного проще.

***

После того, как сертификат загружен (любым из перечисленных выше способов) выполняем его установку:

certreq -accept "C:TempCertificateVPNServer.cer"

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

7.3. Создание сертификата VPN-клиента

Сертификат компьютера, который мы будем создавать для каждого VPN-клиента, как минимум, должен содержать в расширениях «Улучшенный ключ» цель «Проверка подлинности клиента» (OID — 1.3.6.1.5.5.7.3.2)

[Version]
Signature="$Windows NT$"

[NewRequest] 
Subject = "CN=KOM-AD01-WS001.holding.com" ; 
Exportable = FALSE; Private key is not exportable 
KeyLength = 2048
KeySpec = 1
KeyUsage = 0xf0; Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment 
MachineKeySet = TRUE 
ProviderName = "Microsoft RSA SChannel Cryptographic Provider" 
RequestType = PKCS10

[EnhancedKeyUsageExtension] 
OID=1.3.6.1.5.5.7.3.2 ; Client Authentication

Параметр определяющий возможность экспорта закрытого ключа для всех VPN-клиентов — выключаем. Этим самым мы ограничим возможность “утечки” сертификата с закрытым ключом с клиентского компьютера. Команды запроса и установки сертификата на VPN-клиенте в ручном режиме аналогичны п.7.2. В результате подобного запроса к ЦС, будет выдан соответствующий сертификат клиента, который после установки на клиентский компьютер должен говорить нам о наличии закрытого ключа.

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

Пример командного файла Install Certificate.cmd:

set vSubject=%COMPUTERNAME%
set vCAPath="kom-ad01-ca01.holding.comKOMI Root CA"

set vTempPath=%SystemDrive%TempVPNCertFiles
set vRequestInf=%vTempPath%RequestConfigVPNClient.inf
set vRequestBin=%vTempPath%RequestBinaryVPNClient.req
set vCert=%vTempPath%CertificateVPNClient.cer

mkdir %vTempPath%

rem Get the CA's cert
certutil -f -config %vCAPath% -ca.cert %vTempPath%CertificateRootCA.cer

rem Move the CA's cert to the "Trusted Root Authorities" store
certutil -f -addstore Root  %vTempPath%CertificateRootCA.cer

rem Create an INF request file
del %vRequestInf%
echo [Version]                    > %vRequestInf%
echo Signature="$Windows NT$"    >> %vRequestInf%
echo [NewRequest]                >> %vRequestInf% 
echo Subject="CN=%vSubject%"     >> %vRequestInf% 
echo Exportable=FALSE            >> %vRequestInf%
echo KeyLength=2048              >> %vRequestInf%
echo KeySpec=1                   >> %vRequestInf%
echo KeyUsage=0xf0               >> %vRequestInf%
echo MachineKeySet=TRUE          >> %vRequestInf%
echo ProviderName="Microsoft RSA SChannel Cryptographic Provider" >> %vRequestInf%
echo RequestType=PKCS10          >> %vRequestInf%
echo [EnhancedKeyUsageExtension] >> %vRequestInf% 
echo OID=1.3.6.1.5.5.7.3.2       >> %vRequestInf%

rem Create a binary request file from the INF
del %vRequestBin%
certreq -new -f %vRequestInf% %vRequestBin%

rem Submit the request to our CA and save the certificate
certreq -submit -f -config %vCAPath% %vRequestBin% %vCert%

rem This step needed to import the private key.  Also puts the certificate in the local computer personal store.
certreq -accept %vCert%

rem Clear files
rmdir /s /q %vTempPath%

В качестве предварительных условий для работы командного файла должно быть соблюдено, как минимум, два условия:
1) Перед запуском командного файла пользователь должен установить VPN-соединение по протоколу PPTP (для доступности ЦС из локальной сети);
2) Командный файл нужно выполнять на клиентском компьютере с правами администратора (для возможности добавления сертификата в хранилище “Локальный компьютер”)

Работа приведённого примера командного файла без дополнительных условий может использоваться (была проверена) на Windows 8/8.1, Windows 7 SP1, Windows Vista SP2.

Для клиентов же Windows XP, как всегда, всё несколько сложнее. В частности, для Windows XP SP3, согласно статьи KB934576 — Auto-enrollment is not triggered when you try to use Certutil.exe on a Windows XP-based computer, для успешной работы командного файла потребуется наличие трёх дополнительных файлов из состава Windows Server 2003 Administration Pack: certutil.exe, certreq.exe и certadm.dll , так как этих файлов нет в базовом составе ОС.

Помимо этого, на сервере выполняющем роль ЦС, если он работает под управлением Windows Server 2012/2012 R2, согласно документа, потребуется понизить уровень безопасности для обработки процедуры запросов на выдачу для клиентов на Windows XP. Описание того, как это можно сделать, можно найти в одной из прошлых заметок.

Дополнительно для Windows XP потребуется убрать из командного файла строчку

echo ProviderName="Microsoft RSA SChannel Cryptographic Provider" >> %vRequestInf%

В конечном итоге, можно либо дальше расширять логику командного файла для разного алгоритма работы на различных версиях Windows, либо попросту создать готовые командные файлы под каждую версию клиентской ОС Windows. Например, для пользователей, у которых на домашнем компьютере установлена Windows XP должен поставляться  следующий набор файлов:

А, например, для пользователей, у которых на домашнем компьютере установлена Windows 8/8.1 будет другой набор файлов, состоящий фактически только из соответствующего командного файла и пошаговой инструкции для пользователя по настройке VPN подключения:

8. Проверка подключения VPN-клиента из Интернет по протоколу L2TP/IPSec

Меняем настройки VPN-подключения на клиентском компьютере на использование протокола L2TP/Ipsec и проверяем подключение из Интернет.

В случае проблем с подключением, изучаем event-логи на VPN-сервере, а также на сервере RADIUS, так как теперь все события связанные с процедурами аутентификации и авторизации фиксируются именно там.

Если подключение к первому настроенному VPN-серверу по протоколу l2TP/Ipsec прошло успешно, то можно приступить к следующему этапу расширения конфигурации. 

9. Настройка второго VPN-сервера (KOM-AD01-VPN02)

Настройку второго VPN-сервера с именем KOM-AD01-VPN02 выполняем по аналогии с первым VPN-сервером.

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

Не забываем прописать данные второго VPN-сервера на серверах RADIUS и отдельно протестировать возможность подключения к этому VPN-серверу сначала по протоколу PPTP, затем по протоколу L2TP/Ipsec. Если в итоге мы смогли убедиться в том, что VPN-подключения успешно работают для обоих VPN-серверов по отдельности, то настало время собрать их в кластер.

10. Создание NLB-кластера из двух VPN-серверов

Отправной документ для построения кластера здесь: Deploy Remote Access in a Cluster
Планирование описано в документе Plan a Remote Access Cluster Deployment
Конфигурирование кластера описано в документе Configure a Remote Access Cluster

***

Первым делом обратим внимание на то, что в свойствах виртуальных машин Hyper-V, в которых работают наши VPN-серверы, которые мы хотим сделать членами NLB кластера, для сетевого адаптера WAN необходимо разрешить спуфинг МАС адресов (Enable spoofing of MAC addresses). Именно этот сетевой адаптер мы будем делать членом NLB-кластера.

***

Затем создаём во внешней зоне DNS статическую А-запись для будущего NLB кластера:

<

p align=»center»>***
Далее, с помощью PowerShell установим на оба VPN-сервера исполняемые компоненты NLB

Import-Module "ServerManager" 
Add-WindowsFeature "NLB" -IncludeManagementTools

<

p align=»center»>***

После добавления роли NLB в Windows Firewall добавляется ряд правил связанных с этой ролью. Нам нужно будет откорректировать эти правила, в частности свести к минимуму возможность контакта к интерфейсам управления NLB из Интернет, отключить правила для IPv6, если этот протокол не используется, ограничить правила меж-узлового обмена и т.п. В конечном итоге, из включённых и настроенных правил, касающихся NLB, у меня получилась такая картина на первом VPN-сервере:

На втором VPN-сервере:

<

p align=»center»>***

Теперь приступим к процессу создания NLB-кластера.

На первом сервере RAS (KOM-AD01-VPN01) открываем консоль Network Load Balancing Manager (nlbmgr.exe). Выбираем пункт меню Cluster > New Cluster

Вводим имя первого узла, который хотим добавить в NLB, кнопкой Connect подключаемся к нему, и получив с него набор доступных интерфейсов, выбираем тот, который хотим сделать участником кластера:

На странице параметров хоста (Host Parameters) оставляем настройки по умолчанию:

В следующем окне мастера создания кластера добавляем IP адрес NLB кластера, на который мы ранее зарегистрировали А-запись во внешней зоне DNS.

Далее указываем FQDN кластера NLB (по той самой A-записи), а также режим его работы. В нашем примере выбран режим одноадресной рассылки – Unicast.

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

Отдельное замечание по допустимым режимам фильтрации (Filtering Mode), касающееся построения NLB для VPN можно найти в документе Create a new Network Load Balancing Port Rule:

When using NLB to load balance virtual private network (VPN) traffic (such as PPTP/GRE and IPSEC/L2TP), you must configure the port rules that govern the ports handling the VPN traffic (TCP port 1723 for PPTP and UDP port 500 for IPSEC) to use either Single or Network affinity.

В общей сложности, в нашем примере балансировке в NLB кластере мы будем подвергать следующие порты:

TCP 1723 – Routing and Remote Access (PPTP-In);
UDP 1701 – Routing and Remote Access (L2TP-In);
UDP 500 – Routing and Remote Access (Allows IKE traffic to the VPN server);
UDP 4500 – Routing and Remote Access (Allows IPsec NAT-T traffic from the VPN client to the VPN server.);

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

Далее, переходим на имя NLB кластера и пунктом меню Add Host to Cluster вызываем мастер добавления второго сервера в кластер.

Вводим имя второго VPN-сервера, подключаемся к нему кнопкой Connect и после появления информации о сетевых интерфейсах сервера выбираем WAN-интерфейс, который хотим включить в NLB кластер.

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

После добавления второго узла мы получим работоспособный Windows NLB кластер

11. Проверка работы NLB-кластера

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

12. Инструкции для пользователей

Как уже отмечалось ранее, для пользователей выполняющих подключение к корпоративным VPN-серверам из Интернет необходимо разработать чёткие пошаговые инструкции. Мне удалось протестировать (и параллельно разработать пошаговые инструкции для пользователей) VPN-подключения в составе следующих операционных систем:

• Windows XP 32-bit RU SP3
• Windows Vista Business 32-bit RU SP2
• Windows 7 Pro 32-bit RU SP1
• Windows 8.1 Pro 64-bit RU
• Ubuntu Desktop Linux 14.04.1 64-bit

Архив с инструкциями (а также нужными исполняемыми файлами), которые, при желании, вы можете адаптировать под своё окружение можно скачать по ссылке.

Если потребуется заниматься настройкой VPN-подключения по протоколу L2TP/Ipsec на других дистрибутивах Linux, возможно, будет полезен документ L2TP over IPsec VPN Manager User Guide

С настройкой подключения на Android у меня, к сожалению так ничего и не вышло. Задачи такой в общем-то и не стояло, просто было интересно попробовать. Перепробовал несколько разных бесплатных приложений доступных на Google Play, все довольно сносно работали по PPTP, но ничего не получалось при этом с L2TP/Ipsec. Встречались интересные приложения, но все они были либо платные, либо заточены под старые версии Android, например тот же OneVpn. Параллельно познакомился с таким “зверем”, как эмулятор Android — Android-x86. Пару полезных ссылок на тему того, как это дело завести в среде Hyper-V:

• STH — Installing Android-x86 on Hyper-V with Windows 8.1 in under 5 minutes
• Luisrato Blog — How to Install Android x86 4.4 RC2 on Hyper-V – Part 1: Install
• Luisrato Blog — How to Install Android x86 4.4 RC2 on Hyper-V – Part 2: Configuration, Screen resolution and Network

Дополнительные источники информации

• TechNet Library — Step-by-Step Guide for Setting Up VPN-based Remote Access in a Test Lab
• TechNet Library — Configure a Remote Access Network Policy
• TechNet Library — IPsec Algorithms and Methods Supported in Windows
• TechNet Library — Certificate Requirements for PEAP and EAP
• TechNet Library — Certreq.exe Syntax
• Windows PKI blog — Firewall Rules for Active Directory Certificate Services
• MSDN Library — Сертификаты и проверка подлинности доступа к сети
• TechNet Library — Troubleshooting Network Load Balancing Clusters
• KB926179 — How to configure an L2TP/IPsec server behind a NAT-T device in Windows Vista and in Windows Server 2008 
• KB885407 — The default behavior of IPsec NAT traversal (NAT-T) is changed in Windows XP SP2      
  
• Routing and Remote Access Blog — Remote Access Design Guidelines – Part 3: Tunnel selection, Authentication, Authorization and Accounting
• Routing and Remote Access Blog —  Remote Access Deployment – Part 3: Configuring RADIUS Server for remote access
• Routing and Remote Access Blog — Troubleshooting common VPN related errors
• Routing and Remote Access Blog — What type of certificate to install on the VPN server

Для прохождения аттестации на соответствие требованиям стандарта PCI DSS потребовалось настроить двухфакторная аутентификация. А так как у нас в качестве фаервола используется решение от Cisco, то решили его и использовать… Казалось бы ничего сложного, — все уже давно изучено и не один раз настроено и легко можно найти необходимые инструкции, например, эти:

Руководство по лаборатории тестирования: развертывание двухуровневой иерархии инфраструктуры открытых ключей служб сертификации Active Directory

CISCO: Configuring Digital Certificates

Cisco ASA with Radius and Certificates for Two-Factor Authentication (using a Microsoft CA)

но, как обычно и бывает с подобными «универсальными» инструкциями — тонкости они не учитывают, а это как раз и занимает бОльшую часть времени, при развертывании. об этих моментах мне как раз и хочется вам рассказать. надеюсь, это вам позволит сэкономить массу времени!

Первым неприятным моментом оказолось то, что Offline Root CA выдал сертификат для Subordinate Issuing CA сроком на 1 год(!) и это несмотря на заранее созданный

[Version]
Signature="$Windows NT$"
[PolicyStatementExtension]
Policies=InternalPolicy
[InternalPolicy]
OID= 1.2.3.4.1455.67.89.5
Notice="Legal Policy Statement"
URL=http://www.contoso.com/pki/cps.txt
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
CRLPeriod=weeks
CRLPeriodUnits=26
CRLDeltaPeriod=Days
CRLDeltaPeriodUnits=0
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=1

Поэтому внимательно проверяйте срок действия сертификата и если он выдан на 1 год, — сразу меняйте. Изменить можно так:

Нажмите кнопку Пуск и выберите команду Выполнить.
В поле Открыть введите команду regedit и нажмите кнопку ОК.
Найдите и выделите следующий раздел реестра:
HKEY_LOCAL_MACHINESystemCurrentControlSetServicesCertSvcConfiguration < Имя_цс >
В правой области дважды щелкните ValidityPeriod.
В поле значение введите введите одно из следующих действий и нажмите кнопку ОК:
Дней
Недели
Месяцев
Лет
.
В правой области дважды щелкните ValidityPeriodUnits.
В поле значение введите числовое значение, которое требуется и нажмите кнопку ОК. Например введите 2.
Остановите и перезапустите службы сертификации. Для этого:
Нажмите кнопку Пуск и выберите команду Выполнить.
В поле Открыть введите команду cmdи нажмите кнопку ОК.
В командной строке введите следующие команды. Нажмите клавишу ВВОД после каждой строки.

certsvc net stop
net start certsvc

Введите exit для выхода из командной строки.

А еще грубой ошибкой было игнорирование предупреждения от Microsoft:

Caution-Внимание
Клиенты сертификатов под управлением Windows XP и Windows Server 2003 не поддерживают альтернативный алгоритм подписи. Чтобы такие клиенты могли подавать заявки на сертификаты, не добавляйте строку AlternateSignatureAlgorithm=1 в файл CAPolicy.inf. Дополнительные сведения см. в разделе Рекомендации по использованию альтернативных форматов подписи.

Поэтому — уберите из CAPolicy.inf строку AlternateSignatureAlgorithm=1, иначе заимеете проблему с установкой сертификатов на ASA: Microsoft CA RSASSA-PSS Algorithm Issue with ASA
Решается изменением параметров в реестре:

и перевыпуском всех сертификатов.

Ну и наконец, третий момент был связан с настройкой параметров SSL на ASA, а именно TLS V1 и соотв. Cipher (версий и алгоритмов). На момент развертывания инфраструктуры PKI у нас была установлена прошивка asa911-smp-k8, которая не позволяла это нормально настроить. Приняли решение обновиться на версию asa941-smp-k8, но снова не совсем внимательно прочли порядок обновления конфигурации. заимели вот такую странную ошибку:

— это при попытке загрузить файл прошивки на железку. А всего лишь необходимо было сначала установить прошивку версии asa912-smp-k8

Надеюсь, кому-то эти знания и опыт пригодятся. Удачи!

P.S. как справедливо заметили в комментариях — совсем забыл про двухфакторная аутентификация, написал про сертификаты, забыл про Active Directory. Попытаюсь исправиться, для начала процесс настройки через ASDM:

Идем в Configuration -> Device Management -> Users/AAA -> AAA Servers Group, создаем новую группу (название и протокол). Я на картинках покажу настройки для протокола LDAP, а в конфиге и RADIUS тоже (кому что сподручнее использовать). Далее добавляем в только что созданную группу сервер:
1. указываем DNS имя или IP сервера; тип сервера Microsoft
2. Base DN, — в примере пусть будет DC=domain,DC=ru
3. Атрибут у пользователя, по которому будет производится из объектов AD — sAMAccountName
4. Distinguished Name пользователя, который имеет доступ на просмотрпоиск объектов в AD (взять его можно из консоли «Active Directory — пользователи и компьютеры», включив отображение дополнительных компонентов, в редакторе атрибутов)
5. Путь к OU, по которому будет производиться поиск групп
Обратите внимание на пункт LDAP Attribute Map — важная деталь, которую необходимо настроить!

ldap attribute-map AD
map-name memberOf IETF-Radius-Class

Ну и наконец, — когда у нас уже настроены CA, установлены все необходимые сертификаты, проверено подключение к AAA серверам, настроен AnyConnectWebVPN можно включить двухфакторная аутентификация:

В этой статье мы покажем, как внедрить двухфакторную аутентификацию пользователей в домене Windows с помощью open source продукта multiOTP. MultiOTP эта набор php скриптов и утилит, который реализует протокол OATH для HOTP/TOTP (Time-based One Time Password). Возможно использовать как в Windows, так и через RADIUS для реализации 2FA практически в чем угодно.

После внедрения multiOTP для входа пользователя Windows будет запрашивать дополнительный одноразовый пароль (OTP – one time password), который пользователь должен получить со своего мобильного устройства (приложение Microsoft или Google Authenticator, или другого генератора OTP). Вы можете настроить двухфакторную аутенфтикацию для входа на рабочие станции Windows, или для удаленного RDP доступа к хостам RDS на Windows Server.

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

Установка и настройка MultiOTP в домене Active Directory

В этом разделе мы покажем, как установить MultiOTP в Windows Server 2019 и настроить синхронизацию пользователей из Active Directory.

Также вы можете развернуть MultiOTP с помощью готового образа OVA для VMware, виртуальной машины Hyper-V или Docker контейнера.

Начнем с настройки сервера MultiOTP, который будет получать пользователей из Active Directory, генерировать уникальные QR коды для пользователей и проверять правильность второго фактора.

Создадим в Active Directory отдельную группу и добавим в нее пользователей, для которых мы будет требовать проверку второго фактора при входе в Windows. Создадим группу с помощью PowerShell:

New-ADGroup 2FAVPNUsers -path 'OU=Groups,OU=Moscow,dc=winitpro,DC=ru' -GroupScope Global -PassThru –Verbose

Добавьте пользователей в группу:

Add-AdGroupMember -Identity 2FAVPNUsers -Members kbuldogov, user1, user2

Создайте в AD нового пользователя multiotp_srv, который будет использоваться multiotp для доступа к AD (с минимальными привилегиями).

$passwd = ConvertTo-SecureString -String "[email protected]!" -AsPlainText -Force
New-ADUser -Name "multiotp_srv" -SamAccountName "multiotp_srv" -UserPrincipalName "[email protected]" -Path "OU=ServiceAccounts,OU=Moscow,DC=winitpro,DC=ru" –AccountPassword $passwd -Enabled $true

Скачайте архив с файлами MultiOTP с сайта разработчиков https://download.multiotp.net/.

Откройте архив multiotp_5.8.2.9.zip и извлеките из него каталог windows в папку на локальном диске (C:MultiOTP).

Откройте командную строку и перейдите в каталог с утилитой multiotp.exe:

CD C:MultiOTPwindows

Следующими командами мы настроим MultiOTP для получения пользователей из LDAP каталога Active Directory.

multiotp -config default-request-prefix-pin=0
multiotp -config default-request-ldap-pwd=0
multiotp -config ldap-server-type=1
multiotp -config ldap-cn-identifier="sAMAccountName"
multiotp -config ldap-group-cn-identifier="sAMAccountName"
multiotp -config ldap-group-attribute="memberOf"
multiotp -config ldap-ssl=0
multiotp -config ldap-port=389

REM Адрес контроллера домена

multiotp -config ldap-domain-controllers=msk-dc03.winitpro.ru,ldap://192.168.13.10:389
multiotp -config ldap-base-dn="DC=winitpro,DC=ru"

REM Учетная запись для аутентификации multiotp в AD:

multiotp -config ldap-bind-dn="CN=multiotp_srv,OU=ServiceAccounts,OU=Moscow,DC=winitpro,DC=ru"
multiotp -config ldap-server-password="[email protected]!"

REM группа пользователей, для которых нужно включить OTP

multiotp -config ldap-in-group="2FAVPNUsers"
multiotp -config ldap-network-timeout=10
multiotp -config ldap-time-limit=30
multiotp -config ldap-activated=1

REM ключ для доступа к MultiOTP серверу

multiotp -config server-secret=secretOTP

Ранее мы создали группу 2FAVPNUsers и добавили в нее 3 пользователей. Выполните синхронизацию пользователей AD в MultiOTP.

multiotp -debug -display-log -ldap-users-sync

OG 2022-01-17 14:36:44 info LDAP Info: 3 users created, based on 3 LDAP entries (processed in 00:00:00)
LOG 2022-01-17 14:36:44 debug System Info: *File created: c:MultiOTPwindows.usersa.ivanov.db

В данном случае MultiOTP обнаружила трех пользователей и синхронизировала их.

Запустите с правами администратора файл webservice_install.cmd. Это установит веб интерфейс управления MultiOTP.

Зайдите на веб-интерфейс
http://127.0.0.1:8112/
под учётной запись admin с паролем 1234 (желательно сменить при входе).

Настройка двухфакторной аутентификации MultiOTP для пользователя домена

В разделе List of users будет доступен список пользователей домена, которые были синхронизированы ранее (источник AD/LDAP).

Выберите пользователя и нажмите Print. Перед вами появится QR код пользователя, который нужно добавить в приложение-аутентфикатор.

Установите на смартфон пользователя приложение Microsoft Authenticator (или Google Authenticator) из Google Play или App Store. Запустите его и отсканируйте QR код пользователя.

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

Из командной строки можно проверить, что MultiOTP позволяет аутентифицировать данного пользователя с помощью OTP:

multiotp.exe -display-log kbuldogov 719854

где
719854
– одноразовый пароль, полученный из приложения.

LOG 2022-01-17 15:13:11 notice (user kbuldogov) User OK: User kbuldogov successfully logged in with TOTP token
Filter-Id += "2FAVPNUsers"

Также можно проверить корректность работы OTP из веб-интерфейса. Перейдите в раздел Check a user, введите имя пользователя и одноразовый пароль.

Установка multiOTP CredentialProvider в Windows

Следующий этап – установка multiOTP-CredentialProvider на компьютеры Windows, на которых вы хотите внедрить двухфакторную аутентификацию пользователей с помощью MultiOTP. CredentialProvider можно установить на все версии Windows 7/8/8.1/10/11 и Windows Server 2012(R2)/2016/2019/2022.

В это примере мы настроим двухфакторную аутентификацию для RDP входа пользователей на RDSH сервер на Windows Server 2019.

Скачайте и установите multiOTP CredentialProvider с GitHub https://github.com/multiOTP/multiOTPCredentialProvider/releases. На момент написания статьи эта версия
5.8.4.0
.

Запустите установку:

1. Укажите IP сервера, на котором был установлен multiOTP
2. В нижнее поле укажите секретное слово из конфигурации multiOTP (

   в нашем конфиге);

3. Выберите тип входа в Windows, для которых нужно применять аутентфикацию через OTP. В нашем примере мы ограничимся 2FA только для RDP входов (OTP authentication mandatory for remote desktop only).

Можно включить использование OTP аутенфтикации как для RDP так и для локальных входов.

MultiOTP CredentialProvider хранит настройки в реестре HKEY_CLASSES_ROOTCLSID{FCEFDFAB-B0A1-4C4D-8B2B-4FF4E0A3D978}. Если нужно, вы здесь можете изменить настройки CredentialProvider без переустановки.

Перезагрузите Windows Server RDS и попробуйте через RDP подключиться к нему. Теперь после отправки имени и пароля пользователя появляется дополнительное окно one-time password. Здесь пользователь должен ввести одноразовый пароль из приложения Authenticator на своем смартфоне.

На севере MultiOTP можно включить ведение логов, это полезно при отладке:

multiotp -config debug=1
multiotp -config display-log=1

Your script is running from C:MultiOTPwindows
2022-01-17 15:21:07 debug CredentialProviderRequest Info: *Value for IsCredentialProviderRequest: 1 0 SPB-SRV01
2022-01-17 15:21:07 debug Server-Client Info: *CheckUserToken server request. 0 SPB-SRV01
2022-01-17 15:21:07 notice kbuldogov User OK: User kbuldogov successfully logged in (using Credential Provider) with TOTP token 0 SPB-SRV01
2022-01-17 15:21:07 debug Server-Client Info: *Cache level is set to 1 0 SPB-SRV01
2022-01-17 15:21:07 debug Server-Client Info: *Server secret used for command CheckUserToken with error code result 0: secretOTP 0 SPB-SRV01

Не забудьте убедиться, что ваш домен синхронизирует время с тайм-серверами в интернете и время на клиентах не разбегается. Эти критично для работы OTP.

В любом случае перед массовым внедрением 2FA на базе MultiOTP в вашей сети рекомендуем в течении пары недель протестировать все режимы работы и нештатные ситуации (недоступность сервера MultiOTP, DC, ошибки в CredentialProvider и т.д.). Если возникли существенные проблемы со входом через MultiOTP, вы можете удалить CredentialProvider в безопасном режиме.

На этом настройка двухфакторной аутентификации в Windows Server с помощью MultiOTP закончена. Доступны сценарии использования MultiOTP с RADIUS сервером, для аутентификации практически любых типов клиентов через OTP. Также вы можете использовать OTP для дополнительной зашиты RDP серверов в интернете от брутфорса в дополнении к https://winitpro.ru/index.php/2019/10/02/blokirovka-rdp-atak-firewall-powershell/.

Раздел содержит инструкцию по настройке входа в домен по предъявлению токена в операционной системе Windows Server 2012 R2.

Для настройки необходим компьютер с установленной операционной системой Windows 2012 R2 Server Rus и драйверами Рутокен, а также дистрибутив этой ОС.

Операционная система должна быть настроена как Контроллер домена, должны быть установлены Службы Сертификации, а пользователям выданы сертификаты типа Пользователь со смарт-картой или Вход со смарт-картой.

Все описанные действия производятся с правами администратора системы.

Для примера используется учетная запись Admin.

Этапы входа в домен по предъявлению токена:

1 этап:  Настройка учетных записей пользователей.

2 этап: Настройка политик безопасности домена.

3 этап: Настройка клиентской операционной системы.

Настройка учетных записей пользователей 

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

Для настройки учетной записи пользователя:

1. Откройте Панель управления.

2. Два раза щелкните по названию Администрирование. 
   

   В домене под управлением Windows Server 2012 R2 есть возможность одним действием запретить всем входить в домен без наличия устройства Рутокен с необходимым сертификатом (пользователь с учетной записью Administrator также не сможет войти в домен без устройства Рутокен). Шаги 2-5 данной инструкции необходимо выполнить только в том случае, если в домене будут пользователи не только с устройствами Рутокен, но и использующие альтернативные способы аутентификации (пароли, биометрические данные и т. д.). При этом шаги 9-10 надо пропустить.  

3. Два раза щелкните по названию оснастки Пользователи и компьютеры Active Directory. 
   
4. В левой части окна оснастки щелкните по названию папки Users.
5. Щелкните правой кнопкой мыши по имени пользователя, которому будет разрешено входить в домен только при наличии устройства Рутокен, и выберите пункт Свойства.
   
6. В окне свойств пользователя перейдите на вкладку Учетная запись.
7. В секции Параметры учетной записи установите флажок Для интерактивного входа в сеть нужна смарт-карта. Нажмите OK.
   
8. Закройте окно Active Directory — пользователи и компьютеры. 
9. Аналогичным образом настройте другие учетные записи в домене. Для таких пользователей вход в домен будет доступен только при наличии устройства Рутокен с сертификатом, выданным администратором домена. 

Настройка политик безопасности домена 

Для настройки политик безопасности:

1. Откройте Панель управления.
2. Два раза щелкните по названию пункта Администрирование.
3. Два раза щелкните по названию оснастки Управление групповой политикой.
   
4. В окне Управление групповой политикой рядом с названием категории Объекты групповой политики щелкните по стрелочке.

5. Щелкните правой кнопкой мыши по названию объекта групповой политики Default Domain Policy и выберите пункт Изменить…
   

   Шаги 4-5 данной инструкции необходимо выполнять только в том случае, если всем пользователям будет запрещен вход в домен без устройства Рутокен с необходимым сертификатом.

6. В окне Редактор управления групповыми политиками рядом с названием пункта Конфигурация Windows щелкните по стрелочке.
7. Рядом с названием пункта Параметры безопасности щелкните по стрелочке.
8. Рядом с названием пункта Локальные политики щелкните по стрелочке.
9. Щелкните по названию пункта Параметры безопасности.
10. Щелкните два раза по названию политики Интерактивный вход в систему: требовать смарт-карту.
     
11. Установите флажок Определить следующий параметр политики.
12. Установите переключатель в положение Включен.
13. Нажмите OK. 
    
14. В окне Редактор управления групповыми политиками рядом с пунктом Конфигурации Windows щелкните по стрелочке.
15. Рядом с названием подпункта Параметры безопасности щелкните по стрелочке.
16. Рядом с названием Локальные политики щелкните по стрелочке.
17. Щелкните по названию подпункта Параметры безопасности.
18. Щелкните правой кнопкой мыши по названию политики Интерактивный вход в систему: поведение при извлечении смарт-карты и выберите пункт Свойства. 
     
19. Установите флажок Определить следующий параметр политики.
20. Из раскрывающегося списка выберите поведение клиентской ОС при отсоединении устройства Рутокен в процессе открытого пользовательского сеанса. В данном примере выбрано поведение ОС — Блокировка рабочей станции.
21. Нажмите OK. 
    
22. Закройте окно Редактор управления групповыми политиками.
23. Закройте Панель управления.

Настройка будет доступна только после перезагрузки компьютера. Настройка серверной операционной системы после этого будет завершена.                  

Настройка клиентской операционной системы

Компьютеры с установленными клиентскими операционными системами Windows 10/8.1/8/7/Vista/XP/2000 необходимо ввести в домен и установить на них драйверы Рутокен.

Редакции ОС должны включать возможность присоединения к домену.

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

Теперь пользователи, которым выдан сертификат типа Пользователь со смарт-картой или Вход со смарт-картой, смогут входить в домен только при подключении к компьютеру устройства Рутокен с этим сертификатом.
При извлечении устройства Рутокен в процессе открытого пользовательского сеанса, клиентская ОС будет автоматически заблокирована (в ОС Windows 10/8.1/8/7/Vista для блокировки рабочего стола при отключении устройства Рутокен необходимо установить автоматический запуск службы Политика удаления смарт-карт/Smart Card Removal Policy).  

Пароль является не очень надежным средством защиты. Очень часто используются простые, легко подбираемые пароли или же пользователи не особо следят за сохранностью своих паролей (раздают коллегам, пишут на бумажках и т.д.). В 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:WindowsSystem32certsrvCertEnroll. Закрываем 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) Если не получается запустить процесс генерации сертификата по стандартному шаблону «Вход с смарт-картой», создайте его копию с такими параметрами.

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

В этой статье будет показано, как внедрить двухфакторную аутентификацию пользователей в домене Windows с помощью open source продукта multiOTP. MultiOTP эта набор php скриптов и утилит, который реализует протокол OATH для HOTP/TOTP (Time-based One Time Password). Возможно использовать как в Windows, так и через RADIUS для реализации 2FA практически в чем угодно.

После внедрения multiOTP для входа пользователя Windows будет запрашивать дополнительный одноразовый пароль (OTP – one time password), который пользователь должен получить со своего мобильного устройства (приложение Microsoft или Google Authenticator, или другого генератора OTP). Вы можете настроить двухфакторную аутенфтикацию для входа на рабочие станции Windows, или для удаленного RDP доступа к хостам RDS на Windows Server.

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

Установка и настройка MultiOTP в домене Active Directory.

В этом разделе будет продемонстрировано, как установить MultiOTP в Windows Server 2019 и настроить синхронизацию пользователей из Active Directory.

Также вы можете развернуть MultiOTP с помощью готового образа OVA для VMware, виртуальной машины Hyper-V или Docker контейнера.

Начнем с настройки сервера MultiOTP, который будет получать пользователей из Active Directory, генерировать уникальные QR коды для пользователей и проверять правильность второго фактора.

Создадим в Active Directory отдельную группу и добавим в нее пользователей, для которых мы будет требовать проверку второго фактора при входе в Windows. Создадим группу с помощью PowerShell:

New-ADGroup 2FAVPNUsers -path ‘OU=Groups,OU=Moscow,dc=winitpro,DC=ru’ -GroupScope Global -PassThru –Verbose

Добавьте пользователей в группу:

Add-AdGroupMember -Identity 2FAVPNUsers -Members kbuldogov, user1, user2

Создайте в AD нового пользователя multiotp_srv, который будет использоваться multiotp для доступа к AD (с минимальными привилегиями).

$passwd = ConvertTo-SecureString -String «P@ssw0rd!» -AsPlainText -Force
New-ADUser -Name «multiotp_srv» -SamAccountName «multiotp_srv» -UserPrincipalName «multiotp_srv@contoso.com» -Path «OU=ServiceAccounts,OU=Moscow,DC=mydomain,DC=com» –AccountPassword $passwd -Enabled $true

Скачайте архив с файлами MultiOTP с сайта разработчиков https://download.multiotp.net/.

Откройте архив multiotp_5.8.2.9.zip и извлеките из него каталог windows в папку на локальном диске (C:MultiOTP).

Откройте командную строку и перейдите в каталог с утилитой multiotp.exe:

CD C:MultiOTPwindows

Следующими командами мы настроим MultiOTP для получения пользователей из LDAP каталога Active Directory.

multiotp -config default-request-prefix-pin=0
multiotp -config default-request-ldap-pwd=0
multiotp -config ldap-server-type=1
multiotp -config ldap-cn-identifier=»sAMAccountName»
multiotp -config ldap-group-cn-identifier=»sAMAccountName»
multiotp -config ldap-group-attribute=»memberOf»
multiotp -config ldap-ssl=0
multiotp -config ldap-port=389

REM Адрес контроллера домена

multiotp -config ldap-domain-controllers=msk-dc03.mydomain.com,ldap://192.168.13.10:389
multiotp -config ldap-base-dn=»DC=mydomain,DC=com»

REM Учетная запись для аутентификации multiotp в AD:

multiotp -config ldap-bind-dn=»CN=multiotp_srv,OU=ServiceAccounts,OU=Moscow,DC=mydomain,DC=com»
multiotp -config ldap-server-password=»P@ssw0rd!»

REM группа пользователей, для которых нужно включить OTP

multiotp -config ldap-in-group=»2FAVPNUsers»
multiotp -config ldap-network-timeout=10
multiotp -config ldap-time-limit=30
multiotp -config ldap-activated=1

REM ключ для доступа к MultiOTP серверу

multiotp -config server-secret=secretOTP

Более подробное описание всех опций есть в документе https://download.multiotp.net/readme_5.8.2.9.txt в секции “HOW TO CONFIGURE MULTIOTP TO SYNCHRONIZED THE USERS FROM AN ACTIVE DIRECTORY”.

Ранее мы создали группу 2FAVPNUsers и добавили в нее 3 пользователей. Выполните синхронизацию пользователей AD в MultiOTP.

multiotp -debug -display-log -ldap-users-sync

OG 2022-01-17 14:36:44 info LDAP Info: 3 users created, based on 3 LDAP entries (processed in 00:00:00)
LOG 2022-01-17 14:36:44 debug System Info: *File created: c:MultiOTPwindows.usersa.ivanov.db

В данном случае MultiOTP обнаружила трех пользователей и синхронизировала их.

Для регулярной синхронизации новых учетных записей в Active Directory, нужно создать задание планировщика с командой:

multiotp -debug -display-log -ldap-users-sync

Запустите с правами администратора файл webservice_install.cmd. Это установит веб интерфейс управления MultiOTP.

Зайдите на веб-интерфейс http://127.0.0.1:8112/ под учётной запись admin с паролем 1234 (желательно сменить при входе).

В разделе List of users будет доступен список пользователей домена, которые были синхронизированы ранее (источник AD/LDAP).

Выберите пользователя и нажмите Print. Перед вами появится QR код пользователя, который нужно добавить в приложение-аутентфикатор.

Установите на смартфон пользователя приложение Microsoft Authenticator (или Google Authenticator) из Google Play или App Store. Запустите его и отсканируйте QR код пользователя.

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

Из командной строки можно проверить, что MultiOTP позволяет аутентифицировать данного пользователя с помощью OTP:

multiotp.exe -display-log my-login 719854

где 719854 – одноразовый пароль, полученный из приложения.

LOG 2022-01-17 15:13:11 notice (user xxx) User OK: User xxx successfully logged in with TOTP token
Filter-Id += «2FAVPNUsers»

Также можно проверить корректность работы OTP из веб-интерфейса. Перейдите в раздел Check a user, введите имя пользователя и одноразовый пароль.

Установка multiOTP CredentialProvider в Windows.

Следующий этап – установка multiOTP-CredentialProvider на компьютеры Windows, на которых вы хотите внедрить двухфакторную аутентификацию пользователей с помощью MultiOTP. CredentialProvider можно установить на все версии Windows 7/8/8.1/10/11 и Windows Server 2012(R2)/2016/2019/2022.

В это примере мы настроим двухфакторную аутентификацию для RDP входа пользователей на RDSH сервер на Windows Server 2019.

Скачайте и установите multiOTP CredentialProvider с GitHub https://github.com/multiOTP/multiOTPCredentialProvider/releases. На момент написания статьи эта версия 5.8.4.0 .

Запустите установку:

• Укажите IP сервера, на котором был установлен multiOTP

Не забудьте открыть порт в файерволе на сервере и клиенте multiOTP. Открыть порт в Windows Firewall на сервере можно с помощью PowerShell:
New-NetFirewallRule -DisplayName «AllowMultiOTP» -Direction Inbound -Protocol TCP –LocalPort 8112 -Action Allow

• В нижнее поле укажите секретное слово из конфигурации multiOTP ( в нашем конфиге);

• Выберите тип входа в Windows, для которых нужно применять аутентфикацию через OTP. В нашем примере мы ограничимся 2FA только для RDP входов (OTP authentication mandatory for remote desktop only).

Можно включить использование OTP аутенфтикации как для RDP так и для локальных входов.

MultiOTP CredentialProvider хранит настройки в реестре HKEY_CLASSES_ROOTCLSID{FCEFDFAB-B0A1-4C4D-8B2B-4FF4E0A3D978}. Если нужно, вы здесь можете изменить настройки CredentialProvider без переустановки.

Перезагрузите Windows Server RDS и попробуйте через RDP подключиться к нему. Теперь после отправки имени и пароля пользователя появляется дополнительное окно one-time password. Здесь пользователь должен ввести одноразовый пароль из приложения Authenticator на своем смартфоне.

Если на RDS хосте отключен NLA для RDP, пользователь просто увидит три поля для ввода (имя учетной записи, пароль и OTP).

На севере MultiOTP можно включить ведение логов, это полезно при отладке:

multiotp -config debug=1
multiotp -config display-log=1

Your script is running from C:MultiOTPwindows
2022-01-17 15:21:07 debug CredentialProviderRequest Info: *Value for IsCredentialProviderRequest: 1 0 SPB-SRV01
2022-01-17 15:21:07 debug Server-Client Info: *CheckUserToken server request. 0 SPB-SRV01
2022-01-17 15:21:07 notice kbuldogov User OK: User kbuldogov successfully logged in (using Credential Provider) with TOTP token 0 SPB-SRV01
2022-01-17 15:21:07 debug Server-Client Info: *Cache level is set to 1 0 SPB-SRV01
2022-01-17 15:21:07 debug Server-Client Info: *Server secret used for command CheckUserToken with error code result 0: secretOTP 0 SPB-SRV01

Не забудьте убедиться, что ваш домен синхронизирует время с тайм-серверами в интернете и время на клиентах не разбегается. Эти критично для работы OTP.

В любом случае перед массовым внедрением 2FA на базе MultiOTP в вашей сети рекомендуем в течении пары недель протестировать все режимы работы и нештатные ситуации (недоступность сервера MultiOTP, DC, ошибки в CredentialProvider и т.д.). Если возникли существенные проблемы со входом через MultiOTP, вы можете удалить CredentialProvider в безопасном режиме.

На этом настройка двухфакторной аутентификации в Windows Server с помощью MultiOTP закончена. Доступны сценарии использования MultiOTP с RADIUS сервером, для аутентификации практически любых типов клиентов через OTP. Также вы можете использовать OTP для дополнительной зашиты RDP серверов в интернете от брутфорса в дополнении к https://pc103help.blogspot.com/2020/07/nastrojka-rdp-zashhita-ot-perebora-parolej.html

По теме:

• Устанавливаем и настраиваем Cyberarms Intrusion Detection and Defense Software (IDDS).
• Защита RDP подключения от брутфорса при помощи IPBan.
• Где хранить резервные копии для малого бизнеса в Украине?
• Защита RDP для бизнеса в Украине — облачная приватная сеть.
• Нужен ли вам «IT-аудит безопасности»?

Важно знать.

Что будет, если на компьютер с multiOTP CredentialProvider по RDP будет заходить пользователь, который не входит в группу 2FAVPNUsers?

Такой пользователь не сможет зайти, т.к. для него будет требоваться одноразовый пароль:

2022-01-19 12:31:44 warning System Error: database file C:MultiOTPwindowsusersxxx.db for user a.khramov does not exist 0 SRV01
2022-01-19 12:31:44 debug Server-Client Info: *Server secret used for command ReadUserData with error code result 21: secretOTP 0

Если нужно разрешить ему вход по RDP без 2FA, нужно будет добавить его аккаунт в веб интерфесе с опцией Token type: Without2FA. При входе по RDP у него будет появляться запрос OTP, в нем нужно просто нажать Enter (пустой пароль)

2022-01-19 12:42:15 notice user_xxx User OK: User ххх successfully logged in (using Credential Provider) without 2FA token 0 SPB-SRV01