Radius server ip address что вводить: wi-fi Radius Server IP, ?

Настройка сервера Radius в Windows Server 2016

В этой статье мы покажем, как настроить сервер централизованной аутентификации, авторизации и аккаунтинга (RADIUS) на операционной системе Windows Server 2016, а также как настроить Radius-аутентификацию на Cisco устройствах с помощью службы Политики сети и доступа (Network Policy Server).

RADIUS (англ. Remote Authentication in Dial-In User Service) — протокол для реализации аутентификации, авторизации и сбора сведений об использованных ресурсах, разработанный для передачи сведений между центральным севером и различными сетевым оборудованием и клиентами.

В первую очередь создайте в домене Active Directory группу безопасности AllowRemoteCiscoUsers, в которую нужно добавить пользователей, которым будет разрешена аутентификации на маршрутизаторах и коммутаторах Cisco.

Далее нужно установить на сервере, с помощью которого будет выполнятся аутентификация клиентов и назначаться права доступа, роль RADIUS сервера. Для этого на сервере Windows Server 2016 откройте оснастку Server Manager и вызовите мастер добавления ролей — Add Roles and features.

В открывшемся мастере на шаге выбора ролей отметьте роль Network Policy and Access Services. На шаге выбора служб роли в нашей ситуации достаточно будет выбрать только службу Network Policy Server.

Протокол Remote Authentication Dial In User Service (RADIUS) в Windows Server 2016 включен в состав роли Network Policy Server.

В консоли Server Manager выберите меню Tools и откройте консоль Network Policy Server (nps.msc).

Для полноценного использования NPS-сервера в домене необходимо зарегистрировать его в домене Active Directory. В оснастке на NPS, щелкните ПКМ по вашему NPS узлу и выберите Register server in Active Directory.

Подтвердите регистрацию сервера в Active Directory:

При этом мы должны предоставите серверу полномочия на чтение свойств учётных записей пользователей, касающихся удалённого доступа. Сервер при этом будет добавлен во встроенную доменную группу RAS and IAS Servers.

Теперь можно добавить клиента Radius. Для этого в дереве консоли NPS разверните раздел RADIUS Clients and Servers и на элементе RADIUS Clients выберите пункт New.

На вкладке Settings заполните поля Friendly name, Client address (можно указать IP адрес или DNS имя подключающегося сетевого устройства) и пароль — Shared Secret + Confirm shared (этот пароль вы будете использовать в настройках коммутатора или маршрутизатора Cisco для установления доверительных отношений с Radius сервером).

Во вкладке Advanced выберите в поле Vendor name — Cisco.

Теперь нужно создать политики доступа на сервере RADIUS. С помощью политик доступа мы свяжем клиента Radius и доменную группу пользователей.

Раскройте ветку Policies —> Network Policies, и выберите пункт меню New:

Укажите Имя политики (Policy name). Тип сервера доступа к сети (Type of network access server) оставьте без изменения (Unspecified):

На следующем шаге Specify conditions нам нужно добавить условия, при которых будет применяться данная политика RADIUS. Добавим два условия: вы хотите, что для успешной авторизации пользователь входил в определенную доменную группу безопасности, и устройство, к которому осуществляется доступ, имело определённое имя. С помощью кнопки Add добавим сначала условие, выбрав тип Windows Group (добавьте группу RemoteCiscoUsers) и укажите Client Friendly Name (Cisco_*).

На следующем выберите значение Доступ разрешен (Access Granted).

Т.к. наш коммутатор Cisco поддерживает только метод аутентификации Unencrypted authentication (PAP, SPAP), снимите все остальные флажки.

Следующий шаг настройки ограничений (Constraints) мы пропустим.

В разделе Configure Settings перейдите секцию RADIUS Attributes -> Standard. Удалите имеющиеся там атрибуты и нажмите кнопку Add.

Выберите Access type -> All, затем Service-Type->Add. Укажите Others=Login.

Теперь в секции RADIUS Attributes -> Vendor Specific добавьте новый атрибут. В пункте Vendor, найдите Cisco и нажмите Add. Здесь нужно добавить сведения об атрибуте. Нажмите Add и укажите следующее значение атрибута:

shell: priv-lvl = 15

На последнем экране будут указаны все созданные вами настройки политики NPS. Нажмите Finish:

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

После создания политики, можно переходить к настройке маршрутизаторов и коммутаторов Cisco для аутентификации на сервере Radius NPS.

AAA работает таким образом, что, если не получен ответ от сервера, клиент предполагает, что аутентификация не выполнена. Чтобы не потерять доступ к своим сетевым устройствам, которые вы переключаете на авторизацию на Radius сервера, обязательно создайте локальных пользователей на случай если RADIUS сервер станет недоступен по какой-либо причине.

Ниже пример конфигурации для авторизации на Radius (NPS) сервере для коммутатора Cisco Catalyst:

aaa new-model
aaa authentication login default group radius local
aaa authorization exec default group radius if-authenticated
radius-server host 192.168.1.16 key R@diu$pa$$
service password-encryption

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

Настройка WiFi авторизации через RADIUS-сервер NPS на Mikrotik.

Использование для WiFi авторизации доменных учетных записей является очень удобным решением для любой организации где есть контроллер домена. Это удобно в случае если у вас несколько офисов т.к. можно подключаться под личным логином и паролем к wifi в любом офисе и безопасно в случае увольнения сотрудника т.к. его доменный профиль удаляется или блокируется.

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

1. Настройка сервера политики сети NPS в Windows 2012
2. Настройка RADIUS-клиента на Mikrotik.

Освоить MikroTik Вы можете с помощью онлайн-куса «Настройка оборудования MikroTik». Курс основан на официальной программе MTCNA. Автор курса – официальный тренер MikroTik. Подходит и тем, кто уже давно работает с микротиками, и тем, кто еще их не держал в руках. В курс входит 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.

Настройка сервера политики сети NPS в Windows 2012.

Открываем «Диспетчер сервера» и приступаем к установке роли «Сервер политики сети» через «Мастер добавления ролей и компонентов». Подробно рассматривать процедуру установки не буду, здесь нет никаких сложностей. У меня на сервере эта роль уже установлена (см. скриншот).

После установки Роли потребуется перезагрузка. Перезагружаем сервер и приступаем к настройке NPS.

Настраиваем подключение RADIUS-клиента.

В Диспетчере серверов открываем /Средства/Сервер политики сети.

Переходим в /NPS/Radius-клиенты и сервер/Radius-клиенты, щелкаем пр. клавишей мыши и выбираем пункт «Новый документ»

Указываем имя (любое понятное для себя), ip-адрес роутера Mikrotik и придумываем общий секрет посложней (можно воспользоваться генератором).

Создаем политики для WiFi авторизации.

На этом шаге настройки воспользуемся мастером настройки 802.1x.

Кликаем лев. клавишей мыши по пункту «NPS(Локально)», затем в правом окне разворачиваем пункт «Стандартная конфигурация».

В пункте сценария настройки выбираем «RADIUS-сервер для беспроводных или кабельных подключений 802.1x» и переходим по ссылке «Настройка 802.1x».

Выбираем пункт «Безопасные беспроводные подключения»

На следующем шаге добавляем RADIUS-клиенты, которые были подключены к RADIUS-серверу ранее.

В качестве метода проверки подлинности выбираем «Microsoft: защищенные EAP (PEAP)».

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

В результате получаем следующие результаты политик.

Политика запросов на подключение:

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

На этом настройка NPS в качестве RADIUS-сервера для WiFi-авторизации завершена. Приступаем к настройке роутера Mikrotik.

Настройка подключения Mikrotik к RADIUS-серверу.

Чтобы добавить в Mikrotik подключение к RADIUS-серверу открываем меню RADIUS и жмем плюсик.

• Отмечаем нужную службу «Services» — в случае WiFi авторизации это «wireless».
• Указываем «Adsress» Radius-сервера — это ip-адрес настроенного ранее сервера сетевой политики NPS.
• Заполняем Secret, который был указан при добавлении radius-клиента в NPS.

Все остальные настройки оставляем как есть, если только вы не решили изменить на NPS стандартные порты подключения 1812 и 1813.

Добавляем профиль авторизации: /Wireless/Security profiles. Здесь в Authentication types оставляем только WPA2 EAP.

Указываем в нашем действующем WiFi интерфейсе новый Security profile.

На этом настройка Mikrotik в качестве RADIUS-клиента закончена.

Для диагностики неисправности подключений можно включить Logging для RADIUS: /System/Logging/+. В «Topics» выбираем «radius».

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

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

Освоить MikroTik Вы можете с помощью онлайн-куса «Настройка оборудования MikroTik». Курс основан на официальной программе MTCNA. Автор курса – официальный тренер MikroTik. Подходит и тем, кто уже давно работает с микротиками, и тем, кто еще их не держал в руках. В курс входит 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.

Использование RADIUS (Windows Network Policy Server) для аутентификации и авторизации на ИПБ APC (Web/SNMP Management Card)

Если в организации имеется большое количество сетевых устройств, таких как маршрутизаторы, коммутаторы, сетевые принтеры, контроллеры управления ИБП и др., – рано или поздно может встать вопрос о централизации управления этими устройствами. Понятие централизации управления в данном контексте является очень широким и мы в данной заметке рассмотрим одну из его составляющих – централизация функций аутентификации/авторизации/контроля доступа к этим устройствам. Реализацию этих функций можно найти в программных и программно-аппаратных вариантах у разных производителей оборудования, но если речь идёт об унификации этих функций в парке устройств разных производителей, — на помощь нам приходит протокол RADIUS. Любой уважающий себя производитель сетевого оборудования имеет на сегодня для своих устройств поддержку этого протокола.

Рассмотрим на практике случай, когда в организации имеется некоторое количество источников бесперебойного питания (ИБП) фирмы APC с установленными в них контроллерами управления APC Web/SNMP Management card. Для сетевого доступа на каждый из таких контроллеров, как правило, используются встроенные в эти контроллеры учетные записи пользователей трёх категорий доступа:

• Полный административный доступ
• Доступ на чтение с функциями управления клиентами ИБП
• Доступ “только на чтение”

Встроенная в эти контроллеры поддержка протокола RADIUS позволит нам использовать вместо встроенной аутентификации аутентификацию на основе учетных записей Active Directory. Чтобы реализовать этот механизм поэтапно рассмотрим процесс установки/настройки сервера RADIUS на базе Windows Server 2008 R2 и последующей настройки ИБП.В качестве аппаратных исходных данных будут выступать ИБП APC с установленными контроллерами управления:

