Diff for "LinuxDebian/Squid/ntlm_auth_winbind"

Differences between revisions 2 and 3

Autenticatore ntlm_auth (fornito con Winbind)

Questo autenticatore non e` solo per squid, supporta diversi protocolli e puo` essere usato per autenticare un po` quello che volete su un dominio NT o AD tramite Winbind.

Funziona con qualsiasi server supportato da Winbind
E` parte di Samba, non di Squid, e si evolve con Samba
Lo si puo` usare non solo per Squid
Supporta limitazioni per gruppi
Permette di accedere anche a server AD (win2000 e successivi) pero` non supporta totalmente AD e Kerberos. Comunque funziona come autenticatore su win2008 senza problemi.

Configurazione di Samba

Posto che non vogliamo usare Samba per niente altro, ma solo come client (a mezzo winbind) per autenticare Squid, la configurazione minima e` questa:

workgroup = <DOMAIN NAME>
password server = *
security = domain
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind use default domain = yes

# cache dei gruppi a 30 secondi (default 300)
winbind cache time = 30

La riduzione del tempo di caching dei gruppi serve per evitare che quando si mette o toglie un utente da un gruppo debbano passare 5 minuti (piu` il tempo di cache interno di squid, che vedremo dopo) prima che la modifica venga recepita da Squid. Ovviamente meno cache usiamo e piu` stress mettiamo sul DC. Consideriamo che squid autentica OGNI RICHIESTA HTTP, e questo vuole dire decine di richieste per ogni pagina web visualizzata da un solo utente. La cache e` quindi fondamentale per motivi di performance.

Dopo aver fatto questa configurazione e riavviato samba, occorre joinare il server samba al dominio: net rpc join -UAdministrator%password

Se il join ha avuto successo, possiamo provare a leggere dati dal DC:

