Аутентификация и авторизация squid (basic, Digest, NTLM, negotiate)

настройка аутентификации прокси-сервера SQUID Приветствую всех, гостей и постоянных читателей блога. Сегодня попробую изложить информацию о методах аутентификации в squid, а так же интегрировать suid в доменную инфраструктуру Active Directory на Windows Server 2008 R2. То есть заставить squid разрешать доступ к интернету на основе доменных учетных записей. Для понимания происходящего, советую ознакомиться с предыдущими статьями о настройке сети в Linux и вводной статье о squid. Итак, приступим...

Введение

Из прошлой статьи о squid мы знаем, что в прозрачном режиме squid не способен аутентифицировать пользователей. Поэтому придется настроить пользовательские браузеры. Кроме того, мы знаем, что хороший админ - это ленивый админ и ходить пешком по рабочим станциям и настраивать вручную браузеры пользователей он не станет. Поэтому расскажу как через GPO мы настроим IE (для пользователей бабушек с особо клиническим случаем и для сайтов, использующих ActiveX...), Firefox и Google Chrome. Все эти 3 браузера умеют настраиваться через GPO.

Squid в части авторизации и аутентификации подобен Web-серверу Apache и поддерживает те же способы аутентификации, что и Apache. На текущий момент существуют четыре основных типа проверки подлинности в HTTP протоколе:

  • Basic - самая первая схема, часто используемая по текущий момент
  • NTLM - это первая попытка Microsoft к SSO (single-sign-on) единого входа для ресурсов локальной сети
  • Digest - она же дайджет аутентификация. Чуть защищенней basic
  • Negotiate (aka SPNEGO) - она же Kerberos SPN generation - вторая попытка реализации Microsoft SSO

В статье я рассмотрю пример реализации basic аутентификации и Kerberos и кратко опишу NTLM и Digest.

Настройка адреса прокси через GPO в Windows Server 2008 R2

Настройка Internet Explorer через GPO

Желательно на всех машинах локальной сети обновить Internet Explorer до 7 версии, ибо с IE 6 доменная проверка подлинности не будет работать. Об этом Mictosoft официально заявляет. Настройка параметров прокси сервера задается в объекте групповой политики в разделе Конфигурация пользователя - Политики - Конфигурация Windows - Настройка Internet Explorer - Подключение - Параметры прокси-сервера:Параметры прокси-сервера IE в объекте GPO Т.к. данная настройка расположена в конфигурации пользователя, то и применяться будет к пользователям, расположенным в текущем подразделении OU, к которому будет применен Объект групповой политики.

Настройка Mozilla Firefox через GPO

1. Качаем MSI пакет FrontMotion Firefox Community Edition с http://www.frontmotion.com/FMFirefoxCE/download_fmfirefoxce.htm. (Обязательно Community Edition, ибо кроме CE-версии на данном сайте предлагается обычная сборка msi пакета, которая не принимает настройки из реестра GPO). Оттуда же качаем файлы административных шаблонов mozilla.admx и mozilla.adml, которые собственно и задают настройки групповых политик. Если у Вас сервер AD 2003 версии, то нужно скачивать firefox.adm и mozilla.adm.

2. Распространяем скачанный MSI пакет через объект GPO (как это сделать я описывал в статье установка программ через AD GPO).

3. Кладем скачанные файлы административных шаблонов...:

  • Если используется централизованное хранилище, то mozilla.admx кладется в каталог %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\, а mozilla.adml - в %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\en-US\.
  • Если используется локальное хранилище административных шаблонов, то mozilla.admx кладется в каталог %systemroot%\PolicyDefinitions\, а mozilla.adml - в %systemroot%\PolicyDefinitions\en-US\. После этого появиться новый раздел в настройках GPO.

4. Задаем настройки браузера в созданном объекте групповой политики. Настройки прокси-сервера задаются в разделе Конфигурация компьютера - Политики - Административные шаблоны - Mozilla Advanced Options - Locked Settings - network:

Настройка прокси сервера Mozilla Firefox через GPO

Т.к. данная настройка расположена в конфигурации компьютера, то и применяться будет к компьютеру всем пользователям, вошедшим в компьютер, расположенный в текущем подразделении OU, к которому будет применен Объект групповой политики. Кроме настроек прокси, браузер поддерживает еще туеву хучу настроек, о которых можно почитать тут http://kb.mozillazine.org/About:config_entries.

Настройка Google Chrome через GPO

1. Качаем MSI пакет Chrome с https://www.google.com/intl/en/chrome/business/browser/ или http://www.google.com/chrome/intl/ru/business/index.html. Качаем файлы административных шаблонов chrome.admx и chrome.adml, которые собственно и задают настройки - отсюда http://dl.google.com/dl/edgedl/chrome/policy/policy_templates.zip.

2. Распространяем скачанный MSI пакет через объект GPO (как это сделать я описывал в статье установка программ через AD GPO).

3. В скачанном архиве  policy_templates.zip имеются каталоги policy_templates\windows\admx, из данного каталога кладем файлы административных шаблонов...:

  • Если используется централизованное хранилище административных шаблонов, то chrome.admx кладется в каталог %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\, а chrome.adml - в %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\ru-RU\.
  • Если используется локальное хранилище административных шаблонов, то \ru\chrome.admx кладется в каталог %systemroot%\PolicyDefinitions\, а \ru\chrome.adml - в %systemroot%\PolicyDefinitions\en-US\. После этого появиться новый раздел в настройках GPO.

4. Задаем настройки браузера в созданном объекте групповой политики. Настройки прокси сервера задаются в разделе Конфигурация пользователя -  Политики - Административные шаблоны - Google - Google Chrome - Прокси-сервер:

Настройка прокси сервера chrome через GPO

Т.к. данная настройка расположена в конфигурации пользователя, то и применяться будет к пользователям, расположенным в текущем подразделении OU, к которому будет применен Объект групповой политики. Кроме настроек прокси, браузер Crome поддерживает еще много настроек, о которых можно почитать в скачанном архиве в файле policy_templates\common\html\ru\chrome_policy_list.html. Кроме того, можно ознакомиться с Кратким руководством от гугла http://support.google.com/a/bin/answer.py?hl=ru&answer=187202.

Методы аутентификации SQUID

