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”.   

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

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)

E’ altresì comoda la disabilitazione temporanea quando si deve svuotare (totalmente o parzialmente) una tabella per effettuarne il carico tramite BCP. Dopo aver disabilitato le foreign keys, visto che comunque non è possibile effettuare il truncate (essendo queste ultime ancora presenti sebbene disabilitate), è possibile effettuare le DELETE selettive o sull’intera tabella.  Ovviamente in presenza di milioni di righe nella tabella consiglio di SCRIPTARE i constraints, DROPPARLI, effettuare il TRUNCATE, e RICREARLI.

Se volessimo effettuare la disabilitazione complessiva dei constraints su tutto il DB basterebbe eseguire la seguente stored procedure:

EXEC sp_MSForEachTable 'ALTER TABLE ? NOCHECK CONSTRAINT ALL'

e per la riabilitazione:

EXEC sp_MSForEachTable 'ALTER TABLE ? CHECK CONSTRAINT ALL'

Se viceversa volessimo disabilitare tutti i constraint di una singola tabella dovremmo usare:

ALTER TABLE tableName NOCHECK CONSTRAINT ALL

e per l’abilitazione:

ALTER TABLE tableName CHECK CONSTRAINT ALL

Di seguito riporto uno script TSQL che genera il codice per disabilitare selettivamente ogni singolo constraint del DB:

DECLARE @String as varchar(max)
SELECT @String = ''+char(13)+char(10);

SELECT @String = @String +
   'ALTER TABLE ['+schema_name(so.schema_id)+'].['+object_name(so.parent_object_id)+
   '] NOCHECK CONSTRAINT [' + so.name +']' + char(13)+char(10)
FROM sys.objects so
where so.type in ('F')

SELECT @String = @String + char(13)+char(10)

SELECT
@String = @String +
   'DELETE FROM ['+schema_name(so.schema_id)+'].['+ so.name + ']'+char(13)+char(10)
FROM sys.objects so
where so.type in ('U')

SELECT @String = @String + char(13)+char(10)

SELECT @String = @String +
   'ALTER TABLE ['+schema_name(so.schema_id)+'].['+object_name(so.parent_object_id) +
   '] CHECK CONSTRAINT [' + so.name +']' + char(13)+char(10)
FROM sys.objects so
where so.type in ('F')

SELECT  1 AS TAG, 0 AS PARENT, @String
            as [SqlCommand!1!!cdata]
FOR XML
EXPLICIT, xmldata

Viene generata una riga XML (unico tipo di dati testuale che viene visualizzato per intero nel Management Studio), dentro alla sezione CDATA troviamo lo script TSQL suddiviso in tre parti:

• vengono dapprima disabilitati i constraints (ALTER TABLE … NOCHECK …)
• poi vengono effettuate le operazioni, in questo caso DELETE
• vengono riabilitati i constraints (è stato modificata l’istruzione da NOCHECK a CHECK)

Riporto anche uno stralcio dell’output

ALTER TABLE [dbo].[Applicazioni] NOCHECK CONSTRAINT [FK_Applicazioni_Ambiti]
ALTER TABLE [dbo].[Applicazioni] NOCHECK CONSTRAINT [FK_Applicazioni_Fornitori]

DELETE FROM [dbo].[Ambiti]
DELETE FROM [dbo].[Fornitori]
DELETE FROM [dbo].[Applicazioni]

ALTER TABLE [dbo].[Applicazioni] CHECK CONSTRAINT [FK_Applicazioni_Ambiti]
ALTER TABLE [dbo].[Applicazioni] CHECK CONSTRAINT [FK_Applicazioni_Fornitori]

Esistono in internet degli script (ne viene riportato sotto uno stralcio) che modificano la collation degli oggetti contenuti nel DB (tabelle, colonne, viste, ecc.) e infine quella del DB stesso (utilizzando iterativamente dapprima ALTER TABLE tablename ALTER COLUMN columnname COLLATE default, ed infine ALTER DATABASE databasename COLLATE default). Funzionano in casi semplici, ma ci sono seri problemi quando la struttura del DB non è banale, ovvero sono presenti anche oggetti complessi (funzioni, foreign keys, trigger, indici, librerie, ecc. con le relative dipendenze), che devono essere droppati e ricreati.

La soluzione più semplice per migrare un database senza mantenere la collation originale da SERVER1 a SERVER2 è quella che descrivo nel seguito; i passi sono 3:

1. scriptare il DB (e tutti gli oggetti contenuti) senza generare le collation sulla prima istanza.
2. eseguire tale script sulla seconda istanza
3. esportare ed importare i dati di tutte le tabelle con l’utility BCP

I primi due passi sono banali. Per automatizzare il terzo, ho sviluppato il seguente script: in funzione del database MyDatabase scelto, l’obiettivo è quello di generate tutte le istruzioni BCP, una per ogni tabella (nel relativo schema) con i corretti parametri.

