La mia reflex Exacta Il manuale del giovane fotografo

Personalmente aborro il modo di fotografare oggi con le macchinette fotografiche digitali compatte, ovvero mirando a distanza col display lcd e lasciando l’apparecchio in modalità automatica: fotografando senza un controllo fine e senza impegno e cura nella composizione
si avranno risultati mediocri e più o meno casuali.
Dal mio punto di vista avvicinare l’occhio al mirino dell’apparecchio è il primo sforzo da compiere per affacciarsi ad un nuovo mondo…
Da poco più di due anni sono il felice possessore di una Canon EOS 1000D, che per quando reflex entry-level, mi ha indotto a riscoprire a poco a poco la fotografia digitale; la passione mi ha coinvolto a tal punto che mesi fà ho acquistato e iniziato a leggere la serie di ottimi libri di tecnica fotografica di Michael Freeman e di fotoritocco avanzato con Photoshop. E la produzione di fotografie digitali è ovviamente aumentata a dismisura, confluendo nei dispositivi di storage e ovviamente i backup.

Canon EOS 1000D

Penso che, se le foto non vengono visionate e catalogate in modo sistematico, rimangono solamente files nel PC.
Per organizzare il materiale digitale si può sicuramente iniziare da un sistema semplice di memorizzazione in cartelle, ma questa modalità non è essere sicuramente efficente nel processo (workflow) di catalogazione, di scelta , di revisione, sviluppo e fotoritocco delle immagini: pensiamo al tempo da dover dedicare soprattutto in presenza di migliaia di files e di quanto poco ne abbiamo (in media) a disposizione… 

Dopo molto leggere e documentarmi, tra vari software presenti sul mercato per la gestione dei contenuti multimediali (DAM, Digital Asset management: Lightroom,Extensis Portfolio,Expression Media ), ho scelto Adobe Bridge poichè corrispondeva alle mie esigenze tra le quali: 

• non è invasivo, nel senso che non stravolge l’organizzazione preesistente dei file in cartelle, ma l’affianca con le funzionalità mancanti
• gestisce i metadati, il rating e la classificazione delle foto in modo semplice ed intuitivo
• ha delle maschere per sfogliare e revisionare velocemente
• possiede delle funzioni molto potenti per creare collezioni di foto basate su raccolte dinamiche e preferiti
• è espandibile: supporta un potente linguaggio a script (API e SDK).

Adobe Bridge

Il workflow nella fotografia digitale si può rissumere  in modo grossolano nelle seguenti fasi:
1- fotografare (bene)
2- scaricare le foto dalla scheda di memoria in una o più cartelle del disco, secondo il proprio schema preferito
3- effettuare immediatamente il backup
4- perdere un po’ di tempo per categorizzare (taggare) le foto, attribuendole keywords specifiche (per facilitare la ricerca futura)
5- visionare le foto, marcandole coi colori (rosso/verde) al fine di scartare quelle palesemente brutte e non utilizzabili e che dovrebbero essere poi cancellate
6- revisionare le foto, attribuendo alle rimanenti il rating (1,2 o 3 stelle) valutandole in base a composizione, esposizione, fuoco e bellezza
7- assegnare ad una collezione le foto identificate come le migliori
8- fase di sviluppo e fotoritocco con il software specifico Photoshop, Camera Row, ecc.
9- backup ulteriore
Le fasi centrali (dalla 4 alla 7), che normalmente portano via molto tempo, sono completamente effettuabili in Bridge in modo assai semplice. 

Nella mia Canon 1000D lascio impostata la qualità RAW+JPG, utilizzabile nella modalità creativa, perchè, indipendentemente dal fatto che le fotografie vengano bene o abbiamo qualcosa che non và, non voglio perdere la possibilità di svilupparle nuovamente dal negativo digitale (il formato RAW) o di “ritoccarle” alla massima qualità e definizione.
I file RAW Canon hanno dal 2004 l’estensione CR2; anche se una piccola anteprima è immagazzinata nel file raw stesso, selezionando RAW+JPG vengono prodotti fisicamente 2 files, ovvero un file row CR2 e un’immagine JPG, la cui qualità è solitamente impostabile
(tranne che in EOS 10D, 350D, 400D, 450D, 1000D). 

Avere sempre anche il file JPG è comodo nel caso in cui non sia necessaria la fase di sviluppo o fotoritocco, ma avere due files da catalogare e valutare è abbastanza scomodo, proprio se voglio minimizzare le operazioni e i tempi di tali fasi. 

Ho quindi utilizzato le potenzialità offerte da Adobe Bridge per creare una funzionalità che mi permettesse, dopo aver categorizzato i file JPG, di riportare keywords, rating e labels anche sui relativi files CR2; tutto sommato lo scripting jsx di Bridge (o meglio della suite CS) è javascript object oriented, che si interfaccia alle API messe a disposizione dai prodotti Adobe. 

Menu delle estensioni da me scritte

Per ogni immagine selezionata viene verificato se nella stessa cartella è presente il corrispondente file raw CR2, e nel caso i metadati vengono aggiornati con quelli presenti nell’immagine JPG. Alla modifica viene creato o modificato il file XMP dei metadati: è questa la strategia di Adobe, cioè affiancare un file XML contenente tutte le informazioni aggiuntive necessarie, scelta a mio avviso felice,
poichè mi consentirà di esporarle facilmente verso altri software o anche in un database, in caso di una futura migrazione. 

Download script: MDExtensionBridgeScript_v1 

Lo script deve essere installato nell’apposita cartella “Startup Scripts” (cfr. readme.txt) e dalla prima attivazione crea il menu Scripts con le voci della figura sopra.

Riferimenti 

Canon EOS 1000D 

Canon impostazioni RAW+JPG 

http://en.wikipedia.org/wiki/Digital_asset_management DAM – Digital Asset Management

http://www.adobe.com/devnet/bridge.html   Bridge Developer Center  – CS5/CS4 SDK + Reference, Bridge CS2 Scripting Reference

http://www.creativescripting.net/BridgeScripts/barredrock.html  – Barred Rock Scripts

http://lclevy.free.fr/cr2/     Understanding What is stored in a Canon RAW .CR2 file, How and Why

Photoshop® CS4 After the Shoot – Mark Fitzgerald (Amazon.com)

100 e un consiglio per il fotografo, L’esposizione fotografica, L’illuminazione nella fotografia digitale, L’occhio del fotografo – la composizione in fotografia, Natura e paesaggi – Michael Freeman (Ed. Logos)

www.juzaphoto.com Juza Nature Photography

Ho poi securizzato il form di contatto utilizzando il plugin Fast Secure Contact Form.

Ancora qualche piccola limatura… ma lo stile del sito oramai è delineato: uno stile più pulito, un pagina più lineare e semplice da leggere.

Altopiano di Asiago 2010

Ho trascorso le ferie di fine agosto in montagna. Tornando, una decina di giorni fà, ho ricevuto una newsletter dal fornitore dell’hosting nella quale veniva fatto riferimento ad alcuni disagi subiti da alcuni utenti a causa del crash del database.

Rimanendo un po’ perplesso, ma giusto per curiosità, ho aperto col browser il mio sito, trascurato per molte settimane. 

Ho sgranato gli occhi leggendo su una pagina semi-bianca il titolo  “jhjhlooddwwd: Solo un altro sito WordPress” !

Orrore e tragedia! Pochi istanti e la conferma dei tecnici dell’Hosting provider
e ho capito che il database del mio sito era uno di quelli sfortunati, cioè si era in pratico “fumato” a causa di un grave errore hardware del server, ma soprattutto che i dati non potevano essere ripristinati!

Chi predica bene razzola male: non avevo impostato backup periodici, e l’ultimo backup che avevo fatto manualmente al DB era purtroppo abbastanza vecchio da non contenere alcuni ultimi post! Accidentaccio… il contenuto di qualche articolo, a mio avviso, era veramente interessante ed era un peccato che fosse stato perso così.

Per fortuna che alcune idee buone vengono al momento giusto: grazie alla cache delle pagine nei motori di ricerca e
grazie anche alla latenza con la quale i crawlers effettuano la scansione dei siti, sono riuscito fortunosamente a recuperare e salvare tutti i contenuti persi.
Se la velocità di scansione fosse stata più elevata, anche per esempio settimanale, avrei recuperato solo parzialmente le informazioni: non tutti i mali vengono per nuocere quindi!

Grazie allora a

 Google,  Bing e  Gigablast

non lo conoscevo, ma ho utilizzato anche Gigablast, The “Green” Search Engine, la cui server farm viene alimentata al 90% dall’energia pulita del vento.
Poi, per non affidarmi esclusivamente a backup manuali, ho creato opportuni script per il backup:
Il database non è accedibile direttamente, ma solo via Web da MySqlAdmin e accedendo precedentemente da CPanel:
certamente sono precauzioni legate alla sicurezza, ma impediscono l’implementazione di un automatismo semplice.

Utilizzando Wget in 3 passi, si riesce a scaricare un backup gzippato del DB, simulando le stesse azioni che farebbe un utente reale.

Di seguito riporto il contenuto dello script backup.sh:

-- cpanel url
cpurl=https://cp.tophost.it/
cpusr=user1
cppwd=pass1

-- mysqladmin url
dburl=$cpurl/mysql/
dbusr=database_user
dbpwd=database_pass

-- file location
d=$(dirname $0)
bkfile="backup.sql-$(date +%F).gz"
bkurl="$dburl/export.php?export_type=server&db_select%5B%5D=database_user&what=s
ql&header_comment=&sql_compat=NONE&sql_structure=structure&sql_auto_increment=1&
use_backquotes=1&sql_data=data&showcolumns=yes&extended_ins=yes&max_query_size=5
0000&hexforbinary=yes&sql_type=insert&latex_caption=yes&latex_structure=structur
e&latex_structure_caption=Struttura+della+tabella+__TABLE__&latex_structure_cont
inued_caption=Struttura+della+tabella+__TABLE__+%28continua%29&latex_structure_l
abel=tab%3A__TABLE__-structure&latex_data=data&latex_showcolumns=yes&latex_data_
caption=Contenuto+della+tabella+__TABLE__&latex_data_continued_caption=Contenuto
+della+tabella+__TABLE__+%28continua%29&latex_data_label=tab%3A__TABLE__-data&la
tex_replace_null=%5Ctextit%7BNULL%7D&csv_data=csv_data&export_separator=%3B&encl
osed=%22&escaped=%5C&add_character=%5Cr%5Cn&csv_replace_null=NULL&excel_data=exc
el_data&excel_replace_null=NULL&excel_edition=win&htmlexcel_data=htmlexcel_data&
htmlexcel_replace_null=NULL&htmlword_structure=structure&htmlword_data=data&html
word_replace_null=NULL&pdf_data=pdf_data&pdf_report_title=&xml_data=xml_data&asf
ile=sendit&filename_template=__SERVER__&remember_template=on&compression=gzip" 

/usr/bin/wget  --save-cookies=c --keep-session-cookies --http-user=$cpusr --http
-passwd=$cppwd -O $d/u1 -q $cpurl
/usr/bin/wget  --save-cookies=c1 --load-cookies=c --keep-session-cookies --http-
user=$dbusr --http-passwd=$dbpwd -O $d/u2 -q $dburl
/usr/bin/wget  --save-cookies=c2 --load-cookies=c1 --keep-session-cookies --http
-user=$dbusr --http-passwd=$dbpwd -O $d/$bkfile -q $bkurl

 
Per quanto riguarda la copia del filesystem ho utilizzato Lftp.

echo "open ftp://$login:$password@$desthost" > $tmpfile
echo "mirror -ec / $d/MIRROR/" >> $tmpfile
echo "exit" >> $tmpfile

/usr/bin/lftp -f  $tmpfile

Pomeriggio d'agosto sull'Altopiano

In questi giorni sto finendo di ri-caricare i contenuti persi. Ora, con i backup periodici schedulati e funzionanti, mi sento più tranquillo e sereno.

Riferimenti

- lftp: http://lftp.yar.ru/

- Cpanel: http://www.cpanel.net/

- MysqlAdmin: http://sourceforge.net/projects/mysql-admin/

- Altopiano di Asiago: http://www.asiago7comuni.to/it/home.htm

Introduzione

Ultimamente mi sono scontrato con la problematica di eseguire una stored procedure da una funzione SQL UDF (google: How to execute Stored procedures into a UDF function).
L’esecuzione di codice INSERT/UPDATE/DELETE/STORED PROCEDURE che alterano il contesto esterno alla funzione non è possibile by design; è possibile solo apportare modifiche a variabili locali definite nella funzione. Infatti appena tentiamo di alterare il contesto del database otteniamo uno dei seguenti messaggi di errore, rispettivamente se stiamo utilizzando comandi TSQL INSERT/UPDATE/DELETE, chiamando STORED PROCEDURE o cercando di eseguire SQL dinamico:  

Invalid use of side-effecting or time-dependent operator in ‘INSERT’ within a function.  

Only functions and extended stored procedures can be executed from within a function.  

Invalid use of side-effecting or time-dependent operator in ‘EXECUTE STRING’ within a function.  

L’utilizzo delle funzioni SQL è utilizzato per leggere e applicare una certa logica ai dati letti, ma non a trasformarli o modificarli. E’difficile pensare che leggendo dei dati da una tabella con una SELECT questi vengano modificati sotto il naso.
Se ci dovessero essere logiche più complesse, come l’utilizzo di tabelle di appoggio temporanee, certo è preferibile e doveroso racchiudere il codice in una stored procedure.  

Questo in linea di principio e come best practice. 

Caching con una funzione SQL

Un caso che ho dovuto affrontare era quello dell’ottimizzazione delle performance di una serie di applicazioni. Queste, accedendo al DB, ed utilizzando gli strumenti offerti TSQL, utilizzavano tutte, in più punti e ripetutamente una certa funzione, che, accedendo a dati esterni al DB con protocollo TCP/IP, risultava particolarmente lenta a rispondere. 

Da qui l’idea di implementare un meccanismo di caching nella funzione stessa; non era assolutamente pensabile cambiare la logica
applicativa modificando il codice e le modalità di interfacciamento al DB. L’operazione doveva essere completamente trasparente per le applicazioni!  

L’algoritmo di caching può essere banalmente il seguente:  

IF (prima volta)
 BEGIN
  recupera i dati online
  memorizzali nella cache
 ELSE
  recupera i dati dalla cache
 END

Includere tale logica in una funzione SQL è semplice…
Peccato che il significato di memorizzare i dati è quello di utilizzare un’istruzione del tipo INSERT/UPDATE/ST.PROCEDURE e che quindi modifica il contesto esterno alla funzione.  

Nel seguito espongo la soluzione di come eseguire una stored procedure in una funzione, descrivendo i passi utili a creare una logica di caching sopra descritta.  

Immaginiamo di avere una funzionalità di basso livello (my_very_slow_function) che, dopo essersi connessa con un tal sistema autorizzativo, restituisca i ruoli associati ad un utente.
Vogliamo utilizzare questa funzionalità in una funzione di più alto livello (my_function) che incapsuli la logica (quindi una funzione wrapper)  

CREATE FUNCTION [dbo].my_very_slow_function(@login nvarchar(50))
RETURNS TABLE
AS
RETURN
(  
 SELECT 'Administrator' as Role,0 as Type UNION
 SELECT 'Contributor', 0 UNION   
 SELECT 'Public role', 0 UNION   
 SELECT @login, 1
)

SELECT type,role FROM [dbo].my_very_slow_function('DOMAIN\testuser') ORDER BY type,role
type role
0    Administrator
0    Contributor
0    Public role
1    DOMAIN\testuser

CREATE FUNCTION [dbo].[my_function](@login nvarchar(50))
RETURNS
@roles TABLE (role varchar(400), type int)
AS
BEGIN
 INSERT INTO @roles (role,type)
  SELECT role,type FROM my_very_slow_function(@login)
  RETURN
END

SELECT type,role FROM [dbo].my_function('DOMAIN\testuser') ORDER BY type,role

Vogliamo quindi inserire nella funzione wrapper my_function la logica di caching. Creiamo la tabella per la cache e modifichiamo opportunamente la funzione.  

CREATE TABLE dbo.MYCACHE (
login VARCHAR(50) NOT NULL,
role VARCHAR(400) NOT NULL,
type INT NOT NULL,
ts datetime DEFAULT getdate(),
PRIMARY KEY (login,role)
)
GO
ALTER FUNCTION [dbo].[my_function](@login nvarchar(50))
RETURNS
@roles TABLE (role varchar(400), type int)
AS
BEGIN
 INSERT INTO @roles (role,type)
  SELECT role,type FROM dbo.MYCACHE
  WHERE login = @login
 IF @@ROWCOUNT = 0
 BEGIN  
  INSERT INTO [dbo].MYCACHE (login,role,type)
   SELECT @login,role,type FROM my_very_slow_function(@login)
  INSERT INTO @roles (role,type)
   SELECT role,type FROM dbo.MYCACHE
   WHERE login = @login
 END  
  RETURN
END

Se tentiamo di modificare la funzione in tal senso otteniamo il seguente errore:  

Msg 443, Level 16, State 15, Procedure my_function, Line 11
Invalid use of side-effecting or time-dependent operator in 'INSERT' within a function.

Cerchiamo di seguire un’altra strada: eseguire nella funzione una stored procedure contenente la logica del caching.  

CREATE PROCEDURE [dbo].MYCACHEINSERT 
 @login VARCHAR(50) 
AS
BEGIN
 INSERT INTO [dbo].MYCACHE (login,role,type)
  select @login,role,type
  FROM dbo.my_very_slow_function(@login) 
END
GO

ALTER FUNCTION [dbo].[my_function](@login nvarchar(50))
RETURNS
@roles TABLE (role varchar(400), type int)
AS
BEGIN
 DECLARE @sql NVARCHAR(400)

 INSERT INTO @roles (role,type)
  SELECT role,type FROM dbo.MYCACHE
  WHERE login = @login
 IF @@ROWCOUNT = 0
 BEGIN  
  exec dbo.MYCACHEINSERT @login

  INSERT INTO @roles (role,type)
   SELECT role,type FROM dbo.MYCACHE
   WHERE login = @login
 END  
  RETURN
END
GO

Questa volta la creazione/aggiornamento non hanno problemi ma si presenta un errore in fase di esecuzione  

SELECT type,role FROM [dbo].my_function('DOMAIN\testuser') ORDER BY type,role

Msg 557, Level 16, State 2, Line 1
Only functions and extended stored procedures can be executed from within a function.

Possiamo anche provare a modificare la funzione per farle eseguire codice SQL dinamico, e questa volta otteniamo un errore in fase di modifica.  

