Windows server 2012 подключиться к сеансу пользователя

Configuring Cisco devices to authenticate management users via RADIUS is a great way to maintain a centralized user management base. Traditionally this has been done using the Cisco Access Control Server (ACS) which of course is fairly expensive and is typically out of the price range for most small & medium sized businesses.

If you are like most businesses you may already have an Active Directory infrastructure deployed and thus you already have the necessary software and licenses required to setup a basic RADIUS server using Network Policy Server (NPS) which can be used to authenticate network administrators on your Cisco IOS equipment for management purposes. The main benefit you get from RADIUS authentication is a centralized management console for user authentication and the ability to control which users have access to the Cisco CLI. So look at it this way; if your company hires or fires an employee than whatever changes are applied in Active Directory will take affect immediately. Such as disabling a user account in AD would result in failed authentication attempts for that username when attempting to log into a Cisco device. Also if you have a new employee, you can easily give their username access to Cisco network devices just by adding them into a Security Group in active directory.

This blog will discuss and demonstrate the configuration of Network Policy Server which is included with Windows Server 2008 and greater however will blog concentrate on Windows Server 2008 R2.

Active Directory Configuration

First there are a few small task you must complete in Active Directory. You must create two Security Distribution Groups called Network Engineers and Network Support Technicians

Network Engineers will have level 15 privileges and thus have full read/write permissions to the Cisco Command Line interface after successfully authenticating to Cisco routers and Switches.

Network Support Technicians however will only have Read Only privileges.

Next you will need to assign users to these groups. For the purposes of this blog I have created two users, John Doe and John Smith.

John Doe (Username: jdoe) is a Network Engineer and John Smith (Username: jsmith) is a Network Support Technician. These users will be used to verify the configuration and operational status of NPS.

Once you have completed the basic Active Directory configuration you can move on to the NPS config. Please note that the Security Groups can be named whatever you like.

Windows Network Policy Server Configuration

Prior to configuring NPS it must first be installed and authorized in Active Directory. To install NPS add the “Network Policy and Access Services” role to your server.

After you have authorized NPS in Active Directory you’re ready to add the first RADIUS Client. To add the client you must expan the RADIUS Clients and Servers line and right click on RADIUS Clients and click “NEW”.

You’ll be prompted to enter the Friendly Name and Address, IP address and Shared Secret. Enter this information as required. For this blog we’re using R1 which had the IP address of 172.16.22.215 and the secret of CISCO as shown below;

Note that ND_ is used as a prefix to the device friendly name, this will be used later in the configuration of the NPS Policy which can identify network devices.

Next, click the Advanced Tab across the type and select “Cisco” as the vendor name from the drop down list and click ok;

If you added the client correctly you should see the client friendly name, IP address and other information listed in the RADIUS Clients section;

Now you’re ready to configure the network policy which will authenticate users in the specific active directory groups and grant them access.

to create a new policy you need to expand the Policies item in the left list and right click on “Network Policies” and click NEW.

You must enter a name for the policy, in this case we’re going to use “Network Engineers (Cisco LEVEL 15)”

After you have provided a policy name you must than configure the conditions which are required to match in order to successfully authenticate. You will need to create two conditions;

Configure a User Group to match the Network Engineers security group and the Client Friendly Name to match “ND_?” which denotes the device authenticating has a friendly name starting with ND_

Once you’ve successfully added these conditions you should see the following;

Click next and you’ll be prompted to specify the access permission, leave this as the default “Access Granted” and click next.

Cisco only supports the “Unencrypted authentication (PAP, SPAP) methods. Uncheck everything and check “Unencrypted authentication (PAP, SPAP) as shown below and click next;

After configuring the Authentication Methods you will be prompted to configure the Constraits, you can skip this section and just click next.

When prompted to configure settings, remove the Framed-Protocol and edit the Service-Type and set it to “Login” which is under “Others” as shown below;

Next you will need to add a Vendor Specific Attribute by clicking on “Vendor Specific” under the left side settings and clicking the Add… button

Scroll down the list and select “Cisco-AV-Pair” and click add. You will be prompted to add the Attribute Information, here you will click Add… and set the attribute value as shell:priv-lvl=15

This specifies which privilege level is returned to the authenticating user/device after successful authentication. For Network Engineers this would be shell:priv-lvl=15 and the Network Support Technicians would use shell:priv-lvl=1

