11.5. NTLM Authentication

In questa sezione tratteremo lo schema di autenticazione NTLM (v1 e v2) che è stato implementato a partire versione 2.5 di Squid, faremo riferimento al protocollo NTLM, analizzando le modalità di utilizzo di questo sistema di validazione.

11.5.1. Configurazione

Vediamo in questo paragrafo quali sono le necessità immediate alle quali risponde lo schema di autenticazione NTLM di Squid

l'Autenticazione NTLM funziona esclusivamente con la versione 2.5 di Squid. Sino alla versione 2.5.STABLE4 viene supportata soltanto la versione 1 del protocollo NTLM, a partire dalla versione 2.5.STABLE5 viene anche supportata la versione 2 del protocollo NTLM grazie al nuovo supporto dei pacchetti del tipo NTLM NEGOTIATE. Si rammenta al lettore che, se si intende utilizzare delle password o degli oggetti di lunghezza superiore a 14 caratteri, è necessario ricorrere ad un helper che sia in grado di interpretare correttamente i pacchetti NTLM NEGOTIATE (NTLMv2) con la relativa funzionalità abilitata in squid.conf. Lo schema di autenticazione NTLM utilizza i seguenti parametri

auth_param ntlm program cmdline
auth_param ntlm children numberofchildren
auth_param ntlm max_challenge_reuses number
auth_param ntlm max_challenge_lifetime timespan
auth_param ntlm use_ntlm_negotiate on|off
   

il TAG program cmdline

Specifica il comando che avvia il programma utenticatore esterno. Tale programma legge una riga da stdin contenente pacchetti NTLM di tipo NEGOTIATE in formato uuencoded e risponde su stdout con pacchetti NTLM di tipo challenge/response in formato uuencoded in un loop senza fine. Di default, lo schema di autenticazione NTLM non viene attivato, a meno che non sia specificato un programma autenticatore. Ad esempio:

auth_param ntlm program /usr/local/squid/libexec/wb_ntlmauth
   

il TAG children numberofchildren

Indica quante istanze del programma di autenticazione devono essere eseguite contemporaneamente. Se viene configurato un numero di autenticatori troppo basso, Squid potrebbe essere costretto ad attendere un autenticatore libero, rallentando la navigazione. Il valore predefinito è 5.

auth_param ntlm children 5
   

il TAG max_challenge_reuses number

Specifica il massimo numero di volte che un challenge fornito da un helper può essere riutilzzato. Il valore 0 implica che il challenge può essere utilizzato una volta sola (caching disabilitato).

auth_param ntlm max_challenge_reuses 0
   

il TAG max_challenge_lifetime timespan

Specifica il massimo periodo di tempo per cui un challenge fornito da un helper può essere riutilzzato. L'effetivo periodo di validità del challenge é dato dal minimo tra il numero di riutilizzi consentiti ed il tempo qui specificato.

auth_param ntlm max_challenge_lifetime 2 minutes
   

il TAG use_ntlm_negotiate

Abilita il supporto per lo scambio dei pacchetti NTLM NEGOTIATE con l'helper. L'helper NTLM configurato deve essere in grado di gestire i pacchetti NTLM NEGOTIATE. In caso di dubbi riferirsi alla documentazione dell'helper. ntlm_auth fornito con Samba 3.0.2 o seguenti supporta l'utilizzo di questa opzione. Per compatibilità con i vecchi helper e configurazioni esistenti, il valore predefinito é off. Questa opzione é disponibile a partire dalla versione 2.5.STABLE5 di Squid.

auth_param ntlm use_ntlm_negotiate on
   

a differenza dello schema di autenticazione Basic, non é possibile testare il corretto funzionamento di un helper per la NTLM authentication, in quanto le transazioni di autenticazione non sono di tipo unitario, ma prevedono delle sequenze di challenge/response non simulabili tra il browser client e l'autenticatore.

11.5.2. Autenticazione NTLM nativa

