Аутентификация прокси С открытым исходным кодом с помощью нескольких LDAP

  • Подсистема UNIX иначе Interix (Сервисы для UNIX 3.5 или Подсистема для Приложения Unix + Утилиты)
    • pkg bootsrapper от сообщества Interopsystems SUA
    • OpenSSH (включает OpenSSL),
    • завихрение (версия Unix)
    • md5
    • архивировать/разархивировать
    • whois
  • PowerShell
  • информационная zip (zip.exe, unzip.exe)
  • завихрение с ssl
  • ncftp
  • С 7 zip
  • MagicISO
  • инсайдер
  • Монитор сети
  • На Vista:
    • Windows клиент telnet
    • PuTTYtel
1
задан 30 September 2009 в 06:34
3 ответа

Вы холод заставляете Сквид пройти проверку подлинности против единственного сервера OpenLDAP, действующего как прокси для нескольких каталогов бэкенда. От slapd-meta (5):

ИМЯ slapd-meta - бэкенд метакаталога

РЕЗЮМЕ/etc/ldap/slapd.conf

ОПИСАНИЕ meta бэкенд к slapd (8) выполняет основной LDAP, проксирующий относительно ряда удаленных серверов LDAP, названных "целями". Информация, содержавшаяся в этих серверах, может быть представлена как принадлежащий единственному Информационному дереву каталогов (DIT).

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

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

2
ответ дан 3 December 2019 в 19:58

В моем ответе я предполагаю, что Вы читали о протоколе аутентификации Сквида, знакомы о том, как настроить подлинного помощника LDAP и планирует выполнить Сквид под некоторым Unix operationg система. Кроме того, первые два ответа помогают, Вы выбрали различные серверы LDAP на основе имени пользователя, не подсеть IP (Вы упомянули "подсеть", но "подмножество" ITYM - право?).

  1. Используйте простой сценарий (язык не имеет значения, использует Ваш любимый) передавать запрос к различным серверам LDAP на основе имени пользователя. Опытный администратор Unix должен разбудить это и работающий в течение 30 минут, это не имеет большого значения.
  2. Используйте единственный сервер LDAP, который возвращает направления LDAP на основе DN пользователя.

Если Вы действительно захотите измениться, то серверы LDAP на основе вещей подсети IP станут немного ужасными, так как протокол автора Сквида только передает пар имени пользователя/пароля подлинным помощникам:

  1. Настройте единственный сервер Сквида и имейте его, слушают на localhost только. Этот экземпляр Сквида сделает всю кэширующуюся работу.
  2. Для каждой подсети, настроенной другой экземпляр Сквида, без локального кэша, и, настраивают соответствующий сервер LDAP. Используйте различные порты для каждого экземпляра Сквида, также. Эти экземпляры Сквида передают все запросы к кэширующемуся, определенному на шаге 1.
  3. В зависимости от того, как Вы настраиваете настройки прокси в браузерах своих пользователей, необходимо будет использовать или представления DNS или правила перенаправления в веб-сервере.
1
ответ дан 3 December 2019 в 19:58
  • 1
    Какой I' m смотрящий на definently подсети IP... Я предполагаю, что подмножества пользователей могли быть опцией. Вторая опция, которую Вы упоминаете, я уже рассматривал. Я думал для использования Solaris Zones, чтобы сделать это, но это действительно пахнет подозрительным. –  Antoine Benkemoun 26 September 2009 в 11:21

Можно создать собственного помощника аутентификации для сквида - http://www.visolve.com/squid/squid30/externalsupport.php#auth_param

http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html

0
ответ дан 3 December 2019 в 19:58
  • 1
    Я don' t действительно понимают то, что Вы хотите, чтобы я сделал. Я должен в основном кодировать модуль Сквида? –  Antoine Benkemoun 25 September 2009 в 15:31
  • 2
    да, очень простой. –  Martynas Saint 3 October 2009 в 01:44

Теги

Похожие вопросы