Авторизация в squid windows

Original work By Adrian Chadd, with updates by James Robertson on 19.01.2012
and Christopher Schirner on 11.11.2014

An alternate way to integrate with Active Directory is via Samba and NTLM

🔗 Introduction

This wiki page covers setup of a Squid proxy which will seamlessly
integrate with Active Directory using Kerberos, NTLM and basic
authentication for clients not authenticated via Kerberos or NTLM.

File paths and account user/group names will depend on
the specific operating system setup

🔗 Example Environment

the following examples are utilised, you should update any configuration
examples with your clients domain, hostnames, IP’s etc. where necessary.

  • Network
    • Domain= example.local
    • Subnet = 192.168.0.0/24
  • Proxy Server
    • OS = GNU/Linux
    • Squid 3.1
    • IP = 192.168.0.10
    • HOSTNAME = squidproxy.example.local
    • Kerberos computer name = SQUIDPROXY-K
  • Windows Server 1
    • IP = 192.168.0.1
    • HOSTNAME = dc1.example.local
  • Windows Server 2
    • IP = 192.168.0.2
    • HOSTNAME = dc2.example.local

🔗 Prerequisites

Client Windows Computers need to have Enable Integrated Windows
Authentication ticked in Internet Options ⇒ Advanced settings.

🔗 DNS Configuration

On the Windows DNS server add a new A record entry for the proxy
server’s hostname and ensure a corresponding PTR (reverse DNS) entry is
also created and works. Check that the proxy is using the Windows DNS
Server for name resolution and update /etc/resolv.conf accordingly.

Edit the file according to your network.

domain example.local
search example.local
nameserver 192.168.0.1
nameserver 192.168.0.2

Ping a internal and external hostname to ensure DNS is operating.

ping dc1.example.local -c 4 && ping google.com -c 4

Check you can reverse lookup the Windows Server and the local proxy ip
from the Windows DNS.

dig -x 192.168.0.1
dig -x 192.168.0.10

The ANSWER SECTION should contain the the DNS name of
dc1.example.local and squidproxy.example.local.

Important: If either lookup fails do not proceed until fixed or
authentication may fail.

🔗 NTP Configuration

Time needs to be syncronised with Windows Domain Controllers for
authentication, configure the proxy to obtain time from them and test to
ensure they are working as expected.

🔗 Install and Configure Kerberos

Install Kerberos packages — on Debian these are krb5-user libkrb53

Edit the file /etc/krb5.conf replacing the variables with the your
domain and servers.

Important: If you only have 1 Domain Controller remove the
additional kdc entry from the [realms] section, or add any
additional DC’s.

Depending on your Domain Controller’s OS Version uncomment the relevant
Windows 200X section and comment out the opposing section.

[libdefaults]
    default_realm = EXAMPLE.LOCAL
    dns_lookup_kdc = no
    dns_lookup_realm = no
    ticket_lifetime = 24h
    default_keytab_name = /etc/squid3/PROXY.keytab

; for Windows 2003
    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

; for Windows 2008 with AES
;    default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
;    default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
;    permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5

[realms]
    EXAMPLE.LOCAL = {
        kdc = dc1.example.local
        kdc = dc2.example.local
        admin_server = dc1.example.local
        default_domain = example.local
    }

[domain_realm]
    .example.local = EXAMPLE.LOCAL
    example.local = EXAMPLE.LOCAL

Important notice: One should use “Windows 2008 with AES” if
available. This is not just important for security reasons, but you
might also experience problems when using the DNS name of the squid
server instead of the IP address.

Example error messages regarding this issue may look like this:

ERROR: Negotiate Authentication validating user. Error returned 'BH gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information.'

🔗 Install Squid 3

We install squid 3 now as we need the squid3 directories available.
Squid configuration takes places after authentication is configured. On
Debian install the squid3 ldap-utils packages.

🔗 Authentication

The Proxy uses 4 methods to authenticate clients, Negotiate/Kerberos,
Negotiate/NTLM, NTLM and basic authentication. Markus Moellers
negotiate_wrapper is used for the 2 Negotiate methods.

🔗 Kerberos

Kerberos utilises msktutil an Active Directory keytab manager (I presume
the name is abbreviated for “Microsoft Keytab Utility”). We need to
install some packages that msktutil requires. On Debian install
libsasl2-modules-gssapi-mit libsasl2-modules

