Не только позвонить

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

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

В телефонах 794x и 796x есть замечательная возможность просматривать список телефонных номеров, полученный с сервера. Телефон идёт на URL, указанный в конфигурации, обычным HTTP запросом.

Можно поставить на сервер отдельный tomcat или php, чтобы обработать такие запросы. Но это слишком накладно. CGP справится лучше. Во-первых у него уже есть LDAP, во-вторых у него есть CG/PL.

То есть, мы можем рассматривать CGP, как контейнер для скриптов на CG/PL, и с лёгкостью обойтись без сторонних серверов.

Всё что нам нужно это написать скрипт. Назовём его cd.wcgp. Так как мы будем делать запрос с телефона, то исключим авторизацию и механизм сессий. Для этого используем скрипт с секцией SysEntry, а не с Main. Соответственно, хранится на сервере он должен в базовом веб-скине (http://localhost:8010/Master/Domains/WebSkinsCommon.html).

Ваша компания медленно, но верно выходит из кризиса, открываются новые офисы или магазины, появляются рабочие места — растет количество сотрудников. Вы, как системный администратор, уже позаботились об этом заранее и внедрили Active Directory или LDAP. Фух, проблем с учетками больше нет.
Но в нашем деле проблемы не заставляют себя долго ждать: вчера взяли пять бухгалтеров, троих продавцов и кладовщика. Всем нужна корпоративная электропочта. Отлично, если вы продумали достаточное количество ходов наперед и вместе с установкой AD перевели авторизацию почтосервера на домен. Тратим пять минут на добавление учеток, вписываем правильные данные, отдаем вашим помошникам — они настроят почтоклиенты этим сотрудникам. Но как теперь сообщить новые адреса всем остальным сотрудникам? Написать каждому письмо? Скинуть в чат? Слишком много работы для среднестатистического и вечно ленящегося сисадмина.

Я вижу два удобных пути решения: можно уговорить почтоклиенты бегать в AD за адресами, а можно показывать их на корпоративном сайте. Сегодня мы попробуем обеспечить корпоративный веб-сайт нужной информацией — будем выводить список сотрудников и их почтовые адреса, а за данными ходить к участковому прямо в Active Directory.

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

А здесь я расскажу, как используя ASA, напрямую аутентифицироваться в AD

На МСЭ часто возникает задача проверить пользователя до предоставления ему доступа к определенным ресурсам. На ASA такая проверка называется «перехватывающая аутентификация» (cut-through proxy).

Этот сервис использует инфраструктуру ААА (Authentication, Authorization, Accounting).

Примечание: в английском слове authentication нет слога «фи», который появился в русском «аутентификация» скорее всего из-за созвучия слову «идентификация». Причем, в нашем могучем языке есть и «аутентичность». Без всякого «фи» :) Не попадитесь!

Аутентификация.
Отвечает на вопрос «есть ли такой пользователь». Поиск этого пользователя может производиться как в локальной (LOCAL) базе данных, так и во внешних (TACACS+, RADIUS, AD по протоколу LDAP).

Привет, товарищи

Выложу я свою версию настройки LDAP авторизации с помощью Apache.
Она более подробная, чем чем уже описанная.

Что понадобится:

• Apache 2.2 + open SSL. можно скачать с apache.org.
• SVN совместимый с Apache 2.2. Скачивается здесь — svn.tigris.org.
• Openssl-0.9.7e-Win32.zip. можно скачать отсюда — support.etouch.net/cm/wiki/support.Downloads.wiki/1021721main_Openssl-0.9.7e-Win32.zip
• Стандартный конфиг openssl.cnf — support.etouch.net/cm/wiki/support.Downloads.wiki/1021722main_openssl.cnf

Предыстория

Реализация

Платформа

   AltLinux 4, версия ядра 2.6.18-std-smp-alt6. Все пакеты ставились из официального репозитария.

Установка LDAP-сервера

   Устанавливаем пакеты openldap-servers-2.3.35-alt0, libldap2.3-2.3.35-alt0, openldap-clients-2.3.35-alt0, openldap-2.3.35-alt0, openldap-doc-2.3.35-alt0.
   Включаем дополнительные схемы в файле /etc/openldap/slapd.conf:

Добрый день.
Хотелось бы поделиться с вами одним интересным моим опытом – Контроллер домена на Linux. В данной статье я скорее всего напишу небольшой мини обзор систем с помощью которых я пытался реализовать альтернативу ActiveDirectory.

Немного истории:
Написано мною в Январе 2009: Вообще я далеко не профи в *nix системах, но всё таки активно интересуюсь и изучаю их. В компании, где я работаю, около 3-4 моих серверов на базе Debian и FreeBSD. Которые выполняют различные задачи для обеспечения основных бизнес процессов компании.
По поводу домена на linux я слышал множество упрёков и похвал. И вот более года назад задался вопросом поднятия домена на Linux. Во первых просто интересно, а во вторых он абсолютно бесплатен, что и требовала компания где я работал. За год перебрал кучу вариантов, кучу сборок. Поднимал в ручную… ldap+samba+krb на BSD и Linux системах. Но мне казалось что всё это не то. Либо безумно неудобно управлять, либо куча лишнего. Куча лишнего было в готовых дистрибутивах (аля-домен за одну минуту.). Было боязно внедрять их в мою не большую и не маленькую компанию(Более 80-100 рабочих станций в одном только офисе). Во первых неизвестно что и как разработчики делали с дистрибутивом, во вторых электронная поддержка на иностранном языке ))) А самому разгребать последствия не хочется.



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