Настройка radius windows server 2018 r2: Настройка Radius аутентификации с Windows Server 2012 NPS (Network Policy Server) на Cisco IOS

Cisco 802.1x + Windows 2012R2 NPS

Возникла такая задача\желание сделать в организации авторизацию по проводу через внутренний Radius сервер и Cisco 802.1x, поскольку инфраструктура строится на Wind домене был выбран встроенный механизм NPS.

Для начала нужно проверить что оборудование и сервер видят друг друга по портам 1812 и 1813.

Затем на NPS Сервере нужно создать Connection Request Policy.

Выглядит она так:

Никаких особых настроек, за исключением только типа подключения – NAS – Ethernet

Затем в Templates нужно завести SharedSecret, можно конечно каждый раз вносить его в ручную, но через шаблон это удобнее.

Затем в RADIUS Clients нужно добавить IP нашего коммутатора, с которого будут прилетать запросы на авторизацию:

Как раз тут и пригодится шаблон секрета, в случае если коммутаторов много – меньше шансов ошибиться.

После этого начинается самое интересное, нужно создать политики авторизации как клиентов, так и устройств которые не умеют 802. 1x

Сперва пишем политику для пользователей.

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

Механизмы авторизации указываем EAP и MSCHAP v2

И в NAS так же указываем тип – Ethernet

Тут самое интересное, мы добавляем в Standart следующие параметры:

Tunnel-Medium-Type – 802

Tunnel-Type – Virtual VLANs

Tunnel-Pvt-Group-ID – 100 (Это VLAN в который после авторизации коммутатор поместит клиента, в моем случае это 100 VLAN)

А в Vendor Specific Указываем Tunnel-Tag – 100 (Так же номер VLAN)

И после этого можно уже настраивать коммутатор, для этого на нем нужно ввести такие настройки:

aaa new-model
aaa authentication dot1x default group radius
dot1x system-auth-control
radius-server host ххх.ххх.ххх.ххх
radius-server key суперсекретныйкод

И уже на нужном нам интерфейсе, или на всех если вы поехавший, делаем такие настройки:

interface GigabitEthernet0/46

switchport mode access
authentication event fail action authorize vlan 71

// Это мы указываем в какой влан попадет устройство в случае неудачной авторизации, в моей сети 71 – гостевой vlan.
authentication event no-response action authorize vlan 71

// Тоже самое, но только если устройство не может\не хочет авторизоваться – попадает в 71.

authentication port-control auto
dot1x pae authenticator
dot1x timeout quiet-period 15
dot1x timeout tx-period 3
no cdp enable
spanning-tree portfast

И все, после подключения в этот порт – устройство обязано авторизоваться дабы попасть в рабочий VLAN.

Но это только часть беды, есть же устройства которые не умеют 802.1х, и для этого мы будем использовать механизм авторизации по MAC адресу устройства. В моем случае это камеры видео-наблюдения.

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

Условиями авторизации, появляется параметр PAP, SPAP

И  Tunnel-Pvt-Group-ID  и Tunnel-Tag, нужно будет указать какой VLAN вы будете отдавать при авторизации по MAC.

Но это не самое интересное, самое интересное что для каждого устройства в домене должен быть пользователь у которого username и пароль будут равны его мак адресу, к примеру если у устройства mac адрес 12-34-56-78-90-AB, то в домене должен быть пользователь с логином 1234567890ab и паролем 1234567890ab.

Причем ВАЖНО, Логин и пароль должен быть именно в таком виде, и в нижнем регистре.

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

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

AD DS — Создание нескольких политик паролей Password Settings objects (PSOs) в домене Windows Server 2008/2008 R2

И после написания отдельной политики – создаем пользователя, присваиваем ему группу доступа отвечающую за VLAN и группу с пониженным требованием к паролю.

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

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

И собственно после этих манипуляций нужно на Cisco добавить в строке интерфейса всего 1 строчку – mab

Таким образом настройки интерфейса выглядят так:

interface GigabitEthernet0/46
description Besdima_Test
switchport mode access
authentication event fail action authorize vlan 71
authentication event no-response action authorize vlan 71
authentication port-control auto
mab
dot1x pae authenticator
dot1x timeout quiet-period 15
dot1x timeout tx-period 3
no cdp enable
spanning-tree portfast

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

