VPN verbind, maar SQL Server verwerp Windows-verifikasie

Tonnels kom op, bedieners antwoord op ping, en die databasisaanmelding misluk steeds met 'n verifikasiefout. Daardie kombinasie kom algemeen op VPN-skakels voor, en dit beteken selde dat die netwerk stukkend is, want 'n bereikbare luisteraar en 'n aanvaarde aanmelding is twee verskillende resultate. Die identiteit wat die poort tevrede gestel het, is nie noodwendig die identiteit wat die databaskliënt aanbied nie. Om uit te werk watter rekening opgedaag het, is die hele taak.

Die simptoom: bereikbare bediener, verwerpte aanmelding

'n Time-out sê vir jou die pakkie het nooit 'n luisteraar bereik nie. 'n Verifikasiefout sê die luisteraar het geantwoord en die geloofsbrief geweier. Daardie twee boodskappe stuur jou na verskillende spanne, en om hulle te verwar mors 'n dag op firewallreëls wat nooit die probleem was nie.

Wanneer die fout 'n mislukte aanmelding is, hou op om na poorte te kyk. Die oorblywende vraag is watter Windows-identiteit die kliënt aangebied het, of die bediener daardie identiteit aanvaar het, en of dit na 'n databasisgebruiker met toestemming opgelos het.

Twee identiteite, een tonnel

Die VPN-rekening verifieer by die poort en eindig in die meeste ontplooiings daar. Die databaskliënt bied afsonderlik 'n Windows-token aan, geneem uit die proses wat dit laat loop, of 'n SQL-aanmelding as die verbindingstring een vra. 'n Poort-plaaslike VPN-gebruiker het geen verhouding met die domein wat SQL Server huisves nie, en die tonnel skep ook nie een nie.

Om 'n persoonlike masjien aan 'n VPN te koppel, sluit dit ook nie by die domein aan nie. Om 'n plaaslike rekening te hernoem en sy wagwoord by 'n domeingebruiker te laat pas, is nie 'n inskrywingsprosedure nie, en dit lewer 'n token wat die domeinbeheerder nie as daardie gebruiker sal aanvaar nie.

Sommige inheemse Windows-afstandtoegangskliënte kan die VPN-geloofsbrief vir netwerkbronne hergebruik wanneer hulle profiel so opgestel is. Daardie gedrag hoort by 'n spesifieke kliënt en profiel, nie by VPN-verbindings in die algemeen nie, so verifieer dit vir die kliënt wat gebruik word eerder as om dit te aanvaar.

Lees die modus wat die kliënt gevra het

Die verbindingstring bepaal watter verifikasiepad die kliënt volg. Geïntegreerde sekuriteit gebruik die Windows-token; 'n gebruiker-en-wagwoord-paar kies 'n SQL-aanmelding. Dit is afsonderlike modusse in die bedienerkonfigurasie, en net een van hulle kan vir 'n gegewe verbindingspoging geaktiveer wees.

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

Om na 'n SQL-aanmelding oor te skakel omdat die Windows-aanmelding misluk het, is 'n noodoplossing wat die identiteitsvraag verberg, en dit vereis gewoonlik dat 'n nuwe aanmelding en wagwoord geskep word. As die ontplooiing Windows-verifikasie vereis, hou die modus en maak die identiteitspad reg. 'n SQL-aanmelding het ook sy eie regte nodig, so die noodoplossing koop 'n tweede rekening om in stand te hou.

Bevestig ook watter toepassing verbind. 'n Diens wat as 'n stelselrekening loop, 'n geskeduleerde taak en 'n interaktiewe navraagvenster kan drie verskillende tokens op dieselfde masjien aanbied, en net die laaste een stem ooreen met wat die gebruiker sien wanneer hulle whoami uitvoer.

Vra die bediener wat dit werklik gesien het

Die bediener kan jou vertel watter aanmelding dit opgelos het en hoe die verbinding verifieer het. Voer die navraag binne die sessie uit wat ondersoek word, want 'n administrateur se afsonderlike suksesvolle verbinding bewys niks oor die kliënt wat misluk nie.

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;

Die eerste ry onderskei die aanmelding wat die sessie geopen het van die sekuriteitskonteks wat nou geld, en dié verskil onder verpersoonliking. Die tweede noem die verifikasieskema, so KERBEROS, NTLM en SQL word sigbare feite eerder as raaiskote. 'n Verbinding wat NTLM rapporteer waar jy Kerberos verwag het, is 'n naamresolusie- of SPN-probleem, nie 'n wagwoordprobleem nie.

Die foutnommer vernou dit verder. Toestand 5 beteken gewoonlik die aanmeldingsnaam is glad nie opgelos nie, toestand 8 beteken gewoonlik die wagwoord het nie gepas nie, en toestand 11 beteken die geloofsbrief is aanvaar maar toegang tot die bediener het misluk. Vra die administrateur vir die toestand eerder as die hele boodskap, want die boodskap alleen is doelbewus vaag.

Wanneer die identiteit opdaag en Kerberos steeds misluk

As die bediener die bedoelde Windows-identiteit sien en geïntegreerde verifikasie misluk steeds, is die uitruiling self die probleem. Kerberos benodig die dienshoofnaam wat vir die SQL-diensrekening geregistreer is en 'n kliënt wat die diens by 'n naam aanvra wat daarmee ooreenstem. Om per IP-adres te verbind, kan nie by 'n naamgebaseerde SPN pas nie, en 'n alias kan net pas as dit ook geregistreer is. Kyk eerste na die naam wat die kliënt getik het, want 'n verbinding wat per gasheernaam werk en per IP misluk, beskryf presies hierdie probleem.

Vra die administrateur om die geregistreerde identiteit en die diensrekening na te gaan eerder as om duplikaat-SPN's deur probeer en fouteer te skep. Duplikaatregistrasies lewer wisselvallige foute wat moeiliker is om te diagnoseer as die oorspronklike probleem.

Nadat verifikasie werk, het die aanmelding steeds 'n databasisgebruiker en regte nodig. 'n Suksesvolle VPN-aanmelding, 'n suksesvolle Windows-aanmelding en regte om 'n bepaalde tabel te lees, is drie afsonderlike resultate, en elkeen verdien sy eie kontrole voordat die kaartjie gesluit word.