When added successfully you should see the following;

After you click next you will be presented a summary of the new network policy that you just created as shown below;

Click finish and you’re ready co configure the Cisco Routers and Switches to authenticate to the NPS Radius Server. Please note that you will need to create another policy for the Network Support Technicians and any other privilege levels you wish to use.

Cisco IOS AAA Configuration

The very first thing we need to do prior to configuring AAA is to setup a local user account so that when the RADIUS server has failed, you have the ability to still log into the device. This is done using the username command as demonstrated below;

R1 con0 is now available

Press RETURN to get started.

R1>enable
R1#config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#username NORAD priv 15 secret R@du3F@1led
R1(config)#

Now we can enable AAA new model and configure the radius server group and default authentication list as demonstrated below;

R1(config)#username NORAD priv 15 secret R@du3F@1led
R1(config)#aaa group server radius NPS_RADIUS_SERVERS
R1(config-sg-radius)#server-private 172.16.22.228 auth-port 1812 acct-port 1813 key CISCO
R1(config)#aaa authentication login default group NPS_RADIUS_SERVERS local
R1(config)#aaa authorization exec default group NPS_RADIUS_SERVERS local if-authenticated
R1(config)#aaa authorization console

INFO: Users will ONLY authenticate to the RADIUS servers if the RADIUS server is alive when defining the default aaa authentication list using group NPS_RADIUS_SERVERS followed by local. If you are attempting to log into the device using a local account and the Radius servers are accessable than it will reject the authentication unless the local account used to log in also exist in Active Directory and are member(s) of the Network Engineers or Network Support Technicians security group.

And that’s it for the basic Cisco IOS AAA config. You can however get into some more advanced configurations by using AAA list and applying a radius authentication list to the VTY lines and local authentication only to the console line.

Verification

Now for the fun part, verification. If you completed all the steps correctly you should be able to log in using the jdoe username and be automatically placed into privilged mode as demonstrated below;

And also if you configured the second policy for Network Support Technicians, you should be able to authenticate as jsmith and be placed into user mode as shown below;

If you have any questions or suggestions please comment 🙂

Comments are closed.

Источник

В этой заметке будет рассмотрен пример настройки 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 (KOM\KOM-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, при условии, что эта учетная запись включена в ранее указанную в политике доменную группу безопасности KOM\KOM-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.com\KOMI Root CA" -ca.cert "C:\Temp\CertificateRootCA.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:\Temp\CertificateRootCA.cer"

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

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

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

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

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:\Temp\RequestConfigVPNServer.inf" "C:\Temp\RequestBinaryVPNServer.req"

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

***

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

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

certreq –submit –f -config "kom-ad01-ca01.holding.com\KOMI Root CA" "C:\Temp\RequestBinaryVPNServer.req"

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

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

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

certreq -retrieve -f -config "kom-ad01-ca01.holding.com\KOMI Root CA" 31 "C:\Temp\CertificateVPNServer.cer"

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

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

***

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

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

certreq –submit –f -config "kom-ad01-ca01.holding.com\KOMI Root CA" "C:\Temp\RequestBinaryVPNServer.req" "C:\Temp\CertificateVPNServer.cer"

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

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

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

***

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

certreq -accept "C:\Temp\CertificateVPNServer.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.com\KOMI 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

Источник

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

Установка роли Network Policy Server на Windows Server 2012 R2

После окончания установки запустите 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.

Административный доступ к сетевому оборудованию с помощью RADIUS

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

И, напоследок, переместим новую политику на первое место в списке политик.

Настройка сетевого оборудования для работы с сервером 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 ). Если подключение установлено – вы все сделали правильно!

Доменна авторизация на коммутаторе HP ProCurve

Для коммутатора 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 сервера

Источник

Подключение
Windows Logon
Общие сведения

MULTIFACTOR Logon — программный компонент, экран входа в операционную систему Windows. Работает как при локальном входе в операционную систему, так и при подключении через удалённый рабочий стол.

Компонент в виде установочного файла (ver. 1.4.1) распространяется бесплатно.

Все версии