APC AP9619 Web/SNMP Management card
Hardware Revision: A10
Application Module — sumx — v3.7.2 — 02/02/2010
APC OS (AOS) — aos —  v3.7.3 — 02/02/2010

Этап #1. Установка и активация сервера RADIUS

Итак, поднимаем виртуальный сервер с Windows Server 2008 R2 SP1 на борту, устанавливаем на него все текущие обновления с WSUS. В нашем случае имя сервера будет KOM-AD01-NPS01.

На этом сервере открываем оснастку Server Manager, переходим в раздел Roles и в секции Role Summary вызываем мастер добавления ролей — Add Roles

В открывшемся мастере на шаге выбора ролей отмечаем роль Network Policy and Access Services.

На шаге выбора служб роли в нашей ситуации достаточно будет выбрать только службу Network Policy Server.

После того как установка роли успешно завершена, открываем оснастку Network Policy Server (nps.msc) через Панель управления > Administrative Tools

Для начала использования нужных нам функций сервера в доменной инфраструктуре необходимо провести его регистрацию в AD. Для этого в корне консоли правой кнопкой мыши откроем контекстное меню и выберем пункт меню Register server in Active Directory

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

Этап #2. Добавление клиентов на сервер RADIUS

Теперь нам нужно внести на наш NPS сервер информацию о всех наших клиентах RADIUS. Для этого в дереве консоли NPS развернём раздел RADIUS Clients and Servers и на элементе RADIUS Clients откроем контекстное меню и выберем пункт New

В открывшемся диалоговом окне заполним поля Friendly name и Client address (IP or DNS) указав имя которое мы зарегистрировали предварительно в DNS для контроллера управления одного конкретно взятого ИБП.

Значение поля “Friendly name” может отличаться от DNS имени. Оно потребуется нам в дальнейшем для идентификации конкретного сетевого устройства при создании политик доступа — Remote Access Policy. Опираясь на это имя мы сможем задавать например маску по которой будут обрабатываться определённой политикой доступа несколько разных RADIUS клиентов.

В поля Shared Secret и Confirm shared secret введём пароль, который будет прописан в настройках UPS контроллера для подключения к серверу RADIUS.

Переключимся на закладку Advanced и выберем в списке вендоров оборудования RADIUS Standard, так как APC не представлен в этом списке. 

Этап #3. Создание групп доступа в домене

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

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

Этап #4. Создание политик доступа на сервере RADIUS

С помощью политик доступа мы произведём связку созданных ранее записей о клиентах RADIUS и доменных групп безопасности, определяющих уровень доступа к контроллерам ИБП. То есть в нашем случае будет создано три политики доступа.

Итак, создадим первую политику, определяющую полный административный доступ к контроллеру ИБП. В дереве консоли NPS в разделе Policies > Network Policies откроем контекстное меню и выберем пункт New.

В открывшемся мастере создания политики введём название создаваемой политики (пусть например оно будет созвучно с группой доступа) и выберем тип соединения Unspecified

На следующем шаге Specify conditions нам нужно добавить условия при которых будет применяться данная политика RADIUS. Добавим два условия, – чтобы пользователь, проходящий авторизацию, входил в определенную доменную группу безопасности, и устройство, к которому осуществляется доступ, имело определённое имя. Через кнопку Add добавим сначала условие выбрав тип Windows Group

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

Затем добавим второе условие по свойству Client Friendly Name

В качестве значения можно использовать как конкретные “Friendly name” устройств так и их маску, например в нашем случае политика будет применяться ко всем клиентам RADIUS у которых в свойствах атрибута “Friendly name” указано значение начинающееся с “KOM-AD01-UP”

В итоге, в нашем случае, список условий будет выглядеть так:

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

На следующем шаге Configure Authentication Methods отключим все методы аутентификации и включим метод Unencrypted authentication (PAP, SPAP), так как контроллеры ИБП APC в нашем случае поддерживают только этот метод.

При этом мы получим предупреждение о том, что выбранный метод является не безопасным и для того, чтобы оставить выбор в силе, нужно нажать — No.

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

На шаге конфигурационных настроек Configure Settings в разделе настроек стандартных атрибутов RADIUS удалим имеющиеся по умолчанию там два атрибута и добавим новый по кнопке Add.

В открывшемся окне выбора стандартных атрибутов, выберем Service-Type и нажмём Add.

Переключатель значения атрибута Attribute value установим в положение Others и из выпадающего списка выберем значение Administrative

В итоге список стандартных атрибутов RADIUS в нашем случае будет иметь только одну позицию:

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

По аналогии создаём вторую политику с доступом на чтение с функциями управления клиентами ИБП и при её создании в качестве стандартного параметра RADIUS выбираем Service-Type равный значению Login

Затем так же создаём третью политику с доступом “только на чтение” и при её создании в качестве стандартного параметра RADIUS выбираем Service-Type равный значению Authorize only

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

Этап #5. Настройка контроллеров управления ИБП APC

Подключаемся к контроллеру управления ИБП APC например через Web-интерфейс используя его встроенную учетную запись администратора, переходим на закладку Administration > Security > Remote Users Authentication и включаем опцию RADIUS, then Local Authentication

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

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

При этом надо понимать, что если мы указываем имя а не IP-адрес сервера, в настройках контроллера должны быть прописаны работающие сервера DNS, чтобы контроллер мог корректно разрешать указанное нами имя сервера NPS в его IP-адрес. Так же при настройке интерфейсов управления контроллера ИБП важно включить функции шифрования трафика, например использовать HTTPS вместо HTTP или SSH вместо Telnet, так как при новых настройках в процессе аутентификации по сети на устройство будут передаваться учетные данные доменных пользователей.

Итак, после сохранения настроек выполняем выход из сеанса администрирования контроллером ИБП и входим заново используя доменную учетную запись (без доменных префиксов)

Если мы всё сделали правильно, то успешно пройдём авторизацию на нашем RADUIS сервере и в соответствии с нашими политиками доступа NPS получим определённый набор полномочий на контроллере ИБП. На закладке Logs мы сможем увидеть информацию о наших сессиях входа/выхода.

Помимо этого на нашем NPS сервере RADIUS в системном журнале Security будут зарегистрированы события прохождения авторизации с соответствующими кодами, например:

Поделиться ссылкой на эту запись:

Похожее

Использование RADIUS (Windows Network Policy Server) для аутентификации и авторизации на коммутаторах Cisco

В предыдущей заметке была рассмотрена процедура установки и настройки RADIUS сервера в составе роли Network Policy and Access Services в Windows Server 2008 R2 для использования аутентификации и авторизации на контроллерах APC Web/SNMP Management card. В случае с коммутаторами Cisco на стороне настроек сервера RADIUS всё делается по аналогии, за исключением некоторых моментов. Рассмотрим эти моменты и проведём настройку коммутатора на примере модели Catalyst WS-C2950-24.

Этап #1. Создание групп доступа в домене

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

В первую группу включим пользователей которым нужно предоставить полный административный доступ на управление коммутаторами, во вторую соответственно, — доступ только на чтение текущей конфигурации и состояния устройств. При этом, стоит помнить, что для пользователей, которые будут включаться в эти группы должно быть установлено разрешение в домене, дающее право удалённого доступа (значение настройки Network Access Permission на закладке Dial-In свойств учетной записи пользователя)

Этап #2. Добавление клиентов на сервер RADIUS

На сервере RADIUS в консоли Network Policy Server создадим для нашего коммутатора запись о клиенте, указав его имя или IP-адрес и ключ (Shared secret). Для этого в дереве консоли NPS развернём раздел RADIUS Clients and Servers и на элементе RADIUS Clients откроем контекстное меню и выберем пункт New и заполним соответствующие поля

Значение поля Friendly name может отличаться от DNS имени. Оно потребуется нам в дальнейшем для идентификации конкретного сетевого устройства при создании политик доступа – Remote Access Policy. Опираясь на это имя мы сможем задавать например маску по которой будут обрабатываться определённой политикой доступа несколько разных RADIUS клиентов.

Этап #3. Создание политик доступа на сервере RADIUS

С помощью политик доступа NPS мы произведём связку созданных ранее записей о коммутаторах-клиентах RADIUS и доменных групп безопасности, определяющих уровень доступа к этим коммутаторам. То есть в нашем случае будет создано две политики доступа —  с полными правами и только для чтения.

Итак, создадим первую политику, определяющую полный административный доступ к коммутатору. В дереве консоли NPS в разделе Policies > Network Policies откроем контекстное меню и выберем пункт New. В открывшемся мастере создания политики введём название создаваемой политики (пусть например оно будет созвучно с группой доступа) и выберем тип соединения Unspecified

На следующем шаге Specify conditions нам нужно добавить условия при которых будет применяться данная политика RADIUS. Добавим два условия, – чтобы пользователь, проходящий авторизацию, входил в определенную доменную группу безопасности, и устройство, к которому осуществляется доступ, имело определённое имя «Friendly name». Через кнопку Add добавим условия по типам Windows Group и Client Friendly Name.

Здесь важно понимать, что для условия с Windows Group использование встроенных групп безопасности таких как, например, Domain Admins не является хорошей практикой с точки зрения безопасности.
Для условия Client Friendly Name в качестве значения можно использовать как конкретные «Friendly name» устройств так и их маску, например в нашем случае политика будет применяться ко всем клиентам RADIUS у которых в свойствах атрибута «Friendly name» указано значение начинающееся с “KOM-AD01-SW”

В итоге, в нашем случае, список условий будет выглядеть так:

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

На следующем шаге Configure Authentication Methods отключим все методы аутентификации и включим метод Unencrypted authentication (PAP, SPAP), так как коммутатор в нашем случае поддерживает только этот метод:

При этом мы получим предупреждение о том, что выбранный метод является не безопасным и для того, чтобы оставить выбор в силе, нужно нажать – No.

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

В открывшемся окне выбора стандартных атрибутов, выберем Service-Type и нажмём Add.

Переключатель значения атрибута Attribute value установим в положение Others и из выпадающего списка выберем значение Login

В итоге список стандартных атрибутов RADIUS в нашем случае будет иметь только одну позицию:

Теперь переключимся на закладку Vendor Specific и вызовем диалог добавления атрибута по кнопке Add

В открывшемся списке выберем тип атрибута Vendor-Specific (RADIUS Standard) и вызовем диалог добавления атрибута по кнопке Add

В окне информации об атрибутах для добавления нового атрибута нажмём Add 