Полный список кодов информации о состоянии

0 – 37: http://technet. microsoft.com/ru-ru/library/dd197464(v=ws.10).aspx

38 – 257: http://technet.microsoft.com/ru-ru/library/dd197521(v=ws.10).aspx

258 – 282: http://technet.microsoft.com/ru-ru/library/dd197582(v=ws.10).aspx

283 – 303: http://technet.microsoft.com/ru-ru/library/dd197508(v=ws.10).aspx

настройка FreeRadius 3 на доменную авторизацию (Samba 4.4, Active Directory). Хождение по мукам…

Дано: существующий
домен-контроллер (DC) на Windows Server 2012 R2, заполненный Active Directory (AD) каталог пользователей.

Задача: поднять
бесплатный RADIUS сервер и настроить его на аутентификацию
пользователей через вышеуказанный AD.

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

В
качестве источника бесплатного готового решения Caprive
портала был выбран pfSense 2. 3, которому для сторонней (в том числе доменной) авторизации
пользователей нужен радиус-сервер.

Статья больше является неким логом действий и
ошибкок от закоренелого Windows-админа, поэтому не судите строго, это заметка для unix-чайников от unix-чайников.

В
качестве радиус сервера был выбран бесплатный FreeRadius версии
3.

В
качестве операционной системы для него — FreeBSD 10.3

Допустим,
что FreeBSD 10.3 уже установлена.

Дистрибутив FreeBSD/releases/amd64/amd64/ISO-IMAGES/10.3/

Зададим, например,
следующие исходные данные:

Пусть
имя ПК с FreeBSD и радиусом будет:
FreeRADIUS-AO
Его IP: 192.168.10.30

IP ПК с pfSense: 192.168.10.12

IP DC (домен контроллеров): 192.168.10.4 и 192.168.0.4

Домен:
corp.domain.net

Логинимся
на машину FreeRADIUS-AO и
переходим в режим суперадмина (рута, su).

Если
удобнее работать из Windows, то можно подключиться через ssh клиент PuTTY:

Для
удобства сразу установим файловый менеджер MC (Midnight Commander)

# pkg
install mc

Запустить
его без псевдографики можно по команде:

# mc
-a

Т. к.
входить на машину сразу под рутом через тот же PuTTY не рекомендуется, входим
под другим пользователем, например, admin, который предварительно должен быть
добавлен в спец. группу wheel. Добавляем так:

# pw
groupmod wheel -m admin

#
pw groupshow wheel

Вход
под суперпользователем (root):

$ su

Настраиваем
сервера времени на контроллеры домена CORP.DOMAIN.NET

Где, dc1.corp.domain.net и dc2.corp.domain.net имена контроллеров домена.

В
файле /etc/resolv.conf должны быть правильно
настроены наши адреса домен-контроллеров.

nameserver
192.168.10.4

nameserver
192.168.0.4

search corp.domain.net

В файле /etc/hosts
прописываем домены:

127.0.0.1 localhost

192.168.10.30
freeradius-ao.corp.domain.net freeradius-ao

Смотрим,
что уже установлено, какие пакеты имеются:

#
pkg info

Проверяем нет ли
обновлений пакетов:

#
pkg update

#
pkg upgrade

Далее
основной источник, по которому ведется установка и настройка — это официальный
мануал от разработчиков FreeRadius
— wiki. freeradius.org/guide/FreeRADIUS-Active-Directory-Integration-HOWTO

Устанавливаем
пакет Samba (версия 4.4) (необходим для доменной авторизации пользователей).

#
pkg install net/samba44

Установятся также
сопутствующие пакеты

Здесь стоит обратить
внимание на расположение конфигурационных файлов и логов.

Samba
содержит компоненты, которые в дальнейшем понадобятся для
работы с AD:

• winbind, служба (демон в
  терминах FreeBSD) для связи линукс машины и контроллера домена.
• ntlm_auth, утилита, использующая
  службу winbind для NTLM запросов. Она разрешает проверку пользовательских
  данных (логин и пароль) на контроллере домена и возвращает ответ либо
  успешный результат проверки, либо сообщения об ошибках.

Для просмотра опций
самбы можно выполнить команду:

#
smbd -b

Результат
ее выполнения:

Build environment:

   Built
by:    root@101amd64-quarterly-job-14

   Built
