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

Per esempio: il browser viene eseguito nel contesto di sicurezza dell’utente che si logga al computer, poi l’utente si autentica al Web server e le pagine chiamate ed i componenti software che le sottintendono sono eseguiti nel contesto di sicurezza dell’utente stesso. Similmente accade per l’autenticazione e la fruizione di altri servizi di rete o della connessione al database (anche in cascata tramite linked servers).

La seguente figura rappresenta tale scenario.

Dopo aver effettuato un brevissimo e sintetico excursus sui concetti di base, che verranno dati per scontati nei miei prossimi articoli, comincerò a descriverne l’implementazione. Nei prossimi articoli descriverò come implementare questa funzionalità in un ambiente distribuito per mezzo del modello di impersonazione e delega.

Autenticazione integrata

Non mi dilungo a descrivere cos’é l’autenticazione integrata offerta dalla tecnologia Microsoft Windows, se non per porre l’enfasi sui principali vantaggi e benefici:

• per l’utente è principalmente il single sign-on ovvero la fruizione implicita dei servizi e delle applicazioni dopo l’unico login (il famoso Ctrl-Alt-Canc) !
• per gli amministratori dell’infrastruttura di un’organizzazione, e quindi di un dominio o meglio di foreste Active Directory, è la drastica diminuzione del carico di lavoro, potendo gestire gli account degli utenti (che possono facilmente superare la migliaia di unità anche per una media azienda) e le policies in un unico punto.
• per l’organizzazione l’aumento implicito della sicurezza e dell’affidabilità

Autorizzazioni sulle risorse

Le autorizzazioni sono concesse sulle risorse, che siano esse files e cartelle sul filesystem, share di rete, stampanti, virtual directory e URI (cfr. IIS), appartenenza a ruoli applicativi (cfr. Authorization Manager), mailbox (cfr. Exchange), oggetti di Active Directory,  GPO, ecc.

Le best practices e Microsoft consigliano, ove possibile, di assegnare tali autorizzazioni non direttamente ai singoli utenti, ma ai gruppi (security groups) che li contengono. Con le ultime features di Active Directory è possibile effettuare il nesting dei gruppi in svariati livelli.

Web applications e IIS 

Il Web, come piattaforma, è diventato sempre più importante per le aziende, non solo perchè permette di ridurre i tempi e i costi di deployment delle applicazioni, ma anche perché è diventato implicitamente strumento di produttività e collaborazione (cfr. Microsoft Sharepoint) anche tramite i consueti strumenti Office che vi si connettono per pubblicare e condividere documenti.

Nelle organizzazioni che utilizzano i sistemi Microsoft l’accesso e la fruizione delle risorse dell’Intranet aziendale (e dell’Extranet) deve essere il più semplice possibile e può beneficiare con IIS del single sign-on, grazie dell’autenticazione integrata.

Il beneficio dell’autenticazione integrata Windows è duplice, cioé gli utenti vengono riconosciuti e autenticati automaticamente:

• in modo trasparente per gli utenti, senza che debbano inserire alcuna credenziale
• e senza sforzo da parte degli sviluppatori e amministratori che non devono implementare e manutenere alcun archivio degli utenti, essendo questo integrato in Active Directory

L’autenticazione di IIS

IIS può autenticare quindi gli utenti di dominio in modo trasparente tramite l’integrazione con Active Directory; i prerequisiti sono i seguenti:

1. Browser IE recente (5.5 o superiore), se è abilitata tra le opzioni avanzate “Abilita autenticazione windows integrata” e se il dominio relativo all’URL viene censito tra i siti dell’ “Intranet locale”
2. sul server IIS, il site (o la virtual directory) deve essere impostato nelle opzioni di sicurezza per accettare solo l’autenticazione integrata

N.B. in un ambiente Corporate il primo punto può essere ottenuto con estrema facilità con le Group Policies o con gli script di Logon.

 Impersonificazione

 Generalmente il codice legato ad una pagina web, e quindi l’accesso alle risorse, viene eseguito nel contesto di sicurezza di IIS (di default IUSR_servername) o dell’Application Pool (solitamente NETWORK SERVICE o LOCAL SYSTEM), a seconda che si tratti di una pagina html/.asp o di una pagina aspx/.NET.

In qualche caso è utile che il codice venga eseguito nel contesto di sicurezza dell’utente chiamante, ovvero che il servizio/pool impersonifichi il chiamate (impersonate).

Per esempio se utilizzassimo l’impersonazione:

• l’accesso ai documenti del filesystem, verrebbe così regolato dalle DACL impostate sul filesystem; non avremmo bisogno di costruirci le strutture dati per replicare tale funzionalità
• similmente verrebbe regolato l’accesso alle risorse e agli oggetti di rete
• anche l’utilizzo di oggetti COM/DCOM potrebbe essere regolato dalle autorizzazioni già applicate per quell’utente o ai gruppi ai queli l’utente stesso appartiene

 Per abilitare l’impersonazione in un’applicazione .NET, basta impostare la seguente configurazione nel web.config:

    <system.web>
        <authentication mode="Windows" />
        <identity impersonate="true"/>
    </system.web>

 Accesso al database SQL Server

