Nella mia esperienza, la configurazione di un SQL Server per l’autenticazione Kerberos, in particolare un’istanza denominata SQL Server, può essere una delle cose più confuse da fare per un DBA o un amministratore di sistema la prima volta. Il motivo per cui può essere così confuso è che ci sono diverse “parti mobili” che devono essere tutte sincronizzate affinché l’autenticazione Kerberos funzioni. E ciò che può rendere le cose ancora più confuse è che in generale, se non tocchiamo nulla, le persone e le applicazioni possono connettersi ai nostri server di database ma non appena iniziamo la strada della configurazione dell’autenticazione Kerberos, possono improvvisamente ” t. E può essere piuttosto frustrante capire perché. In questo articolo vedremo sia i come che i perché.

Se non faccio nulla, perché di solito funziona?

Quando si tratta di autenticare un accesso (controllando per vedere se sei chi dici di essere), SQL Server esegue l’autenticazione solo quando l’accesso è basato su SQL Server. Ho scelto le mie parole con attenzione qui, perché è importante capire che quando si tratta di un accesso basato su Windows, SQL Server passa l’autenticazione a un componente del sistema operativo, l’interfaccia del provider di supporto di sicurezza di Windows (SSPI). Ecco perché quando si verificano errori di autenticazione Kerberos, di solito viene visualizzato un messaggio sul contesto SSPI. Fondamentalmente, SQL Server si rende conto che è un account di accesso a Windows, ottiene le informazioni che dovranno passare in modo che SSPI possa fare i suoi controlli, quindi attende di vedere cosa dice SSPI. Se SSPI afferma che l’accesso è corretto, SQL Server consente all’account di accesso di completare la connessione. Se SSPI dice che l’accesso è errato,SQL Server rifiuta l’accesso e restituisce qualsiasi informazione di errore fornita da SSPI. Ora, c’è un’eccezione a SQL Server che coltiva l’autenticazione di Windows su SSPI, ma si verifica in Named Pipes e quindi non ci entreremo perché speriamo che tu non stia usando Named Pipes come protocollo.

Una volta compreso che SQL Server sta cedendo la responsabilità dell’autenticazione a SSPI, è tempo di capire cosa farà SSPI. SSPI proverà innanzitutto ad autenticarsi utilizzando Kerberos. Questo è il protocollo preferito per Windows 2000 e versioni successive. Per fare ciò, è necessario che sia presente un nome principale di servizio (SPN). Ne parleremo più tardi. Se non c’è SPN, Kerberos non può succedere. Se Kerberos non può verificarsi a causa della mancanza di SPN o di un altro motivo (tra foreste senza attendibilità a livello di foresta), SSPI tornerà al vecchio protocollo di sicurezza, NT LAN Manager o NTLM. Quindi, se non facciamo nulla, l’autenticazione tornerà a NTLM e tutto tende a funzionare. Cioè, fino a quando non dobbiamo fare più “salti”,come tramite SQL Server Reporting Services impostato su un server separato o quando vogliamo eseguire l’autenticazione di Windows attraverso una connessione al server collegato (vedere la Figura 1).