Anche se non è corretto utilizzare il temine "autenticazione NTLM nativa", in quanto si tratta di un sistema di autenticazione proprietario prodotto da Microsoft, in questo paragrafo tratteremo l'utilizzo degli helper NTLM che sono stati inclusi nativamente nella distribuzione di Squid.2.5, questi helper non devono ricorrere al supporto di altre applicazioni esterne come Samba.

11.5.2.1. helper SMB (ntlm_auth)

Questo helper permette di autenticare gli utenti tramite il protocollo NTLMv1 nell'ambito di uno o più Domain Controller per uno o più domini Windows NT o in Active Directory, la configurazione è quanto mai semplice

auth_param ntlm program /usr/local/squid/libexec/ntlm_auth DOMINIO/SERVER DOMINIO/SERVER
auth_param ntlm children 10 
auth_param ntlm max_challenge_reuses 2 
auth_param ntlm max_challenge_lifetime 15 minutes 
auth_param ntlm use_ntlm_negotiate off
    

in questo caso ntlm_auth si trova in /usr/local/squid/libexec, il numero di helper in esecuzione é 5, i challenge possono essere riutilizzati due volte ed il loro TTL é pari a 15 minuti.

L'helper ntlm_auth può essere utilizzato unicamente sulle piattaforme supportate da Squid su cui é possibile compilare le librerie Samba su cui é basato (Samba non é comunque richiesto), ntlm_auth non supporta i pacchetti NTLM NEGOTIATE e quindi non è in grado di funzionare con il protocollo NTLMv2. La lunghezza massima delle password utilizzate dagli utenti non può superare un numero massimo di 14 caratteri.

Riferendoci all'esempio di cui sopra, la macchina SERVER deve essere un Domain Controller e deve essere sicuramente raggiungibile. In caso di incertezze si consiglia sempre di mettere una voce nel file /etc/hosts per identificare il corretto percorso di rete dei sistemi Domain Controller. E' possibile specificare più di una macchina Domain Controller per ogni Dominio, i Domain Controller possono anche appartenere a domini differenti ed è quindi possibile utilizzare Squid per eseguire l'autenticazione in modalità trasparente per più di un dominio Windows NT/2000/2003.

Vediamo ora un esempio di autenticazione trasparente su più domini

auth_param ntlm program /usr/local/squid/libexec/ntlm_auth SEDE_01/SERVER1 SEDE_02/SERVER2
    

in questo caso Squid autenticherà in maniera trasparente gli utenti del Dominio SEDE_01 e gli utenti del Dominio SEDE_02, i due Domain Controller sono installati rispettivamente sulle macchine SERVER1 e SERVER2, per queste macchine avremo inserito una voce che consenta di identificare il loro indirizzo internet nel file /etc/hosts

% more /etc/hosts
127.0.0.1               localhost.localdomain localhost
192.168.0.3             athlon.sede_00.net    server0
192.168.0.5             dc.sede_01.net        server1
192.168.0.7             dc.sede_02.net        server2
    

l'helper ntlm_auth prevede le seguenti opzioni

-b enables load-balancing among controllers.
-f enables failover among controllers (DEPRECATED and always active).
-l changes behavior on domain controller failures to last-ditch.
-d enables debugging statements if DEBUG was defined at build-time.
    

L'opzione -d consente una diagnostica abbastanza chiara e precisa dei problemi

Questo helper presentava alcuni problemi che venivano erroneamente imputati alla non perfetta implementazione del protocolo SMB e che provocavano delle saltuarie richieste di autenticazione da parte del Browser. A partire da Squid 2.5.STABLE5, questo tipo di anomalia è stato finalmente eliminato, pertanto ntlm_auth può essere tranquillamente utilizzato nel caso in cui si decidesse di utilizzare il protocollo NTLMv1 per autenticarsi in un dominio Windows NT o in un sistema Active Directory.

11.5.2.2. helper fakeauth & no_check