Install msktutil — you can find msktutil here
“http://fuhm.net/software/msktutil/releases/”

Initiate a kerberos session to the server with administrator permissions
to add objects to AD, update the username where necessary. msktutil will
use it to create our kerberos computer object in Active directory.

It should return without errors. You can see if you succesfully obtained
a ticket with:

Now we configure the proxy’s kerberos computer account and service
principle by running msktutil (remember to update the values with
yours).

Important: There are 2 important caveats in regard to the msktutils
–computer-name argument:
— -computer-name cannot be longer than 15 characters due to netbios name
limitations. See this link and this link for further information.
— -computer-name must be different from the proxy’s hostname so computer
account password updates for NTLM and Kerberos do not conflict, see this
link
for further information. This guide uses -k appended to the hostname.

Execute the msktutil command as follows:

msktutil -c -b "CN=COMPUTERS" -s HTTP/squidproxy.example.local -k /etc/squid3/PROXY.keytab \
    --computer-name SQUIDPROXY-K --upn HTTP/squidproxy.example.local --server dc1.example.local --verbose

If you are using a Server 2008 domain then add
--enctypes 28 at the end of the command

Pay attention to the output of the command to ensure success, because we
are using –verbose output you should review it carefully.

Set the permissions on the keytab so squid can read it.

chgrp proxy /etc/squid3/PROXY.keytab
chmod g+r /etc/squid3/PROXY.keytab

Destroy the administrator credentials used to create the account.

On the Windows Server reset the Computer Account in AD by right clicking
on the SQUIDPROXY-K Computer object and select “Reset Account”, then run
msktutil as follows to ensure the keytab is updated as expected and that
the keytab is being sourced by msktutil from /etc/krb5.conf correctly.
This is not completely necessary but is useful to ensure msktutil works
as expected. Then run the following:

msktutil --auto-update --verbose --computer-name squidproxy-k

Even though the account was added in capital letters, the
--auto-update in msktutil requires the --computer-name to be lower
case.

If the keytab is not found try adding -k /etc/squid3/PROXY.keytab to
the command to see if it works and then troubleshoot until resolved or
users will not be able to authenticate with Squid.

Add the following to cron so it can automatically updates the computer
account in active directory when it expires (typically 30 days). Pipe it
through logger so I can see any errors in syslog if necessary. As stated
msktutil uses the default /etc/krb5.conf file for its paramaters so be
aware of that if you decide to make any changes in it.

00 4  *   *   *     msktutil --auto-update --verbose --computer-name squidproxy-k | logger -t msktutil

Edit squid3’s init script to export the KRB5_KTNAME variable so squid
knows where to find the kerberos keytab.

On Debian the simplest way to do that is as follows:

Add the following configuration to /etc/default/squid3

KRB5_KTNAME=/etc/squid3/PROXY.keytab
export KRB5_KTNAME

🔗 NTLM

Install Samba and Winbind. On Debian install samba winbind samba-common-bin

Stop the samba and winbind daemons and edit /etc/samba/smb.conf

workgroup = EXAMPLE
security = ads
realm = EXAMPLE.LOCAL

winbind uid = 10000-20000
winbind gid = 10000-20000
winbind use default domain = yes
winbind enum users = yes
winbind enum groups = yes

Now join the proxy to the domain.

net ads join -U Administrator

Start samba and winbind and test acces to the domain.

This command should output something like this:

checking the trust secret for domain EXAMPLE via RPC calls succeeded

wbinfo -a EXAMPLE\\testuser%'password'

Output should be similar to this.

plaintext password authentication succeeded
challenge/response password authentication succeeded

Set Permissions so the proxy user account can read
/var/run/samba/winbindd_privileged

gpasswd -a proxy winbindd_priv
  • on Debian an Ubuntu systems there may also be a
    /var/lib/samba/winbindd_privileged directory created by the
    winbind and ntlm_auth tools with root ownership. The group of that
    folder needs to be changed to match the
    /var/run/samba/winbindd_privileged location.

append the following to cron to regularly change the computer account
password (Samba might do this automatically, check Samba documentation)

    05  4  *   *   *     net rpc changetrustpw -d 1 | logger -t changetrustpw

🔗 Basic