Начну с рассмотрения общих принципов организации аутентификации в squid. Если быть точным, то сам squid не выполняет никаких функций аутентификации. Работа squid по аутентификации заключается в декодировании HTTP заголовка Authorization и передаче декодированной информации - так называемому хелперу. Если предоставленная информация верна, то доступ пользователю предоставляется, если же не верна или отсутствует, то squid возвращает клиенту HTTP код 407. Более подробно этот процесс будет рассмотрен далее. Т.о. всю основную работу по проверке подлинности пользователей выполняют сторонние модули (они же - хелперы, они же helpers). Расположение этих модулей зависит от дистрибутива и версии SQUID, например в Debian+squid3 они расположены в каталоге /usr/lib/squid3, в Red Hat скорее всего их расположение будет в /usr/lib/squid. Просмотреть, какие методы проверки подлинности поддерживает Ваш сквид, размещение хелперов и многие другие параметры, можно командой squid3 -v, вывод которой содержит опции, с которыми squid был сконфигурирован, например:

--prefix=/usr - префикс для других ключей:
--libexecdir=${prefix}/lib/squid3 - каталог с исполняемыми модулями (в том числе и хелперы)
--enable-auth=basic,digest,ntlm,negotiate - поддерживаемые модули аутентификации. Кроме того
                                            имеется множество дополнительных ключей,
                                            позволяющих настраивать отдельные методы аутентификации:
--enable-basic-auth-helpers=LDAP,MSNT,NCSA... - список программ для аутентификации basic
--with-logdir=/var/log/squid3
и др.

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

squid ~ # pstree -ap 14068
squid3,14068 -YC -f /etc/squid3/squid.conf
  └─squid3,14070 -YC -f /etc/squid3/squid.conf
      ├─ncsa_auth,14089 /etc/squid3/squidusers
      ├─ncsa_auth,14090 /etc/squid3/squidusers
      ├─ncsa_auth,14091 /etc/squid3/squidusers
      ├─ncsa_auth,14092 /etc/squid3/squidusers
      ├─ncsa_auth,14093 /etc/squid3/squidusers
      ├─squid_kerb_auth,14079 -s HTTP/squid.domain.local@DOMAIN.LOCAL
      ├─squid_kerb_auth,14080 -s HTTP/squid.domain.local@DOMAIN.LOCAL
      ├─squid_kerb_auth,14081 -s HTTP/squid.domain.local@DOMAIN.LOCAL
      ├─squid_kerb_auth,14082 -s HTTP/squid.domain.local@DOMAIN.LOCAL
      └─unlinkd,14094

Взаимодействие и описание настроек сторонних модулей аутентификации производится с помощью параметра auth_param. Клиент будет поочередно пытаться использовать схемы аутентификации в том порядке, в котором они заданы в squid.conf. При этом (ходят слухи, но я с этим не столкнулся), у IE есть баг, который заставляет использовать сначала basic аутентификацию, даже если до basic заданы другие более безопасные схемы.

Новая настроенная схема аутентификации вступит в силу только после перезапуска squid, при этом, внесение изменений в уже существующие настроенные схемы может производится без перезапуска демона (достаточно дать команду squid3 -k reconfigure или /etc/init.d/squid3 reload). Настроенный внешний модуль проверки подлинности еще не означает, что эта проверка будет работать и пускать пользователя в интернет. Для контроля доступа в интернет, необходимо создать acl, который будет задействовать настроенный модуль аутентификации. Для этого, acl в поле тип_отбора должен иметь значение proxy_auth, proxy_auth_regex или external с использованием переменной %LOGIN. И, естественно, для заданного acl необходимо иметь разрешение на доступ в параметре http_access.

Формат указания типа используемой аутентификации (формат использования параметра auth_param) следующий:

auth_param схема_аутентификации параметры_схемы [значения_параметров]

где, схема_аутентификации - одна из вышеуказанных схем (basic, digest,...), параметры_схемы - задают настройки указанной схемы и в разных схемах могут различаться, значения_параметров - в этом поле описываются значения параметров_схемы. К каждой схеме аутентификации могут использоваться сколько угодно разные внешние модули, вплоть до использования и самописных скриптов bash. Обычно при установке squid устанавливаются все необходимые модули согласно поддерживаемым схемам аутентификации. Описание их работы и настройки от разработчиков можно найти на этой странице.

Для дальнейшей настройки прокси-сервера я буду использовать "умолчательный" конфиг из коробки, в котором пока разрешен доступ только с петлевого интерфейса:

squid ~ # grep -v ^# /etc/squid3/squid.conf | grep -v ^$
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access deny all
http_port 3128
hierarchy_stoplist cgi-bin ?
coredump_dir /var/spool/squid3
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320

Basic - метод аутентификации в squid (NCSA)

Давайте рассмотрим простейший способ аутентификации, который существовал еще со времен протокола HTTP/1.0. Basic метод аутентификации основан на предоставлении клиентом (веб-браузером или другой программой) - учетных данных (имени и пароля) при запросе какой-либо страницы. При этом, имя пользователя, объединенное двоеточием с паролем кодируется в кодировку base64 и передается в http-запросе в поле Authorization. Например имя пользователя Mc.Sim и пароль 12345 в виде строки Mc.Sim:12345 будут переданы в кодированном виде: TWMuU2ltOjEyMzQ1 . Кодирование текста в кодировку base64 не является защитой!!! Фактически пароль передается в открытом виде!!! Единственным преимуществом этой схемы является то, что любой браузер? каким бы он старым не был, поддерживает данный вид аутентификации.

Давайте рассмотрим практический пример basic-аутентификации:

  1. Клиент запрашивает страницу, которая требует проверки подлинности (в нашем случае - клиент обращается к серверу squid), но не указывает имя пользователя и пароль.
        GET /path/index.html HTTP/1.1
        Host: localhost
  2. Сервер отвечает клиенту с кодом 407 (" Proxy Authentication Required"), в ответ включается список поддерживаемых методов аутентификации и заголовок (realm)
        HTTP/1.1 401 Authorization Required
        Server: HTTPd/1.0
        Date: Mon, 27 Feb 2012 11:18:15 GMT
        WWW-Authenticate: Basic realm="Сервер безопасности"
        Content-Type: text/html
        Content-Length: 311
    
        <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
        <HTML>
           <HEAD>
              <TITLE>Error</TITLE>
              <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
           </HEAD>
           <BODY><H1>401 Unauthorized.</H1></BODY>
        </HTML>
  3. Клиент представит аутентификационную информацию (при этом браузер отобразит окно ввода логина/пароля и пользователь должен его ввести, либо отменить)
  4. После того, как пользователь ввел имя и пароль, браузер (или другая программа), склеит имя пользователя и пароль двоеточием, закодирует символы в base64, подставит это значение исходных запрос в поле Authorization и направит серверу.
        GET /path/index.html HTTP/1.1
        Host: localhost
        Authorization: Basic TWMuU2ltOjEyMzQ1
  5. Сервер проверяет подлинность пароля и логина и предоставляет доступ.
        HTTP/1.1 200 OK
        Server: HTTPd/1.0
        Date: Mon, 27 Nov 2012 11:19:07 GMT
        Content-Type: text/html
        Content-Length: 1076
  6. Либо не предоставляет доступ, если данные не верны.