on:    Thu Jul 28 15:46:26 UTC 2016

   Built
using: cc

   Build
host:  FreeBSD 101amd64-quarterly-job-14
10. 1-RELEASE-p37 FreeBSD 10.1-RELEASE-p37 amd64

  
SRCDIR:     
/wrkdirs/usr/ports/net/samba44/work/samba-4.4.5/source3

  
BUILDDIR:   
/wrkdirs/usr/ports/net/samba44/work/samba-4.4.5/source3

Paths:

   SBINDIR:
/usr/local/sbin

   BINDIR:
/usr/local/bin

   CONFIGFILE:
/usr/local/etc/smb4.conf

  
LOGFILEBASE: /var/log/samba4

  
LMHOSTSFILE: /usr/local/etc/lmhosts

   LIBDIR:
/usr/local/lib/samba4

   MODULESDIR:
/usr/local/lib/shared-modules

   SHLIBEXT:
so

   LOCKDIR:
/var/db/samba4

   STATEDIR:
/var/db/samba4

   CACHEDIR:
/var/db/samba4

   PIDDIR:
/var/run/samba4

  
SMB_PASSWD_FILE: /var/db/samba4/private/smbpasswd

  
PRIVATE_DIR: /var/db/samba4/private

System Headers:

  
HAVE_SYS_ACL_H

  
HAVE_SYS_CAPABILITY_H

  
HAVE_SYS_CDEFS_H

…

Headers:

   HAVE_AIO_H

…

UTMP Options:

  
HAVE_UTMPX_H

HAVE_* Defines:

   HAVE_ACL

  
HAVE_ACL_EVERYONE

  
HAVE_ACL_GET_FILE

  
HAVE_ACL_GET_PERM_NP

. ..

—with Options:

   WITH_ADS

  
WITH_AUTOMOUNT

  
WITH_DNS_UPDATES

   WITH_PAM

  
WITH_PAM_MODULES

  
WITH_PTHREADPOOL

   WITH_QUOTAS

  
WITH_SENDFILE

   WITH_SYSLOG

  
WITH_WINBIND

Build Options:

  
AD_DC_BUILD_IS_ENABLED

  
BROKEN_NISPLUS_INCLUDE_FILES

  
BSD_STYLE_STATVFS

…

Cluster support features:

   NONE

Type sizes:

  
sizeof(char):         1

  
sizeof(int):          4

  
sizeof(long):         8

   sizeof(long
long):    8

  
sizeof(uint8_t):      1

  
sizeof(uint16_t):     2

  
sizeof(uint32_t):     4

  
sizeof(short):        2

  
sizeof(void*):        8

  
sizeof(size_t):       8

  
sizeof(off_t):        8

  
sizeof(ino_t):        4

  
sizeof(dev_t):        4

Builtin modules:

   vfs_default
vfs_posixacl auth_domain auth_builtin auth_sam auth_winbind pdb_smbpasswd
pdb_tdbsam pdb_wbc_sam auth_unix auth_wbc nss_info_template idmap_tdb
idmap_passdb idmap_nss pdb_samba_dsdb auth_samba4 vfs_dfs_samba4 pdb_ldapsam
idmap_ldap

Теперь нужно настроить Samba на наши адреса и домены.

Создаем
конфигурационный файл по пути /usr/local/etc/smb4.conf:

#
vi /usr/local/etc/smb4.conf

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

Для
проверки конфигурации Samba на
ошибки можно выполнить команду:

#
testparm

Правим конфигурационный файл /etc/nsswitch.conf: (указываем ссылку на winbind у group,
passwd, services, protocols)

В
файле etc/rc.conf добавить включение служб:

samba_enable=»YES»

winbindd_enable=»YES»

Теперь можно
включать машину в домен:

#
net join -U Administrator

Где Administrator — это
имя администратора домена.

Спросит пароль
администратора домена, вводим, в итоге должно быть:

Using short domain
name — CORP

Joined
‘FREERADIUS-AO’ to dns domain ‘corp.domain.net’

Примечание: выход из домена, если нужно: net ads leave -U
Administrator

Если
будет сообщение:

Failed to
leave domain: failed to leave realm: No such file or directory

То машина уже не в
домене (например, администратор удалил ее на самом контроллере домена).

Перезагружаемся