Questi helper non compiono alcuna validazione, ma si limitano ad eseguire una transazione NTLM di tipo challenge/response senza eseguire alcuna validazione. Il loro utilizzo può rivelarsi particolarmente utile a scopo di debugging relativamente alla componente NTLM di Squid o per casi particolari, casi nei quali si voglia eseguire solamente il logging degli utenti. I riferimenti di configurazione per squid.conf sono i seguenti

auth_param ntlm program /usr/squid/libexec/fake_auth 
auth_param ntlm children 5 
auth_param ntlm max_challenge_reuses 20 
auth_param ntlm max_challenge_lifetime 15 minutes
auth_param ntlm use_ntlm_negotiate off
    

In questo caso fake_auth si trova in /usr/local/squid/libexec, il numero di helper in esecuzione é 5, i challenge possono essere riutilizzati 20 volte ed il loro TTL é pari a 15 minuti. Gli helper fake_auth e no_check sono utilizzabili su tutte le piattaforme supportate da Squid, e NON supportano i pacchetti NTLM NEGOTIATE (NTLMv2).

11.5.2.3. helper Windows win32_ntlm_auth

L'helper win32_ntlm_auth riguarda esclusivamente Squid per la piattaforma Win32 e consente la validazione trasparente degli utenti su di un dominio Windows NT 4 o Windows 2000 Active Directory. Inoltre é supportato in modo totalmente automatico l'utilizzo dei pacchetti NTLM NEGOTIATE (NTLMv2). Non necessita di alcuna componente esterna in quanto si appoggia sulle API native del sistema operativo

auth_param ntlm program c:/squid/libexec/win32_ntlm_auth.exe
auth_param ntlm children 5
auth_param ntlm max_challenge_reuses 0
auth_param ntlm max_challenge_lifetime 2 minutes
auth_param ntlm use_ntlm_negotiate on
    

In questo caso win32_ntlm_auth.exe si trova in c:/squid/libexec, il numero di helper in esecuzione é 5, i challenge non possono essere riutilizzati, il supporto per i pacchetti NTLM NEGOTIATE é abilitato. L'helper win32_ntlm_auth é utilizzabile solamente in ambiente Windows nativo o Cygwin ed é disponibile nei relativi package Squid. Per questo helper sono disponibili le seguenti opzioni

-d  enable debugging
-v  enable verbose NTLM packet debugging.
-A  specify a Windows Local Group name allowed to authenticate
-D  specify a Windows Local Group name not allowed to authenticate
-h  this message
    

Le opzioni -d e -v consentono una diagnostica abbastanza chiara e precisa di eventuali problemi. Le opzioni -A e -D consentono di specificare un gruppo Windows LOCALE autorizzato o non autorizzato alla navigazione, si raccomanda l'utilizzo di ACL esterne per ottenere una maggiore flessibilità.

11.5.3. Autenticazione NTLM con Samba 2.2.x

Vedremo di seguito come utilizzare il servizio Winbindd di Samba versione 2.2.x come supporto per l'autenticazione NTLM di Squid 2.5.

11.5.3.1. Compilazione helpers

Per utilizzare gli helpers basati su Winbindd è necessario avere installato e correttamente configurato Samba 2.2.4 o seguenti, Squid-2.5 utilizza un'interfaccia interna di Samba per la comunicazione con Winbindd, per questo motivo il suo funzionamento può essere influenzato da modifiche a tale interfaccia da parte del team di sviluppo di Samba. Squid-2.5.STABLE2 supporta Samba 2.2.6 e Samba 2.2.7a e forse anche le versioni seguenti. Per utilizzare le versioni precedenti di Samba è necessario utilizzare la nuova opzione di compilazione

% ./configure --with-samba-sources=path 
    

questa opzione è necessaria per indicare il percorso contenente i sorgenti di Samba, ad esempio

% ./configure --with-samba-sources=/usr/src/samba-2.2.8
    