In order to use basic authentication by way of LDAP we need to create an
account with which to access Active Directory.

In Active Directory create a user called “Squid Proxy” with the logon
name squid@example.local.

Ensure the following is true when creating the account:

  • User must change password at next logon Unticked
  • User cannot change password Ticked
  • Password never expires Ticked
  • Account is disabled Unticked

Create a password file used by squid for ldap access and secure the file
permissions (substitute the word “squidpass” below with your password).

echo 'squidpass' > /etc/squid3/ldappass.txt
chmod o-r /etc/squid3/ldappass.txt
chgrp proxy /etc/squid3/ldappass.txt

🔗 Install negotiate_wrapper

Firstly we need to install negotiate_wrapper. Install the necessary
build tools on Debian intall build-essential linux-headers-$(uname -r)
Then compile and install.

cd /usr/local/src/
wget "http://downloads.sourceforge.net/project/squidkerbauth/negotiate_wrapper/negotiate_wrapper-1.0.1/negotiate_wrapper-1.0.1.tar.gz"
tar -xvzf negotiate_wrapper-1.0.1.tar.gz
cd negotiate_wrapper-1.0.1/
./configure
make
make install

🔗 squid.conf

Then setup squid and it’s associated config files.

Add the following to your squid.conf.

Study and update the following text carefully, replacing the example
content with your networks configuration — if you get something wrong
your proxy will not work.

### /etc/squid3/squid.conf Configuration File ####

### negotiate kerberos and ntlm authentication
auth_param negotiate program /usr/local/bin/negotiate_wrapper -d --ntlm /usr/bin/ntlm_auth --diagnostics --helper-protocol=squid-2.5-ntlmssp --domain=EXAMPLE --kerberos /usr/local/bin/squid_kerb_auth -d -s GSS_C_NO_NAME
auth_param negotiate children 10
auth_param negotiate keep_alive off

### pure ntlm authentication
auth_param ntlm program /usr/bin/ntlm_auth --diagnostics --helper-protocol=squid-2.5-ntlmssp --domain=EXAMPLE
auth_param ntlm children 10
auth_param ntlm keep_alive off

### provide basic authentication via ldap for clients not authenticated via kerberos/ntlm
auth_param basic program /usr/local/bin/squid_ldap_auth -R -b "dc=example,dc=local" -D squid@example.local -W /etc/squid3/ldappass.txt -f sAMAccountName=%s -h dc1.example.local
auth_param basic children 10
auth_param basic realm Internet Proxy
auth_param basic credentialsttl 1 minute

### acl for proxy auth and ldap authorizations
acl auth proxy_auth REQUIRED

### enforce authentication
http_access deny !auth
http_access allow auth
http_access deny all

⚠️ Disclaimer: Any example presented here is provided "as-is" with no support
or guarantee of suitability. If you have any further questions about
these examples please email the squid-users mailing list.

Categories: ConfigExample

Navigation: Site Search,
Site Pages,
Categories, 🔼 go up

Источник

Setting up authentication for your Squid proxy on Windows can help secure your network by ensuring that only authorized users can access the proxy. Here’s a step-by-step guide to configure basic authentication:

1. Install Necessary Tools

  1. Download and Install Squid: Ensure Squid is installed on your Windows system.
  2. Install Apache HTTP Server Tools: These tools include htpasswd, which is used to create and manage user credentials.

2. Create a Password File

  1. Open Command Prompt: Run it as an administrator.
  2. Navigate to Squid Directory: Change to the directory where Squid is installed.
  3. Create Password File: Use the htpasswd tool to create a password file. For example:
    htpasswd -c C:\Squid\etc\passwd username
    Replace username with the desired username. You will be prompted to enter and confirm a password.

3. Configure Squid for Authentication

  1. Open Squid Configuration File: Locate and open squid.conf in a text editor.
  2. Add Authentication Parameters: Add the following lines to configure basic authentication:
    auth_param basic program C:/Squid/libexec/basic_ncsa_auth.exe C:/Squid/etc/passwd
    auth_param basic children 5
    auth_param basic realm Squid proxy-caching web server
    auth_param basic credentialsttl 2 hours
    acl authenticated proxy_auth REQUIRED
    http_access allow authenticated
  3. Save and Close the File: Save the changes and close the text editor.