Un’applicazione web può accedere in due modi ad un database, tramite autenticazione SQL (standard security) oppure tramite autenticazione integrata (trusted connection). In particolare quindi, se si utilizza una SqlConnection .NET, le stringhe di connessione (connection strings) possono essere rispettivamente:

Data Source=myServer;Initial Catalog=dbName;User Id=username;Password=password;

Data Source=myServer;Initial Catalog=dbName;Integrated Security=SSPI;

nel primo caso la connessione avverrà tramite la login specificata, nel secondo con le credenziali dell’utente autenticato da IIS.

Due modelli di sicurezza a confronto

Bisogna fare alcune considerazioni nell’utilizzo dei due modelli,
ovvero il modello che utilizza un’utenza o login fissa per connettersi al database (trusted subsystem) e quello che utilizza l’impersonificazione ed una trusted connection (impersontation/delegation);
entrambi i modelli hanno vantaggi e svantaggi.

I vantaggi del trusted subsystem, cioè quello in cui il database si fida della login utilizzata dall’applicazione indipendentemente dall’utente originale, sono:

• scalabilità. il connection pool è molto efficiente, poichè il contesto di sicurezza rimane sempre lo stesso
• gestione minima delle ACL, che sono configurate solo per una singola identità.
• l’utente non ha accesso diretto ai dati

e gli svantaggi:

• l’auditing è difficile, non potendo distinguere l’utente chiamante effettivo
• rischio elevato se l’application server viene compromesso, poichè ad esso viene garantito elevato accesso alle risorse.

Invece i vantaggi del modello ad impersonazione/delega sono:

• Auditing semplice tramite le features offerte dal sistema operativo
• Auditing a livello di tutti gli strati dell’applicazione
• Accesso granulare, impostabile anche fino a livello utente

Gli svantaggi sono:

• Il connection pool non è utilizzato efficientemente, poichè ogni connessione ha il suo specifico contesto
• Il carico amministrativo è superiore, dovendo eventualmente essere gestite le ACL per utente.

Nel modello ad impersonazione, è come se l’utente facesse una connessione al database, e quindi venisse riconosciuto dallo stesso. Le funzioni o le stored procedures potrebbero restituire risultati diversi a seconda dell’utente che le sta eseguendo; e le viste potrebbero restituire dati diversi (partizionati orrizontalmente) sempre in funzione dell’utente.

Un esempio pratico banale: se nella tabella MOVIMENTI ci fossero le movimentazioni in denaro in funzione dell’utente, allora la vista potrebbe ritornare solo le movimentazioni dell’utente collegato

CREATE VIEW v_movimenti AS SELECT * FROM movimenti WHERE utente = system_user;

e questo ci eviterebbe la noia di creare più viste…

Motivazioni per veicolare il contesto utente

Anche da ciò che è stato prima esposto, si può capire come le più comuni ragioni per portare il contesto dell’utente chiamante fino al database siano:

• Necessità di effettuare l’auditing a livello di utenza, in contrapposizione all’auditing a livello applicativo.
• Necessità di avere un accesso granulare al database e specifiche restrizioni sui suoi oggetti: specifici utenti possono leggere o eseguire alcuni oggetti, mentre altri possono scrivere su altri.
• Necessità di filtrare i risultati a livello database in funzione dell’utente connesso, utilizzando anche il codice in view, funzioni e stored procedures
• Maggior sicurezza in caso di application server compromessi
• L’accesso al database è effettuato da diversi canali ( applicazioni web, applicazioni client/server, connessioni dirette tramite client sql, ecc.) per i quali devono essere garantite le autorizzazioni e la visibilità in funzione dell’utente connesso.

Da tenere in considerazione gli aspetti legati alla minor scalabilità e il carico derivante dal fatto di applicare i permessi direttamente sulle utenze, e non sui ruoli.

 Conclusioni

Riassumendo, le condizioni per poter veicolare il contesto di sicurezza del chiamante fino al database, sono le seguenti:

1. il browser deve essere Interne Explorer e deve essere abilitata l’Autenticazione Integrata Windows
2. il sito chiamato deve trovarsi tra i siti dell’Intranet
3. l’applicazione ospitata dall’IIS deve aver abilitata solo l’Autenticazione Integrata
4. nel caso di applicazioni .NET, l’applicazione deve Impersonare l’utente
5. la connessione al database SQL Server deve essere trusted
6. ovviamente l’utente deve essere abilitato a connettersi allo specifico database

Le precedenti condizioni sono solo necessarie, nel senso che non bastano in tutti gli scenari; diventano anche sufficienti quando il sistema viene interamente implementato su un singolo server, ovvero l’IIS e il SQL Server risiedono sulla stesso server oppure quando l’IIS ha abilitata la basic authentication (punto 3; ovviamente si perde la feature del single sign-on).

Se viceversa si volesse implementare questa feature in un sistema distribuito, allora bisognerebbe modificare leggermente il modello affinché l’IIS possa impersonare l’utente anche al di fuori della stessa macchina (impersonate & delegate)

L’argomento segue nell’articolo Impersonate & delegate .