Hlavní navigace

Integrace SQUID proxy serveru do Active Directory (2)

Dnes nás čeká pokračování integrace našeho proxy serveru do Active Directory. Dokončíme konfiguraci autentizací proti AD na všechny způsoby a podíváme se konečně na Squid, Sambu a nakonec dojde i na HTTP server dle vlastního výběru. Na konci tohoto dílu byste měli mít připravené plně funkční řešení.
Daniel Mašek
Doba čtení: 7 minut

Sdílet

Kerberos – dokončení konfigurace

Navážeme tam, kde jsme minule skončili. Máme stažený Msktutil pro naši architekturu (na výběr máme amd64 nebo i386, já použiji i386) a balíček si nainstalujeme.

# dpkg -i msktutil_0.4-2_i386.deb

Teď nastal čas si zažádat AD o autorizaci, abychom mohli vytvořit účet počítače pro účely autentizace přes Kerberos. Z důvodů, které jsou popsány v mailing listu Squidu, nyní nepoužíváme jako hostname proxy.domain.internal, ale v minulém díle zmíněný PROXY-K. Důvodem je Samba (potažmo zřejmě Winbind), která pravidelně mění heslo účtu počítače a nám by tím neustále zneplatňovala uložený klíč Kerberose.

# kinit administrator
Password for administrator@DOMAIN.INTERNAL:

a zkontrolujeme

# klist

Pokusíme se založit první účet počítače. Podmínkou je také maximální délka 15 znaků. Poslední parametr --enctypes 28 je nutný pouze pro verzi AD 2008.

# msktutil -c -b "CN=COMPUTERS" -s HTTP/proxy.domain.internal -k /etc/squid3/PROXY.keytab --computer-name PROXY-K \
--upn HTTP/proxy.domain.internal --server eupdc1.domain.internal --verbose --enctypes 28

Také existuje možnost, kdy si účet založíme přímo na Windows serveru a pak ho reinicializujeme a exportujeme keytab.

Co vlastně msktutil umí?

  • vytvářet účet PC v AD a měnit jeho heslo
  • ukládat klíče pro Kerberos a provádět údržbu keytab

Účet počítače v Active Directory, zde je možno ho ručně vytvořit i resetovat

Pokud vše proběhlo dobře, máme v souboru /etc/squid3/PROXY.keytab klíče. Zajistíme si, aby mohl Squid soubor číst.

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

Odhlásíme se.

# kdestroy

Jako test funkčnosti můžeme resetovat na Windows serveru účet počítače a zkusit aktualizovat keytab. Pozor, hostname malými písmeny.

# msktutil --auto-update --verbose --computer-name proxy-k -k /etc/squid3/PROXY.keytab

Čas od času je potřeba aktualizovat účet hosta v AD, proto si do /etc/crontab přidáme to, co jsme si teď vyzkoušeli

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

Posledním úkolem u konfigurace Kerberose je říci Squidu, kde najde keytab.

# echo "export KRB5_KTNAME=/etc/squid3/PROXY.keytab" | tee /etc/default/squid3

NTLM

Nastal čas doinstalovat Sambu a Winbind, ten nám zajistí NTLM autentizaci.

# apt-get install samba winbind samba-common-bin

a pro jistotu je zatím zastavíme

# service smbd stop
    smbd stop/waiting
# service winbind stop
    * Stopping the Winbind daemon winbind                  [ OK ]

následně upravíme sekci [global] v /etc/samba/smb.conf

#GLOBAL PARAMETERS
[global]
workgroup = DINTERNAL
realm = DOMAIN.INTERNAL
preferred master = no
server string = squid proxy server
security = ADS
encrypt passwords = yes
log level = 3
log file = /var/log/samba/%m
max log size = 50
printcap name = cups
printing = cups
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes
winbind nested groups = Yes
winbind trusted domains only = Yes
winbind cache time = 3600
winbind separator = +
;template primary group = “Domain Users”
template shell = /bin/bash

a přidáme náš server do domény

# net ads join -U Administrator

Úspěch tohoto kroku poté ověříme spuštěním obou služeb a použitím následujícího příkazu. Zde by neměl být žádný problém.

# wbinfo -t
checking the trust secret for domain DINTERNAL via RPC calls succeeded

Pokus o ověření standardním doménovým uživatelem user vypadá také pořádku.

# wbinfo -a user --verbose
Enter user's password:
plaintext password authentication succeeded
Enter user's password:
challenge/response password authentication succeeded

Teď ještě přidáme proxy do skupiny winbindd_priv, aby mohla číst z adresáře  /var/run/samba/winbindd_privileged.

# gpasswd -a proxy winbindd_priv

A posledním krokem u konfigurace NTLM je zabezpečení pravidelné aktualizace hesla u našeho druhého účtu hosta. Některé zdroje uvádí, že to Samba dělá samostatně, častější změnou každopádně ničemu neuškodíme. Vložíme opět do /etc/crontab.

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

Basic autentizace

Základní ověřování používá protokol LDAP a pro jeho účely si musíme nachystat uživatelský účet v doméně. Tento nebude vyžadovat žádná speciální oprávnění, naopak, měl by mít práva co nejmenší, protože jde pouze o možnost číst údaje o objektech v AD. Dále je potřeba nastavit, aby mu nevypršelo heslo, protože ho budeme mít staticky uložené v souboru na našem proxy serveru. V našem případě se bude jmenovat prostě  user.

