Настроить 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
1. Предварительная настройка DNS и контроллера домена.
Для корректной работы Kerberos необходимо иметь корректные прямые (A) записи и соответствующие обратные (PTR) записи для сервера squid.
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
3. Настроить и проверить Kerberos на идентификацию пользователя без ключевого файла krb5.keytab.
Данный шаг так же описан в статье о NFS в Windows AD, здесь он абсолютно идентичен.
4. Создать ключевой файл krb5.keytab на KDC (контроллер домена Windows 2008 R2)
Далее, необходимо создать кейтаб-файл на контроллере домена (файл ключей, который будет использоваться для взаимодействия с Active Directory). Вся необходимая теория опять же есть в статье о NFS – создание keytab. Для squid команда создания keytab файла будет выглядеть так:
5. Настроить и проверить работу Kerberos для авторизации через krb5.keytab и корректность созданного keytab-файла.
Допустим, лежит наш keytab в /etc/squid3/squid.keytab, давайте проверим корректность работы данного кейтаба с текущей ОС:
Настройка squid на проверку подлинности через Kerberos в домене Windows 2008 R2.
Для того чтобы сквид знал, какой кейтаб использовать, ему нужно указать, где он лежит. Для этого нужно создать и заполнить файл /etc/default/squid3 следующим содержимым (задать переменную, хранящую путь к кейтаб файлу, которую читает сквид):
squid ~ # cat /etc/default/squid3 KRB5_KTNAME=/etc/squid3/squid.keytab export KRB5_KTNAME
Так же, необходимо вsquid.conf настроить схему аутентификации, для этого нужно добавить следующие строки:
Настроить веб-браузеры на Kerberos аутентификацию в squid.
Собственно, настройка браузеров для SQUID заключается в использовании FQDN-имени в адресе прокси-сервера вместо IP-адреса. То есть делаем все по инструкции Настройка адреса прокси через GPO в Windows Server 2008 R2, но адрес прокси указываем не 10.0.0.10, а squid.domain.local.
После попытки доступа мы видим в логе access.log заветные строки:
Digest – метод аутентификации в squid
Этот метод более защищен, нежели basic-аутентификация, т.к. использует MD5-шифрование для отправки пароля через сеть. Схема
работы
взаимодействия аналогична basic, за тем лишь исключением, что на 2-ом и последующих шагах в ответ сервера и ответы клиента в поля аутентификации добавляются некоторые дополнительные параметры и случайные значения, которые используются для шифрования пароля.
утилита htdigest
, которая находится в
пакете apache2-utils
. Используется хелпер
/usr/lib/squid3/digest_pw_auth
Ntlm – метод аутентификации в squid
Про протокол NTLM и его особенности и недостатки я рассказывал в первой статье о samba. В данной теме особенно делать упор на этот протокол не буду, ибо – небезопасен. Для проверки подлинности используется хелпер /usr/lib/squid3/ntlm_auth. Данный вид аутентификации работает в браузерах IE, Mozilla, Opera, Crome.
Squid samba4 ad kerberos authorization
/usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g FastInet@EXAMPLE.COM
Для дебага можно добавить опции -i или -d. Опция -h покажет встроенный хелп.
Нормальная работа хелпера выглядит так:
root@gw0:~# /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g FastInet@EXAMPLE.COM
inettest01@example.com
OK
inettest02@example.com
ERR
Соответственно, пользователь inettest01 является членом группы FastInet в домене EXAMPLE.COM, а пользователь inettest02 – нет.
external_acl_type fastgroup_krb children=10 cache=10 grace=15 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g FastInet@EXAMPLE.COM
acl fastinet external fastgroup_krb
http_access allow fastinet
Аутентификация ntlm
NTLM представляет собой расширенную версию старого протокола аутентификации LM (LAN Manager). NTLM работает посредством вопросов/ответов между сервером и клиентом без передачи пароля пользователя через сеть в открытом виде. Клиент должен подтвердить то, что он знает пароль пользователя, посредством отправки зашифрованного хэша.
NTLM функционирует следующим образом:
- Пользователь указывает имя пользователя, пароль и имя домена при входе на компьютер-клиент.
- Клиент создает хэш данного пароля и удаляет оригинал.
- Клиент отправляет серверу имя пользователя в открытом виде.
- Сервер отправляет клиенту 16-битный фрагмент случайных данных.
- Клиент шифрует этот фрагмент, а также хэш пароля пользователя и передает их на сервер.
- Сервер передает имя пользователя, случайный фрагмент данных и ответ клиента на контроллер домена.
- Контроллер домена шифрует отрезок случайных данных вместе со своим собственным хэшем пароля пользователя, после чего сравнивает их с элементами, присланными сервером.
- Если значения совпадают, контроллер домена уведомляет сервер об успешном завершении аутентификации.
- Если значения или имя пользователя не совпадают, контроллер домена уведомляет об этом сервер, который передает клиенту соответствующее сообщение. После этого браузер клиента запрашивает у пользователя аутентификационные данные.
Настройка internet explorer через gpo
Желательно на всех машинах локальной сети обновить Internet Explorer до 7 версии, ибо с IE 6 доменная проверка подлинности не будет работать. Об этом Mictosoft официально . Настройка параметров прокси сервера задается в объекте групповой политики в разделе Конфигурация пользователя – Политики – Конфигурация Windows – Настройка Internet Explorer – Подключение – Параметры прокси-сервера: Т.к. данная настройка расположена в конфигурации пользователя, то и применяться будет к пользователям, расположенным в текущем подразделении OU, к которому будет применен Объект групповой политики.