Авторизация и аутентификация squid (basic, Digest, NTLM, negotiate, Kerberos), SQUID AD, squid auth | Блог любителя экспериментов

Настроить 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 [email protected]

Для дебага можно добавить опции -i или -d. Опция -h покажет встроенный хелп. 

Нормальная работа хелпера выглядит так:


root@gw0:~# /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g [email protected]
[email protected]
OK
[email protected]
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 [email protected]

acl fastinet external fastgroup_krb
http_access allow fastinet

Аутентификация ntlm

NTLM представляет собой расширенную версию старого протокола аутентификации LM (LAN Manager). NTLM работает посредством вопросов/ответов между сервером и клиентом без передачи пароля пользователя через сеть в открытом виде. Клиент должен подтвердить то, что он знает пароль пользователя, посредством отправки зашифрованного хэша.

NTLM функционирует следующим образом:

  1. Пользователь указывает имя пользователя, пароль и имя домена при входе на компьютер-клиент.
  2. Клиент создает хэш данного пароля и удаляет оригинал.
  3. Клиент отправляет серверу имя пользователя в открытом виде.
  4. Сервер отправляет клиенту 16-битный фрагмент случайных данных.
  5. Клиент шифрует этот фрагмент, а также хэш пароля пользователя и передает их на сервер.
  6. Сервер передает имя пользователя, случайный фрагмент данных и ответ клиента на контроллер домена.
  7. Контроллер домена шифрует отрезок случайных данных вместе со своим собственным хэшем пароля пользователя, после чего сравнивает их с элементами, присланными сервером.
  8. Если значения совпадают, контроллер домена уведомляет сервер об успешном завершении аутентификации.
  9. Если значения или имя пользователя не совпадают, контроллер домена уведомляет об этом сервер, который передает клиенту соответствующее сообщение. После этого браузер клиента запрашивает у пользователя аутентификационные данные.

Настройка internet explorer через gpo

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *