По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Привет! В статье расскажем как сделать аутентификацию пользователей FreePBX 13 в модуле User Management через Microsoft Active Directory. Настройка выполняется достаточно тривиально. Указанные параметры протестированы с MSE 2012.
Pre - work
Перед началом настройки, необходимо протестировать доступность 389 порта в AD по транспорту TCP. Для этого, сделаем telnet в cmd консоли рабочей машины:
telnet 192.168.1.67 389
В нашем случае, 192.168.1.67 - это адрес AD – сервера. Если все ОК, то переходим к проверке Base DN (базы поиска). Открываем консоль CMD на своей рабочей машине и выполняем dsquery запрос:
dsquery user -name MerionNetworks
dsquery user - команда для поиска пользователей;
-name - поиск пользователей, по критерию имени (в нашем случае MerionNetworks) – можно использовать маски, например, «*Networks»;
MerionNetworks - имя, по которому осуществляем поиск;
Команда вернет нам примерно вот такой вывод:
"CN= MerionNetworks,CN=Users,DC=merionet,DC=local"*
Запоминаем вот эту часть CN=Users,DC=merionet,DC=local и переходим к настройке FreePBX.
Настройка в FreePBX
Переходим в раздел Admin → User Management нажимаем на вкладку Settings и далее Authentication Settings. В поле Authentication Engine выбираем Microsoft Active Directory и приступаем к настройке:
Authentication Engine - тип подключения. Мы рассматриваем подключения к Microsoft AD, его и указываем;
Remote Authentication IP Addresses - список IP – адресов, с которых разрешена удаленная аутентификация методом отправки POST на URL 192.168.1.7/admin/ajax.php?module=userman&command=auth, где 192.168.1.7 – IP – адрес нашего сервера Asterisk (FreePBX);
Synchronize - как часто синхронизировать данные с AD. Мы указали раз в час;
Host - имя или IP – адрес сервера AD;
Port - порт, на котором слушает AD. У нас стандартный 389 порт;
Username - существующее имя пользователя в AD. Мы производили проверку в первой части статьи пользователем MerionNetworks, его и укажем;
Password - указываем пароль этого пользователя;
Domain - указываем доменную часть;
Base DN - копируем сюда Base DN, который получили ранее с помощью dsquery;
Status - статус подключения к AD. У нас Connected :)
В интернете всегда можно легко найти информацию о веб-службах, которые базируются на SOAP и XML-RPC, а вот REST, почему-то, обделен вниманием. В рамках этой статьи будет рассмотрен базис этой архитектуры и ее практическое применение.
REST: что это?
REST является стилем архитектуры ПО для систем распределения (пример - всем известная www). Обычно с его помощью строят веб-службы. Рой Филдинг, который имеет прямое отношение к созданию протокола HTTP, ввел термин REST в начале века. После этого любую систему, которая поддерживала его, стали называть RESTFul. Доступный интерфейс контроля без ненужных слоев - вот что из себя представляет эта архитектура. Глобальный ID, а именно URL, определяет каждую очередную информационную единицу. Сам же URL характеризуется форматом, который находится в жестких рамках.
Что такое API
REST на практике
Если нет пустых прослоек, данные будут переданы в виде, аналогичном им самим. "Заворачивание" информации в XML не происходит, как в случае с SOAP и XML-RPC, также не используется и AMF, как это бывает с Flash. По сути, происходит чистая передача.
URL, на деле, является базовым ключом для единицы данных. Пример: вторая книга из стопки, лежащей на столе, будет интерпретирована как /book/2, а 145 страница в этой книге - /book/2/page/145. Это достаточно жесткий формат. Самое интересное, что он может присутствовать в любом внешнем источнике, будь то HTML или doc-файл.
Контроль информации сервиса
Протокол передачи данных - основа контроля и управления. Самый часто используемый протокол - это, само собой, HTTP, и для него команды действий выглядят так:
GET (получение);
PUT (добавление);
POST (изменение);
DELETE (удаление).
Поэтому Create/Read/Update/Delete-действия будут выполнены и с 4 указанными алгоритмами, и посредством GET и POST. Это позволит в некоторых случаях обойти негативные эффекты с использованием непринятых PUT и DELETE.
REST в построении веб-сервисов
Веб-сервис - приложение, которое работает в www с доступом, предоставленным через HTTP-протокол. Информационный обмен в рамках веб-сервиса осуществляется посредством формата XML. А это значит, что все данные из тела запросов будут всегда в аналогичном формате.
Для любой информационной единицы можно задать 5 вариантов действия:
GET /info/ (Index) используется для получения списка объектов. Конечно, полученный список будет ограничен заданным идентификатором.
GET /info/{id} (View) позволяет получить всю информацию об объекте.
PUT /info/ или POST /info/ (Create) осуществляет создание нового объекта.
POST /info/{id} или PUT /info/{id} (Edit) производит замену данных, соответствующих введенному идентификатору.
DELETE /info/{id} (Delete) удаляет данные, выделенные идентификатором.
Итоги
Очевидно, что REST, как архитектура, обладает интуитивными алгоритмами и отличается простотой в использовании. Если запрос получен, то определить, что именно он делает, можно немедленно, без форматных разбирательств. При передаче не используются дополнительные слои, что обеспечивает REST особую ресурсоемкость.
Для чего можно использовать?
Основное достоинство сервисов REST - дружественность. Рабочая связка с сайтом, flash, программой? Не важно, ведь алгоритмы парсинга XML и обработка запросов HTTP есть буквально везде. REST значительно упрощает все связанные с этим задачи. Конечно, на практике описанных здесь алгоритмов недостаточно, так как отсутствует защита данных. Но ввести в систему авторизацию и аутентификацию всегда можно при помощи HTTP Authentication.
Беспроводные решения вендора MikroTik для сегмента SOHO (Small Office, Home Office) - являются крайне универсальными, и, кроме того, они крайне гибки в плане настроек беспроводных интерфейсов в “простом” режиме.
SOHO продукты - продукты для маленького и/или домашнего офиса
Однако, присутствует также “продвинутый” режим, в котором можно произвести более качественную настройку многих фич. Во многих SOHO моделях, к примеру - RB-750 и RB-951 уже установлены приемлемые заводские настройки, но если произвести несколько изменений - качество подключения может сильно возрасти и, более того, позволить одновременное подключение большего количества пользователей.
Это может сыграть роль, если вы используете SOHO оборудование в небольшом филиале, в котором более десяти пользователей. Особенно учитывая тот факт, что все они используют смартфоны, планшеты и ноутбуки - нагрузка на сеть растет, и, если беспроводная инфраструктура настроена некорректно, все признаки плохого подключения будут видны невооруженным взглядом.
Что делать?
Следующие параметры могут сильно улучшить качество подключения:
frequency-mode=regulatory-domain country=russia
frequency=auto
channel-width=20mhz
wireless-protocol=802.11
distance=indoors
Для того чтобы применить эти настройки, просто скопируйте и вставьте команду ниже:
Данная команда предназначена для маршрутизаторов RB751/951
/interface wireless set wlan1 mode=ap-bridge wireless-protocol=802.11 frequency=auto band=2ghz-b/g/n channel-width=20mhz distance=indoors frequency-mode=regulatory-domain country="russia"
Очевидно, что первый параметр отвечает за регион - в нашем случае, это Россия. Кроме того, в настоящий момент некоторые из этих опций являются стандартными в последней версии RouterOS, однако, почему-то не всегда они установлены корректно.
Также, детальную информацию о данных настройках не всегда можно найти в документации MikroTik, но, по опыту, эти настройки действительно улучшают производительность беспроводной сети. Проверить производительность вашей сети можно проверить на вкладке “Status” информации о беспроводном интерфейсе, вам нужно поле Overall Tx CCQ (Client Connection Quality).
Ниже пример на одном из RB-951 - обратите внимание на очень высокий показатель 97%:
Однако, при установке более новых моделей RB-951 со стоковыми настройками, чаще всего был замечен показатель в районе CCQ < 60%, и это явный знак того, что есть куда двигаться в плане качества подключения.
Заключение
Мы рекомендуем мониторить CCQ в течение нескольких часов на загруженной беспроводной сети, чтобы определить средний уровень, и, затем, применить рекомендованные настройки по очереди, чтобы понять, как они влияют на показатель. Не все из этих настроек универсальны для всех инсталляций, но если вы заметите улучшение CCQ на 10-20% - пользователи обязательно это оценят.