В окне добавления атрибута из ниспадающего списка выберем вендора оборудования к которому мы настраиваем доступ, в нашем случае это Cisco , укажем что атрибут соответствует стандартам RADIUS RFC и нажмём кнопку Configure Attribute чтобы настроить значение атрибута

В открывшемся окне конфигурации значения атрибута введём значение номера атрибута – 1, тип значения строковой – String и само значение:

shell:priv-lvl=15

Это значение будет означать что авторизованному пользователю данной политикой нужно предоставить максимальный 15 уровень административного доступа на коммутаторе Cisco

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

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

По аналогии создаём вторую политику для организации доступа на чтение и при её создании, как и в первом случае, в качестве стандартного параметра RADIUS выбираем Service-Type равный значению Login , а вот значение специфического атрибута уже просто не создаём вообще.

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

Этап #4. Настройка коммутатора Cisco

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

configure terminal 
crypto key generate rsa modulus 1024 
ip ssh version 2

При выполнении команды генерации RSA-ключей мы можем получить сообщение о необходимости сконфигурировать параметр конфигурации domain-name:

% Please define a domain-name first.

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

KOM-AD01-SW003(config)# ip domain-name mydom.holding.com

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

aaa new-model 
aaa authentication login default group radius local 
aaa authorization exec default group radius if-authenticated

Затем вводим информацию о сервере RADIUS и ключ (Shared secret), который в ранее был прописан для этого устройства на самом сервере RADIUS:

radius-server host 10.160.160.160 key RjRh5adkj63D
service password-encryption

Для того чтобы сделать использование SSH обязательным и отключить Telnet при удалённом доступе выполним команды:

line vty 5 15
transport input ssh

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

Источники информации:

Поделиться ссылкой на эту запись:

Похожее

RADIUS — Краткое руководство — CoderLessons.com

Прежде чем начать изучать Radius, важно, чтобы вы поняли:

• Что такое ААА?
• Что такое NAS?

Итак, давайте сначала разберемся с этими двумя темами.

Что такое ААА?

AAA означает Аутентификацию, Авторизацию и Учет.

Аутентификация

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

• Выполняется путем представления личности и учетных данных.

• Примеры учетных данных включают пароли, одноразовые токены, цифровые сертификаты и телефонные номера (звонящие / вызываемые).

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

Выполняется путем представления личности и учетных данных.

Примеры учетных данных включают пароли, одноразовые токены, цифровые сертификаты и телефонные номера (звонящие / вызываемые).

авторизация

• Относится к предоставлению пользователям определенных видов услуг (в том числе «без обслуживания») на основе их аутентификации.

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

• Примеры услуг включают в себя фильтрацию IP-адресов, назначение адресов, назначение маршрутов, шифрование, QoS / дифференциальные услуги, управление полосой пропускания / управление трафиком и т. Д.

Относится к предоставлению пользователям определенных видов услуг (в том числе «без обслуживания») на основе их аутентификации.

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

Примеры услуг включают в себя фильтрацию IP-адресов, назначение адресов, назначение маршрутов, шифрование, QoS / дифференциальные услуги, управление полосой пропускания / управление трафиком и т. Д.

бухгалтерский учет

• Относится к отслеживанию потребления сетевых ресурсов пользователями.

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

• Может использоваться для управления, планирования, выставления счетов и т. Д.

Относится к отслеживанию потребления сетевых ресурсов пользователями.

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

Может использоваться для управления, планирования, выставления счетов и т. Д.

AAA-сервер предоставляет все вышеперечисленные услуги своим клиентам.

Протоколы ААА

Радиус — это протокол AAA для таких приложений, как доступ к сети или мобильность IP. Помимо Radius, у нас есть следующие протоколы в AAA:

Контроллер доступа к терминалу Система контроля доступа (TACACS)

TACACS — это протокол удаленной аутентификации, который используется для связи с сервером аутентификации, обычно используемым в сетях Unix. TACACS позволяет серверу удаленного доступа обмениваться данными с сервером аутентификации, чтобы определить, имеет ли пользователь доступ к сети.

TACACS +

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

ДИАМЕТР

Диаметр — плановая замена Радиуса.

Что такое сервер доступа к сети?

Сервер доступа к сети (NAS) — это элемент службы, который клиенты набирают для получения доступа к сети. NAS — это устройство, имеющее интерфейсы как к магистрали, так и к POTS или ISDN, и принимает вызовы от хостов, которые хотят получить доступ к магистрали через службы коммутируемого доступа. NAS находится в точке присутствия интернет-провайдера, чтобы обеспечить доступ в Интернет своим клиентам.

Сервер доступа к сети:

• Единая точка доступа к удаленному ресурсу.

• Сервер удаленного доступа, поскольку он обеспечивает удаленный доступ к сети.

• Начальная точка входа в сеть.

• Шлюз для защиты защищаемого ресурса.

Единая точка доступа к удаленному ресурсу.

Сервер удаленного доступа, поскольку он обеспечивает удаленный доступ к сети.

Начальная точка входа в сеть.

Шлюз для защиты защищаемого ресурса.

Примеры включают в себя:

• Проверка доступа в Интернет с использованием идентификатора пользователя и пароля.

• VoIP, FoIP и VMoIP требуют действительный номер телефона или IP-адрес.

• Телефонная карта предоплаты использует номер карты предоплаты.

Проверка доступа в Интернет с использованием идентификатора пользователя и пароля.

VoIP, FoIP и VMoIP требуют действительный номер телефона или IP-адрес.

Телефонная карта предоплаты использует номер карты предоплаты.

На следующем рисунке показана базовая архитектура Radius.

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

• RADIUS расшифровывается как удаленная аутентификация Dial In User Service.

• RADIUS — это протокол AAA для таких приложений, как доступ к сети или мобильность IP

• Он работает в обеих ситуациях, локальных и мобильных.

• Он использует протокол аутентификации по паролю (PAP), протокол аутентификации при вызове (CHAP) или протоколы расширяемого протокола аутентификации (EAP) для аутентификации пользователей.

• Это смотреть в текстовом файле, серверах LDAP, базе данных для аутентификации.

• После проверки подлинности параметры сервиса передаются обратно в NAS.

• Он уведомляет, когда сеанс начинается и заканчивается. Эти данные используются для выставления счетов или статистики.

• SNMP используется для удаленного мониторинга.

• Может использоваться как прокси.

RADIUS расшифровывается как удаленная аутентификация Dial In User Service.

RADIUS — это протокол AAA для таких приложений, как доступ к сети или мобильность IP

Он работает в обеих ситуациях, локальных и мобильных.

Он использует протокол аутентификации по паролю (PAP), протокол аутентификации при вызове (CHAP) или протоколы расширяемого протокола аутентификации (EAP) для аутентификации пользователей.

Это смотреть в текстовом файле, серверах LDAP, базе данных для аутентификации.

После проверки подлинности параметры сервиса передаются обратно в NAS.

Он уведомляет, когда сеанс начинается и заканчивается. Эти данные используются для выставления счетов или статистики.

SNMP используется для удаленного мониторинга.

Может использоваться как прокси.

Вот простая сетевая диаграмма радиуса:

Вот список всех ключевых особенностей Radius:

Модель клиент / сервер

• NAS работает как клиент для сервера Radius.

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

• Сервер Radius может выступать в качестве прокси-клиента для других серверов Radius.

NAS работает как клиент для сервера Radius.

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

Сервер Radius может выступать в качестве прокси-клиента для других серверов Radius.

Сетевая безопасность

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

• Пароль зашифрован перед отправкой по сети.

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

Пароль зашифрован перед отправкой по сети.

Гибкие механизмы аутентификации

Радиус поддерживает следующие протоколы для аутентификации:

• Двухточечный протокол — PPP

• Протокол аутентификации пароля — PAP

• Протокол аутентификации при вызове — CHAP

• Простой UNIX-вход

Двухточечный протокол — PPP

Протокол аутентификации пароля — PAP

Протокол аутентификации при вызове — CHAP

Простой UNIX-вход

Расширяемый протокол

Радиус расширяемый; большинство поставщиков аппаратного и программного обеспечения Radius реализуют свои собственные диалекты.

Протокол без сохранения состояния, использующий UDP, работает на порту 1812.

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

Как только Клиент настроен правильно, тогда:

• Клиент запускается с Access-Request.

• Сервер отправляет Access-Accept, Access-Reject или Access-Challenge.

• Access-Accept сохраняет все обязательные атрибуты для предоставления услуг пользователю.

Клиент запускается с Access-Request.

Сервер отправляет Access-Accept, Access-Reject или Access-Challenge.

Access-Accept сохраняет все обязательные атрибуты для предоставления услуг пользователю.

Коды радиуса (десятичные) назначаются следующим образом:

• 1 запрос доступа
• 2 Access-Accept
• 3 Доступ-Отклонить
• 4 Бухгалтерский учет-запрос
• 5 Бухгалтерский учет-Ответ
• 11 Access-Challenge
• 12 Status-Server (экспериментальный)
• 13 Статус-Клиент (экспериментальный)
• 255 зарезервировано
• Концепция No Keep Alive — хорошо или плохо ??

Коды 4 и 5 относятся к функциональности учета радиуса. Коды 12 и 13 зарезервированы для возможного использования.

Формат пакета Radius, как показано ниже:

Код: это 1 октет (1 байт) длиной и идентифицирует различные типы пакетов. Обычно 1 октет означает 1 байт.

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

Длина: это длина 2 октета и указывает длину пакета, включая код, идентификатор, длину и аутентификатор. (Минимальный пакет составляет 20 октетов, а максимальный — 4096 октетов).

Аутентификатор: это 16 октетов длиной и заполняется в случае некоторых запросов и ответов.

Список атрибутов: существует список из 63+ атрибутов, и атрибут Radius также будет иметь определенный формат, который описан в следующей главе.

Атрибут Radius состоит из следующих трех частей:

• Тип: 1 октет длиной, идентифицирует различные типы атрибутов. Это код атрибута, указанный ниже.

• Длина: длина 1 октет, длина атрибута, включая тип.

• Значение: 0 или более октетов, содержит информацию, специфичную для атрибута.

Тип: 1 октет длиной, идентифицирует различные типы атрибутов. Это код атрибута, указанный ниже.

Длина: длина 1 октет, длина атрибута, включая тип.

Значение: 0 или более октетов, содержит информацию, специфичную для атрибута.

Список атрибутов RADIUS

Пример запроса радиуса

Давайте посмотрим на пример запроса радиуса:

• NAS по адресу 192.168.1.16 отправляет UDP-пакет запроса доступа на сервер RADIUS для пользователя с именем Nemo, который входит в порт 3 с паролем «arctangent».

• Аутентификатор запроса — это 16-октетное случайное число, генерируемое NAS.

• Пароль пользователя состоит из 16 октетов, дополненных нулями, XOR и D5 (Shared Secret | Request Authenticator).

• 01 00 00 38 0f 40 3f 94 73 97 80 57 bd 83 d5 cb 98 f4 22 7a 01 06 6e 65 6d 6f 02 12 0d be 70 8d 93 d4 13 ce 31 96 e4 3f 78 2a 0a ee 04 06 c0 a8 01 10 05 06 00 00 00 03

• 1 код = запрос доступа (1)

  1 идентификатор = 0

  2 Длина = 56

  16 Запрос аутентификатора

• Список атрибутов

  6 User-Name = «Nemo»

  18 Пароль пользователя

  6 NAS-IP-адрес = 192.168.1.16

  6 NAS-Port = 3

NAS по адресу 192.168.1.16 отправляет UDP-пакет запроса доступа на сервер RADIUS для пользователя с именем Nemo, который входит в порт 3 с паролем «arctangent».

Аутентификатор запроса — это 16-октетное случайное число, генерируемое NAS.

Пароль пользователя состоит из 16 октетов, дополненных нулями, XOR и D5 (Shared Secret | Request Authenticator).

01 00 00 38 0f 40 3f 94 73 97 80 57 bd 83 d5 cb 98 f4 22 7a 01 06 6e 65 6d 6f 02 12 0d be 70 8d 93 d4 13 ce 31 96 e4 3f 78 2a 0a ee 04 06 c0 a8 01 10 05 06 00 00 00 03

1 код = запрос доступа (1)

1 идентификатор = 0

2 Длина = 56

16 Запрос аутентификатора

Список атрибутов

6 User-Name = «Nemo»

18 Пароль пользователя

6 NAS-IP-адрес = 192.168.1.16

6 NAS-Port = 3

Пример ответа радиуса

Вот пример пакетов ответа:

• Сервер Radius аутентифицирует Nemo и отправляет UDP-пакет Access-Accept на NAS, сообщая его telnet Nemo для размещения 192.168.1.3

• Аутентификатор ответа представляет собой 16-октетную контрольную сумму MD5 кода (2), id (0), длины (38), аутентификатора запроса сверху, атрибутов в этом ответе и общего секрета.

• 02 00 00 26 86 fe 22 0e 76 24 ba 2a 10 05 f6 bf 9b 55 e0 b2 06 06 00 00 00 01 0f 06 00 00 00 00 0e 06 c0 a8 01 03

• 1 код = доступ-принятие (2)

  1 идентификатор = 0 (такой же, как в запросе доступа)

  2 Длина = 38

  16 Аутентификатор ответа

• Список атрибутов:

  6 Тип обслуживания (6) = Логин (1)

  6 Логин-Сервис (15) = Telnet (0)

  6 Login-IP-Host (14) = 192.168.1.3

Сервер Radius аутентифицирует Nemo и отправляет UDP-пакет Access-Accept на NAS, сообщая его telnet Nemo для размещения 192.168.1.3

Аутентификатор ответа представляет собой 16-октетную контрольную сумму MD5 кода (2), id (0), длины (38), аутентификатора запроса сверху, атрибутов в этом ответе и общего секрета.

02 00 00 26 86 fe 22 0e 76 24 ba 2a 10 05 f6 bf 9b 55 e0 b2 06 06 00 00 00 01 0f 06 00 00 00 00 0e 06 c0 a8 01 03

1 код = доступ-принятие (2)

1 идентификатор = 0 (такой же, как в запросе доступа)

2 Длина = 38

16 Аутентификатор ответа

Список атрибутов:

6 Тип обслуживания (6) = Логин (1)

6 Логин-Сервис (15) = Telnet (0)

6 Login-IP-Host (14) = 192.168.1.3

Диаметр — плановая замена RADIUS. Это протокол AAA для таких приложений, как доступ к сети и мобильность IP. Ниже перечислены некоторые моменты, которые вам нужно знать о диаметре:

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

• Диаметр всего в два раза превосходит протокол предшественника Радиус.

• Он использует TCP или SCTP, а не UDP.

• Он использует безопасность транспортного уровня (IPSEC или TLS).

• Он имеет 32-битный идентификатор вместо 8-битного.

• Он поддерживает режимы без сохранения состояния и состояния.

• Он поддерживает подтверждение уровня приложения, определяет отказоустойчивость.

• Он предлагает лучшую поддержку роуминга.

• Он использует AVP.

• Диаметр позволяет определять новые команды и атрибуты. Это легко расширить.

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

Диаметр всего в два раза превосходит протокол предшественника Радиус.

Он использует TCP или SCTP, а не UDP.

Он использует безопасность транспортного уровня (IPSEC или TLS).

Он имеет 32-битный идентификатор вместо 8-битного.

Он поддерживает режимы без сохранения состояния и состояния.

Он поддерживает подтверждение уровня приложения, определяет отказоустойчивость.

Он предлагает лучшую поддержку роуминга.

Он использует AVP.

Диаметр позволяет определять новые команды и атрибуты. Это легко расширить.

Что дальше?

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

Авторизация через Network Policy Server (NPS) для MikroTik / Хабр

Как быстро и просто настроить авторизацию через RADIUS от Microsoft? Думаю, это поможет тем, кто захочет иметь возможность заходить на устройства MikroTik через дружелюбный WinBox и простой SSH.

План:

Установка роли NPS;
Добавление RADIUS клиента;
Создание политики подключения;
Создание политики сети;
Добавление сервера авторизации на MikroTik;
Проверка через SSH и WinBox.

Установка роли NPS

Имеем Windows Server 2016 Datacenter с уже установленным доменом.

Выбираем сервер, на котором будет разворачиваться роль. Microsoft не рекомендует делать это на контроллере домена, но в некоторых best practices для уменьшения задержек дают совет ставить именно на него. Добавляем роль Network Policy and Access Server вместе с management tools для настройки.

Install-WindowsFeature NPAS -IncludeManagementTools

Запускаем любым удобным способом админку NPS. Например, через менеджер серверов.

Регистрируем сервер NPS в AD.

netsh ras add registeredserver

Добавление RADIUS клиента

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

Для примера, добавляю свой MikroTik wAP. Friendly name установил как Identity на устройстве и IP заданный на его единственном проводном интерфейсе. Для того, чтобы устройство смогло авторизоваться на сервере нужно ввести ключ. Он создается на сервере либо вручную, либо генерируется автоматически. Я предпочел второй вариант.

New-NpsRadiusClient –Address "10.1.1.21" –Name "router01" –SharedSecret "egEcM4myJCptphGlZ1UymS#qLh^urp@fJ1hF8dE6dwb27NI^oIJtTWKKp^MEsU6p"

Vendor name остановим на стандартном RADIUS.

Устройство добавлено.

Создание политики подключения

Подбираем подходящее название для политики.

Определяем наше устройство с которым будет работать сервер.

Я выбрал только Client Friendly Name со значением Router01. Это четко привязывает данный пункт политики к устройству через созданного клиента. Можно идентифицировать устройство Mikrotik по Identity выбрав NAS Identifier.

Без предварительной конфигурации устройства Identity = MikroTik.

Дальнейшая настройка политики.

На этапе выбора протокола аутентификации достаточно выбрать нешифрованный (о чем получите предупреждение) PAP для SSH или шифрованный CHAP для WinBox. Я выбрал оба. Если есть необходимость использовать web версию, то достаточно включить MS-CHAPv2, в остальном всё аналогично.

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

На данном этапе я не стал ничего трогать.

Итоговые установки политики.

У меня не получилось воспроизвести это через PowerShell, даже стандартный example с technet’а. Буду признателен, если подскажете почему.

netsh nps add crp name = "Request Policy Router01" state = "ENABLE" processingorder = "1" policysource = "0" conditionid ="0x1020" conditiondata = "router01" profileid = "0x1025" profiledata = "0x1" profileid = "0x1009" profiledata = "0x1" "0x2" profileid = "0x1fb0" profiledata = "TRUE"

Выбираем нужный приоритет двигая выше или ниже пункт политики.

Создание политики сети

Назовем её Routers.

Как и прежде, нужно определить условия.

В AD у меня создан дополнительный пользователь состоящий в группе Domain Admins. Выбираю условие Windows Group исходя из того, чтобы все администраторы домена смогли получать доступ к MikroTik.

Разрешительное или запретительное правило. Мы будем разрешать всем, кто попал под условие.

Способ аутенификации выбираем аналогичный прошлой политике.

Исходя из необходимости можно настроить дополнительные настройки. Я оставил без изменений.

Далее необходимо выбрать что будет отправляться на сервер.

Итоговые настройки политики сети.

Выбираем необходимый приоритет среди других политик, если необходимо.

Чтобы учетная запись проверялась через NPS в AD у этого пользователя на вкладке Dial-in в разделе Network Access Permission должен быть отмечен пункт Control access through NPS Network Policy.

Для возможности авторизовываться через WinBox нужно включить обратимое шифрование в профиле пользователя.

Добавление сервера авторизации на MikroTik

Первым делом присвоим System/Identity равным router01 и IP с маской для интерфейса.

/system identity set name=router01
/ip address add address=10.1.1.21/24 interface=ether1 network=10.1.1.0

В System/Users и на вкладке Users включаем пункт Use RADIUS. По умолчанию выбран доступ только для чтения.

/user aaa set use-radius=yes

Открываем настройки Radius и добавляем новый сервер. Сервис выбирается исходя из назначения. Лучше, конечно же, делить доступ между ними. Address — адрес сервера на котором установлен NPS.

Secret — ключ, который был сгенерирован на стадии добавления клиента на сервере.

/radius add address=10.1.1.1 secret=egEcM4myJCptphGlZ1UymS#qLh^urp@fJ1hF8dE6dwb27NI^oIJtTWKKp^MEsU6p service=login

Проверка через SSH и WinBox

Проверка подключения через SSH и экспорт конфигурации.

И проверяем авторизацию в Winbox.

Как видим, в активных пользователях висят системный admin и оба подключения доменного юзера с доступом для чтения через SSH и Winbox.

Всё работает.

Спасибо за внимание.

Домашняя страничка Славика

Домашняя страничка Славика

Что такое RADIUS сервер