#
reboot

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

По
команде проверяем статус состояния в домене:

#
net ads testjoin

Если
получаем сообщение:

kerberos_kinit_password [email protected]
failed: Client not found in Kerberos database

Join to domain is not valid: Improperly formed account name

То означает, что
машина не в домене.

Если всё
успешно, то должны получить сообщение:

Join is OK

Стартуем
samba

#
samba

Стартуем
winbind

#
winbindd

Проверяем статус
коннекта к домену:

#
wbinfo -p

Если получаем
сообщение:

Ping to winbindd failed

could not ping winbindd!

То
сервис winbind не запущен, надо
его запустить по команде выше.

Проверяем
утилиту авторизации ntlm_auth пытаясь войти под каким-либо доменным пользователем:

#
ntlm_auth —request-nt-key —domain=corp.domain.net —username=test1

Запросит пароль,
вводим, покажет статус NT_STATUS_OK:
Success (0x0)

Если получаем
сообщение:

could not obtain winbind separator!

Reading winbind reply failed! (0x01)

:  (0x0)

То
значит сервис winbind не запущен,
надо его запустить по команде # winbindd.

Если
сообщение:

NT_STATUS_USER_SESSION_DELETED:
User session deleted (0xc0000203)

То возможно забыли
включить машину в домен.

Теперь ставим FreeRadius (последняя версия на дату статьи 3.0.11)

#
pkg install freeradius3

Добавляем
клиента, который будет пользоваться радиусом, в конфигурационный файл /usr/local/etc/raddb/clients.conf (в нашем случае это машина с pfSense)

client 192.168.10.12 {

       
secret  = ХХХpf-SenseXXX

       
ipaddr = 192.168.10.12

       
shortname = 192. 168.10.12

}

Где
ХХХpf-SenseXXX — это придуманное Вами секретное
кодовое слово для обмена с радиус-сервером.

Также
проверяем секцию client localhost,
чтобы сервер мог обращаться к самому себе:

client localhost {

       
ipaddr = 127.0.0.1

       
secret  = testing123

…     

Теперь настраиваем радиус для работы с ntlm_auth.

(источник wiki.freeradius.org/guide/NTLM-Auth-with-PAP-HOWTO)

Корректируем
конфигурационный файл /usr/local/etc/raddb/mods-available/ntlm_auth. Нужно указать в нем правильный путь до утилиты ntlm_auth и прописать
домен (необязательно). Пример:

program = «/usr/local/bin/ntlm_auth
—request-nt-key —username=%{mschap:User-Name}
—password=%{User-Password}»

Также
создаем файл /usr/local/etc/raddb/policy.d/ntlm_auth со следующим содержимым:

ntlm_auth.authorize
{  

    if (!control:Auth-Type &&
User-Password) {

        update control {

            Auth-Type := ntlm_auth

        } 

    } 

} 

Далее
дополняем файл /usr/local/etc/raddb/sites-enabled/default следующим содержимым (находим соответствующие секции, а также
комментируем модуль pap):

authorize {

    …

    ntlm_auth

    # pap

}

authenticate
{ 

    Auth-Type ntlm_auth {

        ntlm_auth

    }

    …

}

Теперь
добавляем включение радиуса в ранее упоминавшийся файл rc. conf

#
echo ‘radiusd_enable=»YES»‘ >> /etc/rc.conf

(либо этой командой, либо вручную)

Проверить
корректность настройки конфигурационных файлов радиуса можно командой:

#
radiusd -X

Ошибки
будут подсвечены.

Возможные
предупреждения при проверке:

[/usr/local/etc/raddb/mods-config/attr_filter/access_reject]:11
Check item «FreeRADIUS-Response-Delay»      found in filter list for realm
«DEFAULT».

[/usr/local/etc/raddb/mods-config/attr_filter/access_reject]:11
Check item «FreeRADIUS-Response-Delay-USec»         found in filter list for realm
«DEFAULT».

Ignoring «sql» (see
raddb/mods-available/README.rst)

Ignoring «ldap» (see
raddb/mods-available/README.rst)

Если
получили сообщение:

Failed binding to auth address 127.0.0.1 port 18120 bound to server
inner-tunnel: Address already in use

/usr/local/etc/raddb/sites-enabled/inner-tunnel[33]: Error binding
to port for 127.0.0.1 port 18120

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

#
service radiusd stop

Старт
радиуса

#
service radiusd start

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

#
radtest test1 testpass localhost 1218 testing123

Где,

test1 — логин пользователя

testpass — пароль
пользователя

localhost — машина,
где расположен радиус (в данном случае запрос к самому себе)

1218 — порт по умолчанию

testing123 —
секретное слово по умолчанию для клиента localhost

Если нет связи или
радиус не запущен, будет бесконечный цикл отправки запроса:

После
запуска, вариант с отклонением пользователя:

Пример удачного
ответа:

Возможные ошибки:
Access-Reject:

admin@FreeRADIUS-AO:/#
radtest test1 testpass localhost
0 testing123

Sent
Access-Request Id 169 from 0. 0.0.0:40117 to 127.0.0.1:1812 length 89

        User-Name = «test1»

        User-Password = «testpass»

        NAS-IP-Address = 192.168.10.30

        NAS-Port = 0

        Message-Authenticator = 0x00

        Cleartext-Password = «testpass»

Received Access-Reject Id 169 from 127.0.0.1:1812 to 0.0.0.0:0
length 20

(0) -: Expected Access-Accept got Access-Reject

Если ответ Reject,
хотя всё введено правильно, то включаем режим отладки радиуса и смотрим на
каком этапе проблема.

Включение
радиуса в режиме отладки:

#
service radiusd stop 

#
service radiusd debug

Не
выходя из отладочного режима, запускаем команду radtest и смотрим логи.

Пример лога с
ошибкой:

Если
на самом радиус сервере тест проходит, можно попробовать сделать тест на машине
с pfSense (при условии, что там
установлен модуль freeradius,
иначе проверить можно будет только через pfSense):

#
radtest test1 testpass 192. 168.10.30 0 ХХХpf-SenseXXX

В итоге должен быть
ответ:  Access-Accept

Далее настраиваем работу протокола mschap (если
требуется).

В
конфигурационном файле /usr/local/etc/raddb/mods-available/mschap нужно скорректировать строку ntlm_auth (указать путь к утилите
ntlm_auth, указать правильный домен (указывать домен необязательно), изменить
параметры запроса имени пользователя, если отличается).

Здесь, возможно
придется поэкспериментировать с вариантами:

ntlm_auth = «/usr/local/bin/ntlm_auth
—request-nt-key —domain=corp.domain.net
—username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}}
—challenge=%{%{mschap:Challenge}:-00}
—nt-response=%{%{mschap:NT-Response}:-00}»

Или так

ntlm_auth = «/usr/local/bin/ntlm_auth
—request-nt-key —username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}}
—challenge=%{%{mschap:Challenge}:-00}
—nt-response=%{%{mschap:NT-Response}:-00}»

Или так

ntlm_auth = «/usr/local/bin/ntlm_auth
—request-nt-key —username=%{mschap:User-Name}
—challenge=%{%{mschap:Challenge}:-00}
—nt-response=%{%{mschap:NT-Response}:-00}»

В конфигурационном файле /usr/local/etc/raddb/mods-available/eap нужно заменить опцию:

default_eap_type = md5

Меняем md5 на peap,
в итоге:

default_eap_type = peap

А также
расскомментируем строку

random_file = /dev/urandom

Теперь можно
тестировать работу радиус сервера:

#
radtest -t mschap test1 testpass localhost 0 testing123

Ответы будут такие
же, как было указано ранее.

Возможные ошибки: ошибка 691:

admin@FreeRADIUS-AO:/# radtest -t mschap
test1 testpass localhost 0 testing123

Sent Access-Request Id 191 from 0.0.0.0:13388 to
127.0.0.1:1812 length 145

       
User-Name = «test1»

       
MS-CHAP-Password = «testpass»

       
NAS-IP-Address = 192.168.10.30

       
NAS-Port = 0

       
Message-Authenticator = 0x00

       
Cleartext-Password = «testpass»

       
MS-CHAP-Challenge = 0x343cf762608b18eb

       
MS-CHAP-Response =
0x0001000000000000000000000000000000000000000000000000c5d3be2d767350eccce93ac4f1dc4bb7c32558c8d9bd1508

Received Access-Reject Id 191 from 127.0.0.1:1812 to 0.0.0.0:0
length 61

        MS-CHAP-Error =