4. Restart Squid Service

  1. Open Services: Go to the Services management console.
  2. Restart Squid: Find the Squid service, right-click, and select “Restart”.

5. Test the Configuration

  1. Configure Browser: Set your web browser to use the Squid proxy.
  2. Access a Website: When prompted, enter the username and password you created.

By following these steps, you can successfully configure authentication for your Squid proxy on Windows, ensuring that only authorized users can access your network resources.

Источник

   В этой статье расскажу об установке и настройке Squid на контроллере домена на базе Windows 2008 R2. Помимо всего прочего реализована авторизация пользователей живущих в Active Directory и проверка нахождения их в определённой группе. Каждой группе назначены свои разрешения и доступные ресурсы.

   Чего стоило реализовать эту схему — лучше промолчать. Не смотря на то, что документации и готовых примеров в интернете пруд пруди, пришлось собирать мозаику из кучи источников что бы схема стала работоспособной. Изначально, хотелось реализовать авторизацию и проверку в группах через Kerberos, но на это у меня просто терпения не хватило. Затык наступил на создании .keytab файла.

   Ладно, начнём.

   Немного простонародной теории. По-умолчанию, после установки Squid, не важно на какой платформе, прохождение всего трафика разрешено. Плюс ко всему возможность авторизации в AD и запроса информации от туда, осуществляется так называемыми хелперами. Т. е. само приложение или демон Squid запускает другие приложения или скрипты для выполнения тех или иных действий. Речь о действиях, в нашем случае, идёт в AD. Для того чтобы запрашивать информацию в AD, необходимо это делать от имени пользователя, находящегося в AD. Поэтому плавно переходим к пратике с иллюстрациями.

   В первую очередь необходимо завести в Active Directory служебного пользователя, от имени которого хелперы будут выполнять действия в AD. Важной особенностью учётной записи является бессрочный пароль и невозможность смены пароля пользователем.

   Далее переходим к установке Squid. Дистрибутив Squid я брал на сайте, как мне казалось, разработчиков. Однако, в последствии выяснилось, что эти ребята только скомпилировали дистрибутив и не более того. Так что обращаться к ним за помощью бесполезно. Инсталлятор только для x64 систем. Версия Squid 3.5.20. По самой установке вопросов возникнуть не должно — запускаем инсталлятор от имени администратор и, как говорится, жмём Далее.

   Самое скучное позади. Поверь, мой друг, выполнив настройку по этому руководству, ты вряд ли ощутишь тоже самое, что и я. Когда все ссылки уже фиолетовые в поисковике, а ничего не получается. Куча литературы об одних и тех же вещах, но у всех по-разному реализовано. Хватит соплей, идём смотреть конфигу Squid. По-умолчанию она находится в C:\Squid\etc\squid\. Файл в котором находится основная конфигурация squid.conf. Его мы и откроем любым редактором. К счастью, начальная конфига без полного описания возможностей, поэтому в исключительный вид её привести будет не сложно. Я приведу пример уже готовой конфигурации с описанием. Конфигурация разделена на блоки для более лучшего понимания. Итак:

C:\Squid\etc\squid\squid.conf

#В этом блоке описан запуск хелпера отвечающего за проверку наличия пользователя в домене. Параметр -D указавает от какого пользователя мы запрашиваем информацию в AD, параметр -W — путь к файлу с паролем этого пользователя. Параметр -h — CD к которому подключается хелпер. -v — версия LDAP. Остальное не помню.
auth_param basic program C:/Squid/lib/squid/basic_ldap_auth.exe -R -v 3 -b «dc=pcs,dc=local» -D Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра. -W C:/Squid/etc/squid/pwd -f sAMAccountName=%s -h pcs.local
auth_param basic realm Enter your System LOGIN
auth_param basic children 5
auth_param basic credentialsttl 2 hours

 #В этом блоке запускается хелпер который проверяет нахождение в домене (-b), в группе (-f) пользователя. Расположение самой группы Сама группа находится в организационных еденицах (ou=). Остальные параметры идентичны хелперу basic_ldap_auth.exe.
external_acl_type ldap_group ttl=900 children-max=10 %LOGIN C:/Squid/lib/squid/ext_ldap_group_acl.exe -R -b «dc=pcs,dc=local» -f «(&(cn=%v)(memberOf=cn=%a,ou=Proxy,ou=System Accounts,ou=IT,ou=Office,ou=PCS,dc=pcs,dc=local))» -D «Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.» -w «Qwerty148635» -h pcs.local

