VPN verbindt, maar SQL Server weigert Windows-verificatie

Tunnels komen op, servers antwoorden op ping, en de database-aanmelding mislukt nog steeds met een verificatiefout. Die combinatie komt vaak voor op VPN-verbindingen en betekent zelden dat het netwerk kapot is, want een bereikbare listener en een geaccepteerde aanmelding zijn twee verschillende resultaten. De identiteit die de gateway tevredenstelde is niet noodzakelijk de identiteit die de databaseclient aanbiedt. Uitzoeken welk account is aangekomen, is de hele opgave.

Het symptoom: bereikbare server, geweigerde aanmelding

Een time-out vertelt u dat het pakket nooit een listener heeft bereikt. Een verificatiefout vertelt u dat de listener antwoordde en de referentie weigerde. Die twee berichten sturen u naar verschillende teams, en ze door elkaar halen kost een dag aan firewallregels die nooit het probleem waren.

Als de fout een mislukte aanmelding is, stop dan met naar poorten te kijken. De resterende vraag is welke Windows-identiteit de client presenteerde, of de server die identiteit accepteerde, en of die werd omgezet in een databasegebruiker met toestemming.

Twee identiteiten, één tunnel

Het VPN-account verifieert bij de gateway en eindigt in de meeste implementaties daar. De databaseclient presenteert apart een Windows-token, genomen uit het proces dat hem uitvoert, of een SQL-aanmelding als de verbindingsreeks er een vraagt. Een gateway-lokale VPN-gebruiker heeft geen relatie met het domein dat SQL Server host, en de tunnel maakt er geen.

Een persoonlijke machine aan een VPN koppelen voegt hem ook niet toe aan het domein. Een lokaal account hernoemen en het wachtwoord laten overeenkomen met een domeingebruiker is geen inschrijvingsprocedure, en het levert een token op dat de domeincontroller niet als die gebruiker accepteert.

Sommige native Windows-clients voor externe toegang kunnen de VPN-referentie hergebruiken voor netwerkresources wanneer hun profiel zo is geconfigureerd. Dat gedrag hoort bij een specifieke client en profiel, niet bij VPN-verbindingen in het algemeen, dus verifieer het voor de gebruikte client in plaats van het aan te nemen.

Lees de modus die de client vroeg

De verbindingsreeks bepaalt welk verificatiepad de client neemt. Geïntegreerde beveiliging gebruikt het Windows-token; een paar van gebruiker en wachtwoord selecteert een SQL-aanmelding. Dat zijn afzonderlijke modi in de serverconfiguratie, en voor een bepaalde verbindingspoging kan er slechts één zijn ingeschakeld.

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

Overschakelen naar een SQL-aanmelding omdat de Windows-aanmelding mislukte, is een omweg die de identiteitsvraag verbergt, en het vereist meestal toch dat er een nieuwe aanmelding en wachtwoord worden gemaakt. Als de implementatie Windows-verificatie vereist, houd de modus en repareer het identiteitspad. Een SQL-aanmelding heeft ook eigen machtigingen nodig, dus de omweg koopt een tweede account om te onderhouden.

Controleer ook welke toepassing verbindt. Een service die als systeemaccount draait, een geplande taak en een interactief queryvenster kunnen drie verschillende tokens op dezelfde machine presenteren, en alleen de laatste komt overeen met wat de gebruiker ziet wanneer hij whoami uitvoert.

Vraag de server wat hij werkelijk zag

De server kan u vertellen welke aanmelding hij heeft omgezet en hoe de verbinding is geverifieerd. Voer de query uit binnen de sessie die wordt onderzocht, want een aparte geslaagde verbinding van een beheerder bewijst niets over de falende client.

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;

De eerste rij onderscheidt de aanmelding die de sessie opende van de beveiligingscontext die nu geldt, en die verschillen onder imitatie. De tweede noemt het verificatieschema, zodat KERBEROS, NTLM en SQL zichtbare feiten worden in plaats van vermoedens. Een verbinding die NTLM meldt waar u Kerberos verwachtte, is een naamresolutie- of SPN-probleem, geen wachtwoordprobleem.

Het foutnummer vernauwt het verder. Status 5 betekent meestal dat de aanmeldingsnaam helemaal niet is omgezet, status 8 betekent meestal dat het wachtwoord niet overeenkwam, en status 11 betekent dat de referentie werd geaccepteerd maar de toegang tot de server mislukte. Vraag de beheerder om de status in plaats van het hele bericht, want het bericht alleen is bewust vaag.

Wanneer de identiteit aankomt en Kerberos nog steeds mislukt

Als de server de bedoelde Windows-identiteit ziet en geïntegreerde verificatie mislukt nog steeds, is de uitwisseling zelf het probleem. Kerberos heeft de servicenaam (SPN) nodig die is geregistreerd voor het SQL-serviceaccount, en een client die de service opvraagt met een naam die daarmee overeenkomt. Verbinden via IP-adres kan niet overeenkomen met een op naam gebaseerde SPN, en een alias kan alleen overeenkomen als die ook is geregistreerd. Controleer eerst de naam die de client heeft getypt, want een verbinding die via hostnaam werkt en via IP faalt, beschrijft precies dit probleem.

Vraag de beheerder de geregistreerde identiteit en het serviceaccount te beoordelen in plaats van dubbele SPN's aan te maken door te proberen. Dubbele registraties veroorzaken periodieke storingen die moeilijker te diagnosticeren zijn dan het oorspronkelijke probleem.

Zodra verificatie werkt, heeft de aanmelding nog steeds een databasegebruiker en machtigingen nodig. Een geslaagde VPN-aanmelding, een geslaagde Windows-aanmelding en toestemming om een bepaalde tabel te lezen zijn drie afzonderlijke resultaten, en elk verdient zijn eigen controle voordat het ticket wordt gesloten.