Impersonate & delegate

Finalmente trovo un po’ di tempo per continuare la trattazione iniziata in un mio articolo precedente dei Motivi per veicolare il contesto utente fino al database, e a questo rimando dando per scontati alcuni argomenti.

Sono già stati evidenziati i benefici e le caratteristiche dell’utilizzo dell’autenticazione integrata e del contesto utente anche fino all’ultimo livello applicativo (tier). E’ stata poi spiegata la configurazione da  utilizzare in un’archiettura a 3-tier (IE-IIS-SQL) tutta implementata in un unica macchina (single server).

Per capire come il security context di un utente possa essere veicolato esternamente ad un server da un servizio ad un altro,  bisogna comprendere i protocolli di autenticazione utilizzati.

NTLM e Kerberos a confronto

Il protocolli di autenticazione supportati da Windows sono NTLM (NT Lan Manager, fino dalla versione 4.0)  e Kerberos (da Win 2000 in poi).  Mentre NTLM si basa su un meccanismo di  challenge/response (ovvero lo scambio di un hash criptato tra client e server), Kerberos basa la sua architettura sull’esistenza di server autenticatori (KDC, Key distribuition center), che distribuiscono tikets (cifrati e firmati e quindi affidabili) ai client per utilizzare specifici servizi.

I pregi di Kerberos sono:

  • lo standard aperto, basato sull’RFC 4120
  • la maggiore velocità, poiché, diversamente da NTLM, il servizio non deve verificare la validità dell’utente/client presso un DC, ma gli basta semplicemente il ticket stesso
  • la mutua autenticazione, poichè non solo il client si autentica al servizio (come NTLM),  ma il client stesso è certo dell’identità del servizio, poichè solo quello può leggere il ticket fornito
  • supporto per il logon tramite smart card
  • supporto per la delega dell’autenticazione (Authentication delegation o Authentication forwarding): grazie a questa caratteristica un servizio può accedere ad un risorsa remota per conto di un utente.

Quet’ultimo punto sta a significare che un utente A può dare diritti ad un’entità intermedia B per autenticarsi ad un terzo server C, come se
l’entità B fosse l’utente A stesso. Il server C baserà le sue decisioni autorizzative sull’identità di A invece che su quella di B.

E’ possibile iterare questo schema per più livelli applicativi distribuiti (multi-tier applications) solamente utilizzando Kerberos e non NTLM, semplicemente perchè NTLM non supporta la delegation! Quindi NTLM funziona su un’architettura a single server solo perchè il security context dell’utente viene creato alla sua connessione al primo livello sul server (dopo l’autenticazione) ed è disponibile poi per i livelli applicativi sucessivi.

Nell’implementazione Microsoft di Kerberos, il servizio stesso è altamente integrato con Active Directory (AD) e tutti i dati e le credenziali sono memorizzati in essa.

Negotiate

Quando è attivata l’autenticazione Kerberos, tra Internet Explorer (MSIE) e Internet Information Server (IIS) vengono scambiati alcuni pacchetti per negoziare il protocollo più sicuro (RFC 4559): viene utilizzato l’algoritmo HTTP/SPNEGO che tenta dapprima di utilizzare Kerberos (Negotiate) e in caso negativo (fallback) poi i protocolli meno sicuri come NTLM, Digest e BASIC.

Per capire bene il meccanismo rimando all’interesante articolo Two easy ways to determine kerberos from NTLM in a HTTP capture di Ken Schaefer.

Service Principal Names (SPN)

Un service principal name (SPN) è il nome col quale un servizio si registra in Kerberos e anche col quale un client identifica univocamente un’istanza di un servizio. Quando un client vuole connettersi ad un servizio, ne localizza un’istanza, ne ricava un SPN, si connette al servizio e presenta l’SPN del servizio per autenticarsi.

Un SPN è definito nel formato serviceclass/host:port/servicename . Se nome e porta non sono standard devono essere specificate. Ad esempio:

Se il servizio si chiama  MyService ed è eseguito sul computer DCA  e usa le porte TCP o UDP  8088 ed è localizzato in AD con il nome MyS nella UO denominata CS,  nel dominio cpandl.com, allora l’SPN sarà

MyService/DCA.cpandl.com:8088/CN=MyS,OU=CS,DC=cpandl,DC=com

Se il server WS2003A sta erogando un servizio di desktop remoto (RDP) sulla porta standard (TCP 3389). Allora i 2 SNP associati in AD saranno semplicemente:

TERMSRV/WS2003A
TERMSRV/WS2003A.cpandl.com

Per registrare un SPN è possibile utilizzare l’utility setspn.exe disponibile in Windows Server 2003, Windows Server 2008 o su XP/Vista con i Windows Server 2003 Support Tools.

Ad esempio per aggiungere un SPN per il servizio web-IIS di Machine (il cui pool gira con l’account di dominio “domain\user”) usare:

 Setspn.exe -A HTTP/Machine domain\user
 Setspn.exe -A HTTP/Machine.domain.com domain\user 