l'utilizzo di tale opzione potrebbe anche rendersi necessario per le future versioni di Samba o in caso di applicazione di patch ai suoi sorgenti. Squid-2.5.STABLE1 supporta Samba 2.2.4 e Samba 2.2.5, per le versioni di Samba a partire dalla 2.2.6 e seguenti è necessario sostituire, prima della compilazione di Squid, gli include winbind_nss.h e winbindd_nss_config.h presenti nel source tree di Squid con quelli del source tree di Samba.

11.5.3.2. Configurazione di Samba2

Come detto precedentemente, per utilizzare l'autenticazione Winbindd è necessario installare Samba, versione 2.2.4 o seguenti, e configuralo in modo opportuno. Alcune linee guida per una corretta installazione possono essere le seguenti. In fase di compilazione, eseguendo il ./configure di Samba, inserire le seguenti opzioni:

% ./configure --with-winbind --with-winbind-auth-challenge 
    

nella grande maggioranza delle distribuzioni GNU Linux, la versione binaria di Samba che viene fornita é compilata senza l'opzione --with-winbind-auth-challenge, si raccomanda quindi la ricompilazione ad hoc per la propria installazione e si consiglia anche di non utilizzare la versione fornita a corredo della propria distribuzione.

Dopo avere compilato il demone, dovremo integrare il file smb.conf le seguenti direttive (si prega di confrontare la documentazione di samba per maggiori informazioni)

;******************* section global ***************** 
[global] 
password server = * 
wins server = 192.168.5.1 192.168.0.1 
security = domain
encrypt passwords = Yes 
workgroup = DOMINIO 
;******************* winbindd *********************** 
winbind separator = \ template 
homedir = /home/%D/%U template 
shell = /bin/bash 
winbind uid = 10000-20000 
winbind gid = 10000-20000 
winbind enum users = yes 
winbind enum groups = yes 
    

sarà quindi necessario inserire il server Samba nel dominio come "member" con il comando smbpasswd(8)

% smbpasswd -j DOM -r DOMPDC -UAdministrator%password
    

l'opzione -j viene utilizzata per aggiungere il server samba nel dominio NT quale membro del dominio, il valore DOM è il nome del dominio al quale si vuole aggiugere la macchina samba. Grazie a questa opzione, il nostro server samba sarà in grado di eseguire l'autenticazione degli utenti verso uno qualsiasi dei domain controller così come potrebbe operare uno qualsiasi dei server Windows NT, 2000 e 2003. L'opzione -r invece, indica il nome della macchina remota ovvero il nome netbios del server SMB/CIFS da contattare per inserire il nostro server samba nel dominio. Il valore DOMPDC equivale quindi al nome netbios del domain controller. Assicurarsi che i demoni Samba (http://www.samba.org/) smbd, nmbd e winbindd siano stati avviati automaticamente con il boot del sistema, prima dell'avvio di Squid. Maggiori dettagli sul comando smbpasswd(8) possono essere reperiti alla URLs http://us1.samba.org/samba/ftp/docs/htmldocs/smbpasswd.8.html.

Se Samba viene utilizzato sulla macchina solamente per il supporto winbindd, a partire dalla versione 2.2.6 di Samba é anche possibile non eseguire il demone smbd. É però INDISPENSABILE eseguire un rinnovo periodico della relazione di trust tra la macchina Samba ed il dominio Windows. Per fare ciò, nel caso in cui non si esegua smbd, é sufficiente schedulare il seguente comando una volta al giorno

% smbpasswd -t DOM -r DOMPDC
    

ecco una entry da inserire nella tabella di crontab(8)

02 4 * * * root /usr/bin/smbpasswd -t DOM -r DOMPDC
    

questa linea inserita nella tabella di crontab ci consentira di eseguire il comando smbpasswd(8) una volta al giorno e rinnovare la relazione di trust tra la macchina UNIX® e il server Windows NT/2000, dove DOM è il nome di dominio e DOMPDC è il nome netbios del Domain Controller.

11.5.3.3. helper wb_ntlmauth