За хранение паролей в Basic аутентификации отвечает обычный текстовый файл, в котором хранятся стоки с логином и паролем в закодированном в base64 виде. Управление данным файлом удобно осуществлять с помощью утилиты htpasswd. В Debian/ubuntu данная утилита входит в пакет apache2-utils. В squid, по умолчанию, для реализации данного метода аутентификации используется хелпер /usr/lib/squid3/ncsa_auth, который проверяет соответствие логина и пароля в соответствии с заданным файлом и возвращает "OK" или "ERR" в бесконечном цикле. Синтаксис команды htpasswd следующий:

squid ~ # htpasswd -c /создаваемый/файл/паролей имя_пользователя
New password:
Re-type new password:
Adding password for user имя_пользователя
squid ~ # htpasswd /редактируемый/фвйл/паролей имя_пользователя2
New password:
Re-type new password:
Adding password for user имя_пользователя2
squid ~ #  ##############################################################
squid ~ #  # с ключом -с команда htpasswd выполняется первый раз (создает новый файл), пример:
squid ~ # htpasswd -c /etc/squid3/squidusers mc.sim
New password:
Re-type new password:
Adding password for user mc.sim
squid ~ # cat /etc/squid3/squidusers
mc.sim:rpSb8bNGJSfTw
squid ~ # # без ключа -c происходит добавление пользователей к уже существующему файлу:
squid ~ #  htpasswd /etc/squid3/squidusers mc.sim2
New password:
Re-type new password:
Adding password for user mc.sim2
squid ~ # cat /etc/squid3/squidusers
mc.sim:rpSb8bNGJSfTw
mc.sim2:cXIAu76Wn9/7I
squid ~ # # для созданного файла желательно установить права на чтение
squid ~ # # только пользователю и группе, от которой работает демон:
squid ~ # chmod 440 /etc/squid3/squidusers
squid ~ # chown proxy:proxy /etc/squid3/squidusers

Для работы basic аутентификации в squid, необходимо задать параметр, указывающий на описанный нами хелпер, который взаимодействует с созданным нами файлом паролей. Кроме того, необходимо описать acl содержащий список пользователей, которые могут получить доступ к интернету (эти пользователи должны присутствовать в списке паролей), либо вместо пользователей указать значение REQUIRED, которое "включит" в созданный acl всех пользователей, прошедших аутентификацию. Ну и конечно необходимо разрешить доступ созданному acl с помощью параметра http_access. Живой пример:

squid ~ # grep -v ^# /etc/squid3/squid.conf | grep -v ^$
auth_param basic program /usr/lib/squid3/ncsa_auth /etc/squid3/squidusers
acl lan proxy_auth REQUIRED
http_access allow lan
<....>

Собственно, с данной конфигурацией уже вполне можно работать (не забудьте перезапустить squid). У параметра  auth_param basic есть дополнительные настройки (например, количество одновременных соединений - auth_param basic concurrency n, время хранения/кэширования успешных авторизаций - auth_param basic credentialsttl 2 hours и др.), с которыми можно ознакомиться в squid.conf.

Кроме хранения паролей в файле, при basic аутентификации можно использовать еще великое множество источников информации о пользователе/пароле, например:

  • LDAP - хелпер squid_ldap_auth
  • PAM - хелпер pam_auth
  • SASL - хелпер sasl_auth
  • NIS - хелпер yp_auth
  • MySQL - хелпер squid_db_auth
  • RADIUS - хелпер squid_radius_auth
  • и др

Digest - метод аутентификации в squid

Этот метод более защищен, нежели basic-аутентификация, т.к. использует MD5-шифрование для отправки пароля через сеть. Схема работы взаимодействия аналогична basic, за тем лишь исключением, что на 2-ом и последующих шагах в ответ сервера и ответы клиента в поля аутентификации добавляются некоторые дополнительные параметры и случайные значения, которые используются для шифрования пароля. Сам пароль передается в виде хэша, который шифруется и дешифруется с использованием случайного числа. Для создания файла паролей используется утилита htdigest, которая находится в пакете  apache2-utils. Используется хелпер /usr/lib/squid3/digest_pw_auth с указанием файла паролей. Вообще, этот хелпер поддерживает файл паролей в открытом виде, вроде user:password. Может так же использоваться ldap для извлечения информации о пользователях, но опять же - низкий уровень безопасности. Для LDAP - хелпер /usr/lib/squid3/digest_ldap_auth.

NTLM - метод аутентификации в squid

Про протокол NTLM и его особенности и недостатки я рассказывал в первой статье о samba. В данной теме особенно делать упор на этот протокол не буду, ибо - небезопасен. Для проверки подлинности используется хелпер /usr/lib/squid3/ntlm_auth. Данный вид аутентификации работает в браузерах IE, Mozilla, Opera, Crome.

Negotiate - метод аутентификации в squid


Теперь перейдем к самому интересному. Итак, Kerberos - аутентификация в squid в домене на Windows 2008 R2. Проверять валидность пользователя через Kerberos можно разными путями, например многие советуют использовать SAMBA+Winbind, но нам на сервере лишние службы не нужны, поэтому будем использовать другой способ - пакет krb5-user и файл krb5.conf. Пакет krb5-user и его зависимости содержит утилиты, разработанные Massachusetts Institute of Technology (MIT). Существует еще версия, разработанная hedimal, но мне с ней работать не приходилось. Способ аутентификации на основе MIT Kerberos на примере NFS я рассматривал в статье использование AD на Windows 2008 R2 как KDC для NFS, которую очень желательно почитать перед тем как приступать к текущему разделу. Большая часто теории - в указанной статье. Здесь я лишь частично опишу необходимые действия, отличные от NFS.

Схема наших действий примерно следующая:

1. Настроить squid и проверить работоспособность без Kerberos с доступом по IP, либо basic-аутентификация.
2. Настроить Kerberos

  1. Предварительная настройка DNS и контроллера домена.
  2. Настройка синхронизации времени (на основе демона ntpd)
  3. Настроить и проверить Kerberos на идентификацию пользователя без ключевого файла krb5.keytab.
  4. Создать ключевой файл krb5.keytab на KDC (контроллер домена Windows 2008 R2)
  5. Настроить и проверить работу Kerberos для авторизации через krb5.keytab и корректность созданного keytab-файла.

