Perché SQL Server tramite VPN ricade comunque su NTLM?

La connessione funziona, l’accesso viene accettato e SQL Server usa NTLM mentre tutti si aspettavano Kerberos. Quel risultato non è un difetto della VPN, perché un tunnel fornisce solo un percorso; lo schema è stato deciso dal nome richiesto dal client, dal principal registrato nella directory e dal ticket che il client è riuscito davvero a ottenere. Tre condizioni devono valere insieme, e la sessione stessa dice quale ha ceduto. Leggilo prima che qualcuno modifichi un nome di principal del servizio.

La sessione nomina lo schema che hai effettivamente ottenuto

Lo schema di autenticazione appartiene a una connessione e non a un server o a un tunnel, quindi il controllo deve essere eseguito dentro la sessione che ti interessa. Esegui la query qui sotto dallo stesso client, strumento e account che hanno prodotto il report, e annota il nome di destinazione e il trasporto accanto al risultato.

SELECT session_id, auth_scheme, net_transport, client_net_address, login_name
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Una riga da una finestra SSMS locale sull’host del database descrive una connessione del tutto diversa, per cui la query deve essere eseguita dal lato client. Salva l’output con una marca temporale, perché la prossima persona che lo leggerà chiederà quando è stato rilevato. Quando più applicazioni condividono un endpoint, preleva un campione da ciascuna, perché una differenza di origine dati tra due applicazioni è spesso tutta la storia.

Prima condizione: il nome corrisponde all’SPN?

Kerberos autentica un servizio con nome, quindi il client chiede alla directory un ticket per un principal specifico. Per il provider TCP la forma documentata è MSSQLSvc/ seguita dal nome host completamente qualificato e, per un’istanza predefinita, dalla porta. Un’istanza con nome registra MSSQLSvc/db01.corp.example:SQLPROD, dove il suffisso è il nome dell’istanza invece di un numero. Raggiungere il listener tramite un alias, un CNAME che si risolve altrove o un indirizzo IP nudo cambia il nome richiesto, e una richiesta senza un principal corrispondente non ha alcun ticket da restituire.

Ecco perché un’applicazione funziona su una rete e ricade su un’altra: una risposta DNS, un record alias o una voce hosts hanno cambiato il nome usato dal client. Confronta il nome richiesto con ciò che contiene la directory prima di toccare la registrazione.

Seconda condizione: l’SPN è sull’account corretto?

Un SPN deve appartenere all’account che esegue il servizio SQL, non all’account del client e non, per caso, a un oggetto computer. SQL Server può registrare i propri SPN all’avvio quando il suo account di servizio ha il permesso di scriverli, il che è comodo e spiega anche come compare un duplicato dopo un cambio di account di servizio.

Interroga la directory per il nome atteso, poi elenca ciò che l’account possiede davvero. Quale oggetto detiene la voce conta più della presenza del nome da qualche parte nella foresta. Una discrepanza significa che l’accesso non è mai stato il problema, e la guida SPN di Microsoft documenta i formati e i casi in cui un amministratore di dominio deve creare la voce.

setspn -Q MSSQLSvc/db01.corp.example:1433
setspn -L CORP\svc-sql01

Aggiungere un’altra voce non è un esperimento sicuro. Un duplicato o una registrazione in conflitto può rompere client che funzionavano, quindi ispeziona la proprietà prima della modifica e ricontrollala dopo.

Terza condizione: il client può ottenere un ticket?

Un SPN corretto è inutile se il client non raggiunge un controller di dominio o non ha un contesto di credenziali utilizzabile. Lo scambio richiede il KDC e il DNS attraverso la VPN, e un tunnel che instrada solo la porta SQL fallisce proprio in questo passaggio. La raggiungibilità va verificata dalla stessa macchina e dallo stesso account, non dal firewall che li precede.

Ispeziona la cache dei ticket sulla macchina e sotto l’account che esegue l’applicazione. Un elenco a livello di macchina da una finestra con privilegi elevati non dice nulla su un servizio in esecuzione come altro utente, e una cache vuota per quell’utente è una constatazione, non un inconveniente.

klist
klist -li 0x3e7

Poi decidi cosa può fare un ripiego. Se la policy richiede Kerberos, NTLM deve essere rifiutato esplicitamente, perché un ripiego silenzioso trasforma un errore di configurazione in una connessione funzionante che viola il requisito. Se NTLM resta accettabile per alcune applicazioni, nominale e smetti di trattare ogni sessione NTLM come un incidente.

Cambiare il launcher è una variabile, non una correzione

Avviare SSMS con un’altra credenziale può curare un’identità in uscita indesiderata, che è una vera classe di problema. Non prova nulla sul nome di destinazione, sulla registrazione o sul percorso del ticket, e non cambia ciò che il server ha accettato.

Mantieni il confronto controllato: stesso endpoint, stesso provider, un contesto di esecuzione noto, poi una nuova connessione di cui ispezioni lo schema. Conferma separatamente l’accesso accettato e le sue autorizzazioni sul database, perché accesso e autenticazione falliscono per motivi diversi.

Quando Kerberos è richiesto, annota perché il primo percorso è ricaduto, applica una correzione e riesegui la query dallo stesso client. Una query riuscita dopo un cambio di launcher è prova di accesso, e non è ancora prova che il requisito di autenticazione sia stato soddisfatto.