(IT
инженерам не читать! А то уши в трубочку завернутся)
 

Насколько я понял,
после бесконечных попыток пояснить мне, тупому Славику,
любимыми: Гуглом и Яндексом, что ЭТО есть
такое, я пришел к выводу, что RADIUS сервер (Remote
Authentication in Dial-In User Service) — это есть
программа работающая с некой базой данных пользователей, где, в этой базе, сидят
такие данные, как логин, пароль, тариф и прочие атрибуты пользователя
(абонента). Эта программа получает данные пользователя( логин и пароль) от от
NAS (Network Access Server), коим могут быть такие
вещи, как:

1. Точка Wi Fi
доступа
2. VPN сервер (в моем случае это
был некий L2TP сервер)
3. IP АТС
4. …и прочее железо,
которое в дальнейшем так и будем называть — «железка».

и
затем смотрит по своей базе, можно ли этому пользователю давать добро на
подключение к «железке» (NAS-у),
или нет.

Так как RADIUS сервер практически
вряд ли сможет работать с БАЗОЙ
пользователей сам по себе, то его еще называют буфером
(интерфейсом) между некой Биллинговой
программой и «железкой» (NAS-ом)
провайдера.  Хотя такая терминология больше путает, чем что-то разъясняет.
 

«Железки» (NAS-ы)
провайдера, по сути своей, являются подчиненными, или «клиентами»
RADIUS сервера. Они, по научному говоря, являются «сетевыми
серверами доступа» — NAS (Network Access Server), которые передают через себя
данные пользователя (абонента) — логин, пароль, объем трафика, время подключения
RADIUS серверу, а RADIUS сервер смотрит в БАЗУ
данных пользователей и уже затем решает, «перекрыть
кислород» пользователю на основе этих полученных от «железок» данных, или нет. В
моем личном случае в качестве NAS выступал отдельно взятый компьютер под Linux,
на котором был запущен L2TP сервер (VPN сервер). Этот L2TP сервер переправлял
данные пользователя, (его логин, пароль, количество трафика, время подключения),
RADIUS серверу, а тот, посмотрев базе пользователей, может абонент работать в
интернете дальше или нет, принимал свое решение. С соответствии с этим решением
L2TP сервер, который организовывал клиенту VPN-подключение, либо отключал
абонента, либо разрешал ему работать дальше. Так же можно и нужно представить
себе для понимания такую, всегда неизменную, связку
трех разных служб:
1. VPN-сервер (PPTP, L2TP, PPP, IPIP, IPSec) он же NAS, или наша любая другая
«железка» провайдера.
2. RADIUS сервера (буфер, интерфейс между NAS-ом и Биллингом).
3. Биллинг (от любой фирмы изготовителя).
Далее все то же самое, только несколько иными словами…
 

Итак! Еще раз… Для чего же нужен
RADIUS
сервер и
что это есть такое???
RADIUS сервер используется
ТОЛЬКО И В
ОСНОВНОМ
для того, чтобы
работать
с
БАЗОЙ данных пользователей и их валидностю.
То есть каждому пользователю
из Биллинговой программы заранее
прописываются те
или иные привилегии по использованию той или иной «железки» провайдера. Логин,
пароль, тариф,
скорость, время, (когда можно, когда нельзя) и так далее.
И затем, RADIUS сервер, на основе этих данных из
базы данных, выносит свой приговор пользователю, посылая этот приговор «железке»
провайдера (NAS-у).
И «железка», в моем случае это отдельный комп с установленным на него
L2TP
сервером (VPN
сервером) вырубает
пользователя или разрешает ему работать дальше. Авторизует его или отказывает в
авторизации. Если эти привилегии
пользователя
учитывать не нужно, и в мире давно наступил
коммунизм, то RADIUS сервер можно смело
засунуть в топку и забыть про него, как про страшный сон.
Я это сказал к тому, что по своей
сути, RADIUS сервер
— это мешающее провайдеру и
пользователю, устройство. Так же как и Биллинг. Вполне достаточно иметь только
VPN-сервер
(к примеру, L2TP
сервер) со своей личной базой
пользователей, где будут только логины и пароли пользователей. И все…
 

Важное замечание — для чего еще может быть полезен
RADIUS сервер…
Естественно, как
очень важный
момент, получается, что
при использовании RADIUS сервера
не нужно каждой «железке»
(NAS-у)
провайдера, хранить в себе
личную базу
пользователей,
их пароли, атрибуты и
прочее, а можно и нужно хранить эту
базу пользователей только в одном месте, на RADIUS сервере. Там эту базу
провайдер будет админить
через Биллинговую программу и
ВСЕ
«железки» (NAS-ы)
провайдера,
сразу будут об этом узнавать. Хвала, RADIUS серверу, что не нужно будет бегать к
каждой «железке»
в отдельности!!!
Хоть
это и вполне возможно при наличии и у
админа здорового
тела, времени и желания заниматься
такой фигней.
 

Дык,
вот!
Каждая
«железка» (NAS) провайдера, с которой общается пользователь
ОБЯЗАНА
знать IP-адрес RADIUS сервера и имеет
в себе
соответствующее поле, куда этот адрес можно прописать. Выходит, что
КАЖДАЯ
такая «железка» (NAS)
умеет общаться не только с
пользователем-клиентом,
но и с RADIUS сервером, куда она, эта «железка», как шпион, как «стукачка»,
по тихому, по подлому,
передает данные о том, что творит пользователь с ней родной, с
бедной
«железкой». Как долго подключен к ней пользователь, какой трафик прогнал через
нее и прочее. Ну, и как было сказано выше, эта подлая «железка», получив от
пользователя его имя и пароль, сначала спросит разрешение на аутентификацию
пользователя у своего «начальства», то есть у RADIUS сервера, и уже затем даст
пользователю добро на подключение к себе,
или пошлет куда подальше.
Так же
RADIUS сервер,
на основе своей, постоянно изменяющейся базы данных, может запросто сказать
своей подчиненной «железке», что мол все, баста, лимит трафика или времени,
клиент исчерпал. Отключай его, на фиг! И «железка» (NAS),
подчинившись приказу RADIUS сервера,
безропотно выполнит этот
приказ.

В инете, в
многочисленных описаниях, очень часто звучит терминология подобного вида:
«Клиент авторизуется на RADIUS сервере».
И именно эта дебильная фраза сбивала с толку бедного
тупого
Славика и не давала ему понять сущности, что есть такое RADIUS сервер. На кол
таких писателей, блин!!! Дык,
вот, такая терминология в корне НЕВЕРНА!!!
Клиент авторизуется ТОЛЬКО
на «железке»
(на
VPN
сервере, на NAS-е)
провайдера. И именно к
ней он и стучится с мольбой получить доступ в интернет.
А вот сама подлая
«железка» (NAS),
вместо того, чтобы сразу подключить к себе пользователя, ломится к
RADIUS серверу за
разрешением и сообщает ему о том,
что некий клиент к ней авторизуется. RADIUS сервер,
с высоты свой
НЕОПРАВДАННОЙ
значимости, смотрит у себя по
БАЗЕ, есть ли такой пользователь
или нет, (что там записано за
этим пользователем, какие грехи числятся),
и говорит «железке» (NAS-у),
что такой пользователь есть и ему можно дать добро или нужно послать на фиг. И
затем уже
«железка» (NAS)
дает добро своему пользователю (или посылает
его
на фиг). Если RADIUS сервер не установлен
и не существует в природе,
то «железка»(NAS) сама в праве принять решение, авторизовать клиента или нет.
То есть, в ней самой
может существовать база пользователей для авторизации и она самостоятельно
сможет решить,
продолжать
сессию пользователя
или послать
его…
Посему правильно
будет звучать такая
фраза:
«Клиент авторизуется на
«железке»
(на NAS-е)
провайдера». Именно к «железке» провайдера
обращается клиент. НАПРЯМУЮ!!!
А дальше уже подлая «железка» решает, в
зависимости, от того, что прописано в ее настройках, обращаться за разрешение к
своему хозяину — RADIUS серверу, или нет.
А бедный Славик всегда думал иначе. Думал, что обращение идет
всегда и исключительно на RADIUS
сервер и уже затем, он
пропускает клиента дальше, к «железкам», к сервисам провайдера. И потому
непонятны были всегда эти картинки с «прямоугольничками» на разных сайтах с
мануалами, где RADIUS сервер
всегда стоит в сторонке. Как
бы самый последний крайний «прямоугольничек». Типа, — «я тут совсем не при делах
и знать ничего не знаю». А оно вон, оказывается, как обстоят дела! Вон,
оказывается, кто тут на самом деле Главный говнюк!

 

В контексте программ «RADIUS
сервера» и некого «Биллинга», можно сказать еще следующее:

«БАЗА пользователей» —
общая для этих
обеих
служб!!! Формат ее может какой угодно. Даже
может
быть в
формате базы «Ms
SQL»
Главное, чтобы и
RADIUS
сервер и
Биллинговая программа, могли работать с этой базой и понимать ее.

 

RADIUS
сервер, основываясь на данных из этой БАЗЫ, дает команду
NAS

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

сервер пишет в базу статистические данные пользователя,
сколько он спалил трафика, как долго уже продолжается его интернет-сессия и
так далее.. А Биллинговая программа может считать деньги абонентов по этой
базе в реальном времени и так же дает возможность управлять этой базой данных,
внося различные атрибуты пользователя. Дает возможность добавлять нового
пользователя или удалять его. Так же вносит на счет абонента нулевой денежный
остаток, если абонент вовремя не пополнил свой счет. А
RADIUS

сервер, видя «нолик» у пользователя, даст команду «железке»

(NAS-у),
отключить пользователя.

Немного практики для понимания… Чисто теоретически,
допустим, имеем мы три компа:
NAS, RADIUS
сервер и Биллинг.
База стоит на компе c
RADIUS сервером.
Комп с Биллингом включаем, подцепляемся к Базе, вносим туда новых пользователей,
их тарифы и прочее. И вырубаем комп с Биллингом на фиг!!!
Комп с
RADIUS
сервером
будет замечательно
работать и дальше. Будет работать
основываясь на созданной с
помощью Биллинга базе.
Биллинг
RADIUS
серверу
НЕ НУЖЕН!!!
Биллинг нужен, лишь для того, чтобы потом, в дальнейшем, когда база
пользователей уже заполнена, в реальном времени, начать уменьшать денежный
баланс у абонентов. Но если этого делать не нужно и наступил коммунизм, то
Биллинг можно запросто выключить. Повторюсь,
RADIUS
сервер начнет работать сам
по себе, без Биллинга, основываясь лишь на ранее созданной БАЗЕ. Допустим, в
базе данных сказано, что некий Вася Пупки, имеет право работать в интернете
бесплатно, с нулевым балансом, но только в ночное время и только с определенной
скоростью. Все!
Начиная с этого момента,
RADIUS
сервер начнет работать сам по себе, разрешая Васе Пупки подключаться только
ночью и только на определенной скорости. И эта
запись в БАЗЕ есть
неизменная и вечная запись для этого пользователя. Отсюда вопрос. Зачем нам в
этом случае нужен комп с Биллингом? Все верно. Не нужен. Комп с
Билллингом
нужен лишь для того, чтобы что-то изменить в атрибутах и тарифе
этого гипотетического
Васи Пупкина. Только для этого.