ALTER FUNCTION [dbo].[my_function](@login nvarchar(50))
RETURNS
@roles TABLE (role varchar(400), type int)
AS
BEGIN
 DECLARE @sql NVARCHAR(400)

 INSERT INTO @roles (role,type)
  SELECT role,type FROM dbo.MYCACHE
  WHERE login = @login
 IF @@ROWCOUNT = 0
 BEGIN  
  SELECT @sql = 'exec dbo.MYCACHEINSERT '''+@login+''''
  exec(@sql)

  INSERT INTO @roles (role,type)
   SELECT role,type FROM dbo.MYCACHE
   WHERE login = @login
 END  
  RETURN
END

Msg 443, Level 16, State 14, Procedure my_function, Line 14
Invalid use of side-effecting or time-dependent operator in 'EXECUTE STRING' within a function.

La spiegazione nella difformità di comportamento dal precedente tentativo sta nel fatto che si può usare EXEC giusto per chiamare Extended Stored Procedures, ovvero le stored procedures scritte in C e compilate. Per definizione non si può cambiare lo stato del Database da dentro la funzione UDF, e così non si può costruire SQL dinamico ed eseguirlo con la stored procedure estesa “sp_executesql” (EXEC).  

Documentandomi in Internet ho trovato un modo per eseguire uno statement SQL di aggiornamento/inserimento usando la funzione OPENQUERY e un LINKED SERVER che si autoreferenzia:  

SELECT count(*) FROM OPENQUERY(LINKED SERVER,'INSERT INTO ....')

Peccato che la stringa di testo deve essere una costante, e non è possibile sostituirla con variabili e/o espressioni.  

La via programmatica

L’unico modo by design per risolvere il problema è quello di scrivere un’extended stored procedure in C, correndo il rischio che questa non funzioni più nelle prossime versioni di SQL Server, visto che la scrittura di questo tipo di procedures è deprecata. Scrivendo una external stored procedure in C# (.NET) non si risolve il problema, visto che non viene marcata come “extended” da SQL Server e che quindi non è possibile usarla dentro una funzione UDF.  

Anche scrivendo una funzione external in C# ed eseguendo un’operazione INSERT, ottenendo la connessione dal contesto con  

SqlConnection conn = new SqlConnection("context connection= true");

otterremmo gli errori iniziali per i quali non è possibile modificare il contesto del DB. L’unico modo alla fine è quello di scrivere una funzione esterna C# ed istanziare una nuova connessione, ma sempre allo stesso database. In tal modo si inganna SQL Server, che non può più riconoscere l’eventuale modifica al contesto esterno.  

Ora apriamo Visual Studio e creiamo un nuovo progetto SQL Server “MYUDF” in C#. Nelle proprietà del progetto ricodiamoci di impostare l’opzione “Sign the assembly”.  

Poi aggiungiamo un nuovo file al progetto dti tipo Funzione UDF:  

using System;
using System.Data;
using System.Data.SqlClient;
using System.Data.SqlTypes;
using Microsoft.SqlServer.Server;

public partial class UserDefinedFunctions
{
    [Microsoft.SqlServer.Server.SqlFunction(Name = "ExecuteSQL", 

     DataAccess = DataAccessKind.Read, IsDeterministic = false)]

    public static int ExecuteSQL(SqlString sql, SqlString connstr)
    {
        using (SqlConnection conn = new SqlConnection(connstr.Value))
        {
            int res=0;
            try
            {                            
                conn.Open();               
                SqlCommand cmd = conn.CreateCommand();
                cmd.CommandText = sql.Value;               
                res = (int)cmd.ExecuteNonQuery();               
            }
            catch (Exception ex)
            {               
                throw;
            }
            finally {                               
                conn.Close();               
            }
            return res;
        }

    }
}

La funzione riceve dall’input due parametri: la stringa contenente il codice SQL e quella per la connessione ad un DB. I controlli per la sicurezza e la gestione dell’errore è stata volutamente trascurata per semplificare la lettura. Al build del progetto verrà prodotto l’assembly MYUDF.dll, che dovrà essere copiato sul database server in una certa cartella, diciamo C:\TEMP. Creiamo e carichiamo l’assembly nel DB con il comando TSQL “CREATE ASSEMBLY”:  

L’istruzione CREATE ASSEMBLY MYUDF può fallire e produrre i seguenti messaggi d’errore:  

A) Msg 10327, Level 14, State 1, Line 1   

CREATE ASSEMBLY for assembly ‘MYUDF’ failed because assembly ‘MYUDF’ is not authorized for PERMISSION_SET = UNSAFE.  The assembly is authorized when either of the following is true: the database owner (DBO) has UNSAFE ASSEMBLY permission and the database has the TRUSTWORTHY database property on; or the assembly is signed with a certificate or an asymmetric key that has a corresponding login with UNSAFE ASSEMBLY permission.  

ALTER DATABASE MYDB set trustworthy on;

B) Msg 0, Level 20, State 0, Line 0   

Errore grave durante l’esecuzione del comando corrente. Annullare i risultati eventuali.  

Questo è un BUG noto (almeno per SQL2005), basta eseguire il seguente comando: exec sp_changedbowner ‘<username of the db attacher, ‘sa’, or any windows authenticated login>’  

EXEC sp_changedbowner 'sa'

CREATE ASSEMBLY MYUDF
AUTHORIZATION [dbo] FROM 'C:\TEMP\MYUDF.dll' WITH PERMISSION_SET = UNSAFE;

CREATE FUNCTION [dbo].[ExecuteSQL](@sql [nvarchar](4000),@conn [nvarchar](200))
RETURNS int
AS EXTERNAL NAME MYUDF.[UserDefinedFunctions].ExecuteSQL

GRANT EXECUTE ON [dbo].[ExecuteSQL] TO [public]

Abbiamo appena creato la funzione UDF .NET, ed ora ci prepariamo a testarla:  

select [dbo].[ExecuteSQL]('exec dbo.MYCACHEINSERT ''WORKGROUP\user1''','Data Source=MYSERVER;Initial Catalog=MYDB;Integrated Security=False;user id=dbu;password=dbu;')

Msg 6522, Level 16, State 1, Line 1
A .NET Framework error occurred during execution of user defined routine or aggregate 'ExecuteSQL':
System.Data.SqlClient.SqlException: EXECUTE permission denied on object 'MYCACHEINSERT', database 'MYDB', schema 'dbo'.

GRANT EXECUTE ON [dbo].MYCACHEINSERT TO [dbu]

Ora che abbiamo dato i permessi “rieseguiamo” la funzione, che “magicamente” ritorna i risultati attesi. Infatti nella tabella ci sono 4 righe. Bisogna far notare che è stato creata una login specifica “dbu” per inserire i dati nella tabella di cache e solo per quello scopo. Poi integriamo la chiamata ad ExecuteSQL in my_function.  

SELECT * FROM dbo.MYCACHE
login           role            type ts
WORKGROUP\user1 Administrator   0    2010-04-25 12:08:13.513
WORKGROUP\user1 Contributor     0    2010-04-25 12:08:13.513
WORKGROUP\user1 Public role     0    2010-04-25 12:08:13.513
WORKGROUP\user1 WORKGROUP\user1 1    2010-04-25 12:08:13.513
SELECT count(*) FROM dbo.MYCACHE
4