25.08.2023 — MultifactorLogonSetup.exe (ver. 1.4.1)
- Добавлена поддержка 32 битных операционных систем.
- При установке новой версии поверх старой настройки будут сохраняться.
- По умолчанию включен режим Bypass.
- В конфигураторе в allow-списки можно добавлять PLAP провайдеров.
18.05.2023 — MultifactorLogonSetup.exe (ver. 1.3.1)

В случае использования параметра IncludeDomain, имя пользователя и домен будут передаваться на сервер в формате Pre-Windows 2000.
19.04.2023 — MultifactorLogonSetup.exe (ver. 1.3.0.3)

Новый параметр ConsoleMode (/consolemode=true), данный флаг отключает дополнительные окна, рекомендуется использовать на системах типа CORE.
04.04.2023 — MultifactorLogonSetup.exe (ver. 1.3.0.2)

Добавлена возможность смены пароля в случае, если пароль просрочен.
22.02.2023 — MultifactorLogonSetup.exe (ver. 1.3.0.1)

Исправлена ошибка в работе параметра Network Bypass List.
13.02.2023 — MultifactorLogonSetup.exe (ver. 1.3.0)

Добавлена возможность смены пароля при возникновении соответствующего требования.
08.02.2023 — MultifactorLogonSetup.exe (ver. 1.2.9)

Новый параметр Use DOMAIN\user format (/includedomain=true). Если включен, то логин доменных пользователей передается на сервер в формате DOMAIN\username.
11.11.2022 — MultifactorLogonSetup.exe (ver. 1.2.8.1)

Исправлена ошибка с работой параметра SkipUsers для доменных пользователей.
27.10.2022 — MultifactorLogonSetup.exe (ver. 1.2.8.0)

Обновление инсталлятора. Исправлена некорректная обработка последних символов закрывающей фигурной скобки } в параметрах /whitelist и /rdpwhitelist при установке через CLI.
16.09.2022 — MultifactorLogonSetup.exe (ver. 1.2.8.0)

Новый параметр SkipUsers (/skipusers) — список пользователей, для которых проверка второго фактора будет пропускаться.
05.09.2022 — MultifactorLogonSetup.exe (ver. 1.2.7.1)
- Теперь конфигуратор можно запустить только от имени администратора, иначе выводится предупреждение и конфигуратор закрывается;
- Добавлен параметр инсталлятора /debuglog=true.
01.08.2022 — MultifactorLogonSetup.exe (ver. 1.2.7)
26.07.2022 — MultifactorLogonSetup.exe (ver. 1.2.6.4)
21.07.2022 — MultifactorLogonSetup.exe (ver. 1.2.6.3)
20.07.2022 — MultifactorLogonSetup.exe (ver. 1.2.6.2)
13.07.2022 — MultifactorLogonSetup.exe (ver. 1.2.5.2)
11.07.2022 — MultifactorLogonSetup.exe (ver. 1.2.5.1)
06.07.2022 — MultifactorLogonSetup.exe (ver. 1.2.5)
06.07.2022 — MultifactorLogonSetup.exe (ver. 1.2.4)
07.06.2022 — MultifactorLogonSetup.exe (ver. 1.2.3)
25.05.2022 — MultifactorLogonSetup.exe (ver. 1.2.2)
13.05.2022 — MultifactorLogonSetup.exe (ver. 1.2.1)
25.04.2022 — MultifactorLogonSetup.exe (ver. 1.2.0)
21.04.2022 — MultifactorLogonSetup.exe (ver. 1.1.5)
09.03.2022 — MultifactorLogonSetup.exe (ver. 1.1.0)

Данная статья описывает настройку входа на рабочую станцию или сервер на основе операционной системы Windows с логином и паролем и вторым фактором с использованием установленного в вашей сети RADIUS адаптера, либо через облачный сервер radius.multifactor.ru.

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

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

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

Мобильное приложение Multifactor
Telegram
Аппаратные OTP токены
Приложения OTP: Google Authenticator или Яндекс.Ключ
СМС

Может быть полезно

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

Требования для установки компонента

Десктопная ОС Windows 7 или выше;
Серверная ОС Windows Server 2012 или выше;
Открытый исходящий порт 1812 UDP для отправки запросов по RADIUS протоколу;
Сетевой доступ к radius.multifactor.ru или RADIUS адаптеру, установленному в локальной сети;
Свежая версия Microsoft Visual C++ Redistributable x64 или x86.

