Интеграция squid c MS Active Directory / Хабр

Особенности работы squid при авторизации на основе доменных групп ldap

При реализации данной схемы я столкнулся с некоторыми нюансами, которые не стоит оставлять без внимания:

Настройка squid для авторизации на основе членства в доменной группе ldap

Приступаем к финальному шагу. Для реализации авторизации на основе членства в доменной группе в squid используется внешний acl, т.н. параметр external_acl_type. Общая схема работы примерно следующая:

# задаем external_acl_type для взаимодействия с LDAP
external_acl_type произвольное_имя_ext_acl%LOGIN /путь/к/хелперу/squid_ldap_group -R 
-b "BaseDN" -f "фильтр с переменной %v и %a" -D пользователь_ad@домен -K -W /файл/с/паролем имя_dc
# где переменная %v подставляется за счет указания значения %LOGIN,
#  которое извлекает имя аутентифицированного пользователя
# далее необходимо задать acl, которое будет передавать в переменную %a имя групп
acl имя_acl external произволное_имя_ext_aclпередаваемое_название_группы
# далее необходимо с образовавшимся acl работать как с обычным acl,
# то есть задавать какие-то разрешения с помощью соответствующих параметров

Если данную схему наложить на наш домен и нашу задачу, то получится примерно следующий конфиг:

Что такое ldap в active directory (введение)

Т.к. LDAP пока для меня – это маленькая тайна. Расскажу, что знаю… Итак, LDAP – это некий каталог (дословно – lightweight directory access protocol, в переводе – облегчённый протокол доступа к каталогам), который хранит в себе различную информацию в древовидной форме и имеет структуру, на нашем примере (на примере домена AD.LOCAL):  sqiud авторизация пользователей по группам в active directory

Давайте разберем что к чему… В голове структуры – имя домена (AD.LOCAL), “в подчинении” у домена – отделы (т.н. организационные единицы), у каждого отдела могут быть в подчинении другие отделы. Кроме того, в любой отдел (в том числе и в корневой контейнер – домен) могут входить некие элементы – группы, пользователи, принтеры и др., которые “в себе” могут хранить некоторые настройки –  атрибуты объекта (например, у пользователя – пароль, имя, адрес почты и др.).

У каждой записи в LDAP, будь то объект или контейнер с объектами внутри имеется уникальное для всего каталога LDAP имя (т.н.  англ. Distinguished Name (DN) – Отличительное имя). Это даже не имя, а путь, характеризующий полный путь к этом этой записи во всей иерархии.

Уникальный путь может выглядеть (на примере группы squid), следующим образом: «cn=squid, ou=groups, ou=UNIXs,  dc=ad, dc=local». Уникальное имя состоит из одного или нескольких относительных отличительных имен (RDN — англ.

Relative Distinguished Name), разделённых запятой. Относительное уникальное имя имеет вид ИмяАтрибута=значение (например cn=squid ). На одном уровне каталога не может существовать двух записей с одинаковыми относительными уникальными именами (при этом, в Active Directory имеются некоторые дополнительные ограничения, например, не может быть пользователя с одинаковым именем во всем дереве).

Давайте разберем приведенный путь. Данный путь стОит читать с конца. Он начинается с описания домена, в котором расположен каталог и обозначается как dc=ad, dc=local, здесь – имя dc (оно же Domain Component – компонент доменного имени) задает имя домена, то есть если бы у нас был домен, например subdomain.ad.local, то данный кусок отличительного имени выглядел бы как  dc=subdomain,dc=ad, dc=local. Далее описывается

структура

иерархия контейнеров

отделов

(они же OU, они же

Organization Unitорганизационная единица

или

подразделение

), которые представляет собой  

ou=groups, ou=UNIXs

. Это стоит читать так же с конца, то есть в текущем домене есть некий

контейнер UNIXs

, в котором есть

подконтейнер groups

. Если бы необходимый нам объект находился в отделе, например, Склады, то текущий кусок

DN (Distinguished Name)

выглядел бы следующим образом:  

ou=Склады, ou=groups.

Далее мы видим в DN описание конкретной записи (в данном случае – запись – это

группа squid

). Кусок, DN пути, описывающий группу представляет собой строку

cn=squid

, где 

CNCommon Nameобщее (относительное) имя

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

Думаю, что общую структуру объяснил понятно. Этого понимания, думаю, будет достаточно для реализации Kerberos LDAP авторизации на основе группы Active Directory.

Настроить 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 и ntlm-авторизация через active directory [rtzra’s hive]

Первое что нужно сделать – это присоединить наш сервер к домену Active Directory. Для этого в обязательном порядке необходимо синхронизировать время на всех серверах.