3. Настроить squid на проверку подлинности через Kerberos.
4. Настроить веб-браузеры на Kerberos аутентификацию.

Давайте подробней разберем каждый шаг.

Исходные данные для организации NEGOTIATE - схемы аутентификации

  • домен - DOMAIN.LOCAL
  • DNS-имя контроллера домена - DC.DOMAIN.LOCAL
  • IP-адрес контроллера домена - 10.0.0.4
  • прокси-сервер squid
    • DNS-имя SQUID сервера - SQUID.DOMAIN.LOCAL
    • IP-адрес SQUID сервера - 10.0.0.10

1. Настроить squid и проверить работоспособность без Kerberos с доступом по IP, либо basic-аутентификация.

Данный пункт был реализован согласно приведенных в заголовке ссылок - ранее. Но есть некоторые нюансы конфигурирования сетевой подсистемы для корректной работы с Kerberos. Необходимо обязательно правильно настроить файлы /etc/hosts, /etc/hostname, /etc/resolv.conf, ну и конечно /etc/network/interfaces. (приведенные настройки рассмотрены для Debian/Ubuntu, но если учесть особенности другого дистрибутива, то общая схема настройки будет вполне пригодна)

squid ~ # cat /etc/hosts
10.0.0.10       squid.DOMAIN.local    squid
127.0.0.1       localhost
# для Kerberos советуют указывать именно такой порядок
# то есть первой строкой именно 10.0.0.10 (внешний IP, не loopback)
squid ~ # cat /etc/hostname
squid
squid ~ # cat /etc/resolv.conf
domain DOMAIN.local
search DOMAIN.local
nameserver 10.0.0.4
squid ~ # cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
        address 10.0.0.10
        netmask 255.255.0.0

2. Настройка Kerberos

2.1. Предварительная настройка DNS и контроллера домена.

Для корректной работы Kerberos необходимо иметь корректные прямые (A) записи и соответствующие обратные (PTR) записи для сервера squid.

2.2. Настройка синхронизации времени

Настройку синхронизации времени я описывал в статье о NFS в Windows AD. Здесь лишь кратко скажу, что я использую для этих целей NTP-сервер (пакет ntp) и следующий конфиг:

root@nfsd:~# cat /etc/ntp.conf
server dc.domain.local
restrict default ignore
restrict dc.domain.local
restrict 127.0.0.1 nomodify notrap

2.3. Настроить и проверить Kerberos на идентификацию пользователя без ключевого файла krb5.keytab.

Данный шаг так же описан в статье о NFS в Windows AD, здесь он абсолютно идентичен.

2.4. Создать ключевой файл krb5.keytab на KDC (контроллер домена Windows 2008 R2)

Далее, необходимо создать кейтаб-файл  на контроллере домена (файл ключей, который будет использоваться для взаимодействия с Active Directory). Вся необходимая теория опять же есть в статье о NFS - создание keytab. Для squid команда создания keytab файла будет выглядеть так:

C:\Windows\system32>ktpass.exe /princ HTTP/squid.domain.local@DOMAIN.LOCAL \
/mapuser squid$@DOMAIN.LOCAL /crypto ALL /ptype KRB5_NT_PRINCIPAL \
/pass +rndpass /out C:\tmp\squid.keytab
Targeting domain controller: DC.domain.local
Using legacy password setting method
Successfully mapped HTTP/squid.domain.local to SQUID$.
WARNING: Account SQUID$ is not a user account (uacflags=0x1021).
WARNING: Resetting SQUID$'s password may cause authentication problems if SQUID$ is being used as a server.

Reset SQUID$'s password [y/n]? y
WARNING: pType and account type do not match. This might cause problems.
Key created.
Key created.
Key created.
Key created.
Key created.
Output keytab to C:\tmp\squid.keytab:
Keytab version: 0x502
keysize 54 HTTP/squid.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0
x1 (DES-CBC-CRC) keylength 8 (0x2c3b98e6e052ef15)
keysize 54 HTTP/squid.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0
x3 (DES-CBC-MD5) keylength 8 (0x2c3b98e6e052ef15)
keysize 62 HTTP/squid.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0
x17 (RC4-HMAC) keylength 16 (0x85a6dea042798a45a547f8450e1115fc)
keysize 78 HTTP/squid.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0
x12 (AES256-SHA1) keylength 32 (0x4c7b89004af3a67866db313e05592568995e31ce4554ef
a695532300bb2aca7c)
keysize 62 HTTP/squid.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0
x11 (AES128-SHA1) keylength 16 (0x40e69a57b011ac68e08f23b7d1133f33)

Итого, мы получили keytab в каталоге C:\tmp\ - squid.keytab. Теперь этот файл ключей Kerberos необходимо БЕЗОПАСНО скопировать на сервер squid, например чрез WinSCP и приступить к следующему шагу.  Так же нужно задать права кейтабу.

2.5.  Настроить и проверить работу Kerberos для авторизации через krb5.keytab и корректность созданного keytab-файла.

Допустим, лежит наш keytab в /etc/squid3/squid.keytab, давайте проверим корректность работы данного кейтаба с текущей ОС:

squid ~ # kinit -V -k -t /etc/squid3/squid.keytab  HTTP/squid.domain.local
Authenticated to Kerberos v5
squid ~ # klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: HTTP/squid.domain.local@DOMAIN.LOCAL

Valid starting     Expires        em    Service principal
02/29/12 11:20:24  02/29/12 21:20:24  krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
        renew until 03/01/12 11:20:24
squid ~ # kdestroy
squid ~ # chown -v proxy:proxy /etc/squid3/squid.keytab
изменён владелец «/etc/squid3/squid.keytab» на proxy:proxy
squid ~ # chmod -v u=rw,go-rwx /etc/squid3/squid.keytab
права доступа «/etc/squid3/squid.keytab» изменены на 0600 (rw-------)

Что мы сделали в текущем листинге? Утилитой kinit мы инициировали получение и положили в кэш билет от KDC для SPN-записи  HTTP/squid.domain.local с использованием ключа (т.е. не пароля, параметр -k) размещение которого задано с помощью параме. Для/emтра -t /etc/squid3/squid.keytab.  Параметр -V заставляет утилиту выводить сообщение при удачной аутентификации. Далее, с помощью klist мы просматриваем полученный билет, который размещен в кэше. С помощью kdestroy мы уничтожаем все, что есть в кэше. Далее, мы ограничивает права доступа к нашему кейтабу, тем самым разрешаем доступ только пользователю, под которым работает сквид. АХТУНГ!!! Если на данном этапе kinit выдал ошибки, то далее настраивать смысла нет, ибо Kerberos клиент работает не корректно. Необходимо избавиться от ошибок.

3. Настройка squid на проверку подлинности через Kerberos в домене Windows 2008 R2.

Для того чтобы сквид знал, какой кейтаб использовать, ему нужно указать, где он лежит. Для этого нужно создать и заполнить файл /etc/default/squid3 следующим содержимым (задать переменную, хранящую путь к кейтаб файлу, которую читает сквид):

squid ~ # cat /etc/default/squid3
KRB5_KTNAME=/etc/squid3/squid.keytab
export KRB5_KTNAME

Так же, необходимо в squid.conf настроить схему аутентификации, для этого нужно добавить следующие строки:

# указание, какой хелпер использовать с каким SPN
auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s HTTP/squid.domain.local@DOMAIN.LOCAL
# сколько параллельных потоков запускать для обслуживания аутентификации клиентов
auth_param negotiate children 10
# указывает поддерживать связь, а не обрывать, когда браузер опрашивает схемы аутентификации
auth_param negotiate keep_alive on

В некоторых конфигурациях в "сети" приводятся примеры без указания параметра -s и SPN, но у меня такая конфигурация не заработала. Так же, не забываем о наличии строк, разрешающим доступ для авторизованных пользователей:

acl lan proxy_auth REQUIRED
http_access allow lan

Примечание: вместо SPN можно использовать значение GSS_C_NO_NAME, в данном случае, squid будет использовать любой (какой? в какой последовательности?) SPN из keytab файла. Строка будет выглядеть так: <...>ate program /usr/lib/squid3/squid_kerb_auth -s GSS_C_NO_NAME (спасибо за дополнение комментатору selivan)

На этом можно считать настойку сквида законченной (не забудте сделать рестарт сквида). Если необходимо пускать не в всех пользователей в интернет, а только избранных, то в acl необходимо указать имя пользователя в том формате, в котором squid распознает пользователя. Этот формат можно посмотреть в логе access.log. Например для нашего случая имя пользователя имеет следующий вид:

1330858897.314 86 10.0.1.48 TCP_MISS/200 491 GET http://www.google-analytics.com/__utm.gif? test2@DOMAIN.LOCAL DIRECT/173.194.69.113 image/gif
1330858898.296 94 10.0.1.48 TCP_MISS/204 192 GET http://support.google.com/accounts/bin/stats? test2@DOMAIN.LOCAL DIRECT/173.194.69.100 -

то есть имя пользователя имеет формат имя_пользователя@ОБЛАСТЬ_ДОМЕНА. При этом, как показала практика, регистр букв имеет значение, то есть если в acl указать имя пользователя tEst2@DOMAIN.LOCAL или test2@DOMAIN.local, а в AD он заведен как test2 и область домена в верхнем регистре, то доступ пользователю предоставлен не будет. То есть нужно быть внимательным при указании пользователя в acl. Так же, можно задать список пользователей, перечислив их в отдельном файле и указав этот файл как значение для acl, например:

squid ~ # cat /etc/squid3/usersallow
ultest@DOMAIN.LOCAL
test2@DOMAIN.LOCAL
...
testn@DOMAIN.LOCAL
squid ~ # grep allow /etc/squid3/squid.conf
acl allowinet proxy_auth "/etc/squid3/usersallow"
http_access allow allowinet

Кроме данного способа, есть возможность предоставить доступ пользователей к интернету на основе членства в доменных группах. Но для данной задачи используется отдельный хелпер и список доступа в формате external_acl и хелпер /usr/lib/squid3/squid_ldap_group. В сети можно найти много примеров. Конфигурацию на основе доменных групп я постараюсь рассмотреть в следующих статьях.

4. Настроить веб-браузеры на Kerberos аутентификацию в squid.

Собственно, настройка браузеров для SQUID заключается в использовании FQDN-имени в адресе прокси-сервера вместо IP-адреса. То есть делаем все по инструкции Настройка адреса прокси через GPO в Windows Server 2008 R2, но адрес прокси указываем не 10.0.0.10, а squid.domain.local. Корректная работа с Kerberos у меня получилась только в браузерах IE старше 7 версии, Firefox и Chrome. Про IE версии ниже 7 версии можно почитать статью от microsoft.

После попытки доступа мы видим в логе access.log заветные строки:

1330506205.277 828 10.0.1.48 TCP_MISS/204 313 GET http://www.google.ru/client_204? test@DOMAIN.LOCAL DIRECT/209.85.173.94 text/html

Финальный вид настроек в squid.conf

squid ~ # grep -v ^# /etc/squid3/squid.conf | grep -v ^$
 # указание, какой хелпер использовать с каким SPN для negotiate авторизации
auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s HTTP/squid.domain.local@DOMAIN.LOCAL
 # сколько параллельных потоков запускать для обслуживания аутентификации клиентов через kerberos
auth_param negotiate children 10
 # указывает поддерживать связь, а не обрывать, когда браузер опрашивает схемы аутентификации
auth_param negotiate keep_alive on
 # если клиент не прошел negotiate аутентификацию, ему будет выдан запрос логина/пароля для Basic аутентификации
auth_param basic program /usr/lib/squid3/ncsa_auth /etc/squid3/squidbasicusers
 # сколько параллельных потоков запускать для обслуживания basic аутентификации клиентов
auth_param basic children 10
 # создание списка контроля доступа с пользователями, которым далее разрешим доступ
acl allowinet proxy_auth "/etc/squid3/usersallow"
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
 # разрешаем доступ acl allowinet
http_access allow allowinet
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access deny all
http_port 3128
hierarchy_stoplist cgi-bin ?
coredump_dir /var/spool/squid3
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320

Таким образом, мы требуем от клиента - Kerberos (negotiate) аутентификации, если клиент не принадлежит домену, то он должен аутентифицироваться через Basic аутентификацию. Это очень удобно, когда всем доменным пользователям предоставляется доступ по их доменной учетной записи, а "гостям", например с ноутбуками - выдаем логин/пароль для basic аутентификации. Эти логины/пароли храним в файле /etc/squid3/squidbasicusers. Список всех, кому разрешаем доступ мы храним в файле /etc/squid3/usersallow.

Траблешуттинг

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

Для корректной работы kerberos необходимо иметь открытый доступ для исходящих пакетов на tcp/dst-порт 88. Как это сделать, описано в статьях об iptables.

Для диагностики SQUID и Kerberos можно в строке

auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s HTTP/squid.domain.local@DOMAIN.LOCAL

