3.1 Основные понятия AAA
В связи с возникшими и описанными в предыдущей главе проблемами при создании SIP номеров, было решено рассмотреть семейство протоколов Аuthentication, Аuthorization, Аccounting и выбрать один, который максимально подходит к нашим требованиям.
Единый термин AAA обозначает действия по аутентификации, авторизации и учету (Authentication, Authorization, Accounting). Важность эти операций все более возрастает по мере распространения сетей NGN. Все три составляющие AAA связаны тесно друг с другом, представляют собой единое целое.
− аутентификация – сопоставление персоны (запроса) существующей учётной записи в системе безопасности. Осуществляется по логину, паролю, сертификату, смарт-карте и т. д;
− авторизация – проверка полномочий, проверка уровня доступа, выяснение определённых полномочий (или запрета на доступ). В общем случае авторизация может быть «негативной» (пользователю А запрещён доступ к серверам компании);
− учёт – сбор информации о распределении ресурсов пользователем.
Существуют два вида аутентификации:
1) двусторонняя. Процедура выполняется непосредственно участниками диалога. При поступлении запроса аутентификации аутентифицирующая сторона выполняет аутентификацию локально, на основе хранящейся в данной узле информации. Понятно, что данная модель не может использоваться в больших распределенных сетях, из-за возникновения избыточности в них;
2) трехсторонняя. В данной модели точки доступа будут только передатчиками аутентификационной информации к единому хранилищу, которое содержит всю необходимую для аутентификации любого пользователя информацию. Она характеризуется след набором компонентов: поставщик аутентификационной информации, сервер доступа к сети, сервер AAA.
Любой сервис-провайдер использует как раз трехстороннюю модель аутентификации. Функциональная схема используемой модели расположена ниже.
Трехсторонняя модель аутентификации. На участке обмена между NAS (Network Access Server),сервером доступа к сети и сервером ААА и лежит зона ответственности AAA-протоколов.
Точное определения каждой из трех выше описанных процедур AAA позволяет сделать вывод об их тесной взаимосвязи – в реальности в подавляющем большинстве используется одновременно минимум 2 процедуры.
Рисунок 17 – Функциональная схема трехсторонней аутентификации3.2 Протоколы AAA
Существует несколько протоколов обеспечения функционирования метода AAA. Примерами являются протоколы RADIUS, TACACS+, DIAMETER, TACACS и XTACACS. Наиболее распространенными протоколами являются RADIUS, Diameter и TACACS+. Ниже дано краткое описание этих трех протоколов. Не будем заострять внимание на протоколах TACACS и XTACACS, потому что они являются старыми версиями TACACS+ и уже не используются на практике.
RADIUS (англ. Remote Authentication in Dial-In User Service) это протокол для реализации аутентификации, авторизации и сбора сведений об использованных ресурсах, разработанный для передачи сведений между центральной платформой и оборудованием. Этот протокол был разработан независимой группой разработчиков (на данный момент протокол не модифицируется) и поэтому получил широкое распространение у сторонних разработчиков. Как правило, все производители программных и аппаратных клиентов поддерживают данный протокол. На рисунке 18 представлен процесс обмена сообщениями по протоколу RADIUS.
Рисунок 18 – Процесс обмена сообщениями по протоколу RADIUS
Наиболее полными с точки зрения получаемых возможностей являются системы, построенные на основе данного протокола.
Для доступа в роли пользовательского оборудования выступает компьютер и модем или SIP приставка и абонентский роутер, которые обеспечивают соединение с сетевым сервером доступа NAS, и получают доступ к ресурсам сети провайдера услуг. После установления соединения с сетевым сервером доступа пользователь проходит процедуру аутентификации, которая заключается в предоставлении уникального пользовательского имени и пароля.
Прежде чем разрешить доступ пользователя к сети провайдера, NAS проверяет правильность предоставленной пользователем информации. Эта процедура аутентификации проводится RADIUS-сервером, который может взаимодействовать со множеством NAS-серверов, использующих протокол RADIUS.
Среди определенных протоколом RADIUS сообщений наибольший интерес, представляют два – это сообщения запроса доступа Access-Request и разрешения доступа Access-Accept. Сообщение Access-Request посылается от сетевого сервера доступа к RADIUS-серверу и содержит в своем формате поля, соответствующие имени пользователя и его паролю. Информация о пользовательском имени и пароле представляется в определенной форме – в атрибутах RADIUS User-Name и User-Password.
В сети провайдера RADIUS-сервер, выступающий в роли централизованной службы аутентификации, авторизации и учета, после получения от сетевого сервера доступа сообщения Access-Request проверяет пользовательское имя и пользовательский пароль.
По результатам проверки пользователь либо получает доступ к сетевым ресурсам, либо ему дается отказ. В первом случае RADIUS-сервер посылает в обратном направлении сообщение Access-Accept, содержащее IP-адрес (Framed-IP-Address), который указывает сетевому серверу доступа IP-адрес, присвоенный пользователю для запрашиваемого доступа.
Соответствие между сообщениями Access-Request и Access-Accept устанавливается с помощью служебных идентификационных полей.
Существует два алгоритмически различных процесса: процесс аутентификации, изображенный на рисунке 19 и процесс аудита (учета), изображенный на рисунке 20.
Процесс аутентификации заключается в следующих этапах:
1) пользователь инициирует процесс аутентификации, делая запрос к NAS-серверу;
2) NAS-сервер запрашивает логин и пароль, пользователь их вводит;
3) NAS-сервер посылает RADIUS-серверу пакет Acces-Request, содержащий логин, пароль и другие атрибуты. Пароль посылается в открытом или зашифрованном виде, в зависимости от типа аутентификации (наиболее популярные PAP или CHAP/MSCHAPv2);
Рисунок 19 – Функциональная схема процесса аутентификации
4) RADIUS-сервер идентифицирует пользователя по логину, проверяет верен ли пароль, есть ли возможность подключения (ибо есть максимальное число подключений на NAS), сумму на балансе, включена ли услуга и т. п.;
5) RADIUS-сервер возвращает один из вариантов пакета:
а) access-Accept – пользователь аутентифицирован;
б) access-Reject – пользователь не аутентифицирован;
в) access-Challenge – используется при аутентификации по методу CHAP и ему подобных.
6) дополнительно RADIUS-сервер добавляет в пакет атрибуты, содержащие настройки подключения (скорость подключения, запрещенные/разрешенные порты/службы и т. п.).
В процессе учета NAS-сервер, в зависимости от настроек, посылает пакеты Accounting-Request, содержащие информацию о сессиях (start/stop/alive). На каждый присланный пакет RADIUS-сервер отвечает пакетом Accounting-Response, иначе NAS будет слать пакеты, пока не получит ответа.
Рисунок 20 – Функциональная схема процесса учета
RADIUS базируется на протоколе UDP (пакетная передача данных, без гарантии передачи пакета).RADIUS-клиент на любой запрос должен дожидаться ответа от сервера в течении некоторого времени (timeout) и при в случае отсутствии ответа переслать пакет еще раз.
Diameter. Название DIAMETER – игра слов, отражающая превосходство нового протокола над предшественником RADIUS (диаметр – удвоенный радиус). С появлением новых технологий и приложений, таких как беспроводные сети и Mobile IP, требования к аутентификации и авторизации значительно повысились, а механизмы контроля доступа стали более сложными. На основе RADIUS был создан протокол Diameter, предназначенный для того, чтобы стать общей структурной основой для последующих AAA-приложений. Протокол Diameter широко используется в IMS-архитектуре (IP multimedia system) для обмена AAA-информацией между IMS-объектами. Он извлекает суть AAA-протокола из RADIUS и определяет набор сообщений, являющихся достаточно общими, для того чтобы служить ядром базового протокола Diameter. Различные приложения, нуждающиеся в AAA-функциях, могут определять свои собственные расширения на основе базового протокола Diameter.
Diameter имеет одноранговую архитектуру (Peer-To-Peer), и каждый хост, реализующий протокол Diameter, может выступать либо клиентом, либо сервером, в зависимости от сетевой инфраструктуры. Поэтому термин Diameter-узлы используется для ссылки на Diameter-клиент, на Diameter-сервер или на Diameter-агент, с которым мы познакомимся позже. Узел протокола Diameter, принимающий пользовательский запрос на соединение, выступает как Diameter-клиент. В большинстве случаев Diameter-клиентом будет NAS. После сбора информации, удостоверяющей пользователя, такой как имя пользователя и пароль, он передаст сообщение запроса на доступ одному Diameter-узлу, обслуживающему запрос. Для простоты мы предполагаем, что это Diameter-сервер. Diameter-сервер выполняет аутентификацию пользователя на основе предоставленной информации. Если процесс аутентификации выполняется успешно, в ответное сообщение включаются полномочия пользователя, и это сообщение передается обратно соответствующему Diameter-клиенту. В противном случае передается сообщение об отказе.
Для протокола Diameter является обязательным возможность работы по TCP или SCTP. Как и в большинстве моделей взаимодействия клиент-сервер, Diameter-сессия начинается с передачи сообщения запроса от клиента серверу. В контексте Diameter Diameter-клиент передаст сообщение auth-request, содержащее уникальный Session-Id, Diameter-серверу (или Diameter-прокси, если необходимо перенаправление сообщения). Используемые для аутентификации и авторизации пары AVP зависят от приложения и что они не определены в базовом протоколе.
После приема сообщения auth-request Diameter-сервер может включить Authorization-Lifetime.
AVP в ответное сообщение. Эта пара AVP используется для указания количества времени в секундах, которое требуется Diameter-клиенту для повторной авторизации. После истечения лимита времени и допустимого Auth-Grace-Period, Diameter-сервер будет удалять сессию из своего списка сессий и освобождать все ресурсы, выделенные для нее.
Во время сессии Diameter-сервер может инициировать запрос повторной аутентификации или повторной авторизации. Этот тип запросов используется для проверки продолжения использования пользователем службы, и если ответ отрицателен, сервер удаляет сессию, чтобы остановить начисление средств. Кроме того, для догадки об исключительном закрытии сессии используется пара AVP OriginState-Id. Отправитель запроса будет включать эту AVP, и, поскольку необходимо, чтобы это значение монотонно увеличивалось, получатель запроса может легко догадаться о том, что предыдущая сессия была закрыта либо по аварийному завершению работы устройства доступа, либо из-за каких-либо других исключительных ситуаций. Получатель запроса может затем удалить сессию из своего списка, освободить ресурсы и, возможно, уведомить свои Diameter-серверы, если он работает как прокси-сервер.
Завершение сессии.
Сообщения о завершении сессии используются только в контексте аутентификации и авторизации и только тогда, когда поддерживалось состояние сессии. Для служб работы с учетными записями вместо этого сообщения используется сообщение об остановке учета. Сообщение о завершении сессии может быть инициировано либо Diameter-клиентом, либо Diameter-сервером. Когда Diamete-клиент полагает, что нужно закрыть сессию, он передает сообщение Session-Termination-Request Diameter-серверу. В этот запрос включается AVP Termination-Clause, указывающая Diameter-серверу причину, почему сессия должна быть закрыта. В свою очередь, если Diameter-сервер обнаруживает, что сессия должна быть закрыта (возможно, из-за того, что клиент вышел за пределы предоставленного кредита, или просто для административных целей), Diameter-сервер передает сообщение Abort-Session-Request Diameter-клиенту. Однако, в зависимости от различной политики или сценариев использования, Diameter-клиент может решить не закрывать сессию, даже при получении сообщения от сервера о ее завершении, и позволить пользователю продолжать пользоваться своим сервисом [10].
TACACS+ (Terminal Access Controller Access Control System plus).
TACACS+ – результат дальнейшего усовершенствования TACACS, предпринятого Cisco. Улучшена безопасность протокола (шифрование), а также введно разделение функций аутентификации, авторизации и учёта, которые теперь можно использовать по отдельности. TACACS+ использует понятия сеансов. В рамках TACACS+ возможно установление трёх различных типов сеансов: authentication, authorization и accounting. Установление одного типа сеанса в общем случае не требует предварительного успешного установления какого-либо другого. Конкретно: спецификация протокола не требует для открытия сеанса authorization открыть сначала сеанс authentication. Сервер TACACS+ может потребовать authentication, но сам протокол этого не оговаривает.
Данный протокол является разработкой фирмы Cisco Systems и его реализация периодически модифицируется. Данный протокол является новым витком развития более ранних версий протоколов TACACS и XTACACS: хоть в официальных выпусках и говорится, что была просто повышена безопасность протокола, но реально весь протокол технически был переписан заново (осталась разве только идеология), поэтому не стоит путать между собой эти протоколы (в повседневной жизни и в описаниях очень часто оконечный «+» опускают, откуда и появляется неразбериха; более старый протокол TACACS практически никто сейчас не использует. Протокол основан на использовании протокола TCP, поэтому потенциально медленнее RADIUS (установление TCP соединения довольно накладная операция), но за то позволяет вести мультипроцессную обработку запросов (в каждый момент времени могут обслуживаться несколько пользователей). Степень защищенности – высокая (зашифровано все тело пакета).
Для обработки какого-либо запроса TACACS+ сервер и клиент должны установить TCP-соединение (даже если весь процесс будет состоять из посылки и приема двух небольших пакетов), с точки зрения времени это довольно накладный процесс (именно поэтому TACACS+ по определению относительно медленен). Но ввиду использования протокола TCP, гарантия передачи пакета сто процентная. На основе приведенного примера, можно сразу сказать, что RADIUS будет более эффективен в сетях, где процент потерянных пакетов менее 5-10 %; в других сетях лучше использовать TACACS+.
Схема работы TACACS+ состоит из трёх частей, которые могут работать независимо друг от друга. Опишем их работу.
Процесс аутентификации (установления сеанса authentication). Для сеанса authentication определены три типа пакетов: START, CONTINUE и REPLY. Клиент направляет серверу пакеты START и CONTINUE, сервер отвечает REPLY.
Сеанс начинается с посылки клиентом пакета START, содержащий:
а) используемый метод аутентификации: ASCII, PAP, CHAP, ARAP, MSCHAP;
б) уровень доступа, для которого будет выполняться аутентифи-кация, предопределенная на 4 уровня доступа: MIN, USER, ROOT и MAX;
в) данные (или часть, или ничего - в зависимости от метода и желания клиента) для аутентификации.
В ответ на START сервер должен послать REPLY, с одним из возможных результатов (зависящих от метода аутентификации):
− PASS – сообщение об успешном прохождении аутентификации;
− FAIL – о неудачной попытке;
− GETUSER – запрос имени пользователя. Например, если был выбран метод ASCII, но имя пользователя не было включено в пакет START;
− GETPASS – запрос пароля;
− GETDATA – запрос дополнительных сведений. Используется в других методах.
Разные методы аутентификации могут потребовать обмена различным числом сообщений между клиентом (сервером доступа) и сервером TACACS+. Все последующие пакеты (после START) от клиента должны быть CONTINUE.
Клиент может прервать сеанс в любое время, установив флаг ABORT в очередном пакете CONTINUE.
Сервер может запросить переустановку сеанса (статус RESTART в пакете REPLY), а также перенаправить клиента (статус FOLLOW в пакете REPLY). В этом случае сервер в поле данных пакета передаёт список серверов.
Авторизация. Она подразумевает обмен всего двумя пакетами:
− клиент пакетом REQUEST запрашивает права на использование определённых служб;
− сервер отвечает пакетом RESPONSE, содержащим код ответа.
Сервер также может изменять параметры запроса клиента (например, авторизовать доступ, но с другим IP адресом) или добавить свои. Для этих случаев есть свои коды статуса: PASS_REPL, PASS_ADD.
Учёт. Клиент направляет серверу REQUEST, в котором определяется набор параметров учёта.
Для выбора необходимого протокола для решения поставленной задачи, а именно оптимизации процесса предоставления услуги прописки SIP абонента ниже приведена сводная таблица протоколов метода AAA
Исходя из нижестоящей таблицы 1, предпочтение целесообразно отдать протоколу RADIUS основываясь на следующих аспектах:
− протоколы TACACS+ и DIAMETER являются функционально перегруженными, следовательно, более требовательными к вычислительным ресурсам, что влечёт большее время отклика, а это в свою очередь является критическим показателем для системы;
− протокол RADIUS работает на основе транспортного протокола UDP, что делает его более быстродействующим (DIAMETER и TACACS+ используют TCP);
− протокол RADIUS использует порт 1645 или 1812 UDP для аутентификации и порт 1646 или 1813 UDP для учета активности пользователя
− протокол RADIUS позволяет перенаправлять запросы от одного RADIUS-сервера к другому;
− протокол RADIUS использует RADIUS прокси-сервер;
− в протоколе RADIUS процессы аутентификации и авторизации совмещены в один процесс RADIUS;
− протокол RADIUS шифрует только пароли;
− протокол RADIUS поддерживает технологии удаленного доступа, 802.1X и SIP.
Реализацией протокола RADIUS является RADIUS-сервер.
Таблица 1 – Сравнительный анализ рассматриваемых протоколов
|
Виды протоколов |
RADIUS |
Diameter |
TACACS+ |
|
Базовый протокол |
UDP |
TCP |
TCP |
|
Безопасность |
Шифруется пароль |
Шифруется все тело пакета |
Шифруется все тело пакета |
|
Поддерживаемые типы аутентификации |
Clear text (ASCII, PAP), CHAP |
Clear text (ASCII, PAP), CHAP, EAP |
Clear text (ASCII, PAP), CHAP, ARAP |
|
Возможность перенаправления запроса |
Есть |
Есть |
Нет |
3.3 Существующие модели RADIUS-серверов
Чтобы выбрать оптимальный по всем параметрам RADIUS-сервер, для оптимизации существующей схемы предоставления услуги SIP телефонии, необходимо рассмотреть и сравнить существующие сервера. Так как RADIUS сервером является прикладное программное обеспечение, необходимо рассмотреть наиболее популярные из них: Radiator steal belt radius server, Softpi radius, Tekradius, Clear box, Freeradius.
Radiator Steal Belt RADIUS server.
Радиатор поддерживает широкий спектр функций, которых нет во многих других серверов RADIUS:
− максимальная гибкость и возможность настройки с веб-графического интерфейса и мониторинга;
− поддерживается более шестидесяти различных методов аутентификации, которые могут быть смешанными, чтобы удовлетворить почти любому требованию аутентификации;
− неограниченное число пользователей;
− производительность и масштабируемость для больших систем;
− поддержка IPv4 и IPv6 на RADIUS, прокси-сервер, TACACS +, SNMP;
− поддержка VOIP аутентификации: совместимая с Asterisk, SIP Express.
Поддерживает несколько методов аутентификации EAP, используемые в беспроводных локальных сетях 802.1X. Это означает, можно легко настроить безопасную аутентификацию беспроводной связи. Может выступать в качестве шлюза между PEAP-mschapv2 клиентов и не-EAP серверов RADIUS. Поддерживает Novell Edirectory с универсальными паролями. Универсальные пароли могут быть использованы с PAP, CHAP, MSCHAP, mschapv2, TLS, TTLS-*, PEAP, EAP-MD5 и т.д.
Прост в создании веб-отчетов для анализа пользовательских сессий. Поддерживает SNMP Radius IETF MIB Сервера: собирает статистику с сервера по SNMP. Полный набор алгоритмов балансировки нагрузки для RADIUS прокси-серверов. Автоматически распределяет IP адреса из базы данных SQL и DHCP. Поддерживает ADSL. Поддерживает GPRS.
Данный продукт является кроссплатформенным, что дает возможность разворачивать сервер практически на любой операционной системе:
− any Unix including Linux (Red Hat, Debian, Mandrake, SuSE, Lindows, Slackware, Ubuntu etc on Intel, Sparc, PPC, HP-PA etc), FreeBSD, NetBSD, SunOS, AIX, IRIX, SCO Open Server, Digital, HP-UX, etc;
− solaris 8, 9, 10. 32-Bit or 64-Bit. SPARC or Intel;
− windows 95, 98, NT, 2000, ME, XP, 2003, 2008, etc;
− mac OS9, Mac OS X;
Radiator работает с любой базой данных SQL, которая имеет Perl DBD поддержку:
− oracle;
− informix;
− Sybase;
− MySQL;
− microsoft SQL including versions 6.5, 7, 2000 and 2005;
− ODBC;
− interbase;
− SAP;
− PostgreSQL;
− SQLite.
Radiator поддерживает многие системы биллинга, включая:
− platypus;
− emerald;
− engageIP (previously Hawk-i) ;
− billmax;
− rodopi;
− freeside;
− ISPBill;
− advanced ISP billing;
− micros-fidelio opera;
− property management system;
− jet ISP billing.
SoftPI RADIUS.
Система SoftPI RADIUS представляет собой RADIUS-сервер, работающий под операционными системами Windows и предназначенный для выполнения функций аутентификации, авторизации и учета пользователей при подключении и использовании ресурсов интернет/интранет в соответствии с RFC 2865, 2866, 2868, 2869, 2548, 3748 и 5176. SoftPI RADIUS сервер может использоваться для проводных и беспроводных (Wi-Fi) пользователей, для пользователей VPN сетей и других сетевых ресурсов.
SoftPI RADIUS сервер является реализацией RADIUS сервера для операционных систем семейства Windows 2000/XP/2003/Vista/2008/7. Поддерживаются основные функции RADIUS сервера: аутентификация (Authentication), авторизация (Authorization) и учет используемых ресурсов (Accounting).
Поддерживаются следующие протоколы аутентификации пользователей:
− PAP;
− CHAP;
− MS-CHAP v2;
− EAP-MD5;
− EAP-MS-CHAP v2;
− PEAP MS-CHAP v2.
Гибкая настройка параметров аутентификации и авторизации пользователей:
− значения атрибутов пользователя привязываются к устройству доступа;
− возможность задания правила для проверки значения атрибута;
− поддерживаются специфические атрибуты производителя (Vendor-Specific атрибуты). Система содержит более 30 шаблонов атрибутов различных производителей: 3COM, Alcatel, Cisco, Juniper, HP, Microsoft, Avaya-Nortel.
В SoftPI RADIUS сервер реализован учет используемых пользователями ресурсов в соответствии с RFC 2866, что может использоваться при взаимодействии с биллинговыми системами. Эта функция интегрирована с биллинговым комплексом Tariscope 3.5 (SoftPI).
Все настройки параметров SoftPI RADIUS осуществляются в удобном графическом интерфейсе. Имеется возможность контролировать сессии пользователей: возможность разрыва сессии пользователя путем задания ее длительности.
Имеется возможность создания групп пользователей, имеющих одинаковые атрибуты. При этом конкретному пользователю, входящему в какую-то группу можно добавить дополнительные атрибуты, не включенные в список атрибутов группы.
SoftPI RADIUS поддерживает возможность синхронизации пользователей и их атрибутов, используя протокол LDAP, например, с Active Directory.
SoftPI RADIUS содержит режим, обеспечивающий получение информации о его работе. При этом администратор SoftPI RADIUS может с помощью фильтра задать любые условия фильтрации информации и применить сложные условия сортировки информации.
Отчет может быть экспортирован в один из следующих форматов: PDF, Excel (Microsoft), HTML, текстовый. Имеется возможность предварительного просмотра отчета и его распечатки.
В целях безопасности администрирование SoftPI RADIUS сервера выполняется с использованием SSL протокола. Работа этого протокола основывается на сертификате. Использование такого сертификата позволяет выполнить проверку подлинности сервера и шифровать обмен данными при администрировании. Сертификат можно приобрести в центре сертификации, использовать корпоративный сертификат, подписанный доверенным центром сертификации либо использовать самоподписанный сертификат.
В целях защиты от атак на SoftPI RADIUS сервер в нем предусмотрена возможность блокирования пользователя в случае многократных неудачных попыток аутентификации.
TekRADIUS.
TekRADIUS является RADIUS сервер для Windows с встроенным сервером DHCP. TekRADIUS тестируется на Microsoft Windows XP, Vista, Windows 7 и Windows 2003-2008 сервере.
Основные характеристики:
− поддержка функции, описанные в RFC 2865 и RFC 2866 (RADIUS протокол);
− журналы системных сообщений, ошибок и информацию о сессии содержатся в лог-файлах;
− существует возможность ограничения числа одновременных сессий для пользователей;
− порты аутентификации и учета могут быть выбраны пользователем;
− существует возможность создания SQL базы данных и таблиц через TRManager GUI;
− существует возможность сопоставления атрибутов RADIUS Accounting к полям таблице учета;
− поддерживает следующие протоколы аутентификации: PAP, CHAP, MS-CHAP v1-v2, EAP-MD5, EAP-TLS, EAP-MS-CHAP v2, PEAP (PEAPv0-EAP-MS-CHAP v2) и Digest (проект-Стерман-AAA-SIP-00.txt);
− генерирует MS-MPPE ключи для соединений VPN;
− поддерживает OTP (One Time Password) аутентификацию на основе RFC 2289;
− имеет встроенный DHCP-сервер;
− существует возможность аутентификации пользователей домена Windows или Active Directory;
− утилита командной строки для добавления, удаления и редактирования пользователей;
− простой интерфейс для просмотра отчетности Бухгалтерский учет;
− существует возможность задания времени, в течение которого пользователю будет доступна информация после первого входа в систему, а так же можно указать разрешенные дни и часы для возможности использования услуги;
− отключение профиль пользователя после выхода настраивается пользователем количества неудачных попыток входа в систему;
− можно задать кредитные лимиты для ежедневных, еженедельных или ежемесячных периодов;
− можно запустить и проверить результат внешнего исполняемого как контрольно-пропускном пункте;
− быстрая и простая установка.
Clear Box.
ClearBox поддерживает богатые возможности аутентификации и может выполнять проверку подлинности с использованием:
− LDAP directories (MS Active Directory, OpenLDAP, Novell eDirectory, etc);
− Windows NT/2000/2003/2008 Active Directory домена и рабочих групп;
− MS SQL Server, MS Access, MySQL, Oracle, PostreSQL.
ClearBox RADIUS сервер поддерживает IEEE 802.1x аутентификации для обеспечения безопасных и надежных служб аутентификации в WEP/WPA/WPA2 защищенных беспроводных сетей. Он поддерживает все протоколы, поддерживаемые Windows. Работа с цифровыми сертификатами может стать слишком сложной, особенно для сотрудников, которые не имеют опыта работы с ними. ClearBox предоставляет простой в использовании мастер, который помогает создать сертификат или подготовить запрос на некоторых сертификации.
ClearBox Сервер является гибкой системой и может быть легко интегрирован практически во все биллинговые системы поддержки RADIUS сервера аутентификации. В настоящее время полная совместимость со следующими биллинг системами:
− DTH биллинга и управления по DTH программного обеспечения. Система подходит для VoIP провайдера и биллинга. Она может похвастаться большим количеством полезных возможностей, как настраиваемый отчетности, электронной почте или бумажных счетов, электронный перевод средств, веб-порталы, обработка коллекций, сервисные заказы и многое другое;
− расширенный ISP Billing по AdvancedISPBilling.com, эффективный и настраиваемый биллинговой системы для малых и крупных провайдеров;
− platypus Billing System, общее решение биллинга и управления клиентами создан специально для Интернет-провайдеров и хостинг-компаний;
− RADREP by RADIUS Reporting, простой в использовании графический интерфейс Windows приложение.
Конфигуратор поддерживает работу через локальную вычислительную сеть, что позволяет настроить RADIUS сервер удаленно. Новая конфигурация будет применяться немедленно.
И, наконец, ClearBox можете загрузить свою конфигурацию из реляционных баз данных для обеспечения корпоративного учета установок с сотнями клиентов RADIUS и профилей.
FreeRADIUS.
Это альтернатива для других коммерческих RADIUS серверов, поскольку он является самым функциональным и модульным на сегодняшний день. Кроме того, он входит в пятёрку RADIUS серверов мира с точки зрения развёртывания и количества пользователей, которых этот сервер авторизует ежедневно
Может работать на встраиваемых системах с небольшим количеством памяти, обслуживая несколько миллионов пользователей. FreeRADIUS быстрый, гибкий, настраиваемый, а также поддерживает больше протоколов аутентификации, чем многие коммерческие серверы. Сервер поставляется вместе с инструментом управления через веб-интерфейс dialup admin, который написан на PHP. В настоящее время FreeRADIUS используется как основа для разработки коммерческих RADIUS серверов.
Модули ядра сервера поддерживают LDAP, MySQL, PostgreSQL, Oracle и многие другие базы данных. Он поддерживает все популярные типы аутентификации EAP, включая PEAP и EAP-TTLS. Для обеспечения совместимости с широким спектром устройств NAS в него включены более 100 словарей поставщиков.
В версии 2.0.0 была добавлена поддержка виртуального хостинга, IPv6, VMPS, и новой языковой политики, что упрощает многие сложные конфигурации.
Для более привычного и удобного восприятия информации ниже находится таблица RADIUS-серверов.
Исходя из таблицы 2 можно сделать вывод, что сервер FreeRADIUS наиболее подходит к решению поставленной задачи, а именно к включению RADIUS-сервера в существующую систему NGN сети, на основе следующих характеристик:
− поддержка не только стандартной Windows платформы, но и альтернативных;
− использует не только все необходимые протоколы аутентификации, но и протоколы шифрования;
− поддержка баз данных Oracle, которую использует программа АСР «Старт» и SQL, которую использует Softswitch, возможность конвертирования их;
− бесплатный продукт, отсутствуют затраты на покупку системы;
− поддерживает производителя Huawei, на котором базируется вся существующая системa связи NGN.
С использованием RADIUS-сервера изменится структурная схема, изображенная на рисунке 21.
Рисунок 21 – Структурная схема предоставления услуги SIP телефонии с RADIUS-сервером
С момента включения RADIUS-сервера структура оказания услуги претерпевает изменение. Вместо отправки наряда в отдел АТС, для прописки SIP абонента во внутреннюю базу Softswitch, теперь данную функцию будет выполнять RADIUS-сервер. RADIUS-сервер будет синхронизироваться раз в день с базой программы АСР «Старт» для занесения абонента в свою локальную базу.
Используя RADIUS-сервер, в системе предоставления услуги SIP телефонии мы добиваемся уменьшение числа промежуточных звеньев, что ведет в свою очередь к улучшению качества оказываемой услуги, увеличению скорости обработки наряда, уменьшению количества ошибок, возникающих за счет человеческого фактора.
Теперь, если при физическом подключении абонента возникнет ошибка с авторизацией пользователя, то монтеру нет необходимости звонить на АТС, узнавать пришел на наряд к ним на обработку, или правильно ли менеджер указал настройки в программе АСР «Старт», что бы наряд попал в отдел электронных АТС и т.д.
Монтеру, при возникновении ошибки с авторизацией в настоящий момент, необходимо только проверить сторону СПД и настройки на клиентском оборудовании – это заметно ускорит темпы обслуживания клиентов.
Функциональная схема технологического процесса предоставления услуги SIP телефонии, с использованием RADIUS-сервера представлена в приложении Б.
На рисунке 22 изображен процесс синхронизации базы АСР «Старт» и базы данных Softswitch, с использованием RADIUS-сервера.Рисунок 22 – Функциональная схема заведения SIP номера в базу Softswitch
При рассмотрении полученных схем с использованием RADIUS-сервера видно, что по сравнению, с используемой в текущий момент моделью прописки, были исключены, лишние, архаичные и избыточные связи тем самым оптимизировав процесс предоставления услуги создания SIP абонента.