Applicare il paradigma della delega (delegation) a SQL Server significa permettere ad un client collegato ad un’istanza di SQL Server di connettersi implicitamente ad un’altra istanza di SQL Server inviandogli le credenziali kerberos dell’utente autenticato da Windows.  Questo paradigma, applicato a Server SQL, è chiamato double hop.

Sotto delegation è proprio l’istanza di SQL Server alla quale l’utente Windows si è connesso (usando l’autenticazione integrata), che impersona quell’utente stesso nelle comunicazioni con altre istanze.  La delegation è richiesta soprattutto nelle query distribuite che utilizzano linked servers.

Implementazione di un double hop

Consideriamo il caso seguente: un utente si logga una workstation e che si connette (per esempio con SQL Management Studio) ad un server all’istanza di SQL Server  SQLSERVER1. L’utente vuole eseguire query distribuite anche verso un database sul linked server SQLSERVER2.

Requisiti per il Client:

• la login dell’utente deve essere di tipo Windows
• tale login deve aver diritti di accesso su SQLSERVER1 e SQLSERVER2.
• in Active Directory,  bisogna verificare che la proprietà ”Account is sensitive and cannot be delegated” non deve essere selezionata.
• il computer client deve utilizzare per connettersi al DB il protocollo TCP/IP o named pipes.

Requisiti per il primo serverSQLSERVER1 (o in generale per i server intermedi):

• deve essere stato registrato l’SPN per il server.
• l’account col quale viene eseguito SQL deve essere “trusted for delegation”.
• il server deve utilizzare il protocollo TCP/IP o named pipes.
• il secondo server, SQLSERVER2,  deve essere aggiunto come linked server. Può essere fatto anche eseguendo la stored procedure sp_addlinkedserver:

EXEC sp_addlinkedserver 'SQLSERVER2', N'SQL Server'

• il linked server deve essere configurato per effettuare il self mapping sulle login interessate (cioè deve essere passato il contesto di sicurezza della login connessa). Si può usare la stored procedure sp_addlinkedsrvlogin:

EXEC sp_addlinkedsrvlogin 'SQLSERVER2', 'true'

La finestra delle proprietà di sicurezza del linked server dovrà essere simile alla seguente figura:

Sotto riporto un utile script da me creato ed utilizzato nella creazione e nella verifica dei linked server utilizzati negli hop.

Requisiti per il secondo server SQLSERVER2:

• Se viene utilizzato il protocollo TCP/IP, bisogna registrare un SPN  in AD.
• il server deve utilizzare il protocollo TCP/IP o named pipes.

DECLARE @sname as nvarchar(50)
SET @sname ='SERVER2' -- Il nome del linked server

-- Se il linkedsrv esiste ià, viene droppato
IF  EXISTS (SELECT srv.name FROM sys.servers srv
WHERE srv.server_id != 0 AND srv.name = @sname)
EXEC master.dbo.sp_dropserver @server=@sname, @droplogins='droplogins'
IF  EXISTS (SELECT srv.name FROM sys.servers srv
WHERE srv.server_id != 0 AND srv.name = @sname)
EXEC master.dbo.sp_dropserver @server=@sname, @droplogins='droplogins'

DECLARE @providerstr as varchar(255)
SET @providerstr= 'DRIVER={SQL Server};SERVER='+ @sname +
';Integrated Security=SSPI;'

-- Creazione del Linked server
EXEC sp_addlinkedserver  
  @server=@sname,   
  @srvproduct='',    
  @provider='SQLNCLI',   
  @datasrc=@sname, 
  @provstr= @providerstr 

EXEC sp_addlinkedsrvlogin @sname, 'true'

-- Verifica se viene utilizzato il self mapping
SELECT uses_self_credential as delegation , S.name
FROM sys.linked_logins as L, sys.servers as S
WHERE S.server_id=L.server_id and S.name=@sname

-- Esecuzione di una query distribuita
-- (bisogna avere i diritti sul secondo server)
EXECUTE('select * from '+@sname+'.master.dbo.sysdatabases')

-- La prossima query deve restituire:
-- net_transport=TCP e auth_scheme=KERBEROS
SELECT net_transport, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id=@@spid

-- La prossima query deve elencare il linked server creato
SELECT * FROM sys.servers where name=@sname

Contesti di applicazione simili

Lo schema della delegation può facilmente essere implenmentato per gli altri servizi SQL come Analysis Services, Reporting Services ed Integration Services; bisogna solamente fare attenzione alla fase di registrazione dell’SPN e ai diritti da applicate agli user account ed ai computer account coinvolti.

Per esempio per quanto riguarda Analysis Services l’SPN che deve essere registrato è del tipo:

Setspn.exe -A MSOLAPSvc.3/Fqdn:InstanceName OLAP_Service_Account

Riferimenti

MSDN – Security for Linked Servers , Configuring Linked Servers for Delegation

Microsoft – How to configure SQL Server 2005 Analysis Services to use Kerberos authentication

MS Technet – Understanding Kerberos Double Hop

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