добавить ключ -d - это заставит хелпер быть более разговорчивым. При ошибках аутентификации сообщения будут появляться в логе /var/log/squid3/cache.log. Например, когда я неверно указал адрес прокси в браузере (указад ip вместо DNS FQDN), то в лог сыпались вот такие ошибки:

2012/02/28 23:06:46| authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned 'BH received type 1 NTLM token'
2012/02/28 23:06:49| squid_kerb_auth: DEBUG: Got 'YR TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw==' from squid (length: 59).
2012/02/28 23:06:49| squid_kerb_auth: DEBUG: Decode 'TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw==' (decoded length: 40).
2012/02/28 23:06:49| squid_kerb_auth: WARNING: received type 1 NTLM token

Резюме

Фух, статья завершена. Долго пришлось повозиться со всеми этими схемами и приведенными в интернете примерами. Уж очень большое количество комбинаций схем и хелперов поддерживает сквид. По началу можно запутаться, но надеюсь. что моя статья вам помогла в этом всем разобраться. Следующая статья о сквид планирует содержать правила ограничения доступа к интернету, как по посещаемым ресурсам, скорости, так и по времени и, возможно, другим критериям. Так же, планирую создать отдельную статью с тонкими настройками сквида.

Что еще почитать

Примеры использования LDAP групп в AD:
http://ru.gentoo-wiki.com/wiki/Настройка_авторизации_SQUID_в_Active_Directory_по_протоколу_LDAP
http://www.lissyara.su/?id=2101

Использование Kerberos в Web-сервере
ttp://www.grolmsnet.de/kerbtut/

Интересный нюанс работы squid и в целом аутентификации (первый и последний пост):
http://forum.ru-board.com/topic.cgi?forum=8&topic=11275

Отличная книга Squid Proxy Server 3.1 Beginner's Guide

Upd 2012.04.08: добавил книгу Squid Proxy Server 3.1 Beginner's Guide
Upd 2013.10.26: добавил инфу о GSS_C_NO_NAME

С Уважением, Mc.Sim! 




Теги: , , , ,