Делаем выводы из всего выше сказанного:

RADIUS сервер

(вместе с Биллингом)
— ЭТО
МЕРЗОКОЕ ЗЛО,
которое не то, что помогает, оно жутко мешает!!!..
Тормозит работу, и клиента, и провайдера. И для самой
телематики провайдера
это ЗЛО
на фиг не нужно!!!
RADIUS сервер приходиться
терпеть лишь потому, что
пока еще
не наступил коммунизм.
И
только поэтому!!! И если всякие там
DHCP
серверы,
DNS

серверы,
WWW,
FTP,
WINS

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

И все бы так и было, но есть одно большое

НО.
Если вы внимательно читали этот опус, я обмолвился об одной вещи, но внимание на
ней сильно не акцентировал.
Дык вот, повторюсь
еще раз
про то, что
я писал выше.
Представим себе ситуацию, когда
NAS-ов
у провайдера очень много. И что нам делать в этом случае? На каждом

NAS-е
заводить свою личную базу пользователей с их логинам и паролями?! Нет, конечно!
БАЗА должна быть одна. С ней должен работать наш RADIUS сервер, а все

NAS-ы
провайдера должны обращаться к этому
RADIUS
серверу. Только в этом случае, админу не придется бегать между разными
«железками» (NAS-ами),
чтобы подправлять там тариф, логин и пароль у одного и того же Васи Пупкина.

Аминь!

Подробно про это написано тут:
http://ru.wikipedia.org/wiki/RADIUS

Ссылочка
на халявный RADIUS
сервер:
http://ru.wikipedia.org/wiki/FreeRADIUS

Еще описание:
http://www.softpiua.com/en/radius/86-what-is-radius.html
и сам сервер:
http://www.softpiua.com/en/products/softpi/softpi-radius.html
 

Отзыв об
этой Эпопее можете оставить в моей
Гостевой
книге. 🙂

Или на форуме:

http://ntelekom.sytes.net/forum/viewtopic.php?t=254

Настройка клиентов RADIUS | Документы Microsoft

• 07.08.2020
• 6 минут на чтение

В этой статье

Применимо к: Windows Server (полугодовой канал), Windows Server 2016

Этот раздел можно использовать для настройки серверов доступа к сети в качестве клиентов RADIUS в NPS.

При добавлении в сеть нового сервера доступа к сети (VPN-сервер, точка беспроводного доступа, коммутатор аутентификации или сервер удаленного доступа) необходимо добавить сервер в качестве клиента RADIUS в NPS, а затем настроить клиент RADIUS для связи с НПС.

Важно

Клиентские компьютеры и устройства, такие как портативные компьютеры, планшеты, телефоны и другие компьютеры с клиентскими операционными системами, не являются клиентами RADIUS. Клиенты RADIUS — это серверы доступа к сети, например точки беспроводного доступа 802.Коммутаторы с поддержкой 1X, серверы виртуальной частной сети (VPN) и серверы удаленного доступа — потому что они используют протокол RADIUS для связи с серверами RADIUS, такими как серверы политики сети (NPS).

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

• На прокси-сервере NPS настройте группу удаленных серверов RADIUS, содержащую NPS.
• На удаленном сервере политики сети настройте прокси-сервер политики сети в качестве клиента RADIUS.

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

Настройка сервера доступа к сети

Используйте эту процедуру для настройки серверов доступа к сети для использования с NPS. При развертывании серверов доступа к сети (NAS) в качестве клиентов RADIUS необходимо настроить клиентов для взаимодействия с NPS, где NAS настроены как клиенты.

Эта процедура предоставляет общие рекомендации по настройкам, которые следует использовать для настройки NAS; конкретные инструкции по настройке устройства, развертываемого в сети, см. в документации по продукту NAS.

Для настройки сервера доступа к сети

1. На NAS в настройках RADIUS выберите RADIUS-аутентификацию на протоколе пользовательских дейтаграмм (UDP) порт 1812 и RADIUS-учет на UDP-порт 1813 .
2. На сервере аутентификации или сервере RADIUS укажите NPS по IP-адресу или полному доменному имени (FQDN), в зависимости от требований NAS.
3. В поле Секрет или Общий секрет введите надежный пароль. Когда вы настраиваете NAS в качестве клиента RADIUS в NPS, вы будете использовать тот же пароль, поэтому не забывайте его.
4. Если вы используете PEAP или EAP в качестве метода аутентификации, настройте NAS для использования аутентификации EAP.
5. Если вы настраиваете точку беспроводного доступа, в SSID укажите идентификатор набора услуг (SSID), который представляет собой буквенно-цифровую строку, которая служит именем сети. Это имя передается точками доступа беспроводным клиентам и видно пользователям в точках доступа Wi-Fi.
6. Если вы настраиваете точку беспроводного доступа в 802.1X и WPA , включите IEEE 802.1X аутентификацию , если вы хотите развернуть PEAP-MS-CHAP v2, PEAP-TLS или EAP-TLS.

Добавить сервер доступа к сети в качестве клиента RADIUS в NPS

Используйте эту процедуру, чтобы добавить сервер доступа к сети в качестве клиента RADIUS в NPS. Эту процедуру можно использовать для настройки NAS в качестве клиента RADIUS с помощью консоли NPS.

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

Чтобы добавить сервер доступа к сети в качестве клиента RADIUS в NPS

1. На сервере политики сети в диспетчере серверов щелкните Инструменты , а затем щелкните Сервер сетевой политики .Откроется консоль NPS.
2. В консоли NPS дважды щелкните Клиенты и серверы RADIUS . Щелкните правой кнопкой мыши RADIUS Clients , а затем щелкните New RADIUS Client .
3. В Новый клиент RADIUS убедитесь, что установлен флажок Включить этот клиент RADIUS .
4. В New RADIUS Client , в Friendly name введите отображаемое имя для NAS. В поле Address (IP или DNS) введите IP-адрес NAS или полное доменное имя (FQDN).Если вы вводите полное доменное имя, нажмите Проверить , если вы хотите убедиться, что имя правильное и соответствует действительному IP-адресу.
5. В New RADIUS Client , в Vendor укажите имя производителя NAS. Если вы не уверены в названии производителя NAS, выберите RADIUS standard .
6. В Новый клиент RADIUS , в Общий секрет , выполните одно из следующих действий:
   • Убедитесь, что выбран Ручной , а затем в Общий секрет введите надежный пароль, который также вводится на NAS.Повторно введите общий секрет в Подтвердите общий секрет .
   • Выберите Создать , а затем нажмите Создать , чтобы автоматически сгенерировать общий секрет. Сохраните сгенерированный общий секрет для настройки на NAS, чтобы он мог взаимодействовать с NPS.
7. В Новый клиент RADIUS , в Дополнительные параметры , если вы используете какие-либо методы аутентификации, кроме EAP и PEAP, и если ваш NAS поддерживает использование атрибута аутентификатора сообщения, выберите Сообщения запроса доступа должны содержать атрибут аутентификатора сообщения .
8. Щелкните ОК . Ваш NAS появится в списке клиентов RADIUS, настроенных на NPS.

Настройка клиентов RADIUS по диапазону IP-адресов в Windows Server 2016 Datacenter

Если вы используете Windows Server 2016 Datacenter, вы можете настроить клиентов RADIUS в NPS по диапазону IP-адресов. Это позволяет добавлять большое количество клиентов RADIUS (например, точек беспроводного доступа) к консоли NPS одновременно, а не добавлять каждого клиента RADIUS по отдельности.

Вы не можете настроить клиентов RADIUS по диапазону IP-адресов, если вы используете NPS на Windows Server 2016 Standard.

Используйте эту процедуру для добавления группы серверов доступа к сети (NAS) в качестве клиентов RADIUS, для которых все настроены с IP-адресами из одного диапазона IP-адресов.

Все клиенты RADIUS в диапазоне должны использовать одну и ту же конфигурацию и общий секрет.

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

Для настройки клиентов RADIUS по диапазону IP-адресов

1. На сервере политики сети в диспетчере серверов щелкните Инструменты , а затем щелкните Сервер сетевой политики . Откроется консоль NPS.
2. В консоли NPS дважды щелкните Клиенты и серверы RADIUS . Щелкните правой кнопкой мыши RADIUS Clients , а затем щелкните New RADIUS Client .
3. В New RADIUS Client , в Friendly name введите отображаемое имя для набора NAS.
4. В поле Address (IP или DNS) введите диапазон IP-адресов для клиентов RADIUS, используя нотацию бесклассовой междоменной маршрутизации (CIDR). Например, если диапазон IP-адресов для NAS — 10.10.0.0, введите 10.10.0.0/16 .
5. В New RADIUS Client , в Vendor укажите имя производителя NAS. Если вы не уверены в названии производителя NAS, выберите RADIUS standard .
6. В Новый клиент RADIUS , в Общий секрет , выполните одно из следующих действий:
   • Убедитесь, что выбран Ручной , а затем в Общий секрет введите надежный пароль, который также вводится на NAS.Повторно введите общий секрет в Подтвердите общий секрет .
   • Выберите Создать , а затем нажмите Создать , чтобы автоматически сгенерировать общий секрет. Сохраните сгенерированный общий секрет для настройки на NAS, чтобы он мог взаимодействовать с NPS.
7. В Новый клиент RADIUS , в Дополнительные параметры , если вы используете какие-либо методы аутентификации, кроме EAP и PEAP, и если все ваши NAS поддерживают использование атрибута аутентификатора сообщения, выберите Сообщения запроса доступа должны содержать сообщение Атрибут аутентификатора .
8. Щелкните ОК . Ваши NAS появятся в списке клиентов RADIUS, настроенных на NPS.