Остался последний этап – отображать красивую статистику посещений сайтов пользователями. Самый простой и красивый инструмент для этого – LightSquid.

Очень хочется чтобы в отчете фигурировало полное ФИО пользователя, а не доменное имя или IP-адрес. Для этого нужно заменить оригинальный файл /usr/share/lightsquid/ip2name/ip2name.squidauth следующим:

#contributor: esl
#specialy for squid with turned on user authentication
#simple version

use strict;
use warnings;
use Net::LDAP;
use Encode;

my $ldap;
my $message;
my %hDisplayName;

sub StartIp2Name() {
        my $server = "ldap://dc.mydomain.ru";
        $ldap = Net::LDAP->new( $server );
        return if(!defined $ldap);
        $message = $ldap->bind(q(MYDOMAIN.RULightSquid), password => "PASSWORD");
}

sub Ip2Name($$$) {
  # $Lhost,$user,$Ltimestamp
  my $Lhost=shift;
  my $user =shift;
  $user    =URLDecode($user); #decode user name
  return $Lhost if ($user eq "-");
  return $user if (!defined $ldap);
  return $user if ($message->code());

  if (!defined $hDisplayName{$user})
  {
    my $result = $ldap->search(
    base        => "dc=MYDOMAIN,dc=RU",
    filter      => "(&(objectCategory=person)(objectClass=user)(sAMAccountName=" . $user . "))",
    );

my $first_entry = $result->entry(0);
if (!defined $first_entry)
  {
    return $Lhost;
  }

my $pure_displayName = $first_entry->get_value("displayName");
$pure_displayName =~ s/ /_/g;
Encode::from_to($pure_displayName, 'utf-8', 'windows-1251');

  $hDisplayName{$user}=$pure_displayName;
  }

  return $hDisplayName{$user};
}

sub StopIp2Name() {
        return if (!defined $ldap);
        $message = $ldap->unbind;
}

#warning !!!
1;

В этом файле исправляем нижеуказанные строки на свои:

...
        my $server = "ldap://dc.mydomain.ru";
...
        $message = $ldap->bind(q(MYDOMAIN.RULightSquid), password => "PASSWORD");
...
    base        => "dc=MYDOMAIN,dc=RU",
...

Теперь в /etc/lightsquid/lightsquid.cfg включаем преобразование логина в ФИО:

$ip2name="squidauth"

Запускаем /usr/share/lightsquid/check-setup.pl и если все хорошо, можно запускать /usr/share/lightsquid/lightparser.pl

В папке /var/lib/lightsquid/report должны появиться отчеты, которые можно поглядеть по адресу: http://192.168.1.1/lightsquid/

Блог системного интегратора

Squid вполне может служить бесплатной альтернативой коммерческим прокси-серверам в небольших сетях. В Интернете есть достаточное количество руководств по интеграции Squid с Active Directory, настройке контроля доступа и другим вопросам. Опыт показывает, что зачастую руководства эти содержат неточности, даже ошибки, иногда прямо противоречат друг другу – отчасти потому, что операционная система и Squid имеют огромное количество настроечных параметров, и одни и те же задачи можно решать несколькими способами.

Статья описывает минимальную рабочую конфигурацию прокси Squid на CentOS Stream 8 в связке с Windows Server 2022 Active Directory, с авторизацией Kerberos, NTLM и, опционально, LDAP.

1.    Описание среды

·         Домен Active Directory – papa.local (NetBIOS имя PAPA), ОС контроллеров домена – Windows Server 2022 Datacenter Edition, функциональные уровни домена и леса – Windows Server 2022;

·         Подсеть – 192.168.44.0/24, шлюз по умолчанию – 192.168.44.2;

·         Контроллеры домена – cntr-dc2.papa.local (IP-адрес 192.168.44.12) и cntr-dc4.papa.local (IP-адрес 192.168.44.28); мастер всех операций – cntr-dc4.papa.local;

·         Службы DNS и WINS (для совместимости) размещены на контроллерах домена;

·         Сервер Squid с одним сетевым интерфейсом, ОС – CentOS Stream 8, имя хоста – cntr-gate4.papa.local, IP-адрес – 192.168.44.35;

·         В домене AD для авторизации Squid создан специальный пользователь PAPAsquid (UPN squid@papa.local) с достаточно стойким паролем без ограничения срока действия, учетная запись размещена в OU Papa.local/Special;

·         Вся инфраструктура – виртуальная Hyper-V (в принципе, это неважно).

Похожее:  Управляющие компании ЖКХ и ТСЖ в Похвистнево

2.    Установка CentOS