120 комментариев к “Аутентификация и авторизация squid (basic, Digest, NTLM, negotiate)”

  1. Александр
    Август 4th, 2014 at 16:02
    1

    Mc.Sim, доброго времени суток! Может подскажешь еще что можно попробовать, а то всю голову уже сломал. Вообщем имеем FreeBSD 10.0-RELEASE GENERIC amd64, squid33 со всеми нужными хелперами, не один раз проверенными и настроенными по статье AD, DNS, keytab. Билет через keytab получает без ошибок. Но НИКАК не дает пройти аутентификацию, вот хоть убейся. %)
    Конфиги и выводы логов:

    squid.conf

    auth_param negotiate program /usr/local/libexec/squid/negotiate_kerberos_auth -i -d -s HTTP/proxy1.cfpm.ru@CFPM.RU
    auth_param negotiate children 30
    auth_param negotiate keep_alive on

    и т.д.

    krb5.conf

    [libdefaults]
    default_realm = CFPM.RU
    dns_lookup_kdc = no
    dns_lookup_realm = no
    ticket_lifetime = 24h
    default_keytab_name = /etc/krb5.keytab
    default_tgs_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
    default_tkt_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
    permitted_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
    ; forwardable = yes
    [realms]
    CFPM.RU = {
    kdc = cupd2.cfpm.ru
    default_domain = CFPM.RU
    }

    [domain_realm]
    .cfpm.ru = CFPM.RU
    cfpm.ru = CFPM.RU
    [logging]
    default = FILE:/var/log/krb5lib.log
    kdc = FILE:/var/log/krb5kdc.log

    cache.log

    2014/08/04 15:45:00 kid1| Adding nameserver 192.168.1.241 from /etc/resolv.conf
    2014/08/04 15:45:00 kid1| helperOpenServers: Starting 0/30 'negotiate_kerberos_a uth' processes
    2014/08/04 15:45:00 kid1| helperStatefulOpenServers: No 'negotiate_kerberos_auth ' processes needed.
    2014/08/04 15:45:00 kid1| WARNING: no_suid: setuid(0): (1) Operation not permitt ed
    2014/08/04 15:45:00 kid1| Pinger socket opened on FD 10
    2014/08/04 15:45:00| pinger: Initialising ICMP pinger ...
    2014/08/04 15:45:00| pinger: ICMP socket opened.
    2014/08/04 15:45:01 kid1| Loaded Icons.
    2014/08/04 15:45:01 kid1| Accepting HTTP Socket connections at local=0.0.0.0:312 8 remote=[::] FD 8 flags=9
    2014/08/04 15:45:11| Pinger exiting.
    2014/08/04 15:45:38 kid1| Starting new negotiateauthenticator helpers...
    2014/08/04 15:45:38 kid1| helperOpenServers: Starting 1/30 'negotiate_kerberos_auth' processes
    2014/08/04 15:45:38 kid1| WARNING: no_suid: setuid(0): (1) Operation not permitted
    negotiate_kerberos_auth.cc(270): pid=2353 :2014/08/04 15:45:38| negotiate_kerberos_auth: INFO: Starting version 3.0.4sq
    negotiate_kerberos_auth.cc(315): pid=2353 :2014/08/04 15:45:38| negotiate_kerberos_auth: DEBUG: Got 'YR TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==' from squid (length: 59).
    negotiate_kerberos_auth.cc(378): pid=2353 :2014/08/04 15:45:38| negotiate_kerberos_auth: DEBUG: Decode 'TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==' (decoded length: 40).
    negotiate_kerberos_auth.cc(388): pid=2353 :2014/08/04 15:45:38| negotiate_kerberos_auth: WARNING: received type 1 NTLM token
    2014/08/04 15:45:38 kid1| ERROR: Negotiate Authentication validating user. Error returned 'BH received type 1 NTLM token'
    negotiate_kerberos_auth.cc(315): pid=2353 :2014/08/04 15:45:47| negotiate_kerberos_auth: DEBUG: Got 'YR TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==' from squid (length: 59).
    negotiate_kerberos_auth.cc(378): pid=2353 :2014/08/04 15:45:47| negotiate_kerberos_auth: DEBUG: Decode 'TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==' (decoded length: 40).
    negotiate_kerberos_auth.cc(388): pid=2353 :2014/08/04 15:45:47| negotiate_kerberos_auth: WARNING: received type 1 NTLM token
    2014/08/04 15:45:47 kid1| ERROR: Negotiate Authentication validating user. Error returned 'BH received type 1 NTLM token'

    access.log

    192.168.1.205 TCP_DENIED/407 GET http://www.squid-cache.org/Artwork/SN.png - -
    192.168.1.205 TCP_DENIED/407 GET http://www.squid-cache.org/Artwork/SN.png - -
    192.168.1.205 TCP_DENIED/407 GET http://ya.ru/favicon.ico - -
    192.168.1.205 TCP_DENIED/407 GET http://ya.ru/favicon.ico - -
    192.168.1.205 TCP_DENIED/407 CONNECT apis.google.com:443 - -

    Куда копать еще? По этим ошибкам перерыл уже гугл. Wrapper можно использовать но у меня нет хелпера ntlm, вот какие есть:

    basic_db_auth cachemgr.cgi negotiate_kerberos_auth
    basic_fake_auth cert_tool negotiate_kerberos_auth_test
    basic_getpwnam_auth digest_file_auth negotiate_wrapper_auth
    basic_ldap_auth diskd ntlm_fake_auth
    basic_msnt_auth ext_file_userip_acl ntlm_smb_lm_auth
    basic_msnt_multi_domain_auth ext_kerberos_ldap_group_acl pinger
    basic_ncsa_auth ext_ldap_group_acl ssl_crtd
    basic_pam_auth ext_time_quota_acl unlinkd
    basic_pop3_auth ext_unix_group_acl url_fake_rewrite
    basic_radius_auth helper-mux.pl url_fake_rewrite.sh
    basic_sasl_auth log_file_daemon

    • Август 7th, 2014 at 09:30
      2

      Приветствую.
      Давайте по порядку…
      1. Покажите содержимое cat /etc/ntp.conf или чем вы синхронизируете время?
      2. Действительно ли вам необходимо такое количество параметров в /etc/krb5.conf? И осознаете ли вы их значения?
      3. Отрабатывает ли kinit имя_пользователя без keytab файла? Покажите вывод?
      4. После создания keytab файла, покажите kinit -V -k -t /путь/к/кейтаб/файлу HTTP/proxy1.cfpm.ru@CFPM.RU
      5. покажите полный конфиг squid.conf

  2. Макс
    Август 29th, 2014 at 14:13
    3

    Добрый день.

    Поднимаю прокси сервер с авторизацией по доменным учеткам. Перебрал миллион мануалов… Зашел в тупик… Проблема с хелперами аутентификации… куда копать — хз… В общем делал так:

    днсы прописал, самба и сквид с нужными компонентами, ввел фряху в домен. получил билет кербероса, все успешно.. отрабатывает wbinfo -g -u успешно (видит все группы и юзверей в домене!!!)… id user Тоже отрабатывает (показывает в каких группах находится доменный юзверь), krb5.conf настроил (если нужно скину конфиг). Как я понимаю — затык в конфе сквида, а именно его хелперах аутентификации… вот выдержка из конфы:

    # Хелпер в домене
    auth_param negotiate program /usr/local/libexec/squid/negotiate_kerberos_auth -s HTTP/perfect.home.local@HOME.LOCAL
    auth_param negotiate children 50 startup=10 idle=5
    auth_param negotiate keep_alive on

    # ldap
    external_acl_type nt_group ttl=300 negative_ttl=300 %LOGIN \
    /usr/local/libexec/squid/ext_ldap_group_acl \
    -R -b «DC=home,DC=local» \
    -f «(&(samaccountname=%u)(memberof=cn=%g,OU=groups,OU=inet,DC=home,DC=local))» \
    -D max@home.local -W /usr/local/etc/squid/authpw \
    -K -h win2003test.home.local

    по ЛДАПу все рОвно…по отдельности запускал — отрабатывает зашибись…а вот по первому хелперу — в логах сквида пишет постоянно ошибку:

    ERROR: negotiate Authentication validating user. Error returned ‘BH received type 1 NTLM token

    Куда копать — хз… весь мозг уже сломал…. перерыл уже 100500 мануалов на разных ресурсах… конфы все сверяю — все сходится… но работать сцука отказывается… когда юзверь заходит в браузер..вводит любой сайт — ему выскакивает окно авторизации и никуда не уходит… хоть об стену убейся…

    Заранее спасибо за ответы и помощь…

    В принципе та же проблема что и у Александра.

    • Декабрь 17th, 2014 at 20:27
      4

      Сори за поздний ответ… )
      Вы настраиваете SAMBA и SQUID на одном сервере?
      И оба сервиса пытаетесь ввести в домен? Какова конечная цель?

  3. Alex
    Декабрь 24th, 2014 at 12:23
    5

    Приветствую.
    Связку кербероса с неготэт хелпером настроил, все работает, но с одним БОЛЬШИМ но, работает только лишь в ОДНОМ на выбор домене, у меня в сети еще поддоменов c десяток(в каждом поддомене соответственно свой контроллер домена). Как настроит авторизацию на них? Между корневым доменов леса и поддоменами транзитивные отношения настроены.
    Расскажите мне, что в данном случае можно сделать?

    • Апрель 8th, 2015 at 20:27
      6

      Думаю, что ключевым в данном случае будет создание правильного SPN, который будет иметь необходимые права доступа во всем лесу.

  4. Нагадил
    Февраль 25th, 2015 at 13:12
    7

    скажите, опытные люди, ежели обновить версию ебунты 12.04 до 14.04 с настроенным krb5 (авторизация apache через kerberos в MS домене) каковы могут быть последствия? поломается все к чертям, придется ли заново создавать keytab и настраивать krb5 на обновленной убунте?

    • Июнь 7th, 2015 at 20:07
      8

      нужно читать релиз ноты к задействованным (читай — обновляемым) пакетам. Если в релизе заявлено изменение функционала или конфигов, то определенно предстоит работа… Что-либо предположить трудно.
      Общая рекомендация такая: снять образ HDD, обновиться, проверить работоспособность, если поломалось — откатиться.

  5. Евгений
    Февраль 25th, 2015 at 22:58
    9

    Добрый день!
    Подскажите, пожалуйста по такому моменту

    squid ~ # kinit -V -k -t /etc/squid3/squid.keytab HTTP/squid.domain.local

    Ваш сервер называется squid, а файл squid.keytab. Можно ли данный файл положить на другой сервер, скажем, proxy.domain.local? Можно ли его использовать одновременно на нескольких работающих серверах?

    Ключ /mapuser подразумевает, что надо создать учетку в AD с именем squid? Если да, то как и где она используется?
    Спасибо.

    • Июнь 7th, 2015 at 20:11
      10

      Ответы на свои вопросы ВЫ сможете найти в статье Active Directiry как KDC для NFS. Особое внимание рекомендую уделить второму разделу.

  6. Павел
    Апрель 13th, 2015 at 08:50
    11

    Доброго времени суток. Огромное спасибо за статью. Правда, у меня возникла проблема: сделал 2 типа аутентификации, как указано в статье, сначала kerberos, потом basic, если пользователь не в домене. Kerberos работает, но если компьютер не в домене браузер запрашивает логин и пароль, после ввода окно появляется снова и так постоянно. В логах пишет: 2015/04/13 08:07:54| authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned ‘BH received type 1 NTLM token’
    2015/04/13 08:07:54| authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned ‘BH received type 1 NTLM token’
    2015/04/13 08:07:54| authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned ‘BH received type 1 NTLM token’
    2015/04/13 08:14:20| authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned ‘BH received type 1 NTLM token’
    Подскажите, куда копать?

  7. Павел
    Апрель 13th, 2015 at 09:02
    13

    вот config:

    auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s HTTP/squid.domain.ru@DOMAIN.RU
    auth_param negotiate children 100
    auth_param negotiate keep_alive off

    external_acl_type ldap_check children=100 ttl=2200 %LOGIN /usr/lib/squid3/squid_ldap_group -R -b «ou=Group,dc=domain,dc=ru» -f «(&(objectclass=user)(sAMAccountName=%v)(memberOf=cn=%a,ou=squid,ou=Group,dc=domain,dc=ru))» -D adsquid@domain.ru -K -W /etc/squid3/aduser dc1.domain.ru.

    auth_param basic program /usr/lib/squid3/ncsa_auth /etc/squid3/squidusers

    acl test proxy_auth usertest
    acl manager proto cache_object
    acl localhost src 127.0.0.1/32 ::1
    acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
    acl SSL_ports port 443
    acl Safe_ports port 80 # http
    acl Safe_ports port 21 # ftp
    acl Safe_ports port 443 # https
    acl Safe_ports port 70 # gopher
    acl Safe_ports port 210 # wais
    acl Safe_ports port 1025-65535 # unregistered ports
    acl Safe_ports port 280 # http-mgmt
    acl Safe_ports port 488 # gss-http
    acl Safe_ports port 591 # filemaker
    acl Safe_ports port 777 # multiling http
    acl CONNECT method CONNECT
    acl users external ldap_check inet

    http_access allow test
    http_access allow users
    http_access allow manager localhost
    http_access deny manager
    http_access deny !Safe_ports
    http_access deny CONNECT !SSL_ports
    http_access allow localhost
    http_access deny all
    http_port 3128

    (ЗЫ: почему то не могу смотреть комментарии на 1 странице)

    • Июнь 7th, 2015 at 22:20
      14

      С комментами разбираюсь…
      По поводу проблемы — ответ выше )

  8. Serg
    Июнь 2nd, 2015 at 15:48
    15

    Здравствуйте, столкнулся с той же проблемой что и остальные, настраиваю все по мануалам — в итоге не пускает даже на первоначальную страницу настройки в sams, доступ к кешу запрещен. Цель следующая — сделать прокси-сервер, который пропускает через себя запросы от пользователей Active Directory, пуская в инет через авторизацию имя/пароль. Все как-то ну очень уж неочевидно…

    • Июнь 7th, 2015 at 22:51
      16

      на каком шаге из данной статьи у вас возникли проблемы?

  9. Евгений
    Июнь 5th, 2015 at 11:57
    17

    Сам отвечу. Сервер может называться (hostname) как угодно. Должны совпадать доменное имя, прописанное в настройках браузера пользователя (можно короткое, без домена), DNS-запись, указывающая на прокси-сервер и SPN keytab’а.

    То есть если выдан кейтаб для proxy.domain.ru, а в настройках браузера прописан squid.domain.ru, то аутентифицироваться не получится.
    Но можно этот же кейтаб использовать а другом сервере. Например, основной вышел из строя, кейтаб лежит на резервном, меняем DNS-запись, чтобы пользователей отсылало на резервный сервер, и все будут нормально проходить аутентификацию.

    Если использовать NTLM, там несколько проще с этим.

    • Июнь 7th, 2015 at 22:52
      18

      Да, отлично что Вы сами разобрались )
      Все так и есть.

  10. Евгений
    Октябрь 28th, 2015 at 08:23
    19

    Добрый день! Появилась необходимость вернуться к Линукс, ваши статьи помогли в настройке Squid, работает проверка по пользователю в AD, работает управление через группы, но не могу заставить работать в режиме basic через Kerberos. Хелпер basic_ldap_auth работает в консоли, а вот браузеры и другой софт не может пройти проверку, постоянно выскакивает окно запроса логина и пароля, в логах 407.
    squid.conf: http://pastebin.com/5XVAatrg
    Не нашел другого варианта с вами связаться поэтому запостил тут. Буду признателен за помощь.

    • Июль 24th, 2016 at 15:15
      20

      для basic аутентификации это нормальное поведение — запрашивать пароль у пользователя. Поэтому она и basic. Если нужно, чтобы пользователь попадал в интернет без ввода пароля, то нужно настраивать либо NTLM, либо negotiate.
      Если я правильно Вас понял )

  11. Константин
    Ноябрь 24th, 2015 at 05:47
    21

    Здравствуйте. У меня проблема с похожей схемой. Имеется домен, и прокси. Часть пользователей в домене, а часть на ноутах. Проблема в том, что доменные пользователи авторизуются «на лету», а вот по логину и паролю авторизация не проходит. Проверил статус сквида, он даже не запускает ncsa_auth. Если отключить доменную авторизацию, то по логину и паролю проходит..
    squid.conf:
    auth_param ntlm program /usr/bin/ntlm_auth —helper-protocol=squid-2.5-ntlmssp —domain=MYDOMAIN
    auth_param ntlm children 10
    auth_param ntlm keep_alive on
    auth_param basic program /usr/lib64/squid/basic_ncsa_auth /etc/squid/passwd
    auth_param basic children 10
    acl auth_list proxy_auth REQUIRED
    external_acl_type my_domain %LOGIN /usr/lib64/squid/ext_ldap_group_acl -R -d -b «dc=mydomain,dc=local» -f «(&(objectclass=user)(sAMAccountName=%v)(memberOf=cn=%a,CN=Users,DC=mydomain,DC=local))» -D admin@mydomain.local -K -w password -h dc.mydomain.local
    acl localnet src 192.168.100.0/24
    acl inet1 external my_domain Internet
    http_access deny localnet black_list
    http_access allow inet1
    http_access allow auth_list
    http_access deny !auth_list all
    http_access deny all

    • Август 3rd, 2016 at 21:51
      22

      Проблема еще актуальна?
      Что за дистрибутив? Что за версия сквида?

Страницы комментариев

Написать комментарий