Принцип работы

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

Поддерживаемые типы учётных записей

Локальные пользователи

Пользователи Active Directory

Учётные записи Microsoft

Вход с локальной учетной записью на локальном экране входа или экране блокировки Windows может осуществляться в одном форматов:

<computername>\<username>
.\<username>

При входе с локальной учётной записью логин пользователя будет передан на RADIUS сервер в формате <username>@<pcname>.

Вход с доменной учётной записью на локальном экране входа или экране блокировки Windows может осуществляться в одном форматов:

<username>
<domain>\<username>
<username>@<upnsuffix>

Вход с учётной записью Microsoft на локальном экране входа или экране блокировки Windows может осуществляться в формате:

microsoftaccount\<username>

Дополнительные возможности и ограничения

Поддерживает аутентификацию через несколько RADIUS серверов, используя Status-Server (12) запрос для мониторинга доступности;
Позволяет конфигурировать доступные для пользователя методы аутентификации;

Ограничения при работе через radius.multifactor.ru

Не принимает кириллические имена учётных записей при работе через radius.multifactor.ru;
Настройка второго фактора в режиме диалога с пользователем не работает при использовании radius.multifactor.ru.

Важно помнить

Не завершайте сессию текущего пользователя до тех пор, пока не убедитесь, что всё корректно настроено и работает.

Настройка MULTIFACTOR

Зайдите в административную панель, далее в раздел «Ресурсы» и создайте новый ресурс типа «ОС / Сервер» — «Windows»;
Заполните «Название», «Адрес» и «Язык» по вашему усмотрению, установите переключатель в «Запретить доступ» в разделе «При подключении без настроенного второго фактора»;
После создания вам будут доступны два параметра: NAS Identifier и Shared Secret, они потребуются для следующего шага.
Если планируете размещать сервер RADIUS в локальной сети, установите и настройте RADIUS адаптер. Переименуйте файл шаблона Clients/winlogon.config.template в Clients/winlogon.config и настройте его следующим образом:

<!-- Идентифицировать клиентов по заданному RADIUS артибуту NAS-Identifier -->
<add key="radius-client-nas-identifier" value="windows"/>

<!-- Shared secret общий для WinLogon и адаптера -->
<add key="radius-shared-secret" value="SHARED_SECRET"/>

<!-- Где проверять первый фактор: None (не проверять) -->
<add key="first-factor-authentication-source" value="None"/>

<!-- Multifactor API -->
<add key="multifactor-nas-identifier" value="NAS Identifier из личного кабинета MULTIFACTOR"/>
<add key="multifactor-shared-secret" value="Shared Secret из личного кабинета MULTIFACTOR"/>

<!-- Дополнительные настройки для Windows-версии RADIUS адаптера -->
<!-- Active Directory domain -->
<!-- <add key="active-directory-domain" value="domain.local"/> -->

<!-- Разрешить доступ только пользователям группы AD -->
<!-- <add key="active-directory-group" value="VPN Users"/> -->

<!-- Проверять второй фактор только у пользователей из группы AD -->
<!-- <add key="active-directory-2fa-group" value="2FA Users"/> -->

Если вы планируете использовать облачный сервер radius.multifactor.ru, пропустите этот шаг.

На рабочей станции установите приложение MultifactorLogonSetup.exe. После завершения установки будет запущен конфигуратор. Если вы сняли галочку «Run Config» во время завершения установки, запустите конфигуратор mfLogonConfig.exe от имени администратора в папке с установленным компонентом.

На вкладке General:

Hosts — укажите ip или имена хостов с настроенными адаптерами;
Port — порт настроенного адаптера, должен быть одинаковых для всех хостов;
Timeout(sec.) — таймаут запроса доступа (30);
Retransmit count — количество попыток запроса доступа (2);
Shared Secret — Указывайте значение в зависимости от типа развертывания:
1. Локальный RADIUS адаптер c настроенной идентификацией клиентов: укажите значение, заданное в параметре radius-shared-secret в клиентском файле конфигурации.

<add key="radius-shared-secret" value="SHARED_SECRET"/>

Локальный RADIUS адаптер без идентификации клиентов: укажите значение, заданное в параметре radius-shared-secret в корневом файле конфигурации.

<add key="radius-shared-secret" value="SHARED_SECRET"/>