use MyDatabase
DECLARE @srv_source varchar(50)
DECLARE @srv_destination varchar(50)
DECLARE @dbname varchar(50)
DECLARE @tmp varchar(max)
SELECT @dbname = db_name(), @tmp =char(13)+char(10),
           @srv_source = 'SERVER1', @srv_destination = 'SERVER2'

select @tmp = @tmp + 'bcp '+@dbname+'.'+schema_name(so.schema_id)+ '.'+so.name +
' out '+so.name+'.dat -c -T -q -S '+ @srv_source + char(13)+char(10) +
'bcp '+@dbname+'.'+schema_name(so.schema_id)+ '.'+so.name +
' in '+so.name+'.dat -c -T -E -q -S '+ @srv_destination + char(13)+char(10)
from sys.objects so where so.type ='U'

SELECT  1 AS TAG, 0 AS PARENT, @tmp
            as [SqlCommand!1!!cdata]
FOR XML
EXPLICIT, xmldata

• Sostituire MyDatabase col nome del database effettivo.
• Eseguire lo script col Management Studio: viene prodotto come unico risultato un campo XML; al suo interno, internamente al tag <SqlCommand> si troveranno tutte le istruzioni BCP.
• Inserire tali istruzioni in un file .cmd (es. migrazione.cmd) appena creato. Spostare il file su SERVER2.
• Eseguire il batch con un’utenza Windows avente opportuni diritti  sui database di entrambe le istanze SQL Server. Nel caso si voglia utilizzare l’autenticazione SQL, basta sostituire nello script il parametro “-T” con le opzioni “-U login -P password”

Per esempio eseguendo lo script TSQL, viene generato il seguente output:

<Schema name="Schema1" xmlns="urn:schemas-microsoft-com:xml-data" 
xmlns:dt="urn:schemas-microsoft-com:datatypes">
  <ElementType name="SqlCommand" content="mixed" model="open"></ElementType>
</Schema>
<SqlCommand xmlns="x-schema:#Schema1"><![CDATA[
bcp MYDATABASE.dbo.Software out Software.dat -c -T -q -S SERVER1
bcp MYDATABASE.dbo.Software in Software.dat -c -T -E -q -S SERVER2

bcp MYDATABASE.dbo.Ambiti out Ambiti.dat -c -T -q -S SERVER1
bcp MYDATABASE.dbo.Ambiti in Ambiti.dat -c -T -E -q -S SERVER2
bcp MYDATABASE.dbo.Fornitori out Fornitori.dat -c -T -q -S SERVER1
bcp MYDATABASE.dbo.Fornitori in Fornitori.dat -c -T -E -q -S SERVER2
]]></SqlCommand>

Nota: l’utility BCP viene qui utilizzata per esportare i dati in file plain/text. Nella fase di importazione i valori dei campi identity vengono mantenuti (-E) e il relativo seme viene riallineato correttamente; i check constraints, i triggers, le foreign keys, nella fase di importazione vengono temporaneamente disabilitati (per default)

Giusto per soddisfare la curiosità, riporto un breve script utilizzato per generare le istruzioni TSQL per modificare le collation di tutte le colonne di tutte le tabelle.

USE MyDatabase
GO
SET NOCOUNT ON
/*Find database default*/
DECLARE @name sysname,
@Collate VARCHAR(50)
SET @name =DB_NAME(7)
-- These props only available if db not shutdown
SET @Collate =
(SELECT CONVERT (sysname, DATABASEPROPERTYEX (@name,'Collation')))
SELECT 'ALTER TABLE '+ TABLE_NAME +' ALTER COLUMN '+ COLUMN_NAME
+' '+ DATA_TYPE +'('+CAST(CHARACTER_MAXIMUM_LENGTH ASVARCHAR(10))+') '
+'COLLATE '+ @Collate +  (
CASE IS_NULLABLE
WHEN 'NO' THEN' NOT NULL'
WHEN 'YES' THEN' NULL'
END
)
FROM INFORMATION_SCHEMA.columns
WHERE TABLE_NAME <>'dtproperties'
AND COLLATION_NAME NOT LIKE @Collate
ORDER BY COLUMN_NAME

Riferimenti:

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

http://msdn.microsoft.com/en-us/library/ms162802.aspx

http://www.sqlserverspecialists.co.uk/blog/_archives/2007/10/31/3326039.html

Backuppare i backup in un ambiente di produzione è un esigenza indiscutibile; in questo caso la tipologia di backup prescelta è quella full, che può essere tranquillamente utilizzata per DB di piccole e medie dimensioni, ma che può essere modificata per esigenze diverse. I backup vengono salvati nella cartella C:\BACKUP\SQL\.

Da notare che un backup automatizzato tramite script di tutti i DB presenti sull’istanza minimizza sicuramente l’intervento amministrativo.