«\000E=691 R=1 C=0dca59ab2eb746b8
V=2»

(0) -: Expected Access-Accept got Access-Reject

Еще варианты ошибок:

MS-CHAP2-Response is incorrect mschap = reject

mschap: ERROR: Program returned code (1) and output ‘Logon failure
(0xc000006d)’

Опять же
включаем отладку и смотрим логи.

Если
все тесты прошли успешно, можно пробовать подключать радиус сервер на Captive портале на сервере pfSense, как было задумано в первоначальной
задаче.

Какие еще не исследованные проблемы на данный момент:

1) не стартовала
автоматически служба winbind, возможно не верно указаны параметры запуска.

2)
отказ входа пользователя, если имя указано вместе с доменом, например, [email protected] (всегда возвращается
Reject). Возможно надо разбираться
в шаблоне имени пользователя при задании подключения по ntlm_auth.

Также
ради проверки были предприняты неудачные
попытки понизить уровень безопасности на домен контроллере и разрешении
протокола NTLMv1.

Вот
какие поверочные действия были сделаны:

1.
На контроллере домена в реестре в ветке HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy
был создан DWORD ключ «Enable NTLMv2 Compatibility» со значением 1.

2.
Через оснастку secpol.msc (Run — secpol.msc) в
Security Options в параметре «Network security: LAN Manager authentication
level» разрешен «Send LM & NTLM Response», а также в
параметре «Minimum session security for NTLM SSP» отключен
«Disable Require 128-bit encryption».

(с) Ella S.

Если Вам понравилась статья, пожалуйста, поставьте лайк, сделайте репост или оставьте комментарий. Если у Вас есть какие-либо замечания, также пишите комментарии.

RADIUS для ASA на Windows Server 2012r2 —

Как бы стар он ни был, RADIUS по-прежнему остается довольно хорошим инструментом для аутентификации служб, отличных от Windows.
против Active Directory. Он изначально поддерживается на большинстве всех сетевых устройств, хорошо
протестированы модули PAM и хорошо понимаются инфраструктурными системами, такими как балансировщики нагрузки. Черт, это
даже предпочтительный тип аутентификации для некоторых двухфакторных систем, таких как Windows Azure Multi-Factor
Сервер аутентификации (урожденный PhoneFacter). Эта длинная история и сильная поддержка делают его хорошим
посредник, даже если вам вместо с использованием некоторых механизмов доступа и учета на основе политик.

Выбор сервера RADIUS может быть довольно интересным делом. Существует ряд вариантов, т.
наиболее известными являются FreeRADIUS, SteelBelted RADIUS и сетевая политика и доступ Windows.
Услуги. Поскольку мой вариант использования — это, прежде всего, магазин Windows, ответ был довольно простым.

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

Предположим, вы уже настроили базовую машину Windows, я использую 2012r2, которая присоединена к вашей
целевой домен.

1. Войдите в свою целевую систему через RDP, консоль или что-то еще.
2. На главной панели управления сервером нажмите «Добавить роли и функции».
3. Нажмите «Далее» несколько раз, 3 раза для меня, пока не дойдете до экрана «Выбор ролей сервера».
4. Установите флажок «Сетевая политика и службы доступа».
5. Во всплывающем окне убедитесь, что установлен флажок «Включить инструменты управления», и нажмите «Добавить компоненты».
6. Нажимайте «Далее», пока не попадете на страницу подтверждения, 4 раза для меня.
7. Нажмите «Установить».

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

Настройка пользователя

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

1. Удаленное подключение к контроллеру домена или системе управления AD.
2. Запустите «Пользователи и компьютеры Active Directory».
3. Перейдите к организационной единице, содержащей ваши группы.
4. Выберите «Действие» -> «Создать» -> «Группа».
5. В поле «Имя группы:» введите «Пользователи VPN». Нажмите «ОК».
6. Найдите в списке «Пользователи VPN», щелкните правой кнопкой мыши и выберите «Свойства».
7. Добавьте соответствующее описание.
8. Выберите вкладку «Участники» и добавьте пользователей, как обычно.

Разрешения Регистрация

