Работа Squid с Active Directory. Kerberos-аутентификация. Права доступа на основе групп Active Directory.

Разберем как настроить связь Squid 3.5 c Active Directory через kerberos авторизацию, чтобы доступ в интернет предоставлялся только по доменным учетным записям, а так же возможность использования Active Directory групп для разграничения прав доступа в интернет.

 

 

Исходные данные:

  • Установленный на Ubuntu 14.04 Trusty Tahr (srv-squid-s) Squid 3.5
  • Домен контроллер SRV-DC1 (testzone.local) на базе Windows Server 2008 R2

 

Подготовка системы Ubuntu 14.04 Trusty Tahr (srv-squid-s)

Укажем корректное имя системы для работы с Active Directory. В файле (/etc/hostname) дописываем к имени системы название вашего домена (в моем случае я дописываю .testzone.local):

В файле (/etc/hosts) под записью «127.0.0.1 localhost» прописываем данные нашей системы:

Для применения изменений перезагрузим систему:

 

Синхронизация времени

Для нормальной работы с доменом Active Directory и прохождения Kerberos-аутентификации важно чтобы время на текущей системе (srv-squid-s) и контроллере домена (SRV-DC1) было синхронизировано.

 

Для синхронизации времени установим необходимые программы:

В файле конфигурации (/etc/ntp.conf) удалим указанные там по умолчанию серверы синхронизации:

и укажем контроллер домена по которому будем сверять время:

 

Выполним немедленную синхронизацию времени с контроллером домена:

 

Проверить синхронизацию времени можно командой:

when — время с последнего ответа сервера
pool — время опроса сервера
offset — разница времени в секундах.

 

Настройка Active Directory Windows Server 2008 R2 (SRV-DC1)

Теперь проведем подготовительные работы в AD чтобы наша система и Squid могли авторизоваться в ней успешно. В оснастке DNS, в Forward Lookup Zones добавьте A-запись для нашей системы где у нас стоит Squid

squid-ad-1

Обязательно при добавлении записи, отмечаем галочкой пункт: Create associated pointer (PTR) record

 

Создаем в домене учетную запись служебного пользователя для работы Squid (в моем случае учетная запись будет squid-s)

squid-ad-2 squid-ad-3

 

Теперь создадим специальный keytab-файл с помощью утилиты ktpass. В дальнейшем keytab-файл будет использоваться Squid для аутентификации пользователей в AD. Откроем командную строку от имени администратора и введем следующую команду (соблюдая регистр):

Ответ об успешном создании keytab-файла будет вида:

Передаем сгенерированный keytab-файл на систему где развернут Squid любым доступным образом.

После того, как мы передали keytab-файл на систему со Squid, переместим его в папку с настройками Squid и ограничим к нему доступ.

Затем изменим владельца и установим ограниченные права на файл:

Все готово для установки Kerberos, установим пакет krb5-user

Если в ходе установки появится запрос указать «Область по умолчанию для Kerberos«, то необходимо его указать в заглавном виде (прим. TESTZONE.LOCAL)

 

Перед конкурированием Kerberos создадим резервную копию файла конфигурации.

Редактируем файл /etc/krb5.conf

и приводим его к виду:

 

Проверим работу Kerberos, для этого выполним команду

Если получен ответ вида представленного ниже, то все нормально, билет получен и можно двигаться дальше.

Удаляем полученный билет, он нам не нужен.

Установим необходимую зависимость для работы Squid и AD

Укажем Squid путь к нашему keytab-файлу, редактируем файл /etc/init.d/squid

находим строку:

и ниже прописываем следующее:

 

Осталось выполнить конфигурацию самого Squid для работы с AD. Редактируем конфигурационный файл /etc/squid3/squid.conf

У меня вот такой получился итоговый вариант конфигурации Squid. Конфиг с комментариями , поэтому разобраться что там за что отвечает не должно составить труда.

 

Перезапускаем службу Squid, чтобы применилась конфигурация.

На этом настройка полностью завершена. На пользовательских ПК в Свойствах обозревателя — Подключения — Настройка сети в поле Адрес указываем FQDN имя системы где у нас стоит Squid, в моем случае это srv-squid.testzone.local

squid-ad-4

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

Осталось только создать группы в AD которые мы указали в конфиге squid:

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

Так же проверить видит ли Squid пользователя в какой то определенной группе, можно выполнив команду

и ввести имя пользователя AD. Если пользователь находится в данной группе то увидим в конце запроса ОК, если пользователя нет, то ERR

squid-ad-5

Убедились что все отрабатывает успешно. Система Squid с авторизацией AD работает успешно, можно пользоваться.

 

При работе в прозрачном (transparent) режиме, аутентификация пользователей невозможна! Подробнее: http://wiki.squid-cache.org/Features/Authentication#Authentication_in_interception_and_transparent_modes

 

Понравилась или оказалась полезной статья, поблагодари автора

 

БесполезноСлабоватоПриемлемоОтличноПревосходно (2 голос(ов), в среднем: 4,50 из 5)
Загрузка...

Всего комментариев: 22 Комментировать

  1. daniyar /

    Добрый день!
    Может подскажете, снес все и настроил все по мануалу билетик получает по команде проверки и группу проверяет показывает пользователя «ОК», но уже под доменной учеткой открываю страничку в бразере выходит окошко аутентификации, хотя у пользователя есть доступ. Как и у Вас ручной ввод ничего не дает, не принимает. целый день сижу уже два раза ставил на чистую систему. у меня squid 3.5.12 ubuntu последняя 16.04

    1. Жаконда / Автор записи

      Добрый день !
      Если билетик Squid получает и при проверки нахождения пользователя в группе AD вы получаете правильный ответ, то у вас все правильно настроено и Squid и модуль negotiate_kerberos_auth отрабатывает правильно ! Вероятней всего проблема в самом домен контроллере, проверками прогоните службы на ошибки.

      У меня была ситуация точно такая же как и у вас. Только у меня все работало прекрасно, но в один момент появились все аналогичные симптомы. Все так же проверки авторизации Squid были успешны, билет получался, пользователей видел в группе. Пробовал создать нового пользователя в AD и сделать по него новый keytab, не помогало. Решение оказалось простым, выяснилось что синхронизация между домен контроллерами была нарушена и не проходила. Исправили данную проблему и все заработало в нормальном режиме.

      Так что мой совет сейчас проверить свой домен контроллер, т.к. повторюсь у вас все настроено правильно если все проверки Squid успешны.

      P.S. мануал полностью рабочий и порядка 5 раз разворачивался и все работает. Так же может играть роль версий как самого Squid так и системы на которую он ставится.
      P.S.2 попробуйте пройти полностью по шагам как написано в статье, устанавливая версию Squid 3.5.19 на Ubuntu server 14.04, т.к. статья описывает использование именно этих версий.

  2. макс /

    Все настроил все работает кроме аутентификации пологину и паролю… В чем может быть причина?? Неохота все заново переделывать новый мануал искать…

    1. Жаконда / Автор записи

      Добрый день ! По логину и паролю и не будет работать в данном способе через Kerberos авторизацию. Для того чтобы работало по логину и паролю нужно делать все по этой инструкции

  3. Андрей /

    Здравствуйте! Вы пишете: «В оснастке DNS, в Forward Lookup Zones добавьте A-запись для нашей системы где у нас стоит Squid» а где эту оснастку найти стоит Server 2008 r2

  4. Андрей /

    Нашел, только не пойму откуда у вас взялся айпи 192.168.1.20

    1. Жаконда / Автор записи

      Это мой локальный IP адрес

  5. Андрей /

    Ничего не работает билетик не получает!

  6. Андрей /

    Может подскажите что не так делаю?

  7. Xxx /

    В dns вместо srv-squid ошибочно указан srv-squid-s.

  8. Александр /

    Спасибо за статью!
    Проверку при помощи /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -d -i -g S_SQUID_ADMINS_IP -D TESTZONE.LOCAL проходит. НО! при попытки авторизоваться в браузере, не принимает логин пароль, в лог высыпается
    ERROR: Negotiate Authentication validating user. Result: {result=BH, notes={message: received type 1 NTLM token; }}

    1. Жаконда / Автор записи

      Пожалуйста !
      И не примет, т.к. для того чтобы авторизация в браузере заработала, нужно использовать метод NCSA-авторизация

  9. Александр /

    А есть какой то другой метод связи с вами ? Делал все по этой статье и у меня браузер запрашивает логин\пароль

  10. Александр /

    Все мои коменты можно удалить. Всем советую ВНИМАТЕЛЬНО читать статью) И еще раз спасибо.

    1. Жаконда / Автор записи

      Рад что у вас в итоге все получилось 🙂

  11. DmitryDom /

    прописывать адрес прокси каждому ПК обязательно??? Вроде конфиг сделан с прозрачным прокси?

    1. Жаконда / Автор записи

      Да, обязательно ! В прозрачном режиме, аутентификация в AD Не будет проходить.

  12. Дима /

    Добрый день
    negotiate_kerberos_auth_test выдает ошибку spnego cannot find mechanisms to negotiate все остальные проверки ОК
    Что можно поправить?

  13. Игорь /

    Работать будет или нет?
    sudo iptables -t nat -A PREROUTING -s 10.5.5.0/24 -p tcp -m multiport —dports 80,8080 -j REDIRECT —to-ports 3130
    sudo iptables -t nat -A PREROUTING -s 10.5.5.0/24 -p tcp -m multiport —dports 443 -j REDIRECT —to-ports 3129

    1. Жаконда / Автор записи

      Ну если вы пытаетесь реализовать прозрачную аутентификацию с Kerberos-аутентификацией, то у вас ничего не получится.

  14. Евгений /

    С Праздниками!

    чет так и не взлетело в Centos 7 + 2008R2, делал по статье…

    проверки все проходит (тикет получает, в группах видит), а в браузере все равно выдает окно на ввод логин/пароль (ПК и юзер в домене, юзер входит на ПК под доменной учеткой)

    ЧЯДН? =) куда еще покопать?

    и еще если просветите может…. в статье на — (-) keytab генереиться с типом KRB5_NT_SRV_HST, а у Вас KRB5_NT_PRINCIPAL.

    в чем разница?

    1. Жаконда / Автор записи

      Спасибо! Взаимно!

      А прописали прокси-сервер на клиентских машинах ? (как в статье указано).

      При работе в прозрачном (transparent) режиме, аутентификация пользователей невозможна! Подробнее: http://wiki.squid-cache.org/Features/Authentication#Authentication_in_interception_and_transparent_modes

Оставить ответ

пятнадцать − 12 =

© IT-блог Жаконды All Rights Reserved.
Яндекс.Метрика