Vhodné nastavení uživatele v AD, možná by stačilo členství i v Domain Guests

Vytvoříme soubor s heslem a nastavíme odpovídající oprávnění pro přístup.

# echo 'tajne_HeSlo987*#' > /etc/squid3/ldappass.txt
# chmod o-r /etc/squid3/ldappass.txt
# chgrp proxy /etc/squid3/ldappass.txt

A celé to musíme zabalit

Wrapper bude nutné zkompilovat ze zdrojových kódů, ale nejdříve potřebujeme hlavičkové soubory jádra.

# apt-get install build-essential linux-headers-$(uname -r)

pak na něj konečně přijde řada

# 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

Squid už jsme si nainstalovali v minulém díle, teď nás tedy čeká úprava jeho konfigurace v souboru /etc/squid3/squid.conf

### Negotiate Kerberos a NTLM autentizace
auth_param negotiate program /usr/local/bin/negotiate_wrapper -d --ntlm /usr/bin/ntlm_auth --diagnostics --helper-protocol=squid-2.5-ntlmssp --domain=DINTERNAL --kerberos /usr/lib/squid3/squid_kerb_auth -d -s GSS_C_NO_NAME
auth_param negotiate children 10
auth_param negotiate keep_alive off

### NTLM autentizace
auth_param ntlm program /usr/bin/ntlm_auth --diagnostics --helper-protocol=squid-2.5-ntlmssp --domain=DINTERNAL
auth_param ntlm children 10
auth_param ntlm keep_alive off

### Basic autentizace přes LDAP
auth_param basic program /usr/lib/squid3/squid_ldap_auth -R -b "dc=DOMAIN,dc=INTERNAL" -D user@domain.internal -W /etc/squid3/ldappass.txt -f sAMAccountName=%s -h eupdc1.europapier.internal
auth_param basic children 10
auth_param basic realm Internet Proxy
auth_param basic credentialsttl 1 minute

### definujeme si access list pro autentizační metody
acl auth proxy_auth REQUIRED

### a konečně vynutíme ověřování klientů
http_access deny !auth
http_access allow auth
### tohle bude vždy na konci http_access
http_access deny all

Jde o velice minimalistickou konfiguraci vhodnou na začátek při testování funkce proxy serveru. S pomocí acl lze přesně definovat přístupy uživatelů, lze použít i externí přístupové skupiny přímo z Active Directory a ošetřit výjimky. Toto téma by vydalo na další případný článek. Po úpravách si spustíme/restartujeme náš Squid.

# service squid3 restart
    squid3 stop/waiting
    squid3 start/running, process 8688

A teď se vyzkoušíme připojit z nějaké doménové stanice na Internet s použitím našeho nového proxy serveru. Pokud se objeví hláška vyžadující přihlášení anebo se neobjeví nic a Internet stejně nejde, je něco špatně. (Tedy pokud jste si mezitím neukopli síťový kabel.) Při úspěšném připojení se následně podíváme do /var/log/squid3/access.log a pokud uvidíte například toto, máte vyhráno!

1347514512.995     43 192.168.21.52 TCP_MISS/200 1470 GET http://gidnes.cz/u/n4/shadeMid.gif masekd DIRECT/194.79.52.198 image/gif

Doménové jméno uživatele máme konečně v logu a teď si připravíme hezčí výstup.

Statistiky přístupů

Jak jsem na začátku slíbil, nastal váš čas na výběr oblíbeného web serveru. Já zvolil pro účely předvedení webfsd a document root nastavil na /var/www/html/. Pro analýzu logů je také celkem slušný výběr a my si ukážeme Sarg.

# apt-get install sarg

Konfigurace Sargu se usídlí v /etc/sarg, kde nás budou momentálně zajímat pouze soubory sarg.conf a sarg-reports.conf. Statistiky se pravidelně spouštějí cronem, a to už instalace zařídila za nás.

# sarg.conf
access_log /var/log/squid3/access.log
output_dir /var/www/html/squid-reports

Zde uvádím pouze upravené parametry pro správnou funkci, Sarg potřebuje vědet odkud vzít data a kam je zapsat. Nezapomeňte případně upravit oprávnění na zápis do output_dir. U souboru sarg-report.conf také není moc na vysvětlování.

# sarg-reports.conf
       SARG=/usr/bin/sarg
     CONFIG=/etc/sarg/sarg.conf
    HTMLOUT=/var/www/html/squid-reports
  PAGETITLE="Access Reports on $(hostname)"
    LOGOIMG=/squid-reports/images/sarg.png
   LOGOLINK="http://$(hostname)/"
      DAILY=Daily
     WEEKLY=Weekly
    MONTHLY=Monthly
EXCLUDELOG1="SARG: No records found"
EXCLUDELOG2="SARG: End"

Nebudeme čekat na cron, nějaká data v logu máme, vygenerujeme report hned.

tip_Ansible

# /usr/sbin/sarg-reports manual

Výstup poskytuje statistiky přístupů na jednotlivé stránky, TOP uživatele apod. Vše v přehledných tabulkách a grafech.

Náhled vygenerovaných reportů

Kam dál?

Tato ukázka je v podstatě pouze proof-of-concept, při reálném nasazení bychom se museli více zabývat zabezpečením, odladit výkonnostní parametry, mít přehled o SW vybavení na stanicích, které by mohlo mít problémy s tímto „omezením“ přístupu, ošetřit výjimky apod. Teď už ale víme, že to jde.

Použité zdroje informací