Файл: Служба radius и её настройка.docx

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 11.01.2024

Просмотров: 67

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.




Аутентификация и авторизация через RADIU 1



Онлайн учёт через RADIUS-сервер 1

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

  • Используемый "общий секрет" должен иметь длину не менее 32 шестнадцатеричных символов или, соответственно, 22 символов клавиатуры.

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

  • С криптографической точки зрения непременным условием является качественное удостоверение запроса.

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

  • Следует пользоваться ЕАР или схемами типа ЕАР с поддержкой сильных методов аутентификации. Хороший пример подобного метода - ЕАР-TLS. Он требует обмена сертификатами между клиентом, пытающимся получить доступ, и сервером RADIUS. Все сообщения ЕАР должны иметь атрибуты удостоверения сообщения для защиты тех сообщений запроса доступа, к которым IPSec не применяется.

  • Желательно выбирать методы аутентификации, рассчитанные на двустороннюю аутентификацию. При таком подходе противоположные конечные точки соединения аутентифицируют свои системы. Если с какой-либо стороны аутентификация пройдет неудачно, то в установлении соединения будет отказано. Примерами подобных методов служат ЕАР-TLS и MS-CHAPv2. Так, в случае ЕАР-TLS сервер RADIUS проводит проверку пользовательского сертификата клиента, пытающегося получить доступ, а клиент в свою очередь - сертификата сервера RADIUS.

  • Если аутентификация производится посредством РАР, то эту опцию следует отключить. При аутентификации с помощью однократных паролей или токенов происходит откат к PAP. Но поскольку IEEE 802.1x не поддерживает РАР, в подобных случаях чаще всего пользуются соединениями РРР.



    1. Проверка подлинности RADIUS

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


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

  • Access-Reject - показывает, что данный пользовательский запрос неверный. При желании сервер может включить текстовое сообщение в Access-Reject, которое может быть передано клиентом пользователю. Никакие другие атрибуты (кроме Proxy-State) не разрешены в Access-Reject.

  • Access-Challenge - запрос дополнительной информации от пользователя, например, второй пароль, пин-код, номер карты и т.п. Этот отклик также используется для более полного аутентификационного диалога, где защитный туннель выполняется между устройством пользователя и RADIUS сервером, так что сертификаты доступа скрываются от NAS.

  • Access Accept - пользователю разрешен доступ. Поскольку пользователь аутентифицирован, то RADIUS сервер проверяет авторизацию на использование запрошенных пользователем ресурсов. Например, пользователю может быть разрешён доступ через беспроводную сеть, но запрещен доступ к VPN сети.Таким образом, работа RADIUS протокола может в общем случае быть представлена, как показано на таблице ниже.

ГЛАВА II. РЕАЛИЗАЦИЯ

2.1. П

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



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



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



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






DNS делегацию мы не создаем, так как у нас нет в этом какой-либо необходимости, просто нажимаем далее.



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



В данном окне, tools, выбираем необходимы нам пункт - Network Policy Server



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



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



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



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



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



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




На следующем шаге Specify conditions нам нужно добавить условия, при которых будет применяться данная политика RADIUS. Добавим два условия:



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



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



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

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



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



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



ЗАКЛЮЧЕНИЕ

На основе выше проделанной работы мы изучили протокол ‘RADIUS’

Исходя из проделанной выше работы мы можем сделать вывод, что RADIUS необходим для реализации аутентификации, авторизации и сбора сведений об использованных ресурсах, разработанный для передачи сведений между центральной платформой и оборудованием. Так же можно добавить, что RADUIS в настоящее время используется для виртуального доступа к частным сетям (VPN), беспроводным точкам доступа (Wi-Fi), Ethernet коммутаторам и другим сетевым устройствам.

Так же аналогом ‘RADIUS’ является lanbilling 2, в целом он относительно так же прост в использовании, но в основном все настраивается при помощи скриптов.

В целом RADIUS необходим для отслеживания трафика и контроля доступа при удаленном подключении.

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

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ:


  • ru.wikipedia.org

  • osp.ru

  • vasexperts.ru

  • miniorange.com

  • youtube.com