Для получения дополнительной информации см. Клиенты RADIUS.

Дополнительные сведения о NPS см. В разделе Сервер политики сети (NPS).

.

Руководство по настройке атрибутов RADIUS — Атрибут 8 RADIUS в рамке IP-адреса в запросах доступа [Cisco Cloud Services Router 1000V Series]

Когда сетевое устройство подключается к NAS, настроенному для аутентификации RADIUS, NAS начинает процесс установления связи сервер RADIUS в процессе подготовки к аутентификации пользователя. Как правило, IP-адрес узла удаленного доступа не передается серверу RADIUS до тех пор, пока не пройдет успешная аутентификация пользователя. Передача IP-адреса устройства серверу в запросе доступа RADIUS позволяет другим приложениям начать использовать эту информацию.

Когда NAS устанавливает связь с сервером RADIUS, NAS назначает IP-адрес хосту удаленного доступа из пула IP-адресов, настроенных на конкретном интерфейсе. NAS отправляет IP-адрес узла подключения к серверу RADIUS в качестве атрибута 8. В это время NAS отправляет другую информацию о пользователе, например имя пользователя, на сервер RADIUS.

После того, как сервер RADIUS получит информацию о пользователе от NAS, у него есть два варианта:

• Если профиль пользователя на сервере RADIUS уже включает атрибут 8, сервер RADIUS может заменить IP-адрес, отправленный NAS, на IP-адрес, определенный как атрибут 8 в профиле пользователя.Адрес, указанный в профиле пользователя, возвращается на NAS.

• Если профиль пользователя не включает атрибут 8, сервер RADIUS может принять атрибут 8 от NAS, и тот же адрес будет возвращен NAS.

Адрес, возвращаемый сервером RADIUS, сохраняется в памяти NAS в течение всего сеанса. Если NAS настроен для учета RADIUS, пакет запуска учета, отправленный на сервер RADIUS, включает тот же IP-адрес, что и в атрибуте 8.Все последующие учетные пакеты, обновления (если настроены) и стоп-пакеты также будут включать тот же IP-адрес, который указан в атрибуте 8.

Однако атрибут 8 RADIUS (Framed-IP-Address) не включается в начальные пакеты учета в следующих двух условиях:

В обоих этих условиях используйте
ааа
бухгалтерский учет
отсрочка старта
увеличенное время
delay-value команда для задержки согласования адреса протокола управления интернет-протоколом версии 6 (IPCPv6) с использованием настроенного значения задержки.Во время задержки отправляется адрес IPCPv4, а адрес IPv4 во фрейме добавляется в начальный пакет учета.

.Руководство по настройке атрибутов RADIUS

— возможность настройки атрибута IP-адреса NAS-RADIUS [Cisco Cloud Services Router 1000V Series]

Для моделирования большого клиента NAS RADIUS с использованием кластера небольших клиентов RADIUS NAS, как показано на
фигура 1
, в сеть вставлено устройство преобразования сетевых адресов (NAT) или преобразования адресов портов (PAT). Устройство размещается между кластером NAS и IP-облаком, подключенным к серверу RADIUS. Когда трафик RADIUS с разных NAS проходит через устройство NAT или PAT, исходные IP-адреса пакетов RADIUS преобразуются в один IP-адрес, скорее всего, IP-адрес на интерфейсе обратной связи на устройстве NAT или PAT.Различные исходные порты протокола пользовательских дейтаграмм (UDP) назначаются пакетам RADIUS от разных NAS. Когда ответ RADIUS возвращается от сервера, устройство NAT или PAT принимает его, использует порт назначения UDP для преобразования IP-адреса назначения обратно в IP-адрес NAS и пересылает ответ на соответствующий NAS.

На рисунке ниже показано, как исходные IP-адреса нескольких NAS преобразуются в один IP-адрес, когда они проходят через устройство NAT или PAT на пути к IP-облаку.

Серверы RADIUS обычно проверяют IP-адрес источника в IP-заголовке пакетов RADIUS, чтобы отслеживать источник запросов RADIUS и поддерживать безопасность. Решение NAT или PAT удовлетворяет этим требованиям, поскольку используется только один исходный IP-адрес, даже если пакеты RADIUS поступают от разных маршрутизаторов NAS.

Однако при получении учетных записей из базы данных RADIUS некоторые биллинговые системы используют в учетных записях атрибут 4 RADIUS, NAS-IP-Address.Значение этого атрибута записывается на маршрутизаторах NAS как их собственные IP-адреса. Маршрутизаторы NAS не знают о NAT или PAT, которые проходят между ними и сервером RADIUS; поэтому разные адреса атрибута 4 RADIUS будут записаны в учетных записях для пользователей с разных маршрутизаторов NAS. Эти адреса в конечном итоге открывают доступ к различным маршрутизаторам NAS серверу RADIUS и соответствующим биллинговым системам.

.

RADIUS Server Authentication of Management Users on Wireless LAN Controller (WLC) Пример конфигурации

В этом документе объясняется, как настроить Контроллер беспроводной локальной сети (WLC) и Сервер управления доступом (Cisco Secure ACS), чтобы сервер AAA мог аутентифицировать пользователей управления на контроллере. В документе также объясняется, как разные пользователи управления могут получать разные привилегии с помощью атрибутов, зависящих от поставщика (VSA), возвращаемых сервером Cisco Secure ACS RADIUS.

Требования

Перед тем, как попробовать эту конфигурацию, убедитесь, что вы соответствуете этим требованиям:

Используемые компоненты

Информация в этом документе основана на следующих версиях программного и аппаратного обеспечения:

• Контроллер беспроводной локальной сети Cisco 4400, работающий под управлением версии 7.0.216.0

• Cisco Secure ACS, на котором работает версия программного обеспечения 4.1 и который используется в этой конфигурации как сервер RADIUS.

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

Условные обозначения

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

В этом разделе вам представлена ​​информация о том, как настроить WLC и ACS для целей, описанных в этом документе.

Схема сети

В этом документе используется следующая настройка сети:

В этом примере конфигурации используются следующие параметры:

• IP-адрес Cisco Secure ACS —172.16.1.1 / 255.255.0.0

• IP-адрес интерфейса управления контроллера — 172.16.1.30 / 255.255.0.0

• Общий секретный ключ, который используется на точке доступа (AP) и сервере RADIUS — asdf1234

• Это учетные данные двух пользователей, которые в этом примере настраиваются в ACS:

  • Имя пользователя — acsreadwrite

    Пароль — acsreadwrite

  • Имя пользователя — acsreadonly

    Пароль — acsreadonly

Вам необходимо настроить WLC и Cisco Secure Cisco Secure ACS, чтобы:

• Любому пользователю, который входит в WLC с именем пользователя и паролем как acsreadwrite , предоставляется полный административный доступ к WLC.

• Любому пользователю, который входит в WLC с именем пользователя и паролем как acsreadonly , предоставляется доступ только для чтения к WLC.

Конфигурации

В этом документе используются следующие конфигурации:

Конфигурация WLC

Настройте WLC для принятия управления через сервер Cisco Secure ACS

Выполните эти шаги для настройки WLC так, чтобы он мог связываться с сервером RADIUS.

1. В графическом интерфейсе WLC щелкните Security . В меню слева выберите RADIUS> Аутентификация . Откроется страница серверов аутентификации RADIUS . Чтобы добавить новый сервер RADIUS, щелкните New . На странице RADIUS Authentication Servers> New введите параметры, относящиеся к серверу RADIUS. Вот пример.

2. Отметьте переключатель Management , чтобы позволить серверу RADIUS аутентифицировать пользователей, которые входят в WLC.

   Примечание: Убедитесь, что общий секрет, настроенный на этой странице, совпадает с общим секретом, настроенным на сервере RADIUS. Только тогда WLC может связаться с сервером RADIUS.

3. Проверьте, настроен ли WLC для управления Cisco Secure ACS. Для этого нажмите Security из графического интерфейса WLC. В результате появится окно графического интерфейса пользователя, подобное этому примеру.

   Вы можете видеть, что флажок Management включен для сервера RADIUS 172.16.1.1. Это показывает, что ACS позволено аутентифицировать пользователей управления на WLC.

Конфигурация Cisco Secure ACS

Выполните действия, описанные в этих разделах, для настройки ACS:

1. Добавьте WLC в качестве клиента AAA к серверу RADIUS.

2. Настройте пользователей и их соответствующие атрибуты RADIUS IETF.

3. Настройте пользователя с доступом для чтения и записи.

4. Настройте пользователя с доступом только для чтения.

Добавьте WLC в качестве клиента AAA к серверу RADIUS

Выполните эти шаги для добавления WLC в качестве клиента AAA в Cisco Secure ACS.

1. В графическом интерфейсе ACS щелкните Network Configuration .

2. В разделе «Клиенты AAA» щелкните Добавить запись .

3. В окне Добавить клиента AAA введите имя хоста WLC, IP-адрес WLC и общий секретный ключ.

   В этом примере это настройки:

   • Имя хоста клиента AAA: WLC-4400

   • 172.16.1.30/16 — это IP-адрес клиента AAA, которым в данном случае является WLC.

   • Общий секретный ключ — «asdf1234».

   Этот общий секретный ключ должен быть таким же, как общий секретный ключ, который вы настраиваете на WLC.

4. В раскрывающемся меню «Аутентификация с помощью» выберите RADIUS (Cisco Airespace) .

5. Нажмите Submit + Restart , чтобы сохранить конфигурацию.

Настроить пользователей и их соответствующие атрибуты RADIUS IETF

Чтобы аутентифицировать пользователя через сервер RADIUS, для входа в систему и управления контроллером, вы должны добавить пользователя в базу данных RADIUS с атрибутом IETF RADIUS Service-Type , установленным на соответствующее значение в соответствии с привилегиями пользователя.

• Чтобы установить права чтения и записи для пользователя, установите для атрибута Service-Type значение Administrative .

• Чтобы установить привилегии только для чтения для пользователя, установите для атрибута Service-Type значение NAS-Prompt .

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

Первый пример показывает конфигурацию пользователя с полным доступом к WLC. Когда этот пользователь пытается войти в контроллер, сервер RADIUS аутентифицируется и предоставляет этому пользователю полный административный доступ.

В этом примере имя пользователя и пароль — acsreadwrite .

Выполните эти шаги в Cisco Secure ACS.

1. В графическом интерфейсе ACS щелкните User Setup .

2. Введите имя пользователя, которое будет добавлено в ACS, как показано в этом примере окна.

