Miért esik vissza az SQL Server VPN-en át mégis az NTLM-re?

A kapcsolat működik, a bejelentkezést elfogadják, és az SQL Server NTLM-et használ, miközben mindenki Kerberost várt. Ez az eredmény nem VPN-hiba, mert az alagút csak utat ad; a sémát az ügyfél által kért név, a címtárban regisztrált principal és a jegy határozta meg, amelyet az ügyfél ténylegesen be tudott szerezni. Három feltételnek egyszerre kell teljesülnie, és maga a munkamenet mondja meg, melyik engedett. Olvassa el ezt, mielőtt bárki szerkeszt egy szolgáltatás-principalnevet.

A munkamenet megnevezi a sémát, amelyet ténylegesen kapott

A hitelesítési séma a kapcsolathoz tartozik, nem a kiszolgálóhoz vagy az alagúthoz, ezért az ellenőrzést abban a munkamenetben kell futtatni, amely érdekli. Futtassa az alábbi lekérdezést ugyanattól az ügyféltől, eszköztől és fióktól, amelyek a jelentést készítették, és jegyezze fel a célnévhez és a szállítást az eredmény mellé.

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

Az adatbázis-gazdagépen lévő helyi SSMS-ablak egyik sora teljesen más kapcsolatot ír le, ezért a lekérdezést az ügyfél oldaláról kell futtatni. Mentse a kimenetet időbélyeggel, mert a következő olvasó megkérdezi, mikor vették fel. Ha több alkalmazás osztozik egy végponton, mindegyikből vegyen mintát, mert két alkalmazás adatforrás-különbsége gyakran az egész történet.

Első feltétel: egyezik a név az SPN-nel?

A Kerberos egy megnevezett szolgáltatást hitelesít, ezért az ügyfél egy adott principalhoz kér jegyet a címtártól. A TCP-szolgáltatónál a dokumentált forma MSSQLSvc/, amelyet a teljesen minősített gazdanév, alapértelmezett példány esetén pedig a port követ. A nevesített példány MSSQLSvc/db01.corp.example:SQLPROD nevet regisztrál, ahol az utótag a példány neve szám helyett. Ha a figyelőt alias, máshol feloldódó CNAME vagy csupasz IP-cím révén éri el, a kért név megváltozik, és a megfelelő principal nélküli kérésnek nincs visszaadható jegye.

Ezért működik egy alkalmazás az egyik hálózaton, és esik vissza a másikon: egy DNS-válasz, egy aliasrekord vagy egy hosts-bejegyzés megváltoztatta az ügyfél által használt nevet. Hasonlítsa össze a kért nevet azzal, amit a címtár tartalmaz, mielőtt a regisztrációhoz nyúl.

Második feltétel: a megfelelő fiókon van az SPN?

Az SPN-nek ahhoz a fiókhoz kell tartoznia, amely az SQL szolgáltatást futtatja, nem az ügyfél fiókjához és nem véletlenül egy számítógép-objektumhoz. Az SQL Server indításkor regisztrálhatja saját SPN-jeit, ha a szolgáltatásfiókja rendelkezik az írásukhoz szükséges engedéllyel, ami kényelmes, és azt is megmagyarázza, hogyan jelenik meg egy duplikátum a szolgáltatásfiók cseréje után.

Kérdezze meg a címtártól a várt nevet, majd listázza, mi van ténylegesen a fiók birtokában. Az számít jobban, melyik objektum tartja a bejegyzést, mint az, hogy a név létezik-e valahol az erdőben. Az eltérés azt jelenti, hogy a bejelentkezés soha nem volt a probléma, a Microsoft SPN-útmutatója pedig dokumentálja a formákat és azokat az eseteket, amikor a tartományi rendszergazdának létre kell hoznia a bejegyzést.

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

Egy újabb bejegyzés hozzáadása nem biztonságos kísérlet. Egy duplikátum vagy ütköző regisztráció elronthatja a működő ügyfeleket, ezért a módosítás előtt vizsgálja meg a tulajdonjogot, utána pedig ellenőrizze újra.

Harmadik feltétel: egyáltalán szerezhet jegyet az ügyfél?

A helyes SPN haszontalan, ha az ügyfél nem ér el egy tartományvezérlőt, vagy nincs használható hitelesítőadat-környezete. A csere a VPN-en keresztül igényli a KDC-t és a DNS-t, és a csak az SQL portot irányító alagút éppen ennél a lépésnél vall kudarcot. Az elérhetőséget ugyanarról a gépről és ugyanabból a fiókból kell tesztelni, nem az előttük lévő tűzfalból.

Vizsgálja meg a jegy-gyorsítótárat a gépen és az alkalmazást futtató fiók alatt. Egy emelt ablakból származó gép szintű lista semmit sem mond egy másik felhasználóként futó szolgáltatásról, és az adott felhasználó üres gyorsítótára lelet, nem kényelmetlenség.

klist
klist -li 0x3e7

Ezután döntse el, mit tehet egy visszaesés. Ha a szabályzat Kerberost ír elő, az NTLM-et kifejezetten el kell utasítani, mert a csendes visszaesés konfigurációs hibát olyan működő kapcsolattá alakít, amely megsérti a követelményt. Ha az NTLM egyes alkalmazások számára elfogadható marad, nevezze meg őket, és ne kezeljen minden NTLM-munkamenetet incidensként.

Az indító cseréje egy változó, nem javítás

Az SSMS más hitelesítő adatokkal való indítása orvosolhat egy nem szándékos kimenő identitást, ami valódi problémacsztály. Semmit sem bizonyít a célnévről, a regisztrációról vagy a jegy útvonaláról, és nem változtatja meg, mit fogadott el a kiszolgáló.

Tartsa ellenőrzött keretek között az összehasonlítást: ugyanaz a végpont, ugyanaz a szolgáltató, ismert végrehajtási környezet, majd egy friss kapcsolat, amelynek sémáját megvizsgálja. Külön erősítse meg az elfogadott bejelentkezést és annak adatbázis-engedélyeit, mert a hozzáférés és a hitelesítés különböző okokból hiúsul meg.

Ha a Kerberos kötelező, jegyezze fel, miért esett vissza az első útvonal, alkalmazzon egy javítást, és futtassa újra a lekérdezést ugyanattól az ügyféltől. Az indító cseréje utáni sikeres lekérdezés a hozzáférés bizonyítéka, és még nem bizonyítéka annak, hogy a hitelesítési követelmény teljesült.