L'helper wb_ntlmauth consente la validazione trasparente degli utenti su di un dominio Windows NT 4 o Windows 2000 Active Directory. Per il suo corretto funzionamento necessita che Samba 2.2.4 o seguenti siano installati sul sistema. Di seguito vediamo un esempio di configurazione:

auth_param ntlm program /usr/squid/libexec/wb_ntlmauth [domain]
auth_param ntlm children 5 
auth_param ntlm max_challenge_reuses 0 
auth_param ntlm max_challenge_lifetime 15 minutes
auth_param ntlm use_ntlm_negotiate off
    

In questo caso wb_ntlmauth si trova in /usr/local/squid/libexec, il numero di helper in esecuzione é 5, i challenge non possono essere riutilizzati ed il loro TTL é pari a 15 minuti. È possibile specificare il dominio predefinito per l'autenticazione sulla riga comandi dell'helper.

Naturalmente almeno un domain controller del dominio deve essere raggiungibile, si consiglia di verificare il corretto funzionamento della risoluzione dei nomi di rete Microsoft (WINS, LMHOSTS o hosts).

L'helper wb_ntlmauth é utilizzabile solamente sulle piattaforme supportate da Squid per cui é disponibile anche Samba 2.2.4 o seguenti, e NON supporta i pacchetti NTLM NEGOTIATE. In merito all'utilizzo di Samba si rammenta al lettore che devono essere in esecuzione almeno i demoni winbindd e nmbd. Per questo helper sono disponibili le seguenti opzioni

-d enable debugging
-h this message
    

L'opzione -d consente una diagnostica abbastanza chiara e precisa dei problemi. Per controllare il funzionamento di winbindd, é possibile utilizzare il tool wbinfo fornito con Samba. wb_ntlmauth non funziona con Samba 3.x, riferirsi alla sezione su Samba 3 per maggiori dettagli.

11.5.4. Autenticazione NTLM con Samba3

Gli helpers basati su winbindd 2.2.x soffrono di un problema di compatibilità tra le varie versioni di samba, in quanto l'interfaccia software di winbindd non é mai stata standardizzata dal gruppo di sviluppo di Samba. Per ovviare a questo problema, si é instaurata una collaborazione tra i gruppi di sviluppo di samba e di Squid, che ha portato alla realizzazione di un autenticatore NTLM per Squid, ntlm_auth, basato sulle caratteristiche di winbindd 3 che viene incluso direttamente nel package Samba3. Gli autenticatori wb_ntlmauth, wb_auth e wb_group basati su winbindd 2.2 inclusi in Squid non funzionano con Samba 3

11.5.4.1. helper esterno Samba 3.x ntlm_auth

Questo autenticatore é in grado di operare in modalitá basic e ntlm. Inoltre a partire da Samba 3.0.2 é supportato in modo totalmente automatico l'utilizzo dei pacchetti NTLM NEGOTIATE (NTLMv2). Assumendo che Samba sia installato in /usr/local/samba, i parametri da utilizzare in squid.conf diventano

auth_param ntlm program /usr/local/samba/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 5
auth_param ntlm max_challenge_reuses 0
auth_param ntlm max_challenge_lifetime 15 minutes
auth_param ntlm use_ntlm_negotiate on
auth_param basic program /usr/local/samba/bin/ntlm_auth --helper-protocol=squid-2.5-basic
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
    

la precedente configurazione consente di sostituire gli autenticatori wb_auth e wb_ntlmauth abilitando il supporto per i pacchetti NTLM NEGOTIATE. Come accadeva già per Samba 2, anche Samba 3 deve essere compilato con questa opzione di ./configure

% ./configure --with-winbind 
    

11.5.4.2. Inserire nel dominio la macchina Samba 3.0

