A VPN csatlakozik, de az SQL Server elutasítja a Windows-hitelesítést

Az alagutak feljönnek, a kiszolgálók válaszolnak a pingre, és az adatbázis-bejelentkezés továbbra is hitelesítési hibával hiúsul meg. Ez a kombináció gyakori a VPN-kapcsolatokon, és ritkán jelenti azt, hogy a hálózat elromlott, mert egy elérhető figyelő és egy elfogadott bejelentkezés két különböző eredmény. Azt az identitást, amely kielégítette az átjárót, nem feltétlenül az az identitás kínálja, amelyet az adatbázis-ügyfél bemutat. Annak kiderítése, melyik fiók érkezett meg, maga a teljes feladat.

A tünet: elérhető kiszolgáló, elutasított bejelentkezés

Az időtúllépés azt mondja, hogy a csomag soha nem ért el figyelőt. A hitelesítési hiba azt mondja, hogy a figyelő válaszolt és elutasította a hitelesítő adatot. Ez a két üzenet különböző csapatokhoz küldi önt, és összekeverésük egy napot pazarol olyan tűzfal-szabályokra, amelyek soha nem voltak a probléma.

Amikor a hiba sikertelen bejelentkezés, hagyja abba a portok vizsgálatát. A fennmaradó kérdés az, milyen Windows-identitást mutatott be az ügyfél, elfogadta-e a kiszolgáló ezt az identitást, és feloldódott-e engedéllyel rendelkező adatbázis-felhasználóvá.

Két identitás, egy alagút

A VPN-fiók az átjárónál hitelesíti magát, és a legtöbb telepítésben ott véget is ér. Az adatbázis-ügyfél külön mutat be Windows-tokent, amelyet az őt futtató folyamatból vesz, vagy SQL-bejelentkezést, ha a kapcsolati karakterlánc azt kér. Az átjárón helyi VPN-felhasználónak semmilyen kapcsolata nincs azzal a tartománnyal, amely az SQL Servert futtatja, és az alagút nem hoz létre ilyet.

Egy személyes gép VPN-hez csatlakoztatása sem veszi fel a tartományba. Egy helyi fiók átnevezése és jelszavának egy tartományi felhasználóhoz igazítása nem csatlakozási eljárás, és olyan tokent állít elő, amelyet a tartományvezérlő nem fogad el az adott felhasználóként.

Egyes natív Windows távoli hozzáférésű ügyfelek újra felhasználhatják a VPN-hitelesítő adatot hálózati erőforrásokhoz, ha a profiljuk így van beállítva. Ez a viselkedés egy adott ügyfélhez és profilhoz tartozik, nem a VPN-kapcsolatokhoz általában, ezért ellenőrizze a használt ügyfélnél ahelyett, hogy feltételezné.

Olvassa el az ügyfél által kért módot

A kapcsolati karakterlánc dönti el, melyik hitelesítési útvonalat választja az ügyfél. Az integrált biztonság a Windows-tokent használja; egy felhasználónévből és jelszóból álló pár SQL-bejelentkezést választ. Ezek külön módok a kiszolgáló konfigurációjában, és egy adott kapcsolódási kísérlethez csak az egyik lehet engedélyezve.

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

Az SQL-bejelentkezésre váltás amiatt, hogy a Windows-bejelentkezés meghiúsult, olyan kerülő megoldás, amely elrejti az identitás kérdését, és általában így is új bejelentkezés és jelszó létrehozását igényli. Ha a telepítés Windows-hitelesítést ír elő, tartsa meg a módot, és javítsa az identitás útvonalát. Az SQL-bejelentkezésnek saját engedélyekre is szüksége van, tehát a kerülő megoldás egy második karbantartandó fiókot vásárol.

Azt is ellenőrizze, melyik alkalmazás csatlakozik. Egy rendszerfiókként futó szolgáltatás, egy ütemezett feladat és egy interaktív lekérdezőablak három különböző tokent mutathat be ugyanazon a gépen, és csak az utolsó egyezik azzal, amit a felhasználó lát, amikor futtatja a következőt: whoami.

Kérdezze meg a kiszolgálót, mit látott valójában

A kiszolgáló meg tudja mondani, melyik bejelentkezést oldotta fel, és hogyan hitelesítette magát a kapcsolat. A lekérdezést a vizsgált munkameneten belül futtassa, mert egy rendszergazda külön sikeres kapcsolata semmit nem bizonyít a meghiúsuló ügyfélről.

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;

Az első sor megkülönbözteti a munkamenetet megnyitó bejelentkezést a jelenleg érvényes biztonsági környezettől, amelyek megszemélyesítés esetén eltérnek. A második megnevezi a hitelesítési sémát, így a KERBEROS, NTLM és SQL látható tényekké válnak találgatások helyett. Az a kapcsolat, amely NTLM-et jelent ott, ahol Kerberost várt, névfeloldási vagy SPN-probléma, nem jelszóprobléma.

A hibaszám tovább szűkíti. Az 5-ös állapot általában azt jelenti, hogy a bejelentkezési nevet egyáltalán nem oldotta fel, a 8-as állapot általában azt, hogy a jelszó nem egyezett, a 11-es állapot pedig azt, hogy a hitelesítő adatot elfogadta, de a kiszolgálóhoz való hozzáférés meghiúsult. A teljes üzenet helyett az állapotot kérje a rendszergazdától, mert az üzenet önmagában szándékosan homályos.

Amikor az identitás megérkezik, és a Kerberos továbbra is meghiúsul

Ha a kiszolgáló látja a szándékolt Windows-identitást, és az integrált hitelesítés továbbra is meghiúsul, maga a csere a probléma. A Kerberosnak szüksége van az SQL-szolgáltatásfiókhoz regisztrált szolgáltatásnév-re (SPN) és olyan ügyfélre, amely a szolgáltatást azzal egyező néven kéri. IP-címmel csatlakozva nem lehet névalapú SPN-hez illeszkedni, és egy alias csak akkor illeszkedhet, ha az is regisztrálva van. Mindenekelőtt az ügyfél által beírt nevet ellenőrizze, mert az a kapcsolat, amely hosztnévvel működik és IP-vel meghiúsul, pontosan ezt a problémát írja le.

Kérje meg a rendszergazdát, hogy vizsgálja felül a regisztrált identitást és a szolgáltatásfiókot, ahelyett hogy próbálgatással duplikált SPN-eket hozna létre. A duplikált regisztrációk időszakos hibákat okoznak, amelyeket nehezebb diagnosztizálni, mint az eredeti problémát.

Miután a hitelesítés működik, a bejelentkezésnek még mindig szüksége van adatbázis-felhasználóra és engedélyekre. Egy sikeres VPN-bejelentkezés, egy sikeres Windows-bejelentkezés és egy adott tábla olvasására vonatkozó engedély három külön eredmény, és mindegyik megérdemli a saját ellenőrzését, mielőtt a jegyet lezárják.