Nella Figura 1, lo stesso set di credenziali (Dominio \ Utente) viene passato dal client a un server e quindi da quel server a un secondo server. Ogni volta che vengono passate le credenziali, lo chiamiamo hop. Poiché non stiamo modificando le credenziali (ad esempio, non stiamo andando a un secondo account di Windows, come un account di servizio o un account di accesso di SQL Server, diciamo che ci sono stati due hop o ciò che chiamiamo un situazione a doppio hop. NTLM non consente situazioni a doppio hop (o triple o quadruple …); è impedito dalla progettazione. Quindi in uno di questi scenari particolari, se non abbiamo impostato l’autenticazione Kerberos, non possiamo creare il secondo hop. Vedremo errori di accesso attribuiti a login (null) o NT AUTHORITY \ ANONYMOUS LOGON. Per impostazione predefinita, l’autenticazione Kerberos consente solo un singolo hop, ma utilizzando una funzione chiamata delega Kerberos, è possibile configurare più hop e questi scenari a doppio hop possono essere consentiti. Mentre la delega Kerberos va oltre lo scopo di questo articolo, è importante notare che la delega Kerberos non può avvenire senza l’autenticazione Kerberos, ed è così che i DBA di solito vengono trascinati nella mischia.

Cosa c’è di male in NTLM?

In generale, NTLM (o almeno le versioni riviste) fanno un buon lavoro di autenticazione dell’utente e sostanzialmente di sicurezza. Tuttavia, NTLM presenta i seguenti inconvenienti:

• È suscettibile agli attacchi “replay”.
• Presuppone che il server sia affidabile.
• Richiede più traffico di autenticazione rispetto a Kerberos.
• Non fornisce un modo per superare quel primo hop.

Diamo un’occhiata a ciascuno di questi per capire perché sono degli svantaggi, a partire da un attacco di rigiocabilità. Un attacco di replay è quando un attaccante è in grado di catturare il traffico di rete e riutilizzarlo. Ad esempio, immagina di accedere al tuo SQL Server. Un utente malintenzionato ha uno sniffer di pacchetti ed è in grado di acquisire quella sequenza di accesso. Se, in un secondo momento, quell’attaccante fosse in grado di reinserire quel traffico sulla rete e funzionasse, sarebbe un attacco di rigiocabilità. Il classico esempio dato è che un attaccante cattura una transazione bancaria per una certa quantità di denaro. Diciamo che paghi Mr. Attacker US $ 500 per i servizi resi. Se l’attaccante è in grado di acquisire il traffico di rete e riprodurlo più volte, la banca dedurrà ogni volta $ 500 dal tuo conto e lo depositerà sul suo. Alla banca, le transazioni ripetute sembravano legittime (anche se,con tutti preoccupati per le frodi al giorno d’oggi, speriamo che questo genere di cose venga segnalato e verificato). In questo caso, la colpa è del protocollo per quella transazione che stiamo usando perché non ci ha fornito alcuna protezione da tale attacco. È il caso di NTLM. Non fornisce protezione. Kerberos, d’altra parte, include un timestamp di quando è stato inviato il traffico di rete. Se sei al di fuori dell’intervallo di tempo accettabile (per impostazione predefinita, questo è di 5 minuti), Kerberos rifiuta quel traffico di rete. Quindi, nel caso sopra, immagina se la banca ha messo un timestamp sulla transazione e ha avuto un intervallo di tempo accettabile entro 10 secondi. Se il Sig. Attacker provasse a ripetere la transazione dopo che quella finestra di 10 secondi era aperta, la banca avrebbe saputo che stava succedendo qualcosa.speriamo che questo genere di cose venga segnalato e verificato). In questo caso, la colpa è del protocollo per quella transazione che stiamo usando perché non ci ha fornito alcuna protezione da tale attacco. È il caso di NTLM. Non fornisce protezione. Kerberos, d’altra parte, include un timestamp di quando è stato inviato il traffico di rete. Se sei al di fuori dell’intervallo di tempo accettabile (per impostazione predefinita, questo è di 5 minuti), Kerberos rifiuta quel traffico di rete. Quindi, nel caso sopra, immagina se la banca ha messo un timestamp sulla transazione e ha avuto un intervallo di tempo accettabile entro 10 secondi. Se il Sig. Attacker provasse a ripetere la transazione dopo che quella finestra di 10 secondi era aperta, la banca avrebbe saputo che stava succedendo qualcosa.speriamo che questo genere di cose venga segnalato e verificato). In questo caso, la colpa è del protocollo per quella transazione che stiamo usando perché non ci ha fornito alcuna protezione da tale attacco. È il caso di NTLM. Non fornisce protezione. Kerberos, d’altra parte, include un timestamp di quando è stato inviato il traffico di rete. Se sei al di fuori dell’intervallo di tempo accettabile (per impostazione predefinita, questo è di 5 minuti), Kerberos rifiuta quel traffico di rete. Quindi, nel caso sopra, immagina se la banca ha messo un timestamp sulla transazione e ha avuto un intervallo di tempo accettabile entro 10 secondi. Se il Sig. Attacker provasse a ripetere la transazione dopo che quella finestra di 10 secondi era aperta, la banca avrebbe saputo che stava succedendo qualcosa.il riutilizzo è da incolpare perché non ci ha fornito protezione da un simile attacco. È il caso di NTLM. Non fornisce protezione. Kerberos, d’altra parte, include un timestamp di quando è stato inviato il traffico di rete. Se sei al di fuori dell’intervallo di tempo accettabile (per impostazione predefinita, questo è di 5 minuti), Kerberos rifiuta quel traffico di rete. Quindi, nel caso sopra, immagina se la banca ha messo un timestamp sulla transazione e ha avuto un intervallo di tempo accettabile entro 10 secondi. Se il Sig. Attacker provasse a ripetere la transazione dopo che quella finestra di 10 secondi era aperta, la banca avrebbe saputo che stava succedendo qualcosa.il riutilizzo è da incolpare perché non ci ha fornito protezione da un simile attacco. È il caso di NTLM. Non fornisce protezione. Kerberos, d’altra parte, include un timestamp di quando è stato inviato il traffico di rete. Se sei al di fuori dell’intervallo di tempo accettabile (per impostazione predefinita, questo è di 5 minuti), Kerberos rifiuta quel traffico di rete. Quindi, nel caso sopra, immagina se la banca ha messo un timestamp sulla transazione e ha avuto un intervallo di tempo accettabile entro 10 secondi. Se il Sig. Attacker provasse a ripetere la transazione dopo che quella finestra di 10 secondi era aperta, la banca avrebbe saputo che stava succedendo qualcosa.al di fuori della finestra dell’intervallo di tempo accettabile (per impostazione predefinita sono 5 minuti), Kerberos rifiuta il traffico di rete. Quindi, nel caso sopra, immagina se la banca ha messo un timestamp sulla transazione e ha avuto un intervallo di tempo accettabile entro 10 secondi. Se il Sig. Attacker provasse a ripetere la transazione dopo che quella finestra di 10 secondi era aperta, la banca avrebbe saputo che stava succedendo qualcosa.al di fuori della finestra dell’intervallo di tempo accettabile (per impostazione predefinita sono 5 minuti), Kerberos rifiuta il traffico di rete. Quindi, nel caso sopra, immagina se la banca ha messo un timestamp sulla transazione e ha avuto un intervallo di tempo accettabile entro 10 secondi. Se il Sig. Attacker provasse a ripetere la transazione dopo che quella finestra di 10 secondi era aperta, la banca avrebbe saputo che stava succedendo qualcosa.

