Stiamo usando Kerberos?
Utilizzando l'autenticazione integrata per accedere ad una istanza di SQL Server può capitare che nell'application log vengano registrati una serie di eventi simili a questo riportato di seguito
Event Type: Information
Event Source: MSSQLSERVER
Event Category: (2)
Event ID: 26037
Date: 23/08/2007
Time: 6.08.15
User: N/A
Computer: SCRMIPSQLV1
Description:
The SQL Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x2098, state: 15. Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies.
Benchè si tratti di un messaggio puramente informativo è bene accertare le cause per le quali l'autenticazione avviene utilizzando il protocollo NTLM anzichè il più recente (e sicuro) Kerberos. Le cause sono da ricercare essenzialmente nel fatto che in Active Directory non è stato registrato il Service Principal Name (SPN) relativo all'istanza in questione e si rende necessario registrarlo manualmente utilizzando il tool SetSPN.exe, prelevabile dal Resource Kit di Windows Server 2000/2003, come indicato in questo articolo della kb.
Una volta definito il SPN è possibile interrogare la sys.dm_exec_connections e a partire da questo momento, per tutte le nuove connessioni, il campo auth_scheme dovrebbe restituire il valore 'kerberos'.
Se la DMV ci rivela che alcune connessioni utilizzano ancora il protocollo NTLM ciò potrebbe dipendere dal fatto che il client ed il server sono separati da un apparato di rete che filtra in qualche modo le porte utilizzate da kerberos e/o che l'utente ed il database server appartengono a domini di foreste differenti.
Bye