wbinfo -u (legge elenco utenti)
wbinfo -g (legge elenco gruppi)
wbinfo -r username (mostra a quali gruppi appartiene un utente. risponde numerico, e` normale)

Configurazione di Squid

Il minimo di configurazione richiede che il browser possa autenticarsi usando due schemi, NTLM e Plain. Il primo e` supportato da Explorer e il secondo da tutti gli altri.

###
### Autenticazione NTLM (la prima versione, quella commentata, richiede che l'utente sia membro di un gruppo specifico. La seconda no)
###
# auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp  --require-membership-of=<DOMAIN\\GRUPPO>
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 30


###
### Autenticazione Plain (la prima versione, quella commentata, richiede che l'utente sia membro di un gruppo specifico. La seconda no)
###
# warning: basic authentication sends passwords plaintext a network sniffer can and will discover passwords

#auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic  --require-membership-of=<DOMAIN\\GRUPPO>
auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic
auth_param basic children 5
auth_param basic realm Authenticated proxy
auth_param basic credentialsttl 30 minutes

###
### Questa ACL, chiamata domainusers, richiede che almeno una delle due autenticazioni indicate sopra dia risultato positivo.
###
acl domainusers proxy_auth REQUIRED

###
### Se ci basta l'autenticazione cosi` fatta, allora DOPO le varie righe che iniziano per "acl" mettiamo questo.
### Sta a indicare che il cliente deve essere nella lan locale (una acl che qui non e` indicata ma e` nella configurazione standard)
### e che deve anche essere autenticato.
###
http_access allow local_lan domainusers

Se vogliamo complicare la configurazione possiamo verificare l'appartenenza dell'utente a uno o piu` gruppi, e comportarci di conseguenza. Questo e` un esempio di ACL che fa uso dell'appartenenza di un utente ad un gruppo e permette potenzialmente di creare poi regole di accesso complesse, tipo "se sei in un gruppo certi siti sono consentiti altrimenti no". Sempre in squid.conf, possiamo mettere:

###
### autenticazione di un utente su un gruppo (ovvero, l'utente appartiene al gruppo?)
###

# questa riga indica a squid come usare un autenticatore esterno per verificare se un utente appartiene a un gruppo. 
# qui non e` indicato il gruppo, che viene indicato dopo nella relativa ACL.
external_acl_type testForGroup ttl=60 negative_ttl=60 %LOGIN /usr/lib/squid/wbinfo_group.pl

# L'utente appartiene al gruppo che si chiama "internet"? Se si`, allora la ACL di nome "inGroupInternet" e` true.
acl inGroupInternet external testForGroup internet

# Volendo potrei creare una seconda ACL che testa se l'utente appartiene al gruppo "unlimited_internet", per poi fare
# cose diverse
acl inGroupUnlimited_Internet external testForGroup unlimited_internet

###
### A questo punto, dopo le righe "acl", posso mettere delle regole di accesso che combinino le ACL fra di loro
### per consentire o negare l'accesso.
###

# qui consento l'accesso agli host della lan locale AND che sono autenticati come utenti
# AND che appartengono al gruppo "internet" sul dominio
http_access allow local_lan domainusers inGroupInternet

E` possibile mischiare anche blacklist e whitelist di siti con le ACL di autenticazione e appartenenza al gruppo, non ho pero` un esempio pronto.

Per testare l'autenticatore esterno dei gruppi (se ci fossero dubbi sul suo funzionamento) si puo` usare questo comando:

echo "USER GRUPPO" | /usr/lib/squid/wbinfo_group.pl -d

Esempio: l'utente test e` nel gruppo internet?
echo "test internet" | /usr/lib/squid/wbinfo_group.pl -d

Per ulteriori informazioni, vedasi:

Le faq di Squid: http://www.squid-cache.org/Doc/FAQ/FAQ-23.html
Il manuale di ntlm_auth (parte di samba_doc, un "locate ntlm_auth" aiuta)

-  ⇤ ← Revision 2 as of 2009-04-12 17:33:25 → 
  Size: 1728
  Editor: localhost
  Comment: converted to 1.6 markup
+   ← Revision 3 as of 2014-12-29 12:33:40 → ⇥
  Size: 5835
  Editor: Kurgan
  Comment:
-Deletions are marked like this.
+Additions are marked like this.
 Line 3:
-Questo autenticatore non e` solo per squid, supporta diversi protocolli e puo` essere usato per autenticare un po` quello che volete su un dominio NT tramite Winbind.
+Questo autenticatore non e` solo per squid, supporta diversi protocolli e puo` essere usato per autenticare un po` quello che volete su un dominio NT o AD tramite Winbind.
 Line 9:
+ * Permette di accedere anche a server AD (win2000 e successivi) pero` non supporta totalmente AD e Kerberos. Comunque funziona come autenticatore su win2008 senza problemi.
-Line 10:
+Line 11:
-Non ho studiato a fondo questo autenticatore e conto di farlo in futuro, pero` a naso questo funziona solo se il winbind locale e` joinato a un dominio il cui server e` remoto, quindi in pratica richiere che Samba e Squid non siano sullo stesso host.
 Line 12:
-Non se sia possibile joinare winbind a un samba server che gira sullo stesso host. E` comunque necessario anche verificare se occorre adattare smb.conf.
+=== Configurazione di Samba ===

Posto che non vogliamo usare Samba per niente altro, ma solo come client (a mezzo winbind) per autenticare Squid, la configurazione minima e` questa:
{{{
workgroup = <DOMAIN NAME>
password server = *
security = domain
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind use default domain = yes

# cache dei gruppi a 30 secondi (default 300)
winbind cache time = 30
}}}

La riduzione del tempo di caching dei gruppi serve per evitare che quando si mette o toglie un utente da un gruppo debbano passare 5 minuti (piu` il tempo di cache interno di squid, che vedremo dopo) prima che la modifica venga recepita da Squid. Ovviamente meno cache usiamo e piu` stress mettiamo sul DC. Consideriamo che squid autentica OGNI RICHIESTA HTTP, e questo vuole dire decine di richieste per ogni pagina web visualizzata da un solo utente. La cache e` quindi fondamentale per motivi di performance.

Dopo aver fatto questa configurazione e riavviato samba, occorre joinare il server samba al dominio:
{{{net rpc join  -UAdministrator%password}}}

Se il join ha avuto successo, possiamo provare a leggere dati dal DC:

 * wbinfo -u (legge elenco utenti)
 * wbinfo -g (legge elenco gruppi)
 * wbinfo -r username (mostra a quali gruppi appartiene un utente. risponde numerico, e` normale)
-Line 16:
+Line 42:
-Questa configurazione non e` stata provata.
+Il minimo di configurazione richiede che il browser possa autenticarsi usando due schemi, NTLM e Plain. Il primo e` supportato da Explorer e il secondo da tutti gli altri.
-Line 19:
+Line 45:
-# Autenticazione NTLM
+###
### Autenticazione NTLM (la prima versione, quella commentata, richiede che l'utente sia membro di un gruppo specifico. La seconda no)
###
# auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp  --require-membership-of=<DOMAIN\\GRUPPO>
-Line 22:
+Line 51:
-auth_param ntlm max_challenge_reuses 0
auth_param ntlm max_challenge_lifetime 2 minutes
# ntlm_auth from Samba 3 supports NTLM NEGOTIATE packet
auth_param ntlm use_ntlm_negotiate on
-Line 27:
+Line 52:
-# Autenticazione PLAIN
+###
### Autenticazione Plain (la prima versione, quella commentata, richiede che l'utente sia membro di un gruppo specifico. La seconda no)
###
# warning: basic authentication sends passwords plaintext a network sniffer can and will discover passwords

#auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic  --require-membership-of=<DOMAIN\\GRUPPO>
-Line 30:
+Line 61:
-auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
+auth_param basic realm Authenticated proxy
auth_param basic credentialsttl 30 minutes

###
### Questa ACL, chiamata domainusers, richiede che almeno una delle due autenticazioni indicate sopra dia risultato positivo.
###
acl domainusers proxy_auth REQUIRED

###
### Se ci basta l'autenticazione cosi` fatta, allora DOPO le varie righe che iniziano per "acl" mettiamo questo.
### Sta a indicare che il cliente deve essere nella lan locale (una acl che qui non e` indicata ma e` nella configurazione standard)
### e che deve anche essere autenticato.
###
http_access allow local_lan domainusers
}}}
-Line 34:
+Line 78:
-acl domainusers proxy_auth REQUIRED
http_access allow domainusers
+Se vogliamo complicare la configurazione possiamo verificare l'appartenenza dell'utente a uno o piu` gruppi, e comportarci di conseguenza. Questo e` un esempio di ACL che fa uso dell'appartenenza di un utente ad un gruppo e permette potenzialmente di creare poi regole di accesso complesse, tipo "se sei in un gruppo certi siti sono consentiti altrimenti no". Sempre in squid.conf, possiamo mettere:

{{{
###
### autenticazione di un utente su un gruppo (ovvero, l'utente appartiene al gruppo?)
###

# questa riga indica a squid come usare un autenticatore esterno per verificare se un utente appartiene a un gruppo. 
# qui non e` indicato il gruppo, che viene indicato dopo nella relativa ACL.
external_acl_type testForGroup ttl=60 negative_ttl=60 %LOGIN /usr/lib/squid/wbinfo_group.pl

# L'utente appartiene al gruppo che si chiama "internet"? Se si`, allora la ACL di nome "inGroupInternet" e` true.
acl inGroupInternet external testForGroup internet

# Volendo potrei creare una seconda ACL che testa se l'utente appartiene al gruppo "unlimited_internet", per poi fare
# cose diverse
acl inGroupUnlimited_Internet external testForGroup unlimited_internet

###
### A questo punto, dopo le righe "acl", posso mettere delle regole di accesso che combinino le ACL fra di loro
### per consentire o negare l'accesso.
###

# qui consento l'accesso agli host della lan locale AND che sono autenticati come utenti
# AND che appartengono al gruppo "internet" sul dominio
http_access allow local_lan domainusers inGroupInternet
-Line 37:
+Line 105:
+E` possibile mischiare anche blacklist e whitelist di siti con le ACL di autenticazione e appartenenza al gruppo, non ho pero` un esempio pronto.

Per testare l'autenticatore esterno dei gruppi (se ci fossero dubbi sul suo funzionamento) si puo` usare questo comando:
{{{
echo "USER GRUPPO" | /usr/lib/squid/wbinfo_group.pl -d

Esempio: l'utente test e` nel gruppo internet?
echo "test internet" | /usr/lib/squid/wbinfo_group.pl -d
}}}