Il secondo svantaggio di NTLM è che il server non è verificato. Il client si connette a MySQLServer. O almeno, pensa che si stia connettendo a MySQLServer. Il protocollo NTLM può avere la capacità di convalidare che Dominio \ Utente si sta connettendo, ma non consente a Dominio \ Utente di verificare che stia davvero parlando con MySQLServer. Qui entra in gioco il nome principale del servizio (SPN). Quando il client tenta di connettersi tramite Kerberos, viene verificato l’SPN per il servizio a cui si è connessi. In un dominio Windows 2000 o superiore, l’SPN è archiviato in Active Directory e il controller di dominio Active Directory è considerato attendibile dal client. Pertanto, se il servizio, ad esempio un servizio SQL Server, esegue il checkout in base all’SPN che il client trova per quel servizio in Active Directory, sa che può fidarsi che il server sia veramente MySQLServer.

Il terzo svantaggio è la quantità di traffico di autenticazione utilizzato da NTLM rispetto a Kerberos. In NTLM, ogni volta che si verifica l’autenticazione, è necessario effettuare un controllo su un controller di dominio (DC). Con Kerberos, i biglietti vengono emessi sia al client che al server contenente le informazioni di cui ciascuno ha bisogno per convalidare l’altro. Pertanto, il client e il server devono effettuare il check-in con un controller di dominio solo una volta durante la durata di tali ticket (il valore predefinito è 600 minuti o 10 ore) per ottenere i ticket in primo luogo. Successivamente, entrambi hanno le informazioni di cui hanno bisogno senza ricontrollare con un controller di dominio.