ALTER FUNCTION [dbo].[my_function](@login nvarchar(50))
RETURNS
@roles TABLE (role varchar(400), type int)
AS
BEGIN
 DECLARE @sql NVARCHAR(400)
 DECLARE @conn NVARCHAR(200)
 DECLARE @count INT

 INSERT INTO @roles (role,type)
  SELECT role,type FROM dbo.MYCACHE
  WHERE login = @login
 IF @@ROWCOUNT = 0
 BEGIN  
  SELECT @sql = 'exec dbo.MYCACHEINSERT '''+@login+'''',
   @conn = 'Data Source=MYSERVER;Initial Catalog=MYDB;Integrated Security=False;user id=dbu;password=dbu;'
  SELECT @count = [dbo].[ExecuteSQL] (@sql,@conn)

  INSERT INTO @roles (role,type)
   SELECT role,type FROM dbo.MYCACHE
   WHERE login = @login
 END  
  RETURN
END

SELECT type,role FROM [dbo].my_function('DOMAIN\testuser') ORDER BY type,role
type role
0    Administrator
0    Contributor
0    Public role
1    DOMAIN\testuser

SELECT count(*) FROM dbo.MYCACHE
8

CREATE FUNCTION [dbo].[my_function2](@login nvarchar(50),@param1 varchar(50))
RETURNS TABLE
AS
RETURN
( 
 SELECT count(*) as N, @param1 as M FROM [dbo].my_function(@login)  
)
SELECT * FROM [dbo].[my_function2]('DOMAIN\test2','param')
N M
4 param

Continuando a sperimentare

Di seguito espongo una problematica che ho incontrato nell’utilizzare la tecnica sopra esposta in una stored procedure che utilizza un oggetto non locale quale una tabella temporanea (ricordo che è comunque una TABLE nel tempdb). Con simili oggetti si verrebbe a creare una transazione distribuita, ma SQL Server, capendo che la connessione istanziata dal codice .NET, individua un conflitto di sessioni. E da qui il messaggio di errore di cui sotto.

CREATE PROCEDURE [dbo].[my_procedure]  
 @login varchar(50),
 @param1 varchar(50)
AS
BEGIN 
 SET NOCOUNT ON;
 SELECT count(*) as N, @param1 as M FROM [dbo].my_function(@login)  
END
exec [dbo].[my_procedure] 'DOMAIN\test2','param'
N M
4 param

ALTER PROCEDURE [dbo].[my_procedure]  
 @login varchar(50),
 @param1 varchar(50)
AS
BEGIN 
 SET NOCOUNT ON;
 SELECT count(*) as N, @param1 as M INTO #temp FROM [dbo].my_function(@login)  
 SELECT * FROm #temp
END
GO
exec [dbo].[my_procedure] 'DOMAIN\test5','param'

Msg 6522, Level 16, State 1, Procedure my_procedure, Line 7
A .NET Framework error occurred during execution of user defined routine or aggregate 'ExecuteSQL':
System.Data.SqlClient.SqlException: Transaction context in use by another session.

La soluzione è più semplice del previsto: poichè SQL Server tenta implicitamente di costruire una transazione distribuita, il workaround è quello di inibire a priori tale possibilità attraverso il parametro opzionale Enlist nella connectionstring. E infatti, dopo la modifica della stringa di connessione, l’esecuzione funziona come ci si aspetta, ritornando i valori aspettati.

ALTER FUNCTION [dbo].[my_function](@login nvarchar(50))
RETURNS
@roles TABLE (role varchar(400), type int)
AS
BEGIN
 DECLARE @sql NVARCHAR(400)
 DECLARE @conn NVARCHAR(200)
 DECLARE @count INT

 INSERT INTO @roles (role,type)
  SELECT role,type FROM dbo.MYCACHE
  WHERE login = @login
 IF @@ROWCOUNT = 0
 BEGIN  
  SELECT @sql = 'exec dbo.MYCACHEINSERT '''+@login+'''',
   @conn = 'Data Source=MYSERVER;Initial Catalog=MYDB;Integrated Security=False;user id=dbu;password=dbu;Enlist=no'
  SELECT @count = [dbo].[ExecuteSQL] (@sql,@conn)

  INSERT INTO @roles (role,type)
   SELECT role,type FROM dbo.MYCACHE
   WHERE login = @login
 END  
  RETURN
END

exec [dbo].[my_procedure] 'DOMAIN\test7','param'

N M
4 param 

Conclusioni

L’utilizzo di stored procedures in funzioni è inibito in SQL Server by design, ma creando una external UDF in C#.NET è possibile aggirare l’ostacolo. E’stato presentato il codice e un esempio di come implementare il caching per una funzione “lenta”.   

Sviluppare ed implementare un sito o un’applicazione web è un processo creativo che può essere più o meno interessante e quindi più o meno divertente…

E quando finisce il divertimento cominciano i grattacapi! Sicuramente qualcuno nel management o il cliente che ha commissionato il progetto o forse noi stessi vorremmo conoscere quantitativamente le sue prestazioni, in termini di tempi di risposta in funzione del numero di utenti.

Infine potremo arrivare a determinare la capacità del sito, ovvero il numero massimo di richieste/sec aventi tempi di risposta decenti (ovvero prima il numero di utenti appena prima del degrado/collasso del sistema)

Quindi dopo aver sviluppato e pubblicato un sito o una web application conviene affrontare l’annoso problema dei test di carico e della simulazione realistica delle navigazioni degli utenti per:

• vedere  come si comporta il sistema
•  se sussitono colli di bottiglia, aree o sottosistemi dove è possibile ottimizzare qualcosa 
• dove è meglio iniziare ad effettuare il cosiddetto tuning.

Allo scopo si possono trovare vari tools commerciali e opensource.
E’ possibile trovare una lista abbastanza esaustiva dei software all’url http://www.softwareqatest.com/qatweb1.html.

Nell’ultima esperienza personale, non avendo (mai) molto tempo a disposizione mi sono concentrato su alcuni software grafici e interfacciabili con i sistemi Windows Server:
- l’ottimo ma assi costoso Neoload, che permette di controllare e verificare graficamente  tutte le fasi del processo dal design alla fase di test e l’analisi dei risultati
- gratuitamente in casa Microsoft si trovano WCAT (Web Capacity Analysis Tool), largamente programmabile ma solo tramite script,
e WAST (Web Application Stress Tool – Homer ), il ben noto ma vetusto tool grafico.

WAST (o WAS) è uno strumento di simulazione e di carico sviluppato e rilasciato molti anni or sono da Microsoft, ma è un piccolo gioiellino, poichè permette di controllare e verificare graficamente tutte le fasi del processodi test:

• la registrazione visuale della navigazione effettuata con il browser
• la creazione dei profili delle pagine di test
• la definizione degli utenti
• la distribuzione delle tipologie di test
• la definizione del pool di macchine che partecipano al test di carico
• la definizione dei contatori (performance counter) delle macchine oggetto di test
• la gestione del test vero e proprio, ovvero lo stress del sito o dell’applicazione web
• la collezione e l’elaborazione dei risultati, anche se in forma testuale.

Purtroppo WAST è supportato ufficialmente solo su Microsoft Windows NT 4.0 SP 4+ e Microsoft Windows 2000, sistemi operativi che ormai non esistono (quasi) più negli ambiti di produzione.

L’installazione su Windows XP và praticamente sempre a buon fine, ed eseguendo WAST si possono sperimentare da subito le varie funzionalità tranne due:

• non funzionano performance counter
• non funziona la comunicazione con i client del pool

Su Windows Vista invece si ottiene da subito un errore (Steve Schofield Weblog – WAST on Vista ), ma basta caricare il file msvcp50.DLL in c:\windows\system32 (poiché non è compreso di default nel SO).

Vista l’indubbia utilità dell’applicazione, mi sono intestardito nel far funzionare WAST anche sui SO più recenti…e alla fine, dopo un po’ di analisi e troubleshooting ci sono riuscito.

Performance counters

Per far funzionare la finestra di ricerca e di aggiunta dei performance counters delle macchine remote, nonchè il polling dei valori a runtime, basta copiare nella directory del programma il file pdh.dll, che si trova nella distribuzione di Windows 2000, e che è infatti la libreria che contiene le funzioni per i contatori.

Sicuramente WAS è stato compilato nel 2000 utilizzando quella versione di libreria (5.0.2174.1), mentre su XP c’e’ quella nuova (5.1.2600.3536)

Clients

Bisogna tenere presente che WAST è un tool client/server: l’interfaccia client (hclient.exe) colloquia localmente e/o remotamente (con tecnologia DCOM) con un windows service (webtool.exe); inoltre i dati sono resi persistenti su un database access.

Per far funzionare la comunicazione con i client definiti nel pool bisogna quindi  “giocare” con i pemessi DCOM (dcomcnfg.exe).

Si deve ricordare inoltre che, la comunicazione ed in generale i sistemi Microsoft prima del SP2 di Windows XP non erano securizzati di default, e quindi, per far funzionare il nostro WAST su XP, bisogna “rilassare” un pochino la sicurezza.

Procedimento:

1. Eseguire dcomcnfg.exe
2. Visualizzare le Proprietà di Servizi Componenti – Computer – Risorse Computer
3. Nel Tab Proprietà predefinite selezionare la casella Abilita servizi Internet COM in questo computer (che di default è deselezionato)
4. Nel Tab Protezione COM: Modificare i Limiti delle autorizzazioni di accesso abilitare per l’ACCESSO ANONIMO l’accesso remoto;
   Modificare i Limiti delle autorizzazioni di esecuzione e attivazione  abilitare per Everyone l’avvio remoto e l’attivazione remota
5. Entrare nel dettaglio dei componenti DCOM e aprire le Proprietà di “WebTool”: personalizzare eventualmente le ACL in modo tale che Everyone possa avviare ed attivare remotamente il componente

E il gioco è fatto! Provare per credere…

Risorse

- Dll aggiuntive per WAST su XP

- Web Application Stress Tool (compressed with 7zip)

- DCOM Settings for WAST on XP

Riferimenti

- How To Install and Use the Web Application Stress (WAS) Tool

http://support.microsoft.com/kb/313559/en-us

- Introducing Microsoft Web Application Stress Tool (BY Jigesh Shah)

http://www1bpt.bridgeport.edu/sed/projects/cs597/Fall_2002/jishah/web_application_stress.htm

- Load Testing Web Applications using Microsoft’s Web Application Stress Tool (By Rick Strahl)

http://www.code-magazine.com/article.aspx?quickid=0001091&page=1

- Download Microsoft Web Application Stress Tool – Homer:

http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1298

- Steve Schofield Weblog – WAST on Vista

http://weblogs.asp.net/steveschofield/archive/2007/03/10/iis7-post-32-web-application-stress-tool-on-vista.aspx

- Recentemente c’e’ stato qualche problema a reperire WAST sul sito Microsoft download, per cui allego il setup, almeno finchè rimarrano tali problemi. ( N.B. nel caso ci fossero problemi di decompressione è stato compresso con 7zip).

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 server SQLSERVER1 (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

Custodivo la maggior parte dei dati sul mio buon vecchio (3 anni oramai) LACIE, un disco esterno USB da 250 GB. Solitamente faccio backup frequenti per i files di progetto e le fotografie digitali su DVD-ROM, ma nulla per quanto riguarda i montaggi dei filmati AVI, essendo questi di dimensioni spropositate: 50-60 GB complessivamente tra i files originali scaricati dalla videocamera digitale JVC, il montato, i files di contorno e i files temporanei… D’altronde per backuppare tutto ciò ci vorrebbe un’unità nastro o un altro disco fisso; e poi i tempi di backup non sarebbero proprio istantanei…

Lacie unità esterna

E la perdita dei dati a causa della rottura del disco è per me in generale una cosa tremenda!Così, per razzolare bene ed evitare la perdita dei suddetti montaggi video, ho acquistato un’unità esterna che implementasse la tecnologia RAID 1, ovvero la copia real-time dei dati (a livello di byte) tra due dischi. In questo modo, pur rimanendo la problematica del backup, ho aumentato l’integrità dei dati e la tolleranza ai guasti del disco.Ho acquistato un Mapower TB32, cioè un’unità esterna che espone al Sistema Operativo un unico disco (il mirror), mentre invece internamente ci sono 2 dischi SATA che lavorano in parallelo. La configurazione è semplice e viene effettuata solo in hardware tramite un jumper e lo stato dei  dischi è visualizzato tramite i led sul pannello frontale. Le connessioni esterne sono USB ed eSATA

Enclosure TB32 raid1

La sceneggiatura (alla Bill Maxwell) prevedeva quindi la copia dei dati tra le due unità USB. E la copia di 200 GB  non è una cosa da farsi con Windows Explorer, che è estremamente lento ed in caso di errori si ferma a metà.

Ho utilizzato invece Killcopy, un programma freeware che accellera la copia tra files sfruttando parallellismo e grandi buffer di memoria; inoltre può effettuare una verifica dei bytes scritti (utile nelle copie in rete), riservare lo spazio prima della copia effettiva (per ridurre la frammentazione del file) ed essere utilizzato dalla command line.  Cito brevemente  Teracopy, un altro programma con le stesse caratteristiche, disponibile gratuitamente per usi non commerciali.

E nel bel mezzo della copia massiva, dopo un centinaio di GB copiati,  ecco comparire i primi problemi: errori CRC, dovuti probabilmente a settori danneggiati o illeggibili… Non mi preoccupavo, finché questi comparivano su alcuni file thumb.db o su qualche foto già backuppata; mi sono seriamente preoccupato quando, ad un certo punto è comparso il popup di alert Disco non inizializzato, formattare il disco!

Ovviamente non ho seguito il suggerimento di Windows, e mi sono buttato freneticamente nell’attività di data recovery.

Il disco veniva riconosciuto tra le periferiche rimuovibili, la partizione del disco veniva riconosciuta dal Sistema come RAW, non più come NTFS, e questo significava che si era danneggiata l’area del disco dove risiedeva la MFT, quindi non l’elettronica o le meccaniche del disco.

Tutto sommato la situazione non era cosè catastrofica: quello che mi interessava veramente l’avevo già copiato e poi avevo alcuni backup delle foto e del software sviluppato; non mi ricordavo se mancava ancora qualche file…

Alla fine ho utilizzato GetDataBack for NTFS, un eccellente programma commerciale per il recupero dei dati: di fatto analizza i settori del disco alla ricerca di record e pezzi di directory; poi permette il salvataggio dell’indice così ricostruito su un file, in modo tale da poter accedere velocemente ai dati del disco anche in un secondo momento senza dover ripetere l’analisi. 

Alla fine ritengo di aver recuperato il 99% dei dati presenti sul disco USB, e comunque il 100% di ciò che mi interessava veramente.

Una storia comunque finita bene, anche se mi ha fatto sudare freddo perdendo un po’di tempo durante il week-end, e che mi ha dato ragione sull’importanza delle politiche di backup e salvaguardia dei dati per mezzo della tecnologia Raid.

L’idea è stata presa dai siti di Micorsoft Office Sharpoint 2007 (MOSS): di default l’accesso viene effettuato con l’utente corrente di dominio; al bisogno è presente un link nel menù per cambiare l’utente connesso; viene presentato quindi il popup standard per l’immissione delle credenziali, dopo la nuova autenticazione l’utente viene ripresentata la pagina corrente…

I requirement erano simili, ovvero l’utente Windows connesso all’applicazione asp.net su IIS non doveva essere necessariamente quello loggato sulla macchina con il CTRL+ALT+CANC. La problematica è connessa anche col fatto che i siti di una intranet sono tutti trusted di default, per cui Explorer effettua tramite la Windows Authentication un’autenticazione implicita (single sign-on). 

I vantaggi del cambiamento di profilo sono palesi: l’utente non deve scollegarsi e riconnettersi a Windows, chiudendo tutte le applicazioni, oppure eseguire Internet Explorer con l’opzione “Run as”; deve solo cliccare un link…

Il trucco sta nello spedire al browser uno status code 401 “Access denied”, per cui il browser richiede all’utente ulteriori credenziali e richiama la pagina nuovamente.

Nella pagina desiderata, o nella master page, inserire il link alla pagina del cambio utente:

<a href="AccessDenied.aspx?loginasanotheruser=true">Cambio profilo</a>

In AccessDenied.aspx  
 

<%@ Page Language="C#" autoeventwireup="true"%>

<%

if (Session.IsNewSession)  Response.Redirect("default.aspx", true);

Session.Abandon();

Response.StatusCode = 401;

Response.StatusDescription = "Access Denied";

%>

Questa pagina controlla se la sessione è appena stata creata, e nel qual caso reinvia l’utente, che si è appena autenticato ad IIS, alla home page. Viceversa viene reimpostato lo status cose a 401. Il client richiede nuovamente le credenziali e la pagina aspx viene eseguita nuovamente solo se queste sono valide (è IIS infatti che effettua questa verifica).

Al posto di redirezionare il client alla home page è possibile ritornare sulla pagina appena precedente; basta passare a AccessDenied.aspx un parametro con il valore di window.location; ma questa è un’altra storia…

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)