Приветствую всех, гостей и постоянных читателей блога. Сегодня попробую изложить информацию о методах аутентификации в 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 – Подключение – Параметры прокси-сервера: Т.к. данная настройка расположена в конфигурации пользователя, то и применяться будет к пользователям, расположенным в текущем подразделении 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:

Т.к. данная настройка расположена в конфигурации компьютера, то и применяться будет к компьютеру всем пользователям, вошедшим в компьютер, расположенный в текущем подразделении 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 – Прокси-сервер:

Т.к. данная настройка расположена в конфигурации пользователя, то и применяться будет к пользователям, расположенным в текущем подразделении 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/[email protected]
      ├─squid_kerb_auth,14080 -s HTTP/[email protected]
      ├─squid_kerb_auth,14081 -s HTTP/[email protected]
      ├─squid_kerb_auth,14082 -s HTTP/[email protected]
      └─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/[email protected] \
/mapuser [email protected] /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/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0
x1 (DES-CBC-CRC) keylength 8 (0x2c3b98e6e052ef15)
keysize 54 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0
x3 (DES-CBC-MD5) keylength 8 (0x2c3b98e6e052ef15)
keysize 62 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0
x17 (RC4-HMAC) keylength 16 (0x85a6dea042798a45a547f8450e1115fc)
keysize 78 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0
x12 (AES256-SHA1) keylength 32 (0x4c7b89004af3a67866db313e05592568995e31ce4554ef
a695532300bb2aca7c)
keysize 62 HTTP/[email protected] 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/[email protected]

Valid starting     Expires        em    Service principal
02/29/12 11:20:24  02/29/12 21:20:24  krbtgt/[email protected]
        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/[email protected]
# сколько параллельных потоков запускать для обслуживания аутентификации клиентов
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? [email protected] 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? [email protected] DIRECT/173.194.69.100 -

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

squid ~ # cat /etc/squid3/usersallow
[email protected]
[email protected]
...
[email protected]
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? [email protected] 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/[email protected]
 # сколько параллельных потоков запускать для обслуживания аутентификации клиентов через 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/[email protected]

добавить ключ -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! 

---

Теги: Active Directory, Debian, kerberos, Linux, SQUID