L’inconveniente finale è quello di cui abbiamo già discusso, e cioè le situazioni in cui vogliamo fare più speranze. Francamente, NTLM non ci lascia opzioni. Dobbiamo rendere ogni hop diverso dal precedente, che ci piaccia o no. La delegazione Kerberos ci assicura che possiamo trasferire le credenziali attraverso tutti i salti fino a raggiungere la destinazione finale.

Che cos’è un SPN, perché devo configurarlo e come posso farlo?

Un nome principale di servizio (SPN) fornisce le informazioni al cliente sul servizio. Fondamentalmente, ogni SPN è costituito da 3 o 4 informazioni:

• Il tipo di servizio (per SQL Server si chiama MSSQLSvc)
• il nome del server
• La porta (se questo deve essere specificato)
• L’account del servizio che esegue il servizio.

Tutti questi devono corrispondere affinché il client sia in grado di convalidare il servizio. Se uno di questi è sbagliato, l’autenticazione Kerberos non avverrà. In alcuni casi, avremo quell’errore di contesto SSPI e in effetti, SSPI non tornerà nemmeno a usare NTLM, il che significa che non ci connettiamo affatto. Pertanto, la chiave è ottenere tutto corretto quando impostiamo l’SPN.

Per impostare un nome SPN, devi essere un utente di livello Admin di dominio oppure devi essere l’account di sistema del computer (o un account che parla sulla rete come account di sistema, ad esempio l’account del servizio di rete). In genere, consigliamo di eseguire SQL Server come utente locale o di dominio, in modo da escludere il secondo caso. Consigliamo inoltre che SQL Server non dovrebbe essere un account a livello di amministratore di dominio e che esclude il primo caso. Ciò significa che un account a livello di amministratore di dominio dovrà impostare manualmente l’SPN. Per fortuna, Microsoft fornisce una bella utility chiamata SETSPN negli Strumenti di supporto sul CD / DVD del sistema operativo per farlo. Può anche essere scaricato dal sito Microsoft.

Utilizzando SETSPN

SETSPN ha tre flag a cui siamo interessati:

• -L : elenca gli SPN per un determinato account
• -A : Questo aggiunge un nuovo SPN
• -D : questo elimina un SPN esistente

La chiave per comprendere gli SPN è rendersi conto che sono collegati a un account, sia esso un account utente o computer. Se vogliamo vedere quali SPN sono elencati per un determinato account, ecco la sintassi:

SETSPN -L <Account>

Ad esempio, se ho un server chiamato MyWebServer, posso elencare gli SPN assegnati a quell’account computer tramite:

SETSPN -L MyWebServer

Se, invece, sto eseguendo il mio SQL Server con l’account utente MyDomain \ MyServiceAccount, posso controllare gli SPN elencati per tale account:

SETSPN -L MyDomain \ MyServiceAccount

Per aggiungere un nome SPN, è importante conoscere l’account del servizio in cui è in esecuzione SQL Server. Inoltre, è importante sapere la porta TCP su cui SQL Server è in ascolto. Se si tratta di un’istanza predefinita, la porta per impostazione predefinita è 1433, sebbene questa possa essere modificata. Se si tratta di un’istanza denominata, a meno che non abbiamo inserito e impostato manualmente una porta statica, SQL Server potrebbe cambiare la porta in qualsiasi momento. Pertanto, è importante impostare una porta staticamente. Ho descritto come farlo nel post di un blog . Una volta che abbiamo quei bit di informazioni, possiamo aggiungere un SPN tramite la sintassi seguente:

SETSPN -A MSSQLSvc / <Nome server SQL>: <porta> <account>

Se abbiamo a che fare con un’istanza predefinita in ascolto sulla porta 1433, possiamo lasciare: <port> (ma è comunque una buona idea avere una voce sia con che senza la porta). Un’altra cosa da ricordare è che è importante specificare SPN sia per il nome NetBIOS (ad esempio MySQLServer) sia per il nome di dominio completo (ad esempio MySQLServer.mydomain.com). Quindi applicandolo a un’istanza predefinita su MyDBServer.mydomain.com in esecuzione con l’account di servizio MyDomain \ SQLServerService, eseguiremmo i seguenti comandi:

SETSPN -A MSSQLSvc / MyDBServer MyDomain \ SQLServerService

SETSPN -A MSSQLSvc / MyDBServer: 1433 MyDomain \ SQLServerService

SETSPN -A MSSQLSvc / MyDBServer.mydomain.com MyDomain \ SQLServerService

SETSPN -A MSSQLSvc / MyDBServer.mydomain.com: 1433 MyDomain \ SQLServerService

Per un’istanza denominata, in genere sono necessari solo due comandi, poiché non esiste un caso in cui un client si sta semplicemente connettendo al nome del server. Ad esempio, supponiamo di avere un’istanza denominata chiamata Instance2 in ascolto sulla porta 4444 sullo stesso server utilizzando lo stesso account di servizio. In tal caso eseguiremmo i seguenti comandi:

SETSPN -A MSSQLSvc / MyDBServer: 4444 MyDomain \ SQLServerService

SETSPN -A MSSQLSvc / MyDBServer.mydomain.com: 4444 MyDomain \ SQLServerService

E in quei rari casi in cui è necessario eliminare un SPN (ad esempio, cambiamo l’account del servizio o le porte dello switch), possiamo usare l’opzione -D. La sua sintassi è parallela all’opzione -A:

SETSPN -D MSSQLSvc / <Nome server SQL>: <porta> <account>

Ho fatto tutto questo. Come posso verificare che gli accessi si connettano tramite Kerberos?

All’interno di SQL Server esiste una query molto semplice che possiamo eseguire per determinare quale tipo di autenticazione è stata eseguita su ogni connessione. Ecco la domanda:

La query restituisce molte informazioni per aiutarti a identificare le connessioni. Connect_time e login_time dovrebbero essere abbastanza vicini tra loro e ti dà una finestra di quando è stata effettuata la connessione iniziale. Login_name, insieme a host_name e nome_programma, consentono di identificare il login esatto. Da lì, protocol_type ti aiuta a restringere la connessione se hai endpoint diversi per il tuo SQL Server oltre a TSQL (ad esempio mirroring o HTTP). E infine, auth_scheme rivelerà, per un account Windows, quale protocollo di sicurezza è stato utilizzato. Se l’autenticazione Kerberos ha avuto esito positivo, dovresti vedere il file auth_scheme che riflette Kerberos anziché NTLM.

RISORSE AGGIUNTIVE:

https://support.microsoft.com/it-it/help/811889/how-to-troubleshoot-the-cannot-generate-sspi-context-error-message

Come registrare un SPN per le connessioni kerberos,
https://docs.microsoft.com/it-it/sql/database-engine/configure-windows/register-a-service-principal-name-for-kerberos-connections?view=sql-server-ver15

autenticazione Kerberos in SQL SERVER, Kerberos in SQL SERVER, Kerberos Sql Server, LDAPError authenticating. The target principal name is incorrect, Cannot generate SSPI context, The target principal name is incorrect, Cannot generate SSPI context, System.Data.SqlClient.SqlException: The target principal name is incorrect. Cannot generate SSPI context, The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server, This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using