#Дальше мы создаём ACL, для каждой группы в AD к которой мы будем применять правила выхода в интернет. Т. е. ACL inetf соответствует внешняя ACL ldap_group, которая содержит в себе ERR или OK для группы в AD.
acl inetf external ldap_group internetfull
acl inets external ldap_group internetshort

#Стандартный набор правил.
acl SSL_ports port 443
acl Safe_ports port 80
acl Safe_ports port 21
acl Safe_ports port 443
acl Safe_ports port 70
acl Safe_ports port 210
acl Safe_ports port 1025-65535
acl Safe_ports port 280
acl Safe_ports port 488
acl Safe_ports port 591
acl Safe_ports port 777
acl CONNECT method CONNECT

#Эта ACL с сетью из которых разрешеать или заперещать обращения.
ACL acl net src 192.168.0.0/16

#ACL со списком доменов
acl blacklist dstdomain «C:/squid/etc/squid/blacklist»

#ACL с типами файлов:
acl w_media urlpath_regex -i \.gif$ \.jpg$ \.png$ \.ico$ \.jpeg$ \.mp3$ \.mp4$ \.avi$ \.mkv$ \.bmp$

Далее следует список разрешающих и заперещающих правил. Последовательность имеет значение!

http_access deny net blacklist #Заперещает для всех сетей доступ к сайтам в файле C:/squid/etc/squid/blacklist
http_access deny inets w_media #Запрет для ACL inets контента, указанного в ACL w_media. По сути, эта ACL запрещает загрузку пользователям AD, находящимся в группе internetshort, указанных расширений файлов. Т. е. на web странице не будут отображаться картинки, значки, видео, аудио определённых форматов.

#Дальше идут пара общих разрешающих правил для доступа в интернет пользователям находящихся в группах AD (internetshort, internetfull)
http_access allow inets
http_access allow inetf

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

http_access deny all #И, наконец, общее запрещающее правило для всех остальных.

http_port 3128
coredump_dir C:/squid/var/cache/
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
dns_nameservers 192.168.83.5 10.100.0.10
max_filedescriptors 3200

   Всё это заработало, но с запросом логина и пароля. Запомнить его в браузере есть возможность, даже в старых. Однако, практический у всех, за исключением IE11, выходит запрос на подтверждение запомненного пароля. Т. е. пароль уже введён, осталось только нажать OK.

Самое большое разочарование после недельного мозгового штурма было после осознания того, что Squid ничего не петрит в кирилице!!! Сами хелперы без проблем видят учётки на кирилице, а 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

Картинка с сайта: www.k-max.name

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

Картинка с сайта: www.k-max.name

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

Картинка с сайта: www.k-max.name

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








Источник








 Обновлено: 

			 Опубликовано: 
		


Тематические термины: Squid, AD, CentOS.


Инструкция подразумевает, что у нас уже есть рабочий Squid-сервер. В противном случае, настраиваем, используя инструкцию Установка и настройка Squid на CentOS.


Наш сервер будет принимать как наиболее безопасную Kerberos-авторизацию, так и NTLM. Для компьютеров в домене будет поддерживаться прозрачная LDAP-аутентификация. Все команды выполняются на примере системы Linux CentOS 7.




Подготовка

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

    Имя сервера

Настройка на контроллере домена

    Создание учетной записи

    Создание keytab-файла

Настройка CentOS

    Kerberos

    NTLM

Настройка SQUID

Проверка

Авторизация на основе групп AD

Блокировка сайтов

Возможные ошибки

Читайте также




Подготовка


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


Интеграция с Active Directory требует минимального расхождения времени с контроллером домена. Устанавливаем утилиту chrony:


yum install chrony


Запускаем службу для синхронизации времени:


systemctl enable chronyd —now


Имя сервера


Задаем имя сервера следующей командой:


hostnamectl set-hostname proxy.domain.local


* где proxy — имя сервера; domain.local — доменное имя, используемое в сети.


Настройка на контроллере домена


Создание учетной записи


Открываем консоль управления пользователями и добавляем нового со стандартными правами. От этой учетной записи будут выполняться запросы к AD DS.