Notare che deve essere registrato due volte sia per il nome NetBios cheper il FQDN. Nel caso in cui il servizio giri con il Local System Account/Network Service usare invece:

 Setspn.exe -A HTTP/Machine Machine
 Setspn.exe -A HTTP/Machine.domain.com Machine 

L’utility setspn può essere utilizzata per conoscere quali SPN siano registrati in AD:

setspn -l Machine
setspn -l domain\user

Rimando comunque a  Technet per ulteriori esempi, opzioni ed utilizzi di setspn.

Abilitare la delegation

Per abilitare la delegation tra i livelli applicativi è necessario abilitarla:

  • per l’utente che usufruisce del servizio (non deve essere sensitive)
  • sull’utente con cui viene eseguito il servizio
  • per il conmputer account del server

Bisogna verificare che gli user accounts non siano disabilitati per la delegation:

Poi  bisogna abilitare il computer account e l’user account del servizio (dopo che è stato registrato l’SPN compare il Tab sul profilo).

La delegation può essere abilitata per tutti i servizi o per alcuni specifici; nella figura sopra all’ utente-servizio IIS è stata abilitata la delega limitatamente per le connessioni al servizio SQL Server.

Bisogna inoltre verificare che siano impostati i giusti rights agli utenti interessati (ovvero a quelli con cui vengono eseguiti i servizi):

  • Act as part of the operating system per poter impersonare l’utente
  • Impersonate a client after authentication per ogni account che dovrà delegare le credenziali (ovvero su tutti i middle tier intermedi), come l’account IIS

Tali right possono essere impostati nelle local security policy dei singoli server o in qualche GPO di AD a seconda delle policy implementate e del contesto.

 Un comune scenario: IE – IIS (ASP.NET) – SQL

La seguente figura riassume tutte le attività che devono essere fatte o verificate per abilitare la delegation in questo tipico scenario.

A) A livello di dominio:

  • Gli user account non devono essere sentive (Tab Account)
  • Registrare gli SPN per i servizi IIS e SQL, specificatamente agli account con cui vengono eseguiti, usando comandi simili a:
Setspn.exe -A HTTP/MachineIIS domain\userIIS
Setspn.exe -A HTTP/MachineIIS.domain.com  domain\userIIS
Setspn.exe -A MSSQLSvc/MachineSQL:1433 domain\userSQL
Setspn.exe -A MSSQLSvc/MachineSQL.domain.com:1433 domain\userSQL
  • L’account IIS e quello del pool Asp.net deve essere Trusted for delegation (Tab Delegation)

 B) Sui client Internet Explorer

  • Enable Window Authentication
  • In Strumenti-Opzioni Internet-Protezione verificare che il server IIS (o il dominio legato al virtualhost) sia censito nell’Intranet Zone

C) Web Server; nella console di IIS sul Web Server

  • impostare a livello di Site e Virtual directory unicamente l’opzione di Autenticazione integrata. Per evitare problematiche di instabilità o di malfunzionamenti impredicibili, bisogna assicurarsi che tutte le applicazioni web (virtual directory) che si appoggiano al Pool ASP.NET (per il quale è stato registrato l’SPN) abbiano abilitata solo questa impostazione.
  •  Nel web.config della web application impostare: 
<authentication mode="Windows"/>
<identity impersonate="true"/>
  • Nel web.config della web application impostare la connection string opportunamente in modo similare:
connectionString="Server=MachineSQL;Database=MYDB;Integrated Security=True"

 D) Database; con SQL Server Management studio

  • Devono essere dati i diritti opportuni agli utenti  sul database 

Utility e debugging

Una preziosa utility che permette di visualizzare i ticket kerberos attualmente presenti sul client è kerbtray disponibile sul sito Microsoft. da citare anche l’utility testuale klist che oltre a listare permette anche di cancellare i ticket presenti.

Per abilitare invece i logging del client kerberos nel system log e per poterli visualizzare con Event Viewer bisogna valorizzare la seguente chiave di registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Registry Value: LogLevel
Value Type: REG_DWORD
Value Data: 0x1

Una volta risolti i problemi conviene eliminare tale chiave di registro, poichè il logging  influenza le performance.

Riferimenti

IETF – The Kerberos Network Authentication Service (V5)

IETF – SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows

Microsoft Download – Troubleshooting Kerberos Delegation in Windows 2000 and Windows Server 2003

Microsoft – How to use SPNs when you configure Web applications that are hosted on IIS 6.0

MSDN – How To: Use Impersonation and Delegation in ASP.NET 2.0

MSDN – How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0

MS Technet – Setspn Overview

Ken Shaefer – Two easy (easier?) ways to determine Kerberos from NTLM in a HTTP capture

Microsoft – How to configure IIS to support both the Kerberos protocol and the NTLM protocol for network authentication

Microsoft – Kerberos authentication and troubleshooting delegation issues

MS Technet – Troubleshooting Kerberos Problems

Microsoft Download – Windows 2000 Resource Kit Tool: Kerbtray.exe

Questa voce è stata pubblicata in Active Directory, Software, SQL Server, Web, Windows Autentication e contrassegnata con , , , , , , . Contrassegna il permalink.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *


*