TMG 2010 autenticazione Kerberos e configurazione dei client
Per connettersi al servizio proxy di TMG è possibile configurare i client in 3 diversi modi che possono essere indicati per scenari diversi:
Client SecureNAT: ovvero sul client il server TMG viene impostato come gateway, in questo modo è possibile utilizzare i protocolli semplici (per i più complessi che necessitano di più connessioni primarie o secondarie è necessario un filtro di applicazione Forefront TMG), non può utilizzare l’autenticazione a livello utente. E’ indicato per client non Windows o se risulta necessario il supporto a protocolli non TCP o UDP (xes. ICMP o GRE).
Client proxy Web: ovvero sul client il server TMG viene impostato come con figurato come proxy (è possibile eseguire questa configurazione in vari modi: manualmente, tramite DHCP o DNS per informazioni si veda Configurazione di client proxy Web), permette l’utilizzo dei protocolli HTTP, HTTPS e FTP, consente l’autenticazione se TMG lo richiede. E’ indicato per accesso Web basato su utente tramite proxy o tramite applicazioni compatibili con CERN, offre buone prestazioni perché le richieste sono inoltrate direttamente al filtro proxy Web.
Client Firewall: ovvero sul client viene installato il client ForeFront TMG (disponibile per client XP SP3/2003 Server SP2 e successivi), permette il supporto delle applicazioni Winsock, consente l’invio automatico delle credenziali client al server TMG ed esegue l’autenticazione se richiesta. E’ indicato per client Windows quando sono necessarie regole di autenticazione in TMG e per il supporto a protocolli secondari.
In generale se i client devono accedere al Web solo tramite HTTP,HTTPS e FTP tramite regole che prevedano autenticazione a livello utente per fifferenziale gli accessi tramite gruppi e\o utenti in Active Directory la soluzione che consente di avere buone performance e semplicità di deploy è quella del client proxy Web.
Inoltre va detto che un Client proxy Web consuma meno risorse rispetto ad un Clinet Firewall, infatti quest’ultimo stabilisce un numero maggiore di connessioni TCP verso il web proxy listener di TMG per ottenere il contenuto web richiesto, ciò si traduce in un maggiore utilizzo di CPU del server TMG. A riguardo si veda il seguente Optimizing Performance on the Forefront Threat Management Gateway (Part 1) dove viene indicato che per accedere ad un determinato sito di esempio (espn.com) un Client SecureNAT apra 31 connessioni TCP contro le 6 di un Client proxy Web, ovviamente questo rapporto non ha validità generale, ma comuni un idea della differenza sostanziale tra i due tipi di client a livello di risorse utilizzate.
Quindi nell’ipotesi di utilizzare il file wpad.dat generato automaticamente da TMG per il deploy dei client proxy Web in modo da beneficiare della gestione centralizzata della configurazione dello stesso (si pensi ad esempio alle eccezioni dell’uso del proxy per l’accesso a determinati host interni all’infrastruttura aziendale) occorre fare alcune considerazioni riguardanti l’autenticazione dei client (per quanto riguarda la configurazione di TMG e clinet per l’utilizzo del file wpad.dat si vedano Configurazione del rilevamento automatico e Ignorare Forefront TMG per le richieste dei client proxy Web).
Il Service Pack 2 di TMG 2010 introduce la possibilità di utilizzare l’autenticazione Kerberos quando ci si connette a TMG in scenari in alta disponibilità (HA High Availability) come spiegato nel post del team di sviluppo New in SP2: Kerberos Authentication in Load Balanced Scenarios.
Si noti però nel caso si utilizzi il file wpad.dat generato automaticamente da TMG per distribuire ai client le impostazioni del proxy la connessione avviene utilizzando NTLM in quanto nel file il proxy (ovvero il server TMG) viene specificato tramite indirizzo IP e tramite il nome FQDN.
Come avevo spiegato nel post Autenticazione NTLM alcune note la connessione ad un host mediante l’indirizzo IP e non tramite il nome FQDN comporta l’utilizzo dell’autenticazione NTLM.
Dal momento che come illustrato nell’articolo Improving Web Proxy Client Authentication Performance on ISA Server 2006 l’autenticazione NTLM può in certi scenari causare dei colli di bottiglia in quanto TMG è costretto a validare ad richiesta del Client proxy Web le credenziali tramite il Domain Controller.
Per verificare se viene utilizzata l’autenticazione NTLM è possibile utilizzare Performance Monitor sul Domain Controller e controllare se il counter NTDS\NTLM Attentications viene incrementato quando un client proxy Web accede ad una pagina Web tramite TMG, oppure utilizzare Klist.exe o Kerbtray.exe come avevo spiegato nel post Autenticazione Kerberos alcune note.
E’ possibile ovviamente configurare TMG per specificare all’interno del file wpad.dat autogenerato il nome FQND anziché l’indirizzo IP tramite uno script VBS, di seguito riporto gli scripts CheckWPADNameSettings.vbs per il controllo dell’impostazione e SetDNSNamesInWPAD.vbs per impostare il nome FQDN del server TMG nel file wpad.dat
CheckWPADNameSettings.vbs |
Const fpcCarpNameSystem_DNS = 0 Dim oISA: Set oISA = CreateObject( “FPC.Root” ) If fpcCarpNameSystem_DNS = oWebProxy.CarpNameSystem Then |
SetDNSNamesInWPAD.vbs |
Const fpcCarpNameSystem_DNS = 0 Dim oISA: Set oISA = CreateObject( “FPC.Root” ) If fpcCarpNameSystem_DNS = oWebProxy.CarpNameSystem Then oWebProxy.CarpNameSystem = fpcCarpNameSystem_DNS WScript.Echo “TMG was configured to provide DNS names in the WPAD script…” |
Per ulteriori informazioni si veda Understanding By-Design Behavior of ISA Server 2006: Using Kerberos Authentication for Web Proxy Requests on ISA Server 2006 with NLB.
L’utilizzo di Kerberos tramite Internet Explorer consente un’autenticazione più sicura ed efficiente in quanto il processo di autenticazione viene distribuito su tutti i Domain Controller (KDCs) presenti nell’infrastruttura inoltre una volta che il client ha ottenuto il Service Ticket (ST) questo verrà utilizzato negli accessi successivi senza dover rieseguire il processo di autenticazione verso il DC (per default il ticket scadrà dopo 10 ore).
Si noti che l’autenticazione Kerberos è quella preferenziale su Internet Explorer 7 e successivi quando è configurato per l’utilizzo del proxy, mentre con Internet Explorer 6 e precedenti l’autenticazione preferenziale è NTLM (a riguardo si veda Internet Explorer does not support Kerberos authentication with proxy servers)
Perché venga utilizzata l’autenticazione Kerberos assicurarsi che il browser sia configurato per utilizzare l’autenticazione integrata di Windows (impostazione predefinita).
Per altre informazioni si vedano:
- Things to check when Kerberos authentication fails using IIS/IE…
- Configuring Advanced IE Settings Using Group Policy
Si noti che il client proxy web invia la richiesta inziale in modo anonimo e sole se questa viene bloccata da una rule che richiede l’autenticazione invierà una seconda richiesta fornendo le credenziali dell’utente.
Questo è il motivo per cui analizzando i log delle connessioni di TMG si possono notare connessioni respinte (Denied) del tipo “Status: 12209 Forefront TMG requires authorization to fulfill the request. Access to the Web Proxy filter is denied.” (a riguardo si veda il post Access to the Web Proxy Filter on Forefront TMG 2010 is Denied di Richard Hicks).