3. Щелкните Добавить / изменить , чтобы перейти на страницу редактирования пользователя.

4. На странице редактирования пользователя укажите настоящее имя, описание и пароль этого пользователя.

5. Прокрутите вниз до параметра IETF RADIUS Attributes и проверьте Service-Type Attribute .

6. Поскольку в этом примере пользователю acsreadwrite должен быть предоставлен полный доступ, выберите Administrative в раскрывающемся меню Service-Type и нажмите Submit .

   Это гарантирует, что этот конкретный пользователь имеет доступ для чтения и записи к WLC.

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

1. В графическом интерфейсе ACS выберите « Interface Configuration> RADIUS (IETF) », чтобы включить атрибуты IETF в окне User Configuration.

   Вы попадете на страницу настроек RADIUS (IETF).

2. На странице настроек RADIUS (IETF) вы можете включить атрибут IETF, который должен быть видимым в настройках пользователя или группы. Для этой конфигурации отметьте Service-Type в столбце User и нажмите Submit .В этом окне показан пример.

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

   Примечание: Кроме того, если аутентификация выполняется на групповой основе, вам необходимо назначить пользователей определенной группе и настроить атрибуты IETF для настройки групп, чтобы предоставить права доступа пользователям этой группы.См. «Управление группами» для получения подробной информации о том, как настраивать группы и управлять ими.

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

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

В этом примере имя пользователя и пароль — acsreadonly .

Выполните следующие действия в Cisco Secure ACS:

1. В графическом интерфейсе ACS щелкните User Setup .

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

3. Укажите настоящее имя, описание и пароль этого пользователя. В этом окне показан пример.

4. Прокрутите вниз до параметра IETF RADIUS Attributes и проверьте Service-Type Attribute .

5. Поскольку в этом примере пользователь acsreadonly должен иметь доступ только для чтения, выберите NAS Prompt в раскрывающемся меню Service-Type и нажмите Submit .

   Это гарантирует, что этот конкретный пользователь имеет доступ только для чтения к WLC.

Управление WLC локально, а также через сервер RADIUS

Вы также можете настроить пользователей управления локально на WLC. Это можно сделать из графического интерфейса контроллера в разделе «Управление »> «Локальные пользователи управления» .

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

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

2. Если один и тот же пользователь существует как локально, так и на сервере RADIUS, но с разными привилегиями доступа, то WLC аутентифицирует пользователя с привилегиями, указанными локально.Другими словами, локальная конфигурация на WLC всегда имеет приоритет по сравнению с сервером RADIUS.

Порядок аутентификации для управляющих пользователей может быть изменен на WLC. Для этого на странице Security на WLC нажмите Priority Order> Management User . На этой странице вы можете указать порядок аутентификации. Вот пример.

Примечание: Если в качестве второго приоритета выбран ЛОКАЛЬНЫЙ, то пользователь будет аутентифицирован с использованием этого метода только в том случае, если метод, определенный как первый приоритет (RADIUS / TACACS), недоступен.

Чтобы проверить, работает ли ваша конфигурация должным образом, обратитесь к WLC через интерфейс командной строки или графический интерфейс (HTTP / HTTPS). Когда появится приглашение для входа в систему, введите имя пользователя и пароль, как настроено на Cisco Secure ACS.

Если у вас есть правильные конфигурации, вы успешно прошли аутентификацию в WLC.

Вы также можете убедиться, что аутентифицированному пользователю предоставлены ограничения доступа, указанные ACS. Для этого обратитесь к графическому интерфейсу WLC через HTTP / HTTPS (убедитесь, что WLC настроен на разрешение HTTP / HTTPS).

Пользователь с доступом для чтения и записи, установленным в ACS, имеет несколько настраиваемых привилегий в WLC. Например, пользователь для чтения и записи имеет привилегию создать новую WLAN на странице WLANs WLC. В этом окне показан пример.

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

Эти ограничения доступа также можно проверить через интерфейс командной строки WLC.Этот вывод показывает пример.

  (контроллер Cisco) > ? 

debug Управляет параметрами отладки системы.
Помогите помогите
linktest Выполнение теста связи с указанным MAC-адресом.
logout Выйти из сеанса. Все несохраненные изменения теряются.
показать параметры и настройки переключателя дисплея.

(Контроллер Cisco)> конфигурация

Неправильное использование. Использовать '?' или клавишу  для вывода списка команд. 

Как видно из этого примера, ? в интерфейсе командной строки контроллера отображает список команд, доступных текущему пользователю.Также обратите внимание, что команда config недоступна в выходных данных этого примера. Это показывает, что пользователь только для чтения не имеет права выполнять какие-либо конфигурации на WLC. Принимая во внимание, что пользователь чтения-записи действительно имеет привилегии выполнять настройки на контроллере (как в режиме графического интерфейса, так и в режиме командной строки).

Примечание: Даже после аутентификации пользователя WLC через сервер RADIUS при переходе от страницы к странице сервер HTTP [S] все еще полностью аутентифицирует клиента каждый раз.Единственная причина, по которой вам не предлагается пройти аутентификацию на каждой странице, заключается в том, что ваш браузер кэширует и воспроизводит ваши учетные данные.

Существуют определенные обстоятельства, когда контроллер аутентифицирует пользователей управления через ACS, аутентификация завершается успешно (access-accept), и вы не видите никаких ошибок авторизации на контроллере. Но пользователю снова предлагается пройти аутентификацию.

В таких случаях вы не можете интерпретировать, что не так и почему пользователь не может войти в WLC, просто используя команду debug aaa events enable .Вместо этого контроллер отображает другое приглашение для аутентификации.

Одна из возможных причин этого заключается в том, что ACS не настроен для передачи атрибута Service-Type для этого конкретного пользователя или группы, даже если имя пользователя и пароль правильно настроены на ACS.

Выходные данные команды debug aaa events enable не указывают на то, что у пользователя нет требуемых атрибутов (для этого примера, атрибута Service-Type), даже несмотря на то, что access-accept отправляется обратно с сервера AAA .В этом примере debug aaa events enable command output показывает пример.

  (контроллер Cisco) >  события отладки aaa включить 



Пн 13 августа 20:14:33 2011: AuthenticationRequest: 0xa449a8c

Пн 13 августа 20:14:33 2011: Обратный вызов ..................................... 0x8250c40

Пн 13 августа 20:14:33 2011: protocolType ................................. 0x00020001

Пн 13 августа 20:14:33 2011: proxyState ...................... 1A: 00: 00: 00: 00: 00-00: 00

Пн 13 августа, 20:14:33 2011: Пакет содержит 5 AVP (не показаны)

Пн 13 августа 20:14:33 2011: 1a: 00: 00: 00: 00: 00 Успешная передача
Пакет аутентификации (id 8) на 172.16.1.1: 1812, состояние прокси
1a: 00: 00: 00: 00: 00-00: 00

Пн 13 августа 20:14:33 2011: **** Введите processIncomingMessages: код ответа = 2

Пн 13 августа 20:14:33 2011: **** Введите processRadiusResponse: код ответа = 2

  Пн, 13 августа 20:14:33 2011: 1a: 00: 00: 00: 00: 00 Доступ-Принять
получено с сервера RADIUS 172.16.1.1 для мобильного 1a: 00: 00: 00: 00: 00 receiveId = 0 

13 авг 20:14:33 2011: Авторизация Ответ: 0x9802520

Пн 13 августа, 20:14:33 2011: structureSize ................................ 28

Пн 13 августа 20:14:33 2011: resultCode................................... 0

Пн 13 августа 20:14:33 2011: protocolUsed ................................. 0x00000001

Пн 13 августа 20:14:33 2011: proxyState ....................... 1A: 00: 00: 00: 00: 00-00: 00

Пн 13 августа 20:14:33 2011: Пакет содержит 0 AVP: 

В этом первом примере события отладки aaa позволяют выводить команду , вы видите, что Access-Accept успешно получен от сервера RADIUS, но атрибут Service-Type не передан на WLC. Это связано с тем, что конкретный пользователь не настроен с этим атрибутом в ACS.

Cisco Secure ACS необходимо настроить для возврата атрибута Service-Type после аутентификации пользователя. Значение атрибута Service-Type должно быть установлено на Administrative или NAS-Prompt в соответствии с правами пользователя.

Этот второй пример показывает, что события отладки снова активируют вывод команды . Однако на этот раз для атрибута Service-Type установлено значение Administrative на ACS.

  (контроллер Cisco) >  события отладки aaa включить 



Пн, 13 августа, 20:17:02 2011: AuthenticationRequest: 0xa449f1c

Пн 13 августа, 20:17:02 2011: Обратный звонок..................................... 0x8250c40

Пн 13 августа 20:17:02 2011: protocolType ................................. 0x00020001

Пн 13 августа 20:17:02 2011: proxyState ....................... 1D: 00: 00: 00: 00: 00-00: 00

Пн 13 августа, 20:17:02 2011: Пакет содержит 5 AVP (не показаны)

Пн 13 августа 20:17:02 2011: 1d: 00: 00: 00: 00: 00 Успешная передача
Пакет аутентификации (id 11) на 172.16.1.1:1812, состояние прокси
1д: 00: 00: 00: 00: 00-00: 00

Пн 13 августа 20:17:02 2011: **** Введите processIncomingMessages: код ответа = 2

Пн 13 августа 20:17:02 2011: **** Введите processRadiusResponse: код ответа = 2

  Пн, 13 августа, 20:17:02 2011: 1д: 00: 00: 00: 00: 00 Принятие доступа получено
с сервера RADIUS 172.16.1.1 для мобильных 1d: 00: 00: 00: 00: 00 receiveId = 0 

Пн 13 авг 20:17:02 2011: Авторизация Ответ: 0x9802520

Пн 13 августа 20:17:02 2011: structureSize ................................ 100

Пн 13 августа 20:17:02 2011: resultCode ................................... 0

Пн 13 августа 20:17:02 2011: protocolUsed ................................. 0x00000001

Пн 13 августа 20:17:02 2011: proxyState ....................... 1D: 00: 00: 00: 00: 00-00: 00

Пн 13 августа 20:17:02 2011: Пакет содержит 2 AVP:

  Пн, 13 августа, 20:17:02 2011: Тип службы AVP [01]........... 0x00000006 (6) (4 байта) 

Пн 13 августа, 20:17:02 2011: AVP [02] Класс .........
CISCOACS: 000d1b9f / ac100128 / acsserver (36 байт) 

В этом примере выходных данных вы можете видеть, что атрибут Service-Type передан на WLC.

.