Dopo l'installazione di Samba 3, é necessario inserire la macchina in un dominio Windows NT 4 o Active Directory, la procedura da utilizzare varia a seconda del tipo di dominio.

  • Dominio Windows NT 4

    La configurazione da utilizzare in smb.conf é identica a quella utilizzata con Samba 2, con la differenza che le funzionalità del comando smbpasswd sono state incluse nel comando net(8) di Samba 3 (http://www.samba.org/samba/docs/man/net.8.html). L'utility net inclusa con Samba 3 lavora in maniera simile al comando net del DOS[1] e di Windows. Il comando per inserire la macchina samba in dominio Windows NT diventa quindi

    % net join -S DOMPDC -UAdministrator%password
         
    

    con l'opzione -S si indica il nome netbios del server di destinazione o il relativo indirizzo IP, nell'esempio DOMPDC è il nome netbios del domain controller

  • Dominio Active Directory (Samba 3 deve essere compilato con support Kerberos)

    Inserire nel file smb.conf le seguenti direttive:

    realm = your.kerberos.REALM
    security = ADS
    encrypt passwords = yes
         
    

    nel caso in cui Samba non riesca ad identificare il server ADS tramite il REALM

    password server = your.kerberos.server
         
    

    inserire la macchina Samba 3 in dominio con il comando net(8)

    % net ads join -U Administrator%password
         
    

    l'opzione ads viene utilizzata per identificare le ActiveDirectory, l'opzione rap viene invece utilizzata per le macchine NT3 oppure Windows9x, per finire l'opzione rpc può essere utilizzata per le macchine NT4 o Windows 2000, se l'argomento viene omesso il comando net(8) tenterà di determinare automaticamente il tipo di sistema.

Si raccomanda di riferirsi alla documentazione della versione di Samba 3 utilizzata per verificare la corretta procedura da seguire in funzione dell'implementazione Kerberos utilizzata sul sistema. Infine, per consentire agli helper Samba 3 di lavorare correttamente con Squid è necessario fare in modo che il gruppo specificato nella direttiva cache_effective_group di squid.conf abbia i permessi di lettura sulla directory winbindd_privileged in cui si trova la pipe di winbindd, quindi nel caso in cui il gruppo utilizzato da squid sia ad esempio nogroup:

% chgrp nogroup /dove/sta/samba/winbindd_privileged
% chmod 750 /dove/sta/samba/winbindd_privileged
    

Il risultato di un ls -la /dove/sta/samba/winbindd_pipe/pipe dovrebbe essere:

srwxrwxrwx 1 root root 0 Aug 14 22:50 pipe
    

anche con Samba 3, se viene utilizzato sulla macchina solamente il supporto winbindd é possibile non eseguire il demone smbd. Anche in questo caso é però INDISPENSABILE eseguire un rinnovo periodico della relazione di trust tra la macchina Samba ed il dominio Windows. Per fare ciò, nel caso in cui non si esegua smbd, é sufficiente schedulare il seguente comando una volta al giorno

% net rpc changetrustpw
    

le possibilità sono [rpc|ads] CHANGETRUSTPW per forzare il rinnovo della relazione di trust, ecco una entry da inserire nella tabella di crontab(8)

02 4 * * * root /usr/bin/net rpc changetrustpw
    

questa linea inserita nella tabella di crontab ci consentira di eseguire il comando net(8) una volta al giorno e rinnovare la relazione di trust tra la macchina UNIX® e il server Windows NT4/2000.

11.5.5. Problemi comuni con NTLM

La modalità di funzionamento connection oriented propria di NTLM, il fatto che non tutti gli user agent supportino il sistema di autenticazione NTLM, nonchè particolari configurazioni relative al dominio Windows di appartenenza, possono provocare dei problemi di utilizzo anche piuttosto fastidiosi in presenza del sistema di autenticazione NTLM. Vediamo ora alcuni dei problemi più comuni che possono presentarsi con NTLM.

11.5.5.1. Java runtime

Navigando su siti che utilizzano applet Java, il JRE richiede di continuo l'autenticazione all'utente. Ciò accade perché il browser non é in grado di condividere l'autenticazione della connessione con la Java Virtual Machine

  • soluzione: consentire nelle ACL il traffico Java non autenticato

acl java_jvm browser Java/1.4
http_access allow java_jvm
    

11.5.5.2. ftp

Navigando su siti ftp con URL del tipo ftp://ftp.miosito.com, a volte può succedere che il browser richieda l'autenticazione per accedere agli oggetti icona FTP di Squid. Questo é dovuto ad un problema nel riconoscimento dei siti Internet/Intranet da parte di alcune versioni recenti di Internet Explorer

  • soluzione: consentire nelle ACL l'accesso non autenticato agli oggetti interni di Squid

acl internal_icons urlpath_regex -i /squid-internal-static/icons/
http_access allow internal_icons
    

11.5.5.3. Windows Update V5 (Windows XP-SP2)

Che cosa simpatica: il Windows Update V5 che è stato incluso con il SP2 di Windows XP sembra bloccarsi sempre con il sistema di autenticazione NTLM sia nativa che quella con Samba. Ancora non siamo in grado di spiegare le cause di questo fastidioso problema

  • soluzione: consentire nelle ACL l'accesso non autenticato alle URLs di Windows Update

acl wu dstdomain .windowsupdate.com .microsoft.com .windows.com .public-trust.com
http_access allow wu
    

se vogliamo proprio essere pignoli possiamo analizzare il file di log dello user-agent per verificare i seguenti client utilizzati da Windows Update V5

172.31.128.128 [19/Sep/2004:21:12:06 +0200] "Windows Update Control"
172.31.128.128 [19/Sep/2004:21:12:52 +0200] "Microsoft WU Client/2.0"
172.31.128.128 [19/Sep/2004:21:15:28 +0200] "Microsoft BITS/6.6"
    
  • soluzione affinata: consentire nelle ACL l'accesso non autenticato per determinati user-agent la cui destinazione non può essere diversa da quella che viene definita dalla ACL wu

acl wuagent browser "Windows Update Control"
acl wuagent browser "Microsoft WU Client/2.0"
acl wuagent browser "Microsoft BITS/6.6"
acl wuagent browser "Industry Update Control"
acl wu dstdomain .microsoft.com .windowsupdate.com .windows.com .public-trust.com
http_access allow wuagent wu
    

l'ultimo TAG deve essere posizionato prima della direttiva http_access relativa alla autenticazione

11.5.5.4. Windows 2003

É impossibile navigare utilizzando una macchina Windows 2003. Ciò accade in quanto in Windows 2003 l'utilizzo del protocollo LM/NTLM é disabilitato per default e le versione di Squid precedenti la 2.5.STABLE5 non supportano la funzione di NTLM NEGOTIATE

  • soluzione: utilizzare squid 2.5.STABLE5 con ntlm_auth di Samba 3.0.2 o seguenti abilitando il supporto NTLM NEGOTIATE

  • soluzione: attivare il supporto LM/NTLM in Windows 2003

per abilitare il supporto LM/NTLM in Windows 2003 server è necessario aprire il tool "Machine Local Security Policy", nelle opzioni di sicurezza, modificare la voce "Network Security: LAN Manager Authentication Level" da "Send NTLM response only" a "Send LM & NTLM responses".

11.5.5.5. Utenti non autenticati

Utilizzando NTLM può accadere che alcuni utenti non vengano autenticati in modo sistematico, e Samba restituisce l'errore NT_STATUS_INVALID_WORKSTATION. Questo avviene perché l'utente é autorizzato a fare la logon su un numero ristretto di workstation, ma non sul Proxy Server.

  • soluzione: aggiungere il Proxy Server all'elenco delle macchine autorizzate nelle proprietà dell'utente Windows

  • soluzione: utilizzare squid.2.5-STABLE5 con ntlm_auth di Samba 3.0.2 abilitando il supporto NTLM NEGOTIATE

Note

[1]

DOS è l'acronimo di Disk Operating System