При обслуживании больших сетей системные администраторы часто сталкиваются с проблемами аутентификации на сетевом оборудовании. В частности, довольно сложно организовать нормальную работу нескольких сетевых администраторов под индивидуальными учетными записями на большом количестве оборудования (приходится вести и поддерживать в актуальном состоянии базу локальных учетных записей на каждом устройстве). Логичным решение было бы использовать для авторизации уже существующей базы учетных записей — Active Directory. В этой статье мы разберемся, как настроить доменную (Active Directory) аутентификацию на активном сетевом оборудовании (коммутаторы, маршрутизаторы).
Не все сетевое оборудование популярных вендоров (CISCO, HP, Huawei) поддерживает функционал для непосредственного обращения к каталогу LDAP, и такое решение не будет универсальным. Для решения нашей задачи подойдет протокол AAA (Authentication Authorization and Accounting), фактически ставший стандартом де-факто для сетевого оборудования. Клиент AAA (сетевое устройство) отправляет данные авторизующегося пользователя на сервер RADIUS и на основе его ответа принимает решение о предоставлении / отказе доступа.
Протокол Remote Authentication Dial In User Service (RADIUS) в Windows Server 2012 R2 включен в роль NPS (Network Policy Server). В первой части статьи мы установим и настроим роль Network Policy Server, а во второй покажем типовые конфигурации сетевого устройств с поддержкой RADUIS на примере коммутаторов HP Procurve и оборудования Cisco.
Содержание:
- Установка и настройка сервера с ролью Network Policy Server
- Настройка сетевого оборудования для работы с сервером RADUIS
Установка и настройка сервера с ролью Network Policy Server
Как правило, сервер с ролью NPS рекомендуется устанавливать на выделенном сервере (не рекомендуется размещать эту роль на контроллере домена). В данном примере роль NPS мы будем устанавливать на сервере с Windows Server 2012 R2.
Откройте консоль Server Manager и установите роль Network Policy Server (находится в разделе Network Policy and Access Services).
После окончания установки запустите mmc-консоль управления Network Policy Server. Нас интересуют три следующих раздела консоли:
- RADIUS Clients — содержит список устройств, которые могут аутентифицироваться на сервере
- Connection Request Policies – определяет типы устройств, которые могут аутентифицироваться
- Network Polices – правила аутентификации
Добавим нового клиента RADIUS (это будет коммутатор HP ProCurve Switch 5400zl), щелкнув ПКМ по разделу RADIUS Clients и выбрав New. Укажем:
- Friendly Name:sw-HP-5400-1
- Address (IP or DNS): 10.10.10.2
- Shared secret (пароль/секретный ключ): пароль можно указать вручную (он должен быть достаточно сложным), либо сгенерировать с помощью специальной кнопки (сгенерированный пароль необходимо скопировать, т.к. в дальнейшем его придется указать на сетевом устройстве).
Отключим стандартную политику (Use Windows authentication for all users) в разделе Connection Request Policies, щелкнув по ней ПКМ и выбрав Disable.
Создадим новую политику с именем Network-Switches-AAA и нажимаем далее. В разделе Сondition создадим новое условие. Ищем раздел RADIUS Client Properites и выбираем Client Friendly Name.
В качестве значения укажем sw-?. Т.е. условие будет применяться для всех клиентов RADIUS, начинающийся с символов :”sw-“. Жмем Next->Next-> Next, соглашаясь со всеми стандартными настройками.
Далее в разделе Network Policies создадим новую политику аутентификации. Укажите ее имя, например Network Switch Auth Policy for Network Admins. Создадим два условия: в первом условии Windows Groups, укажем доменную группу, члены которой могут аутентифицироваться (учетные записи сетевых администраторов в нашем примере включены в группу AD Network Admins) Второе условие Authentication Type, выбрав в качестве протокола аутентификации PAP.
Далее в окне Configure Authentication Methods снимаем галки со всех типов аутентификации, кроме Unencrypted authentication (PAP. SPAP).
В окне Configure Settings изменим значение атрибута Service-Type на Administrative.
В остальных случаях соглашаемся со стандартными настройками и завершаем работу с мастером.
И, напоследок, переместим новую политику на первое место в списке политик.
Настройка сетевого оборудования для работы с сервером RADUIS
Осталось настроить наше сетевое оборудование для работы с сервером Radius. Подключимся к нашему коммутатору HP ProCurve Switch 5400 и внесем следующе изменение в его конфигурацию (измените ip адрес сервера Raduis и пароль на свои).
aaa authentication console enable radius local aaa authentication telnet login radius local aaa authentication telnet enable radius local aaa authentication ssh login radius local aaa authentication ssh enable radius local aaa authentication login privilege-mode radius-server key YOUR-SECRET-KEY radius-server host 10.10.10.44 YOUR-SECRET-KEY auth-port 1645 acct-port 1646 radius-server host 10.10.10.44 auth-port 1645 radius-server host 10.10.10.44 acct-port 1646
Совет. Если в целях безопасности вы запретили подключаться к сетевому оборудованию через telnet, эти строки нужно удалить из конфига:
aaa authentication telnet login radius local aaa authentication telnet enable radius local
Не закрывая консольное окно коммутатора (это важно!, иначе, если что-то пойдет не так, вы более не сможете подключиться к своему коммутатору), откройте вторую telnet-сессию. Должно появиться новое окно авторизации, в котором будет предложено указать имя и пароль учетной записи. Попробуйте указать данные своей учетной записи в AD (она должна входить в группу Network Admins ). Если подключение установлено – вы все сделали правильно!
Для коммутатора Cisco конфигурация, предполагающая использование доменных учетных записей для аутентификации и авторизации, может выглядеть так:
Примечание. В зависимости от модели сетевого оборудования Cisco и версии IOS конфигурация может несколько отличаться.
aaa new-model radius-server host 10.10.10.44 auth-port 1645 acct-port 1646 key YOUR-SECRET-KEY aaa authentication login default group radius local aaa authorization exec default group radius local ip radius source-interface Vlan421 line con 0 line vty 0 4 line vty 5 15
Примечание. В такой конфигурации для аутентификации сначала используется сервер RADIUS, а если он не доступен – локальная учетная запись.
Для Cisco ASA конфигурация будет выглядеть так:
aaa-server RADIUS protocol radius aaa-server RADIUS host 10.10.10.44 key YOUR-SECRET-KEY radius-common-pw YOUR-SECRET-KEY aaa authentication telnet console RADIUS LOCAL aaa authentication ssh console RADIUS LOCAL aaa authentication http console RADIUS LOCAL aaa authentication http console RADIUS LOCAL
Совет. Если что то-не работает, проверьте:
- Совпадают ли секретные ключи на сервере NPS и коммутаторе (для теста можно использоваться простой пароль).
- Указан ли правильный адрес NPS сервера в конфигурации. Пингуется ли он?
- Не блокируют ли межсетевые экраны порты 1645 и 1646 между коммутатором и сервером?
- Внимательно изучите логи NPS сервера
Содержание статьи:
- 1 Добавление роли, настройка Active Directory
- 2 Настройка Network Policy Server
- 3 Настройка Cisco IOS AAA
- 3.1 Пример настройки на Cisco 2911/K9 15.0(1r)M12
- 3.2 Пример настройки на Cisco WS-C3750V2-48TS 12.2(55)SE5
Рассмотрим настройку Radius аутентификации на Cisco устройствах, посредством службы Политики сети и доступа (Network Policy Server) на Windows Server 2012 R2.
Добавление роли, настройка Active Directory
Добавляем роль , переходим в Диспетчер серверов — Управление — Добавить роли и компоненты.
Выбираем роль (Службы политики сети и доступа):
Выбираем службу ролей (Сервер политики сети):
Для завершения установки роли, нажимаем Установить и дожидаемся установки компонента, после чего нажимаем Завершить.
В Active Directory необходимо создать группу безопасности (прим. NPS_Cisco) и включить в нее пользователей кому будет разрешена аутентификации на маршрутизаторах и коммутаторах Cisco.
Настройка Network Policy Server
Открываем оснастку Сервер политики сети (Network Policy Server).
Для полноценного использования функций NPS-сервера в домене, выполним регистрацию его в Active Directory. В оснастке на NPS (Локально), нажимаем правой кнопкой мыши и выбираем Зарегистрировать сервер в Active Directory (Register server in Active Directory):
Подтверждаем регистрацию сервера в Active Directory:
После регистрации NPS в Active Directory, добавим клиента RADIUS. На строке RADIUS-клиенты и серверы (RADIUS Clients and Servers) щелкаем правой кнопкой мыши и выбираем Новый документ (NEW):
Во вкладке «Параметры» вводим Понятное имя (Friendly name), IP-адрес (Address) и Общий секрет (Shared Secret). Во вкладке «Дополнительно» указываем Имя поставщика (Vendor name) — Cisco
Значение в поле Понятное имя (Friendly name) может отличаться от DNS имени. Оно потребуется нам в дальнейшем для идентификации конкретного сетевого устройства при создании политик доступа. Опираясь на это имя мы сможем задавать например маску по которой будут обрабатываться определённой политикой доступа несколько разных RADIUS клиентов.
Раскрываем ветку Политики (Policies) — Сетевые политики (Network Policies) и щелкаем правой кнопкой мыши и выбираем Новый документ (NEW):
Задаем Имя политики (Policy name), Тип сервера доступа к сети (Type of network access server) оставляем без изменения:
Задаем условия, которые должны соответствовать для успешной аутентификации. Создадим два условия:
- Группы пользователей (указываем ранее созданную в Active Directory группу безопастности)
- Понятное имя клиента (указываем дружественные имена, начинающиеся с префикса CISCO_)
Результат добавления условий:
Указываем разрешение доступа, оставляем значение Доступ разрешен (Access Granted).
Cisco поддерживает только методы Проверка открытым текстом (PAP, SPAP) (Unencrypted authentication (PAP, SPAP)). Снимите все флажки и отмечаем только Проверка открытым текстом (PAP, SPAP):
После настройки методов проверки подлинности вам будет предложено настроить Ограничения (Constraints), пропускаем этот раздел и переходим к следующему шагу.
Настройка параметров (Configure Settings), переходим в Атрибуты RADIUS (RADIUS Attributes) — Стандарт (Standard). Удаляем имеющиеся там атрибуты и нажимаем Добавить… (Add…)
Тип доступа выбираем Service-Type, нажимаем Добавить, выставляем значение атрибута Login
переходим в Атрибуты RADIUS (RADIUS Attributes) — Зависящие от поставщика (Vendor Specific), добавляем новый атрибут, и нажимаем Добавить… (Add…)
В пункте Поставщик (Vendor), указываем Cisco и нажимаем Добавить… (Add…). Будет предложено добавить сведения об атрибуте, нажимаем Добавить… (Add…) и устанавливаем значение атрибута:
В итоге должно получится как изображено ниже. Нажимаем Далее (Next).
Представление сводки новой политики, которая была сформирована. Нажимаем Готово (Finish):
После создания политики, можно переходить к настройке маршрутизаторов и коммутаторов Cisco для аутентификации на сервере Radius NPS.
Настройка Cisco IOS AAA
Сперва настроим локальную учетную запись (прим. admin), на случай выхода из строя RADIUS-сервера, выполняем команды:
|
cisco>enable cisco#config terminal cisco(config)#username admin priv 15 secret Aa1234567 |
Выполняем последовательность действий по добавлению RADIUS-сервера:
- Включаем режим AAA
- Добавляем RADIUS-сервер
- Настраиваем профиль аутентификации (сперва RADIUS-сервер, если он не доступен, то тогда локальные учетные записи)
- Настраиваем профиль авторизации (сперва RADIUS-сервер, если он не доступен, то тогда локальные учетные записи)
- Включаем аутентификацию на интерфейсах
Пример настройки на Cisco 2911/K9 15.0(1r)M12
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
cisco(config)#aaa new—model cisco(config)#radius server NPS cisco(config—radius—server)#address ipv4 10.10.10.1 auth—port 1645 acct—port 1646 cisco(config—radius—server)#key CISCO cisco(config—radius—server)#exit cisco(config)#aaa group server radius NPS cisco(config—sg—radius)#server name NPS cisco(config—sg—radius)#exit cisco(config)#aaa authentication login NPS group NPS local cisco(config)#aaa authorization exec NPS group NPS local cisco(config)#aaa authorization console cisco(config)#line console 0 cisco(config—line)#authorization exec NPS cisco(config—line)#login authentication NPS cisco(config)#line vty 0 4 cisco(config—line)#session—timeout 30 cisco(config—line)#authorization exec NPS cisco(config—line)#login authentication NPS cisco(config—line)#transport input ssh cisco(config)#line vty 5 15 cisco(config—line)#session—timeout 30 cisco(config—line)#authorization exec NPS cisco(config—line)#login authentication NPS cisco(config—line)#transport input none |
Пример настройки на Cisco WS-C3750V2-48TS 12.2(55)SE5
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
cisco(config)#aaa new—model cisco(config)#radius—server host 192.168.0.1 key Aa1234567 cisco(config)#aaa authentication login NPS group radius local cisco(config)#aaa authorization exec NPS group radius local cisco(config)#aaa authorization console cisco(config)#line console 0 cisco(config—line)#authorization exec NPS cisco(config—line)#login authentication NPS cisco(config)#line vty 0 4 cisco(config—line)#session—timeout 30 cisco(config—line)#authorization exec NPS cisco(config—line)#login authentication NPS cisco(config—line)#transport input ssh cisco(config)#line vty 5 15 cisco(config—line)#session—timeout 30 cisco(config—line)#authorization exec NPS cisco(config—line)#login authentication NPS cisco(config—line)#transport input none |
Это минимальная настройка аутентификации/авторизации на маршрутизаторах/коммутаторов Cisco.
Понравилась или оказалась полезной статья, поблагодари автора
ПОНРАВИЛАСЬ ИЛИ ОКАЗАЛАСЬ ПОЛЕЗНОЙ СТАТЬЯ, ПОБЛАГОДАРИ АВТОРА
Загрузка…
22nd July 2016
RADIUS is a form of network security that can link into your Windows Domain. The most common use (at least in my experience) is to secure Wireless Networks. Using RADIUS has the advantage of no shared key that has to be entered on each device, you can allow all domain computers to connect with their computer account and limit users to some trusted staff who only need their domain account to connect.
Before I started I had a fully functioning Windows Domain Controller with AD setup for normal use.
ADCS
Active Directory Certificate Services is used to generate the certificate that your RADIUS server will use to identify itself.
Open the Add Roles and Features wizard from server manager, select your DC and tick Active Directory Certificate Services.
Agree to the required features and click next. Click next again on the features screen and again on the AD CS screen.
On the Role Services screen you only need Certification Authority ticked.
Click Next and then confirm the install.
Once the install finishes click Configure Active Directory Certificate Services on the destination server.
In the wizard that pops up select the user you want to install the service as (in my case it was the same as my logged in user) and hit next.
When asked to Select Role Services to configure tick Certification Authority.
Select Enterprise CA and hit next, then select Root CA and hit next.
Select Create a new private key and hit next. On the Cryptographic screen change the hash algorithm from the insecure sha1 to sha256 and click next.
Leave the CA Name at the default and hit next, do the same with the validity period and database location.
On the Confirmation screen make sure that everything is as it should be and then hit Configure.
After configuration completes hit close.
NPAS
RADIUS is part of the Network Policy and Access Services role in Server 2008+ and is installed like the ADSC role.
Go to the Select Server Roles screen and tick Network Policy and Access Services, agree to the required features and hit next.
Hit next on the Features screen and again on the NPAS introduction.
On the Role Services screen you only need Network Policy Server selected.
On the Confirmation screen hit Install.
After the install finishes you can hit Close.
Open Network Policy Server from the start menu and before you configure your RADIUS network right click Templates Management -> Shared Secrets and select New.
Give your Key a name and either type in or generate a secret.
At this point I normally go into my Wireless system and create the new RADIUS network whilst I have my generated key in the clipboard.
With that template created head back to the main NPS screen and select RADIUS server for 802.1X Wireless or Wired Connections and click Configure 802.1X under it.
Select Secure Wireless Connections and click next (you can change the name if you want to).
You need to add each access point to the list which can be pretty tedious.
When adding an AP select the shared secret template we made earlier. Once you have added all your access points hit next.
On the Configure an Authentication Method screen select Microsoft: Protected EAP (PEAP) and click Configure.
Change to the certificate for your DC, dc.domain.local NOT domain-dc-ca.
On the Specify User Groups screen add your Domain Users and Domain Computers groups and click next.
Click next on the Configure Traffic Controls screen.
On the last screen confirm all the details and then hit finish.
Done
You now have a RADIUS a network! Domain joined computers can now connect with seemingly no password as their computer account allows them to authenticate. None domain devices can authenticate with any user account.
Adam Laycock
Network Manager, Developer & Blogger.
All content is my own unless otherwise stated.
My content is licensed under the CC-BY-NC-SA 4.0 license
В этой заметке будет рассмотрен пример настройки 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
Basic 802.1X Wireless network implementation requires an alphanumeric network key for access and authentication. In an enterprise environment this is not ideal. I’ve recently reconfigured and redesigned a client site’s WPAPersonal Wireless network for Radius (Remote Authentication Dial-In User Service) Authentication on an NPS (Network Policy Server) Server running on the Windows Server 2012R2 platform . Some of the benefits of this redesign are as follows:
1) User access control is managed with usernames and passwords in Active Directory. This replaces easily distributed and insecure network keys.
2) Administrators can more easily manage user and device credentials and centrally revoke access if and when necessary.
In this post, I provide my configuration steps in setting up Microsoft Protected Extensible Authentication Protocol with Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) version 2 authentication. The wireless network is built on the UniFi brand of Access Points with the Windows Server 2012 R2 Network Policy Server (NPS) as the RADIUS server.
Configuration and Setup Elements:
1) WS2012R2 Certificate Authority Server.
2) Network Policy Server on WS2012R2.
2) UniFi AC Access Points and Controller.
4) Group Policy Object configuration for Certificate Auto-enrollment and Wireless 802.1X.
Install and Configure the Active Directory Certificate Services and Certification Authority Role using PowerShell.
Use the following PowerShell cmdlet to install Active Directory certificate services for a Certification Authority role service on a domain joined member server.
Install-WindowsFeature -Name ADCS-Cert-Authority -IncludeManagementTools
Please note that after installation, the Certificate Authority Server will need to be configured as an Enterprise Certificate Root CA. Microsoft has a detailed step-by-step instruction on setting up an Enterprise CA server at the following NPS Server Certificate: CA Installation link.
A summary of the server configuration is as follows:
After the role installation, open the Server Manager console. On the Server Manager tab, click on the Configure Active Directory Certificate Server link and follow the wizard page.
On the Select Role Services page, ensure that Certification Authority is selected, select any additional role services that you require, and then click Next .
On the Specify Setup Type page, ensure that Enterprise is selected, and then click Next .
On the Specify CA Type page, click Root CA , and then click Next .
On the Set Up Private Key page, ensure that Create a new private key is selected, and then click Next .
On the Configure Cryptography for CA page, keep the default settings or change them according to your requirements. Note that the default Key character length is 2048, which is twice as large as previous default key character lengths of 1024. Depending on your network size and traffic, you might want to adjust the size of the key character length. Click Next .
On the Configure CA Name page, keep the suggested common name for the CA or change the name according to your requirements, and then click Next .
On the Set Validity Period page, in Select validity period for the certificate generated for this CA , type the number and select the time value (years, months, weeks, or days) that determines the date upon which certificates issued by the CA will expire. The default setting of five years is recommended. Click Next .
On the Configure Certificate Database page, in Certificate database location and Certificate database log location , specify the folder location for these items. I kept the default locations. If you specify locations other than the default locations, ensure that the folders are secured by using access control lists (ACLs) that prevent unauthorized users or computers from accessing the CA database and log files. Click Next , and then click Finish .
Configure Certificate Autoenrollment for the Designated Network Policy Server.
In this section, I’ll configure the certificate template that Active Directory® Certificate Services (AD CS) uses as the basis for the server certificate that will be enrolled to the Network Policy Server (NPS).
1) Login to the CA server running WS2012 R2, and open the Certificate Authority console.
2) In the CA management console, expand the tree, and right click on the Certificate Templates folder and select Manage.
3) In the Certificate Templates console, all of the certificate templates are displayed in the details pane.
4) In the details pane, click the RAS and IAS Server template. On the Action menu, click Duplicate Template . In the Duplicate Template dialog box, select the template version appropriate for your deployment, and then click OK . The new template properties dialog box opens.
5) On the General tab, in Display Name , type a new name for the certificate template. I renamed my template to RAS and IAS Server2.
6) Click the Security tab. In Group or user names , click RAS and IAS Servers . In Permissions for RAS and IAS servers , under Allow , select the Enroll and Autoenroll permission check boxes, and then click OK .
7) Back on the Certificate Authority page , expand the CA name, and then right click Certificate Templates, select New , and then click Certificate Template to Issue . The Enable Certificate Templates dialog box opens.
In Enable Certificate Templates , click the name of the certificate template you just configured, and then click OK . For this deployment, I changed my template name to RAS and IAS Server2, so I’ll click RAS and IAS Servers2 , and then click OK .
9) On the same server, open the Group Policy Management Console. Right click on the GPO folder and select New to create a new GPO . in the name field, enter a name for the new GPO. I called mine the NPS Certificates Policy. Click OK.
10) Open Computer Configuration , Policies , Windows Settings , Security Settings , and then select Public Key Policies. In the details pane, double-click Certificate Services Client – Auto-Enrollment . The Certificate Services Client – Auto-Enrollment Properties dialog box opens.
11) In the Certificate Services Client – Auto-Enrollment Properties dialog box, in Configuration Model , select Enabled . Select the Renew expired certificates, update pending certificates, and remove revoked certificates check box. Select the Update certificates that use certificate templates check box, and then click OK .
12) After you complete this procedure, servers running NPS automatically enroll a server certificate when Group Policy is refreshed. To refresh Group Policy, restart the server or, at the command prompt, run gpupdate . In the next section, I will install NPS. After the install, I’ll run gpupdate to auto enroll a server certificate for the NPS server.
Install and Configure the Network Policy Server Role using PowerShell.
Check for and verify availability of the Network Policy feature:
Install the Network Policy role using PowerShell:
Run gpupdate to autoenroll the Network Policy server for a server certificate.
Configure the Radius Client:
Open the Server Manager console and highlight the “All Server” command. Select the current server.
Navigate to the Tools menu and select the “Network Policy Server” command. This should open up the Network Policy Server console:
In the Network Policy Server console, expand the ‘Radius Clients and Servers’ folder, “Radius Clients” sub folder and select the New command.
In the “New Radius Client” dialog, enter the values for the following fields indicated the following screen shot and click ok. The Address field refers to the IP Address of the Access point. Run through this step for as many Access points and clients that need to be setup on the Radius server:
Configure Wireless Policy:
Highlight the NPS server folder, under the standard configuration drop down, select the “Radius Server for 802.1X Wireless or Wired Connections” standard config
Click the “Configure 802.1X” link.
In the “Select 802.1X Connection Type” window, select the “Secure Wireless Connections” option and leave the default name or change as needed. Click next.
In the “Specify 802.1X Switches” page verify that the Access Points configured under Radius Clients are in the list.Click next.
In the “Configure Authentication Method” page, select an EAP type from the drop down. I selected the “Microsoft:Protected EAP”.
Still on the “Configure an Authentication Method” page, click the Configure button to open the “Edit Protected EAP Properties” page.Add the EAP Type of “Secured Password (EAP-MSCHAPv2) and select the NPS server name for the “Certificate Issued to” field. This field is autopopulated because we already enrolled the NPS for a Network Policy certificate by running gpupdate.
In the “Specify User Groups” page, click Add to enter an Active Directory group for allowing access to group members based on the network policy. Click next.
Click next on the “Configure Traffic Controls” page.
On the “Completing New IEEE 802.1X Secured Wired and Wireless” page , click finish.
Configure Group Policy Object for Wireless Clients running Windows Vista and Later.
1) Open Group Policy Management Console. Right click on the GPO folder and select New to create a new GPO . in the name field, enter a name for the new GPO. I called mine the NPS Clients Configuration Policy. Click OK.
2) Open Computer Configuration , Policies , Windows Settings , Security Settings , and then right click Wireless Network (IEE802.11) Policies and select to “Create a New Windows Vista and Later Releases Policy”.
3) On the General tab, in Policy Name , type a new name for the policy, Lab Wireless Network Policy. In Description , type a description of your policy. Select the Use Windows WLAN AutoConfig for clients check box to specify that WLAN AutoConfig is used to configure wireless network adapter settings.
4) Still on the General tab, in the ‘Connect to available networks in the order of profiles listed below: section, click Add and then select Infrastructure to add and configure a new wireless profile. This will open a New Profile properties page.
5) On the Connection tab, in Profile Name, type a name for the profile. In Network Name(s) (SSID), type the service set identifier (SSID) for your wireless APs, and then click Add .
6) To specify that wireless clients automatically connect to wireless APs for which the SSID is specified in Network Name(s) (SSID) , select Connect automatically when this network is in range .
7) Click the Security tab. In Select the security methods for this network , in Authentication , I selected WPA2-Enterprise for my Access points. In Encryption , I selected AES. The settings for both Authentication and Encryption match the settings configured on my wireless AP.
In Select a network authentication method , I selected Microsoft: Protected EAP (PEAP) . In Authentication mode , I selected: User authentication. In Max Authentication Failures I entered 2. I enabled the check box for Cache user information for subsequent connections to this network.
9) Click Properties of the network authentication method, the Protected EAP Properties dialog box opens. In Protected EAP Properties , I enabled “Verify the server’s identity by validating the certificate” check box and the “Connect to these servers:” check box. I entered the fully qualified domain name of my radius server(NPS Server) in the text field.
10) In Trusted Root Certification Authorities , I selected the trusted root certification authority (CA) deployed in my domain as described earlier in this post that issued the server certificate to my server running Network Policy Server (NPS). Please note that this setting limits the trusted root CAs that clients trust to the selected CAs. If no trusted root CAs are selected, then clients trust all root CAs listed in their trusted root certification authority store.
11) For “notifications before connecting”, I selected “Tell user if server name or root certificate is not specified”.
12) In Select Authentication Method , select Secured Password (EAP-MS-CHAP v2) . Enable PEAP Fast Reconnect, by selecting Enable Fast Reconnect . Click Configure . In the EAP MSCHAPv2 Properties dialog box, verify Automatically use my Windows logon name and password (and domain if any) is selected, click OK , and then click OK to close Protected EAP Properties .
13) On the Network Permission tab you can use the tick boxes to restrict clients to infrastructure networks or only GPO profiled allowed networks if you wish.
Configure my Unifi Wireless Access Points.
1) I’m using the Unifi Access Points. I’ll login, create a new wireless network and configure for Radius parameters with the highlighted values.
The IP Address field references the IP Address of the Network Policy server. I made sure to match the Radius Server Password/Shared Key with the shared key configured for the Access Point in the Network Policy Server in the “Install and Configure the Network Policy Server Role using PowerShell” section.
Connect Client PC Running Windows 10 to the Wireless Network.
To test the Radius configuration, login to a Windows laptop and run gpupdate to apply the Group Policy settings to the client machine. The screen shots below show the before and after status of the ITTEST Wi-Fi profile. You can choose to enter your username and password manually or check the box to connect automatically.
A Virtual Private Network (VPN) allows to connect to a private network through the Internet, from anywhere in the world.
It may be very helpful to business users willing to access from outside the internal resources of their company.
In this post we’ll see how you can allow Active Directory users to perform the login to a VPN, configured on a Cisco router.
The setup includes a Cisco 1801 router, configured with a Road Warrior VPN, and a server with Windows Server 2012 R2 where we installed and activated the domain controller and Radius server role.
To facilitate the management of the users with the permission to access through VPN, we are going to create a specific group called VpnAuthorizedUsers:
Assign the user who needs the VPN access to the group VpnAuthorizedUsers:
Launch Server Manager and select Add Roles and Features:
Select the server where to install the role:
Select the role Network Policy and Access Services:
Install the required features:
Select Network Policy Server:
Press Install to start the installation of the role:
Press Close to exit from the wizard:
Procced with the configuration of the Radius server selecting NAP, then right-click on the server name and press Network Policy Server:
Right-click on NPS and select Register server in Active Directory:
Collapse the Radius menu and right-click on RADIUS Clients:
Specify the name and the IP address of the peripheral that will forward the authentication requests to the Radius. Also specify a password for the connection:
Expande Policies and right-click on Connection Request Policies:
Specify a policy name:
Add a Client Friendly Name condition:
Specify the same name used for the Radius Clients:
Click Next:
Select the attribute User-Name and click Next:
Right-click on Network Policies:
Specify the policy name:
Specify the UserGroups condition:
Add the group VpnAuthrizedUsers that you’ve precedently created:
Enable the PAP,SPAP access:
Press NO at the following dialog:
Once the Road Warrior VPN has been configured on the Cisco router, you have to enable the authentication of the VPN users through Radius.
The local command allow local users of the router to connect even if the Radius server is offline:
conf t
aaa authentication login vpnuser group radius local
Be sure the crypto map command has the same name of aaa authentication:
Access in configuration mode (Configure terminal) and specify the radius parameter with the IP address and the password specified at the beginning of the tutorial:
radius-server host 10.0.0.1 auth-port 1812 acct-port 1813 key password xxxxxxxxx