В своем примере мы создаем пользователя squid.


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


Создание keytab-файла


В двух словах, данный файл позволяет установить легитимность нашего Linux-сервера. Создается он на контроллере домена и копируется на последний.


Для создания файла переходим на контроллер домена и от имени администратора запускаем Powershell или обычную командную строку. Вводим:


ktpass /princ HTTP/proxy.domain.local@DOMAIN.LOCAL /mapuser squid@DOMAIN.LOCAL /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass «password» /out C:\proxy.keytab


* где proxy.domain.local — полное имя нашего squid-сервера; DOMAIN.LOCAL — наш домен; squid@DOMAIN.LOCAL — учетная запись в AD для выполнения запросов (создана на шаге выше); password — пароль, который будет задан пользователю (должен соответствовать требованию AD).

* регистр важен.


В нашем примере, после выполнения команды на контроллере домена в корне диска С появится файл proxy.keytab. Его копируем на Linux-сервер, например, при помощи WinSCP.


Настройка CentOS


Kerberos


Устанавливаем следующие пакеты:


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


Открываем конфигурационный файл Kerberos:


vi /etc/krb5.conf


Редактируем следующие строки:




[libdefaults]

  …

  default_realm = DOMAIN.LOCAL

  ..


[realms]

  DOMAIN.LOCAL = {

    kdc = 192.168.0.15

    kdc = 192.168.0.16

    kdc = 192.168.0.17

    admin_server = domain.local

  }




* DOMAIN.LOCAL — наш домен; kdc — перечень контроллеров домена; admin_server — первичный контроллер (в данном примере будет использоваться случайный).


Проверяем настройки krb, запросив тикет:


kinit domainuser


klist


При правильных настройках мы увидим на подобие:




Ticket cache: KEYRING:persistent:0:0

Default principal: domainuser@DOMAIN.LOCAL


Valid starting       Expires              Service principal

15.05.2018 10:08:33  15.05.2018 20:08:33  krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL

        renew until 22.05.2018 10:08:30




Проверяем keytab-файл, который мы перенесли на сервер с контроллера домена:


kinit -V -k -t /etc/squid/proxy.keytab HTTP/proxy.domain.local@DOMAIN.LOCAL


* где /etc/squid/proxy.keytab — путь до keytab-файла; HTTP/proxy.domain.local@DOMAIN.LOCAL — принципал, который был задан при создании файла.


И снова:


klist


Картина, примерно, следующая:




Ticket cache: KEYRING:persistent:0:krb_ccache_9MN6pt8

Default principal: HTTP/proxy.domain.local@DOMAIN.LOCAL


Valid starting       Expires              Service principal

16.05.2018 09:35:20  16.05.2018 19:35:20  krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL

        renew until 23.05.2018 09:35:20




Зададим файлу следующие права:


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


chmod u+rwx,g+rx /etc/squid/proxy.keytab


NTLM


Устанавливаем следующие пакеты:


yum install samba-winbind samba-winbind-clients pam_krb5 krb5-workstation


Конфигурируем 


authconfig —enablekrb5 —krb5kdc=domain.local —krb5adminserver=domain.local —krb5realm=domain.LOCAL —enablewinbind —enablewinbindauth —smbsecurity=ads —smbrealm=domain.LOCAL —smbservers=domain.local —smbworkgroup=domain —winbindtemplatehomedir=/home/%U —winbindtemplateshell=/bin/bash —enablemkhomedir —enablewinbindusedefaultdomain —update


* где domain.local — это наш домен, domain — домен в сокращенной нотации. Регистр важен.

* если после ввода команды мы увидим ошибку Job for winbind.service failed because the control process exited with error code. See «systemctl status winbind.service» and «journalctl -xe» for details — игнорируем ее. Она возникает из-за того, что наш сервер еще не в домене.


Добавляем сервер в домен:


net ads join -U administrator


* где administrator — учетная запись в AD с правами на ввод компьютеров в домен.


Разрешаем автозапуск winbind и запускаем его:


systemctl enable winbind


systemctl start winbind


Проверяем, что наш сервер умеет обращаться к службе каталогов:


wbinfo -t


wbinfo -g


* первая команда проверяет возможность отправлять запросы на контроллер домена; вторая — выводит список групп, находящихся в каталоге.


Настройка SQUID