Установка со стандартного дистрибутива CentOS Stream 8, вариант установки – Minimal Install, задаем пароль для root:

Интеграция squid c MS Active Directory / Хабр

Задаем IP-адрес, шлюз по умолчанию и серверы DNS – контроллеры домена, имя хоста cntr-gate4.papa.local и суффикс поиска DNS papa.local :

Интеграция squid c MS Active Directory / Хабр

Задаем NTP-серверы – используем службу NTP контроллеров домена, временная зона Europe/Moscow:

Интеграция squid c MS Active Directory / Хабр
Интеграция squid c MS Active Directory / Хабр

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

3.    Предварительная конфигурация и установка Squid

Обновляем систему:

dnf update

Устанавливаем ntpstat и проверяем синхронизацию времени:

dnf install ntpstat

ntpstat

chronyc sources -v

Должны увидеть успешную синхронизацию времени:

Интеграция squid c MS Active Directory / Хабр

Добавляем разрешение порта 3128/tcp для прокси Squid:

firewall-cmd –permanent –add-port=3128/tcp

firewall-cmd –reload

Устанавливаем Squid (для нашей конфигурации достаточно готового пакета из репозитария):

dnf install squid

Объявляем в /etc/squid/squid.conf нашу сеть как локальную:

acl localnet src 192.168.44.0/24

Включаем службу Squid для автоматического запуска:

systemctl enable squid –now

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

Сначала мы должны подготовить файл ключей (keytab) для Kerberos. Для этого запускаем на контроллере домена следующую команду:

ktpass /princ HTTP/cntr-gate4.papa.local@PAPA.LOCAL /mapuser squid@PAPA.LOCAL /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass “password” /out proxy.keytab

Регистр символов важен! Пароль указывается в двойных кавычках, значение “password“ взято для примера. Результирующий файл proxy.keytab необходимо скопировать в каталог /etc/squid на системе CentOS (cntr-gate4.papa.local).

Учетная запись PAPAsquid в AD выглядит так:

Интеграция squid c MS Active Directory / Хабр

Все остальное делается на системе CentOS. Устанавливаем необходимые пакеты для поддержки Kerberos:

dnf install cyrus-sasl-gssapi krb5-workstation krb5-devel

Теперь редактируем файл конфигурации Kerberos /etc/krb5.conf. У меня файл получился такой:

# To opt out of the system crypto-policies configuration of krb5, remove the

# symlink at /etc/krb5.conf.d/crypto-policies which will not be recreated.

includedir /etc/krb5.conf.d/

[logging]

   default = FILE:/var/log/krb5libs.log

   kdc = FILE:/var/log/krb5kdc.log

   admin_server = FILE:/var/log/kadmind.log

[libdefaults]

   dns_lookup_realm = false

   ticket_lifetime = 24h

   renew_lifetime = 7d

   forwardable = true

   rdns = false

   pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt

   spake_preauth_groups = edwards25519

   default_realm = PAPA.LOCAL

   default_ccache_name = KEYRING:persistent:%{uid}

[realms]

PAPA.LOCAL = {

   kdc = cntr-dc2.papa.local

   kdc = cntr-dc4.papa.local

   admin_server = cntr-dc2.papa.local

   admin_server = cntr-dc4.papa.local

}

[domain_realm]

   .papa.local = PAPA.LOCAL

   papa.local = PAPA.LOCAL

После правки файла /etc/krb5.conf перегружаем систему командой reboot.

Теперь нужно проверить корректность работы Kerberos. Для этого, получаем билеты от KDC и проверяем результат (я для примера сначала использую встроенную учетную запись администратора домена AD, но это не обязательно):

kinit Administrator

klist

kinit -V -k -t /etc/squid/proxy.keytab HTTP/cntr-gate4.papa.local@PAPA.LOCAL

klist

Если мы все сделали правильно, то должны увидеть что-то, похожее на это:

Интеграция squid c MS Active Directory / Хабр

Файл ключей proxy.keytab критичен с точки зрения безопасности системы. Поскольку он предназначен специально для сервиса Squid, ограничиваем доступ к нему только для учетной записи службы:

chown squid:squid /etc/squid/proxy.keytab

chmod 400 /etc/squid/proxy.keytab

Теперь можно править файл конфигурации Squid. Модифицируем /etc/squid/squid.conf, для поддержки обязательной аутентификации Kerberos добавляем в него следующие строки:

auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -k /etc/squid/proxy.keytab -s HTTP/cntr-gate4.papa.local@PAPA.LOCAL

auth_param negotiate children 100 startup=0 idle=10

auth_param negotiate keep_alive on

