Prečo SQL Server cez VPN stále padá späť na NTLM?

Vaše pripojenie funguje, prihlásenie je prijaté a SQL Server používa NTLM, zatiaľ čo všetci očakávali Kerberos. Tento výsledok nie je chyba VPN, pretože tunel poskytuje iba cestu; schému určilo meno, ktoré klient požadoval, principal zaregistrovaný v adresári a lístok, ktorý klient skutočne dokázal získať. Tri podmienky musia platiť súčasne a relácia sama hovorí, ktorá ustúpila. Prečítajte si to, kým niekto upraví názov služby.

Relácia pomenuje schému, ktorú ste skutočne dostali

Schéma overovania patrí pripojeniu, nie serveru alebo tunelu, takže kontrola musí bežať vo vnútri relácie, ktorá vás zaujíma. Spustite dotaz nižšie z rovnakého klienta, nástroja a účtu, ktoré vytvorili správu, a poznamenajte cieľové meno a transport vedľa výsledku.

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

Riadok z lokálneho okna SSMS na hostiteľovi databázy opisuje úplne iné pripojenie, preto musí dotaz bežať zo strany klienta. Uložte výstup s časovou pečiatkou, pretože ďalší človek, ktorý ho bude čítať, sa spýta, kedy bol získaný. Keď niekoľko aplikácií zdieľa jeden koncový bod, odoberte vzorku z každej, pretože rozdiel v zdroji údajov medzi dvoma aplikáciami je často celý príbeh.

Prvá podmienka: zodpovedá meno SPN?

Kerberos overuje pomenovanú službu, takže klient žiada adresár o lístok pre jeden konkrétny principal. Pre poskytovateľa TCP je dokumentovaný tvar MSSQLSvc/ nasledovaný plne kvalifikovaným názvom hostiteľa a pri predvolenej inštancii port. Pomenovaná inštancia registruje MSSQLSvc/db01.corp.example:SQLPROD, kde prípona je názov inštancie namiesto čísla. Prístup k poslucháčovi cez alias, CNAME, ktorý sa prekladá inde, alebo holú IP adresu mení požadované meno a požiadavka bez zodpovedajúceho principalu nemá lístok, ktorý by vrátila.

Preto jedna aplikácia funguje v jednej sieti a v inej padá späť: odpoveď DNS, záznam aliasu alebo položka hosts zmenili meno, ktoré klient použil. Porovnajte požadované meno s tým, čo adresár obsahuje, kým sa dotknete registrácie.

Druhá podmienka: je SPN na správnom účte?

SPN musí patriť účtu, ktorý spúšťa službu SQL, nie účtu klienta a nie náhodou počítačovému objektu. SQL Server môže pri štarte registrovať svoje vlastné SPN, keď má jeho servisný účet oprávnenie ich zapisovať, čo je pohodlné a tiež vysvetľuje, ako po zmene servisného účtu vznikne duplikát.

Opýtajte sa adresára na meno, ktoré očakávate, a potom vypíšte, čo účet skutočne vlastní. Ktorý objekt záznam drží, je dôležitejšie ako to, či meno niekde v lese existuje. Nezhoda znamená, že prihlásenie nikdy nebolo problémom, a sprievodca SPN od Microsoftu dokumentuje formáty a prípady, keď musí správca domény záznam vytvoriť.

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

Pridanie ďalšieho záznamu nie je bezpečný experiment. Duplikát alebo konfliktná registrácia môže pokaziť klientov, ktorí fungovali, preto pred zmenou skontrolujte vlastníctvo a potom ho znova overte.

Tretia podmienka: môže klient vôbec získať lístok?

Správne SPN je zbytočné, ak sa klient nedostane na radič domény alebo nemá použiteľný kontext poverení. Výmena potrebuje KDC a DNS cez VPN a tunel, ktorý smeruje iba port SQL, zlyháva presne v tomto kroku. Dostupnosť sa musí testovať z rovnakého počítača a rovnakého účtu, nie z firewallu pred nimi.

Skontrolujte vyrovnávaciu pamäť lístkov na počítači a pod účtom, ktorý spúšťa aplikáciu. Zoznam pre celý počítač z okna so zvýšenými právami nič nehovorí o službe bežiacej ako iný používateľ a prázdna vyrovnávacia pamäť pre tohto používateľa je zistenie, nie nepríjemnosť.

klist
klist -li 0x3e7

Potom rozhodnite, čo môže záložná cesta urobiť. Ak politika vyžaduje Kerberos, NTLM musí byť výslovne odmietnuté, pretože tiché zlyhanie mení chybu konfigurácie na fungujúce pripojenie, ktoré porušuje požiadavku. Ak NTLM zostáva prijateľný pre niektoré aplikácie, vymenujte ich a prestaňte každú reláciu NTLM považovať za incident.

Zmena spúšťača je jedna premenná, nie oprava

Spustenie SSMS pod inými povereniami môže vyliečiť neúmyselnú odchádzajúcu identitu, čo je skutočná trieda problémov. Nič to nedokazuje o cieľovom mene, registrácii alebo ceste lístka a nemení to, čo server prijal.

Udržte porovnanie pod kontrolou: rovnaký koncový bod, rovnaký poskytovateľ, známy kontext spustenia, potom nové pripojenie, ktorého schému skontrolujete. Potvrďte prijaté prihlásenie a jeho databázové oprávnenia oddelene, pretože prístup a overovanie zlyhávajú z rôznych dôvodov.

Keď je Kerberos povinný, poznamenajte, prečo prvá cesta ustúpila, použite jednu opravu a znova spustite dotaz z rovnakého klienta. Úspešný dotaz po zmene spúšťača je dôkazom prístupu a zatiaľ nie je dôkazom, že požiadavka na overovanie bola splnená.