VPN ferbynt, mar SQL Server wegeret Windows-ferifikaasje

Tunnels komme omheech, tsjinners beantwurdzje ping, en de databankoanmelding mislearret noch altyd mei in ferifikaasjeflater. Dy kombinaasje is gewoan op VPN-ferbinings en betsjut selden dat it netwurk stikken is, want in berikbere harker en in akseptearre oanmelding binne twa ferskillende resultaten. De identiteit dy't de gateway tefreden stelde, is net needsaaklikerwize de identiteit dy't de databankklant oanbiedt. Utfine hokker akkount oankaam, is de hiele taak.

It symptoom: berikbere tsjinner, wegere oanmelding

In time-out fertelt jo dat it pakket nea in harker berikte. In ferifikaasjeflater fertelt jo dat de harker antwurde en de legitimasaasje wegere. Dy twa berjochten stjoere jo nei ferskillende teams, en se trochinoar helje kostet in dei oan firewallregels dy't nea it probleem wiene.

As de flater in mislearre oanmelding is, hâld dan op mei nei poarten te sjen. De oerbleaune fraach is hokker Windows-identiteit de klant oanbea, oft de tsjinner dy identiteit akseptearre, en oft dy oplost waard ta in databankbrûker mei tastimming.

Twa identiteiten, ien tunnel

It VPN-akkount ferifiearret by de gateway en einiget yn de measte ymplemintaasjes dêr. De databankklant biedt apart in Windows-token oan, nommen út it proses dat it útfiert, of in SQL-oanmelding as de ferbiningstekst ien freget. In gateway-lokale VPN-brûker hat gjin relaasje mei it domein dat SQL Server hostet, en de tunnel makket der gjin ien.

In persoanlike masine oan in VPN ferbinen foeget dy ek net ta oan it domein. In lokaal akkount omneame en syn wachtwurd lykmeitsje mei in domeinbrûker is gjin ynskriuwproseduere, en it produsearret in token dat de domeinkontrôler net as dy brûker akseptearret.

Guon native Windows-klanten foar tafal-op-ôfstân kinne de VPN-legitimaasje werbrûke foar netwurkboarnen as har profyl sa konfigurearre is. Dat gedrach heart by in spesifike klant en profyl, net by VPN-ferbinings yn it algemien, dus ferifiearje it foar de brûkte klant ynstee fan it oan te nimmen.

Lês de modus dy't de klant frege

De ferbiningstekst beslút hokker ferifikaasjepaad de klant nimt. Yntegrearre befeiliging brûkt it Windows-token; in pear brûker en wachtwurd kiest in SQL-oanmelding. Dat binne aparte modi yn 'e tsjinnerkonfiguraasje, en mar ien fan beide kin oan stean foar in opjûne ferbiningspoging.

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

Oerstappe nei in SQL-oanmelding om't de Windows-oanmelding mislearre is, is in wurkomwei dy't de identiteitsfraach ferberget, en it freget gewoanlik dochs om in nije oanmelding en wachtwurd. As de ymplemintaasje Windows-ferifikaasje easket, hâld de modus en reparearje it identiteitspaad. In SQL-oanmelding hat ek eigen tastimmingen nedich, dus de wurkomwei keapet in twadde akkount om te ûnderhâlden.

Befêstigje ek hokker applikaasje ferbynt. In tsjinst dy't as systeemakkount rint, in pland taak en in ynteraktyf befreegjingsfinster kinne trije ferskillende tokens op deselde masine oanbiede, en allinnich de lêste komt oerien mei wat de brûker sjocht as er whoami útfiert.

Freegje de tsjinner wat er echt seach

De tsjinner kin jo fertelle hokker oanmelding er oplost hat en hoe't de ferbining ferifiearre is. Fier de beffraach út binnen de sesje dy't ûndersocht wurdt, want in aparte suksesfolle ferbining fan in behearder bewissiget neat oer de mislearjende klant.

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 earste rige ûnderskiedt de oanmelding dy't de sesje iepene fan 'e befeiligingskontekst dy't no jildt, en dy ferskille ûnder persoanlike foardwaan. De twadde neamt it ferifikaasjeskema, sadat KERBEROS, NTLM en SQL sichtbere feiten wurde ynstee fan gissingen. In ferbining dy't NTLM rapportearret dêr't jo Kerberos ferwachten, is in probleem mei nammenei-oplossing of SPN, gjin wachtwurdprobleem.

It flatersifer beheindet it fierder. Steat 5 betsjut meast dat de oanmeldingsnamme hielendal net oplost is, steat 8 betsjut meast dat it wachtwurd net oerienkaam, en steat 11 betsjut dat de legitimasaasje akseptearre waard mar tagong ta de tsjinner mislearre. Freegje de behearder om 'e steat ynstee fan it hiele berjocht, want it berjocht allinnich is mei opsetsin ûndúdlik.

As de identiteit oankomt en Kerberos noch mislearret

As de tsjinner de bedoelde Windows-identiteit sjocht en yntegrearre ferifikaasje noch mislearret, is de útwikseling sels it probleem. Kerberos hat it registrearre tsjinsthaadnamme (SPN) nedich foar it SQL-tsjinstakkount en in klant dy't de tsjinst freget mei in namme dy't dêrmei oerienkomt. Ferbinen fia IP-adres kin net oerienkomme mei in op namme basearre SPN, en in alias kin allinnich oerienkomme as dy ek registrearre is. Kontrolearje earst de namme dy't de klant yntypke, want in ferbining dy't fia hostnamme wurket en fia IP mislearret, beskriuwt krekt dit probleem.

Freegje de behearder om 'e registrearre identiteit en it tsjinstakkount te besjen ynstee fan dûbele SPN's oan te meitsjen troch besykjen en mislearjen. Dûbele registraasjes produsearje tuskenskoflike flaters dy't dreger te diagnostisearjen binne as it oarspronklike probleem.

Nei't ferifikaasje wurket, hat de oanmelding noch in databankbrûker en tastimmingen nedich. In suksesfolle VPN-oanmelding, in suksesfolle Windows-oanmelding en tastimming om in bepaald tabel te lêzen binne trije aparte resultaten, en elk fertsjinnet syn eigen kontrôle foar't it ticket sluten wurdt.