Облачный radius.multifactor.ru: укажите Shared Secret (п.3) из ресурса WinLogon в панели администратора Multifactor.

Nas Identifier — используется для идентификации клиента. Указанное значение передается в запросе доступа на RADIUS сервер в RADIUS-атрибуте NAS-Identifier. Указывайте значение в зависимости от типа развертывания:
1. Локальный RADIUS адаптер c настроенной идентификацией клиентов: укажите значение, заданное в параметре radius-client-nas-identifier в клиентском файле конфигурации.

<add key="radius-client-nas-identifier" value="windows"/>

Локальный RADIUS адаптер без идентификации клиентов: оставьте пустым;
Облачный radius.multifactor.ru: укажите NAS Identifier (п.3) из ресурса WinLogon в панели администратора Multifactor.

Network Bypass List — подключения по RDP из указанных подсетей будут осуществляться без запроса второго фактора. Пример значения: 10.10.*,192.168.1.0/24,127.0.0.1-127.0.0.5
Domain — укажите домен ActiveDirectory для его автоподстановки в поле «Логин» на экране блокировки и на локальном экране входа;
Use Host as StationId — если включено – передавать имя хоста клиента вместо IP клиента при подключении через RDP (влияет также на текст в запросе доступа в мобильном приложении и Telegram-боте MULTIFACTOR);
Sign In Filter — если включено, в качестве методов входа разрешены только методы из белого списка (вкладка White Lists);
Bypass — если включено, проверка второго фактора будет пропущена при недоступности всех RADIUS серверов. Доступность определяется отправкой RADIUS запроса Status-Server в момент подключения. Запрос осуществляется последовательно на каждый RADIUS сервер из списка Hosts с таймаутом 2 секунды и количеством ретрансмитов запроса – 2;
Debug Log — если включено, в папке с установленным компонентом создается файл debuglog.txt с отладочной информацией;
SkipUsers — список пользователей, для которых проверка второго фактора будет пропускаться:
- Пользователей необходимо указывать через запятую без пробелов;
- Локальные пользователи указываются в формате: .\username;
- Доменные пользователи указываются без домена в формате: username;
- Microsoft-пользователи указываются с полным названием аккаунта.

Поддерживаются служебные имена:

local_users — все локальные пользователи;
domain_users — все доменные пользователи;
microsoft_users — все Microsoft пользователи.

Use DOMAIN\user format — если опция включена, то логин доменных пользователей будет передаваться на сервер в формате DOMAIN\username.

На вкладке WhiteLists:

Если включен параметр Sign In Filter, задайте разрешенные методы для локального входа и подключения через RDP.

Протестируйте конфигурацию, нажав на кнопку Check Settings на вкладке General. Если связность с RADIUS серверами настроена корректно, тест должен вернуть OK для каждого сервера в списке Hosts.

В Административной панели создайте пользователя, с которым будете использовать второй фактор, и вышлите ему ссылку на настройку второго фактора на почту.
Настройте второй фактор для пользователя.
Система готова к использованию.

Проверка

Важно

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

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

Загрузка в безопасном режиме

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

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers]
"ProhibitFallbacks"=dword:1

Убедитесь, что:

Машина подключена к сети через LAN (WiFi не подключится в безопасном режиме);
RADIUS Адаптер не установлен локально на одной машине с Windows Logon. В безопасном режиме служба адаптера не будет запущена.

Внимание

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

Если что-то не работает

Последовательно проверьте, что вы ничего не упустили:

Установлена свежая версия Microsoft Visual C++ Redistributable x64 или x86;
С рабочей станции открыт доступ по UDP порту 1812 на адреса вашего RADIUS адаптера или radius.multifactor.ru;
Операционная система имеет 64 битную разрядность (рекомендуется);
Параметры Nas Identifier и Shared Secret указаны корректно;
Пользователю настроен хотя бы один второй фактор;
Проверьте журнал «Запросы доступа» в Личном кабинете;
Проверьте события в системном журнале Windows от источника MultifactorLogon и LogonUI;
Доступ без второго фактора доступен при загрузке в безопасном режиме.

Обновление

Удалите «MULTIFACTOR Logon» из списка установленного в операционной системе ПО. Установите компонент заново.

Удаление компонента

Удалите «MULTIFACTOR Logon» из списка установленного в операционной системе ПО.

