Waarom val SQL Server oor ’n VPN steeds terug op NTLM?

Jou verbinding werk, die aanmelding word aanvaar, en SQL Server gebruik NTLM terwyl almal Kerberos verwag het. Daardie uitkoms is nie ’n VPN-fout nie, want ’n tonnel verskaf net ’n pad; die skema is bepaal deur die naam wat die kliënt gevra het, die prinsipaal wat in die gids geregistreer is en die kaartjie wat die kliënt werklik kon kry. Drie voorwaardes moet gelyktydig geld, en die sessie self sê watter een meegegee het. Lees dit voordat iemand ’n diensprinsipaalnaam wysig.

Die sessie noem die skema wat jy werklik gekry het

Die verifikasieskema hoort by ’n verbinding, nie by ’n bediener of ’n tonnel nie, so die kontrole moet binne die sessie loop wat jou aangaan. Voer die navraag hieronder uit vanaf dieselfde kliënt, gereedskap en rekening wat die verslag opgelewer het, en teken die teikennaam en vervoer langs die resultaat aan.

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

’n Ry uit ’n plaaslike SSMS-venster op die databasisgasheer beskryf ’n heeltemal ander verbinding, en daarom moet die navraag van die kliëntkant loop. Stoor die uitset met ’n tydstempel, want die volgende persoon wat dit lees, sal vra wanneer dit geneem is. Waar verskeie toepassings een eindpunt deel, neem ’n monster van elkeen, want ’n verskil in databron tussen twee toepassings is dikwels die hele storie.

Voorwaarde een: pas die naam by die SPN?

Kerberos verifieer ’n genoemde diens, so die kliënt vra die gids om ’n kaartjie vir een spesifieke prinsipaal. Vir die TCP-verskaffer is die gedokumenteerde vorm MSSQLSvc/ gevolg deur die volledig gekwalifiseerde gasheernaam en, vir ’n verstekinstansie, die poort. ’n Genoemde instansie registreer MSSQLSvc/db01.corp.example:SQLPROD, waar die agtervoegsel die instansienaam is in plaas van ’n nommer. Om die luisteraar via ’n alias, ’n CNAME wat elders oplos of ’n kaal IP-adres te bereik, verander die gevraagde naam, en ’n versoek sonder ’n passende prinsipaal het geen kaartjie om terug te gee nie.

Dit is waarom een toepassing op een netwerk werk en op ’n ander terugval: ’n DNS-antwoord, ’n aliasrekord of ’n hosts-inskrywing het die naam verander wat die kliënt gebruik het. Vergelyk die gevraagde naam met wat die gids bevat voordat jy aan registrasie raak.

Voorwaarde twee: is die SPN op die regte rekening?

’n SPN moet aan die rekening behoort wat die SQL-diens loop, nie aan die kliënt se rekening nie en nie per ongeluk aan ’n rekenaarobjek nie. SQL Server kan sy eie SPN’s by die opstart registreer wanneer sy diensrekening die toestemming het om hulle te skryf, wat gerieflik is en ook hoe ’n duplikaat ná ’n verandering van diensrekening verskyn.

Vra die gids vir die naam wat jy verwag, en lys dan wat die rekening werklik besit. Watter objek die inskrywing hou, maak meer saak as of die naam iewers in die woud bestaan. ’n Wanverhouding beteken die aanmelding was nooit die probleem nie, en Microsoft se SPN-gids dokumenteer die formate en die gevalle waar ’n domeinadministrateur die inskrywing moet skep.

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

Om nog ’n inskrywing by te voeg is nie ’n veilige eksperiment nie. ’n Duplikaat of botsende registrasie kan kliënte breek wat gewerk het, so ondersoek eienaarskap voor die verandering en kontroleer dit daarna weer.

Voorwaarde drie: kan die kliënt hoegenaamd ’n kaartjie kry?

’n Korrekte SPN is nutteloos as die kliënt nie ’n domeinbeheerder kan bereik nie of geen bruikbare geloofwaardigheidskonteks het nie. Die uitruiling het die KDC en DNS deur die VPN nodig, en ’n tonnel wat net die SQL-poort routeer, faal juis by hierdie stap. Bereikbaarheid moet vanaf dieselfde masjien en dieselfde rekening getoets word, nie vanaf die vuurmuur voor hulle nie.

Ondersoek die kaartjiekas op die masjien en onder die rekening wat die toepassing loop. ’n Masjienwye lys uit ’n verhoogde venster sê niks oor ’n diens wat as ’n ander gebruiker loop nie, en ’n leë kas vir daardie gebruiker is ’n bevinding eerder as ’n ongerief.

klist
klist -li 0x3e7

Besluit dan wat ’n terugval mag doen. As beleid Kerberos vereis, moet NTLM uitdruklik geweier word, want ’n stil terugval verander ’n konfigurasiefout in ’n werkende verbinding wat die vereiste oortree. As NTLM vir sommige toepassings aanvaarbaar bly, noem hulle en hou op om elke NTLM-sessie as ’n voorval te behandel.

Om die lanseerder te verander is een veranderlike, nie ’n oplossing nie

Om SSMS onder ’n ander geloofwaardigheid te begin, kan ’n onbedoelde uitgaande identiteit genees, wat ’n werklike klas probleem is. Dit bewys niks oor die teikennaam, die registrasie of die kaartjiepad nie, en dit verander nie wat die bediener aanvaar het nie.

Hou die vergelyking beheers: dieselfde eindpunt, dieselfde verskaffer, ’n bekende uitvoeringskonteks, dan ’n nuwe verbinding wie se skema jy ondersoek. Bevestig die aanvaarde aanmelding en sy databasistoestemmings afsonderlik, want toegang en verifikasie faal om verskillende redes.

Wanneer Kerberos vereis word, teken aan waarom die eerste pad teruggeval het, pas een regstelling toe en voer die navraag weer vanaf dieselfde kliënt uit. ’n Suksesvolle navraag ná ’n verandering aan die lanseerder is bewys van toegang, en dit is nog nie bewys dat die verifikasievereiste nagekom is nie.