acl authenticated_user proxy_auth REQUIRED

http_access deny !authenticated_user

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

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

service squid restart

Настройка авторизации Kerberos на этом закончена.

5.    Настройка NTLM

Так или иначе, обычно этот старый протокол в доменной среде до сих пор используется, несмотря на его очевидные недостатки. Поэтому, здесь описывается рабочая конфигурация для NTLM тоже. Для поддержки NTLM, мы используем связку Samba/Winbind.

Устанавливаем необходимые пакеты для поддержки Samba и Winbind:

dnf install samba samba-client samba-winbind samba-winbind-clients krb5-workstation

Включаем необходимые службы:

systemctl enable smb

systemctl enable nmb

systemctl start smb

systemctl start nmb

Теперь редактируем файл конфигурации Samba /etc/samba/smb.conf для членства в домене. У меня файл получился такой:

# See smb.conf.example for a more detailed config file or

# read the smb.conf manpage.

# Run ‘testparm’ to verify the config is correct after

# you modified it.

[global]

   workgroup = PAPA

   password server = cntr-dc4.papa.local

   realm =PAPA.LOCAL

   security = ads

   idmap uid = 10000-20000

   idmap gid = 10000-20000

   winbind use default domain = no

   winbind request timeout = 300

   wins server = 192.168.44.28

   passdb backend = tdbsam

   printing = cups

   printcap name = cups

   load printers = yes

   cups options = raw

[homes]

   comment = Home Directories

   valid users = %S, %D%w%S

   browseable = No

   read only = No

   inherit acls = Yes

[printers]

   comment = All Printers

   path = /var/tmp

   printable = Yes

   create mask = 0600

   browseable = No

[print$]

   comment = Printer Drivers

   path = /var/lib/samba/drivers

   write list = @printadmin root

   force group = @printadmin

   create mask = 0664

   directory mask = 0775

Включаем систему в домен, используя учетную запись Active Directory с правом добавления компьютеров. У меня это встроенная учетная запись администратора:

net ads join -U Administrator

Вводим пароль и проверяем членство в домене:

net ads testjoin

Если мы все сделали правильно, то должны увидеть “Join is OK”:

Интеграция squid c MS Active Directory / Хабр

при этом, в домене AD (по умолчанию в стандартном контейнере Computers) должен создаться объект компьютера для CNTR-GATE4.

Перестартуем службы Samba и включаем Winbind:

systemctl restart smb

Похожее:  Что такое mi аккаунт, как зарегистрировать и для чего он нужен в xiaomi - MIUI помощь - Mi Community - Xiaomi

systemctl restart nmb

systemctl enable winbind

systemctl start winbind

Проверяем функциональность Winbind:

wbinfo -g

wbinfo -u

Должны увидеть что-то похожее на это:

Интеграция squid c MS Active Directory / Хабр

Интеграция squid c MS Active Directory / Хабр

(это мои примеры. В любом случае, это должны быть валидные списки групп и пользователей домена).

Теперь можно править файл конфигурации Squid. Модифицируем /etc/squid/squid.conf, для поддержки аутентификации NTLM добавляем в него следующие строки:

auth_param ntlm program /usr/bin/ntlm_auth –helper-protocol=squid-2.5-ntlmssp –domain=PAPA

auth_param ntlm children 100 startup=0 idle=10

auth_param ntlm keep_alive off

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

service squid restart

Настройка авторизации NTLM закончена.

6.    Настройка LDAP (опционально)

Squid позволяет настроить авторизацию также и по протоколу LDAP. В данном примере, доступ предоставляется для членов группы безопасности AD InternetAccess в домене papa.local с помощью стандартного helper’а ext_ldap_group_acl. Для этого в конфигурацию Squid необходимо добавить следующие строки:

external_acl_type ldap_group %LOGIN /usr/lib64/squid/ext_ldap_group_acl -R -b “dc=papa,dc=local” -D “cn=squid,ou=special,dc=papa,dc=local” -K -W /etc/squid/password.txt -f “(&(objectclass=person) (sAMAccountname=%u)(memberof=cn=%g,cn=users,dc=papa,dc=local))” -h cntr-dc4.papa.local

acl InternetAccess external ldap_group InternetAccess

http_access allow InternetAccess all

Для LDAP-запросов к AD здесь мы используем учетную запись PAPAsquid с паролем (можно использовать и другую – право на чтение LDAP в домене по умолчанию имеет любая запись рядового пользователя в группе Domain Users). В данном примере пароль указан в дополнительном файле /etc/squid/password.txt открытым текстом, без символа перевода строки. Файл можно создать в любом текстовом редакторе (вроде vi /etc/squid/password.txt). Из соображений безопасности, доступ к нему следует ограничить для учетной записи службы:

chown squid:squid /etc/squid/password.txt

chmod 400 /etc/squid/password.txt

Альтернативно, можно указать пароль с ключом -W в хелпере прямо в файле /etc/squid/squid.conf, но это небезопасно – пароль здесь необходимо указывать открытым текстом.

После внесения изменения в конфигурацию, Squid необходимо перезапустить:

service squid restart

Одно замечание – пароль в запросах LDAP для учетной записи PAPAsquid до контроллера домена здесь передается по сети открытым текстом. А это может быть риском.

7.    Настройка доступа для группы Active Directory с авторизацией NTLM и Kerberos

Выше были описаны базовые настройки авторизации по Kerberos и NTLM. Чтобы ограничить доступ в Интернет для членов определенной группы (здесь это PAPAInternetAccess, как в примере для LDAP), необходимо прописать следующие строки в /etc/squid/squid.conf:

external_acl_type InternetAccess_from_ad_krb ttl=300 negative_ttl=60 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -g InternetAccess@PAPA.LOCAL

external_acl_type InternetAccess_from_ad_ntlm %LOGIN /usr/lib64/squid/ext_wbinfo_group_acl -d

acl InternetAccess_acl_krb external InternetAccess_from_ad_krb

acl InternetAccess_acl_ntlm external InternetAccess_from_ad_ntlm InternetAccess

8.    Базовая аутентификация

Squid поддерживает также базовую аутентификацию с передачей пароля открытым текстом. По понятным причинам, этого лучше не делать, и в этой статье данный метод не рассматривается. Рабочий проверенный пример конфигурации для Squid можно взять здесь (применительно к ПО Kaspersky Web Traffic Security): “Приложение 2. Настройка интеграции сервиса Squid с Active DirectoryНастройка Basic-аутентификации”, https://support.kaspersky.com/KWTS/6.1/ru-RU/166445.htm.

9.    Файлы конфигурации для примера из статьи

В приложении (config.7z) собраны рабочие примеры файлов конфигурации для тестовой среды, описанной в статье. Можно использовать AS IS и править:

chrony.conf (/etc/chrony.conf) – файл конфигурации NTP;

resolv.conf (/etc/resolv.conf) – файл конфигурации распознавателя DNS;

krb5.conf (/etc/krb5.conf) – файл конфигурации Kerberos;

smb.conf (/etc/samba/smb.conf) – файл конфигурации Samba;

squid.conf (/etc/squid/squid.conf) – файл конфигурации Squid. Этот пример содержит минимальные настройки для работоспособной авторизации Kerberos и NTLM для неограниченного доступа через Squid для группы безопасности AD PAPAInternetAccess;

squid_ldap.conf (/etc/squid/squid.conf) – вариант аналогичной конфигурации Squid для работоспособной авторизации LDAP;

kt_pass.cmd – пример команды, выполняемой на контроллере домена AD для генерации файла ключей keytab для CentOS прокси.

Ссылка на конфигурацию:

Config.7z

Альтернативная ссылка на конфигурацию:

https://disk.yandex.ru/d/70jIXe7V3yprGQ

Использование ldap групп из active directory

Собственно, для чего нам использовать LDAP группы из Active Directory? Мы же можем просто составить необходимые списки acl с внесением туда пользователей, например

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

Конфигурация сети следующая:

Настройка active directory для использования групп

настройка пользователя Active Directory для LDAP из squid По умолчанию, в AD запрещено анонимным пользователям получать какую-либо информацию из каталога. Для того, чтобы squid хелпер  squid_ldap_group

 имел право обращаться к

каталогу Active Directory

и извлекать некую информацию из доменной структуры, необходимо хелперу предоставить некие учетные данные для доступа к LDAP. Для этого я в домене создал учетку с минимально необходимыми правами (членство в группе

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

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

Настройка squid на kerberos аутентификацию

Настройку squid на Kerberos аутентификацию необходимо сделать, согласно статьи Negotiate – метод аутентификации в squid. После настройки Kerberos аутентификации у нас начинает работать некий прокси-сервер squid, который аутентифицирует доменных пользователей. Предположим, что он имеет некий конфиг:

Связь хелпера squid_ldap_group с active directory

Нижеприведенная команда была сгруппирована из различных источников в сети, поэтому некоторые параметры останутся без четкого описания (как это не печально…).

Рассмотрим пример установки тестовой связи хелпера squid_ldap_group с каталогом LDAP AD:

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 4,00 из 5)
Загрузка...

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

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

Adblock
detector