DECLARE @dbid int
DECLARE @dbname varchar(100)
DECLARE @sql varchar(1000)

DECLARE curs CURSOR LOCAL FORWARD_ONLY FOR
select database_id, [name] from msdb.sys.databases where name <> ''tempdb''
OPEN curs
FETCH NEXT FROM curs INTO @dbid, @dbname
WHILE @@FETCH_STATUS = 0
BEGIN

SET @sql = ''BACKUP DATABASE [''+@dbname+''] TO 

DISK = N''''C:\BACKUP\SQL\''+@dbname+''.bak''''
WITH NOFORMAT, INIT,  NAME = N''''''+@dbname+''-Full Database Backup'''',
SKIP, NOREWIND, NOUNLOAD,  STATS = 10''

RAISERROR(N''Executing... %s'',2,-1,@sql)
EXEC( @sql )
FETCH NEXT FROM curs INTO @dbid, @dbname
END

Lo script può facilmente essere integrato in un JOB e schedulato ogni notte. Di seguito riporto l’intero script per creare il JOB, lo STEP TSQL e la SCHEDULAZIONE relativa; ho evidenziato il codice precedente presente proprio nella creazione dello Step. Faccio notare che tutto l’output dello script viene appeso nel file C:\BACKUP\SQL\history.txt a mo’ di log.

USE [msdb]
GO

BEGIN TRANSACTION
DECLARE @ReturnCode INT
SELECT @ReturnCode = 0

IF NOT EXISTS (SELECT name FROM msdb.dbo.syscategories
WHERE name=N'[Uncategorized (Local)]' AND category_class=1)
BEGIN
EXEC @ReturnCode = msdb.dbo.sp_add_category
  @class=N'JOB',
  @type=N'LOCAL',
  @name=N'[Uncategorized (Local)]'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback

END

DECLARE @jobId BINARY(16)
EXEC @ReturnCode =  msdb.dbo.sp_add_job
  @job_name=N'BACKUP FULL DB (Tutti i DB definiti sul questa istanza)',
  @enabled=1,
  @notify_level_eventlog=0,
  @notify_level_email=0,
  @notify_level_netsend=0,
  @notify_level_page=0,
  @delete_level=0,
  @description=N'Script per eseguire il backup FULL di tutti i database',
  @category_name=N'[Uncategorized (Local)]',
  @owner_login_name=N'sa', @job_id = @jobId OUTPUT

IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback

EXEC @ReturnCode = msdb.dbo.sp_add_jobstep
  @job_id=@jobId,
  @step_name=N'LIST AND BACKUP ALL DATABASES',
  @step_id=1,
  @cmdexec_success_code=0,
  @on_success_action=1,
  @on_success_step_id=0,
  @on_fail_action=1,
  @on_fail_step_id=0,
  @retry_attempts=0,
  @retry_interval=0,
  @os_run_priority=0, @subsystem=N'TSQL',
  @command=N'
DECLARE @dbid int
DECLARE @dbname varchar(100)
DECLARE @sql varchar(1000)

DECLARE curs CURSOR LOCAL FORWARD_ONLY FOR
select database_id, [name] from msdb.sys.databases where name <> ''tempdb''
OPEN curs
FETCH NEXT FROM curs INTO @dbid, @dbname
WHILE @@FETCH_STATUS = 0
BEGIN

SET @sql = ''BACKUP DATABASE [''+@dbname+'']
TO  DISK = N''''C:\BACKUP\SQL\''+@dbname+''.bak''''
WITH NOFORMAT, INIT,  NAME = N''''''+@dbname+''-Full Database Backup'''',
SKIP, NOREWIND, NOUNLOAD,  STATS = 10''

RAISERROR(N''Executing... %s'',2,-1,@sql)
EXEC( @sql )
FETCH NEXT FROM curs INTO @dbid, @dbname
END

',
  @database_name=N'msdb',
  @output_file_name=N'C:\BACKUP\SQL\history.txt',
  @flags=6
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_update_job @job_id = @jobId, @start_step_id = 1
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_add_jobschedule
  @job_id=@jobId,
  @name=N'Ogni notte',
  @enabled=1,
  @freq_type=4,
  @freq_interval=1,
  @freq_subday_type=8,
  @freq_subday_interval=23,
  @freq_relative_interval=0,
  @freq_recurrence_factor=0,
  @active_start_date=20080506,
  @active_end_date=99991231,
  @active_start_time=20000,
  @active_end_time=235959

IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_add_jobserver
        @job_id = @jobId, @server_name = N'(local)'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
COMMIT TRANSACTION
GOTO EndSave
QuitWithRollback:
    IF (@@TRANCOUNT > 0) ROLLBACK TRANSACTION
EndSave:

Il codice completo di backup_automatizzato dei DB di un’istanza SQL Server è scaricabile a questo link e faclimente  utilizzabile con copia e incolla in SQL Management Studio.