Il VPN si connette, ma SQL Server rifiuta l’autenticazione Windows

I tunnel salgono, i server rispondono al ping e l’accesso al database fallisce ancora con un errore di autenticazione. Questa combinazione è comune sui collegamenti VPN e raramente significa che la rete è guasta, perché un listener raggiungibile e un accesso accettato sono due risultati diversi. L’identità che ha soddisfatto il gateway non è necessariamente quella che il client del database presenta. Stabilire quale account è arrivato è l’intero lavoro.

Il sintomo: server raggiungibile, accesso rifiutato

Un timeout vi dice che il pacchetto non ha mai raggiunto un listener. Un errore di autenticazione vi dice che il listener ha risposto e ha rifiutato la credenziale. Questi due messaggi vi mandano da team diversi, e confonderli fa perdere una giornata su regole del firewall che non sono mai state il problema.

Quando l’errore è un accesso fallito, smettete di guardare le porte. La domanda che resta è quale identità Windows abbia presentato il client, se il server l’abbia accettata e se si sia risolta in un utente del database con autorizzazione.

Due identità, un tunnel

L’account VPN si autentica al gateway e, nella maggior parte delle installazioni, finisce lì. Il client del database presenta separatamente un token Windows, preso dal processo che lo esegue, o un accesso SQL se la stringa di connessione ne richiede uno. Un utente VPN locale al gateway non ha alcun rapporto con il dominio che ospita SQL Server, e il tunnel non ne crea uno.

Collegare una macchina personale a una VPN non la unisce nemmeno al dominio. Rinominare un account locale e allineare la sua password a quella di un utente del dominio non è una procedura di registrazione, e produce un token che il controller di dominio non accetterà come quell’utente.

Alcuni client nativi di accesso remoto di Windows possono riutilizzare la credenziale VPN per le risorse di rete quando il loro profilo è configurato così. Questo comportamento appartiene a un client e a un profilo specifici, non alle connessioni VPN in generale, quindi verificate per il client in uso invece di darlo per scontato.

Leggete la modalità richiesta dal client

La stringa di connessione decide quale percorso di autenticazione prende il client. La sicurezza integrata usa il token Windows; una coppia utente e password seleziona un accesso SQL. Sono modalità separate nella configurazione del server, e solo una può essere abilitata per un dato tentativo di connessione.

Server=tcp:sql.lab.example,1433;Database=ops;Integrated Security=SSPI;Encrypt=True;TrustServerCertificate=False;

Passare a un accesso SQL perché l’accesso Windows è fallito è una soluzione tampone che nasconde la questione dell’identità, e di solito richiede comunque la creazione di un nuovo accesso e di una nuova password. Se l’installazione richiede l’autenticazione Windows, mantenete la modalità e correggete il percorso dell’identità. Anche un accesso SQL ha bisogno delle proprie autorizzazioni, quindi la soluzione tampone compra un secondo account da mantenere.

Verificate anche quale applicazione si connette. Un servizio eseguito come account di sistema, un’attività pianificata e una finestra di query interattiva possono presentare tre token diversi sulla stessa macchina, e solo l’ultimo corrisponde a ciò che l’utente vede quando esegue whoami.

Chiedete al server che cosa ha visto davvero

Il server può dirvi quale accesso ha risolto e come si è autenticata la connessione. Eseguite la query dentro la sessione in esame, perché una connessione riuscita separata dell’amministratore non dimostra nulla sul client che fallisce.

SELECT ORIGINAL_LOGIN() AS original_login,
       SUSER_SNAME() AS current_context;
SELECT auth_scheme, net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

La prima riga distingue l’accesso che ha aperto la sessione dal contesto di sicurezza in vigore adesso, che differiscono sotto rappresentazione. La seconda nomina lo schema di autenticazione, così KERBEROS, NTLM e SQL diventano fatti visibili invece di supposizioni. Una connessione che riporta NTLM dove vi aspettavate Kerberos è un problema di risoluzione dei nomi o di SPN, non un problema di password.

Il numero di errore restringe ancora. Lo stato 5 di solito significa che il nome di accesso non è stato risolto affatto, lo stato 8 di solito significa che la password non corrispondeva, e lo stato 11 significa che la credenziale è stata accettata ma l’accesso al server è fallito. Chiedete all’amministratore lo stato invece del messaggio intero, perché il messaggio da solo è volutamente vago.

Quando l’identità arriva e Kerberos fallisce ancora

Se il server vede l’identità Windows prevista e l’autenticazione integrata fallisce ancora, il problema è lo scambio stesso. Kerberos ha bisogno del nome principale di servizio registrato per l’account del servizio SQL e di un client che richieda il servizio con un nome corrispondente. Connettersi tramite indirizzo IP non può corrispondere a un SPN basato sul nome, e un alias può corrispondere solo se è anch’esso registrato. Controllate prima di tutto il nome digitato dal client, perché una connessione che funziona per nome host e fallisce per IP descrive esattamente questo problema.

Chiedete all’amministratore di rivedere l’identità registrata e l’account del servizio invece di creare SPN duplicati per tentativi. Le registrazioni duplicate producono guasti intermittenti più difficili da diagnosticare del problema originale.

Una volta che l’autenticazione funziona, l’accesso ha ancora bisogno di un utente del database e di autorizzazioni. Un accesso VPN riuscito, un accesso Windows riuscito e l’autorizzazione a leggere una tabella specifica sono tre risultati separati, e ognuno merita il proprio controllo prima che il ticket venga chiuso.