Для скрипта запуска squid добавим следующее:


vi /etc/default/squid


KRB5_KTNAME=/etc/squid/proxy.keytab

export KRB5_KTNAME


* в данном случае, мы задаем переменную KRB5_KTNAME, в которой указан путь до кейтаб файла.


Открываем конфигурационный файл squid:


vi /etc/squid/squid.conf


И добавляем:




auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -d -s HTTP/proxy.domain.local@DOMAIN.LOCAL

auth_param negotiate children 20

auth_param negotiate keep_alive on


auth_param ntlm program /usr/bin/ntlm_auth —diagnostics —helper-protocol=squid-2.5-ntlmssp —domain=DOMAIN

auth_param ntlm children 10

auth_param ntlm keep_alive off




* где /usr/lib64/squid/negotiate_kerberos_auth — путь до библиотеки аутентификации по kerberos, ее путь может отличаться — это зависит от версии системы; HTTP/proxy.domain.local@DOMAIN.LOCAL — учетная запись в keytab.


Также настраиваем, чтобы squid требовал аутентификацию. Для этого в секции acl добавим:


acl auth proxy_auth REQUIRED


Далее это:


http_access allow localnet


Меняем на:


http_access allow auth


* в нашем случае acl localnet использовалась для предоставления доступа.


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


squid -k parse


И если ошибок нет:


squid -k reconfigure


Проверка


Для проверки на сервере открываем лог:


tail -f /var/log/squid/access.log | grep dmosk


* dmosk — учетная запись в AD, от которой будем проверять работу squid.


Теперь на клиентском компьютере заходим в систему под нашей учетной записью (в данном примере, dmosk) и грузим любой сайт.


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


1526474100.078    240 192.168.1.16 TCP_TUNNEL/200 934 CONNECT syndication.twitter.com:443 dmosk HIER_DIRECT/134.144.40.72 —

1526474100.743     45 192.168.1.16 TCP_TUNNEL/200 559 CONNECT login.vk.com:443 dmosk HIER_DIRECT/187.244.139.145 —


Авторизация на основе групп AD


Ранее, мы предоставили доступ к сети Интернет любому пользователю Active Directory. Теперь ограничим доступ с помощью групп AD DS.


Для начала, создаем 2 группы пользователей, например:


    

  1. squidusers. Пользователи squid, которым будет предоставлен доступ к сети Интернет с ограничениями.
    2. 

  2. squidsuperusers. Этим пользователям будет предоставлен неограниченный доступ.
    3. 



Теперь на прокси-сервере открываем конфигурационный файл squid:


vi /etc/squid/squid.conf


Добавляем после настройки аутентификации:


external_acl_type squid_users_from_ad_krb ttl=300 negative_ttl=60 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -g squidusers@DOMAIN.LOCAL

external_acl_type squid_superusers_from_ad_krb ttl=300 negative_ttl=60 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -g squidsuperusers@DOMAIN.LOCAL

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


* где 


    

  • squid_users_from_ad_krb — произвольное название acl, авторизованных пользователей в AD через kerberos, принадлежащих группе squidusers в домене DOMAIN.LOCAL.
    • 

  • squid_superusers_from_ad_krb — произвольное название acl, авторизованных пользователей в AD через kerberos, принадлежащих группе squidsuperusers в домене DOMAIN.LOCAL.
    • 

  • squid_users_from_ad_ntlm — произвольное название acl, авторизованных пользователей в AD через NTLM.
    • 



В секции acl:


#acl auth proxy_auth REQUIRED

acl squid_users_acl_krb external squid_users_from_ad_krb

acl squid_superusers_acl_krb external squid_superusers_from_ad_krb

acl squid_users_acl_ntlm external squid_users_from_ad_ntlm squidusers

acl squid_superusers_acl_ntlm external squid_superusers_from_ad_ntlm squidsuperusers


*  где 


    

  • squid_users_acl_krb — произвольное название acl для всех, кто входит в squid_users_from_ad_krb; 
    • 

  • squid_superusers_acl_krb — произвольное название acl для всех, кто входит в squid_superusers_from_ad_krb; 
    • 

  • squid_users_acl_ntlm — произвольное название acl для всех, кто входит в squid_users_from_ad_ntlm;
    • 

  • squid_superusers_acl_ntlm — произвольное название acl для всех, кто входит в squid_superusers_from_ad_ntlm;
    • 