По умолчанию обычный объект Компьютер не имеет достаточных разрешений для просмотра всех
атрибуты для пользователей. В частности, ему нужен доступ к учетным данным и свойствам удаленного доступа.
У Microsoft есть встроенный механизм для включения этого доступа, который они называют «регистрацией». Есть
несколько способов регистрации, однако единственный, который сработал для меня, — это использование командной строки.

1. Нажмите кнопку «Пуск».
2. Введите cmd .
3. Щелкните правой кнопкой мыши «Командная строка» и выберите «Запуск от имени администратора». Нажмите «Да» для UAC
   подтверждение высоты.
4. Когда запустится оболочка, введите: netsh nps добавить зарегистрированный сервер

Настройки клиента

Чтобы принимать соединения RADIUS с конечного устройства, мы должны настроить его на сервере как
«Клиент».

1. Нажмите кнопку «Пуск».
2. Тип nps.msc
3. На левой боковой панели разверните «RADIUS-клиенты и серверы».
4. Щелкните правой кнопкой мыши «Клиенты RADIUS» и выберите «Создать».
5. Введите отображаемое имя и IP-адрес устройства, которое будет
   РАДИУС-сервер.
6. Выберите общий секрет. ¹
7. Нажмите «ОК».

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

Политика пользователя

1. На левой боковой панели разверните «Политики».
2. Щелкните правой кнопкой мыши «Сетевые политики» и выберите «Создать».
3. Введите имя для этой политики подключения и нажмите «Далее».
4. В «Условиях» нажмите «Добавить…»
5. Выберите опцию «Группы пользователей» и нажмите «Добавить…».
6. Во всплывающем окне «Группы пользователей» нажмите «Добавить группу» и войдите в созданную ранее группу «Пользователи VPN».
7. Нажмите «ОК», «Далее». Убедитесь, что выбран «Доступ предоставлен», и нажмите «Далее».
8. Параметры по умолчанию должны быть хорошими. Убедитесь, что выбраны «MS-CHAPv2» и «MS-CHAP», и нажмите
   ‘Следующий’.
9. Ограничения не обязательны. Нажмите «Далее’.
10. Никаких особых параметров политики не требуется. Нажмите «Далее’.
11. Просмотрите окончательные параметры и нажмите «Готово».

На этом этапе вы должны иметь возможность редактировать свое клиентское устройство и добавлять систему Windows в качестве RADIUS.
сервер для аутентификации. Эта конфигурация будет несколько сильно зависеть от клиентского устройства.
может быть, а может и не быть постом на другой день.

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

Брандмауэр Sophos: настройка RADIUS для корпоративной беспроводной аутентификации с Windows Server 2012 — рекомендуемая литература — брандмауэр Sophos

Обзор

В этой статье описываются необходимые шаги для настройки аутентификации Microsoft Windows Server Radius и брандмауэра Sophos для пользователей беспроводной сети.

Содержание

• Обзор
• Настройка RADIUS на Windows Server
• Настройка брандмауэра Sophos
• Результаты

Применяется к следующим продуктам и версиям Sophos
Sophos Firewall

Настройка RADIUS на Windows Server

Примечание:

• , когда Firewall Sophos Firewall имеет свой Wirless Security Security Sepect 2 WpindesPrPRISP. сетевая политика с  PEAP  требуется.

Сетевая политика

• NPS с EAP не работает для беспроводной сети WPA2 Enterprise.
• Чтобы настроить PEAP, см. раздел Настройка шаблонов сертификатов для требований PEAP и EAP.

Перед установкой и настройкой RADIUS на Windows Server необходимо установить и настроить роль Active Directory.

Сервер RADIUS расположен на панели сервера политики сети (NPS), роль служб политики сети и доступа можно добавить из Server Manager> Добавить роли и функции на Windows Server 2012.

Следуйте мастеру, как показано ниже:

Click

Клинг . .

Ищите Network Policy Server .

Перейдите к NPS (локальный) и щелкните правой кнопкой мыши, чтобы выбрать Зарегистрировать сервер в Active Directory .

Перейдите к NPS (локальный) > Клиенты и серверы RADIUS > Клиенты RADIUS и щелкните правой кнопкой мыши, чтобы выбрать Новый .

Установите IP-адрес брандмауэра Sophos и общий секрет . Обратите внимание на этот общий секрет, который будет использоваться позже при настройке брандмауэра Sophos.

Нам нужна политика запросов на подключение, перейдите к NPS (локальный) > Политики > Политики запросов на подключение и щелкните правой кнопкой мыши, чтобы выбрать Новый .

Следуйте указаниям мастера, как показано ниже.

На странице Укажите условия нажмите Добавить , чтобы добавить условие.

Выберите IPv4-адрес клиента и нажмите Добавить .

Введите IP-адрес брандмауэра Sophos и нажмите OK .

После того, как вы нажмете Готово,  Политика запросов на подключение  должна выглядеть так.

Нам также нужна сетевая политика для тестирования подключения между брандмауэром Sophos и сервером политики сети. Перейдите в раздел NPS (локальный) > Политики > Политики сети и щелкните правой кнопкой мыши, чтобы выбрать Новый .

Введите IP-адрес брандмауэра Sophos и нажмите  OK .

Отключить менее безопасные методы аутентификации  уже включен по умолчанию и включите  Незашифрованная аутентификация (PAP, SPAP) . Это будет использоваться только при тестировании соединения между Sophos Firewall и NPS, как мы увидим позже. Аутентификация всех беспроводных пользователей будет осуществляться через другую сетевую политику с использованием Microsoft Protected EAP (PEAP), как мы увидим позже.

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

Следуйте указаниям мастера, как показано ниже.

На странице Укажите условия нажмите Добавить , чтобы добавить условие.

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

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

На странице Настройка методов аутентификации нажмите Добавить , чтобы выбрать Microsoft Protected EAP (PEAP) 9 0 5 3 9 0 1 3 . Этот метод аутентификации PEAP будет использоваться для аутентификации пользователей беспроводной сети.

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

Убедитесь, что политика Безопасных беспроводных соединений превышает тестирование подключения SFOS SFOS с политикой RADIUS , иначе, беспроводные пользователи будут соответствовать SFOS Connection Connectivity Will Will Will Will Will Will Will Will Will Will Will Will Will Will Will Will Will Will Will Will Test отклонить их запрос на доступ.

Сетевые политики  должен выглядеть так.

Примечание:  Вы можете добавить дополнительные условия в соответствии с потребностями вашего бизнеса. Например, условие Day and Time Restrictions можно использовать для ограничения доступа в определенные дни и часы.

Перейдите к Accounting и нажмите Configure Accounting .

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

Настройте Local File Logging следующим образом и нажмите Next .

Проверьте сводку и нажмите  Далее .

Теперь учет настроен, нажмите  Закрыть  для завершения.

Настройка брандмауэра Sophos

Перейдите к Аутентификация > Серверы и нажмите Добавить . Shared Secre t — это то же самое, что настроено ранее в NPS, Атрибут имени группы  является обязательным полем, но в этом примере не соответствует NPS, поэтому мы можем установить для него что угодно. Включите Включите учет , чтобы брандмауэр Sophos отправлял события входа и выхода на сервер политики сети.

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

Перейдите к Беспроводная связь > Настройки беспроводной сети .

Примечание:  В SFOS 17.5 и более поздних версиях добавлена ​​возможность добавления дополнительного сервера RADIUS в качестве резерва для проверки подлинности предприятия. В случае сбоя основного сервера RADIUS будет использоваться дополнительный сервер, что гарантирует нулевое время простоя для аутентификации.

Перейдите к Wireless > Wireless Networks и нажмите Добавить .

Перейдите к Правила и политики > Правила брандмауэра > Добавить правило брандмауэра и выберите Новое правило брандмауэра  для создания правила из зон WiFi в зоны WAN, разрешающего трафик для пользователей беспроводной сети. Кроме того, применяйте профили безопасности и элементы управления в соответствии с потребностями вашего бизнеса.

Нажмите Создайте связанное правило NAT и настройте его в соответствии с приведенным ниже снимком экрана.

Нажмите Сохранить , а затем Сохранить и правило брандмауэра.

Результаты

Перейдите к   Аутентификация > Серверы  , чтобы выбрать недавно созданный сервер RADIUS, и нажмите  Тестовое соединение . Введите имя пользователя, уже зарегистрированного в Active Directory, с его паролем и нажмите Test Connection .

Тестовое соединение должно пройти успешно.

При необходимости проверьте Event Viewer в Windows Server, чтобы проверить, какая политика запросов на подключение и сетевая политика были применены.

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