Последнее обновление 17 февраля 2025 г.

Источник

23 thoughts on “Microsoft | Windows Server 2012 Radius setup”

nice guide. this page was the 4th ranked page when i googled “server 2012 r2 radius” so i think you may want to consider cleaning up the screenshots. even clicking to the bigger images was like looking at them through a wet paper towel
1. the pictures are just small. I’ve to redo the pictures which will be done in the up coming days. How ever it’s not much difference with a configuration on Windows server 2008 R2 🙂
Pingback: » How my Wifi is unique
1. It’s a nice blog unfortunately, I need to use a translator for it to read this blog post 🙂
  When you need such setup it’s great to use.
Do you know if it possible to apply certain policies to certain clients, ie I want AD Group X to be able to authenticate on client X and AD group Y to be able to authenticate on client Y and so on?
1. In the Small Business Server edition of 2008 and 2011 you are able to select where a user can connect to a computer. At the moment I am unable to look for this policy.
It works if the IP-adress in the accept is static, but how to use an adress of an IP-Scope?
Does the server you use need to be a Domain Controller?
1. no it’s not needed to be a domain controller.
The prompt after clicking “Register Service in Active Directory” says “clients must be authorized to read dial-in properties, etc.” Is it assumed my clients are authorized if they’re in the user list, or should I make sure some other setting is right first? Up until now, we’ve only used AD as authentication for a bunch of Macs to get on Windows Remote Desktop. I don’t want to kick everyone out and have to scramble to undo what I did. Thanks,
Jeff
ps. GREAT GUIDE!
1. Jeff, there you choose how to say that clients can authenticate. If you create a security group in the Active Directory, it will be easier to maintain. Otherwise you need to change the dial-in properties of every user.
  I think the best solution for you is to create a security group > put the users in there > add group to the radius settings and your done. You don’t need to change the dial-in properties.
  I hope this will help you.
we use Dlink DWC2000 controller & 8610 AP, on Windows Radius server ” Radius Clients” , should we add all AP ip address or only controller ip is sufficient ?
1. It depends on the brand. for example a cisco wlan controller it’s not needed while for a netgear wlan controller you need to add all AP’s to the radius setup
  1. what do you recommend, irrespective of bands ? should we add AP also in Radius Clients.
    At the moment with controller its working, so cross checking.
If it’s working now only with the controller installated. it’s not need to change it. ulease the vendor expliciet recommends it in it’s documentation for example the AP’s of netger we have running in our office are basically standalone but connected to the wlan controller this is why we need to add the ap’s of netgear to the radius.
1. users are able to connect to Radius & users gets ip address also, but sometimes users are facing disconnection & connectivity with APIPA Ip address.
  What could be reason for users getting APIPA IP, we have sufficient ip address on DHCP pool.
  With WPA2 we don’t have such APIPA issue, with radius we are seeing this random APIPA issues.
Should the radius server be a member of the domain it’s passing authentication to ?
1. 1. Thanks Fred .
Hey Fred, nice post. Do you know if you can configure 2012R2 NTP Radius to support One Time Password (OTP) from a radius client? In my case the client would be a NetScaler AAA brokering incoming connections. I know NetScaler supports it but cannot find clear information regarding Radius…
1. I didn’t know that should check that out when I got the time.
Hey Fred, great guide. I am unable to register server in Active Directory. I am using it to authenticate to Juniper switches and routers, which do not use Active Directory credentials. Can I just skip that part and add clients?

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Источник

Active Directory Configuration

Windows Network Policy Server Configuration

Cisco IOS AAA Configuration

Verification

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

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

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

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

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

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

2. Проверка подключения VPN-клиента по протоколу 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-сервере и VPN-клиенте

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

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

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

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

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

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

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

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

Установка и настройка сервера с ролью Network Policy Server

Настройка сетевого оборудования для работы с сервером RADUIS

Требования для установки компонента

Принцип работы

Поддерживаемые типы учётных записей

Дополнительные возможности и ограничения

Ограничения при работе через radius.multifactor.ru

Настройка MULTIFACTOR

Проверка

Загрузка в безопасном режиме

Если что-то не работает

Обновление

Удаление компонента

23 thoughts on “Microsoft | Windows Server 2012 Radius setup”

Leave a Reply