* предыдущую acl для общей аутентификации комментируем.


В секции allow:




#http_access allow auth


http_access allow squid_superusers_acl_krb

http_access allow squid_superusers_acl_ntlm


http_access allow squid_users_acl_krb

http_access allow squid_users_acl_ntlm




* разрешаем доступ для созданных ранее acl; предыдущее разрешение для всех пользователей AD запрещаем. На данном этапе разницы между пользователями групп squidusers и squidsuperusers нет — позже мы настроим ограничение доступа к сайтам, где будем применять разные группы для предоставления различных прав.


Перечитываем конфигурацию прокси-сервера:


squid -k reconfigure


Ограничение доступа к сайтам


Мы рассмотрим простой пример блокировки двух сайтов. Доступ к ним будет ограничен в рабочее и ночное время для пользователей группы squidusers. Пользователи группы squidsuperusers будут иметь полный доступ ко всем сайтам.


Открываем конфигурационный файл squid:


vi /etc/squid/squid.conf


В разделе с ACL добавим 2 строки:


acl BLOCKED url_regex -i «/etc/squid/denysite»

acl BLOCKED_ACCESS time 18:00-23:59


* в данном примере мы создаем acl BLOCKED для сайтов, доступ к которым будем блокировать; список сайтов будем хранить в файле /etc/squid/denysite. Второй acl BLOCKED_ACCESS будем использовать для предоставления доступа к заблокированным сайтам, но с промежуток с 18:00 до 23:59.


Теперь преобразовываем к следующему виду, ранее созданные правила для доступа:




http_access allow squid_superusers_acl_krb

http_access allow squid_superusers_acl_ntlm


http_access allow BLOCKED BLOCKED_ACCESS

http_access deny BLOCKED


http_access allow squid_users_acl_krb

http_access allow squid_users_acl_ntlm




* как видим, мы добавили правила блокировки после пользователей группы squidsuperusers — таким образом, на последних они не будут распространяться. Данные правила разрешают заблокированные сайты в указанный ранее промежуток времени и блокируют доступ к сайтам, перечисленным в файле /etc/squid/denysite.


Создаем файл /etc/squid/denysite:


vi /etc/squid/denysite


facebook.com

vk.com


* в данном примере мы блокируем доступ к социальным сетям facebook и ВКонтакте.


Перечитываем конфигурацию squid:


squid -k reconfigure


Возможные ошибки


1. Password set failed! 0x00000020


Возникает при попытке создать keytab на контроллере домена.


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


Решение: перенесите учетную запись для связывания в подразделение, названное на латинице, например, CN=Users,dc=domain,dc=local.


Читайте также


Другие инструкции по SQUID, которые могут показаться интересными:


1. Установка и настройка SAMS2 на CentOS


2. Установка и настройка SARG для анализа логов SQUID на CentOS


3. Настройка SquidGuard на CentOS 7








Источник


	









    
    
    
    



    

                
Понравилась статья? Поделить с друзьями:

        
        

























    








    

    

            

            

            

                

                    0
                    0
                    голоса

                
Рейтинг статьи

                

            
    

                    

                            

            

                

                                            

                             Подписаться
                            
                        

                                            

                                                
                    

                

                                                    

                                                    

                                
Уведомить о 

                                

                                    
                                

                                                                    
                                                                    

                                    
                                

                                                            

                                                

                            

                                        

                                        

                        

                            

                                                                                                        

                                        guest                                    

                                                
                                        

                        

                    

                    
                                        
                    
                

                        

                
                    

                        

                

                    

                        0 комментариев                    

                                        

                    

                                                    

                                

                                                        

                                

                                                        

                                                                        Старые
                                                                        
                                

                                                                            Новые
                                                                                Популярные
                                                                        

                            

                                                

                

                

                    
 Межтекстовые Отзывы                     

                    
Посмотреть все комментарии

                

                                

                                        

                                            

                

            

                

        

    

    

    			
			

  • Как зашифровать usb флешку windows 10
    • 

  • Как запустить install windows
    • 

  • Как называется стандартная программа для просмотра изображений windows 10
    • 

  • Windows system32 ntkrnlpa exe
    • 

  • Ноутбук не видит принтер canon через usb windows 10
    •