VPN yhdistyy, mutta SQL Server hylkää Windows-todennuksen
VPN-kirjautuminen toimii, SQL Server hylkää Windows-todennuksen: vertaa tunnelitiliä asiakkaan tokeniin ja lue sitten auth_scheme palvelimelta.
Tunnelit nousevat, palvelimet vastaavat pingiin, ja tietokantakirjautuminen epäonnistuu silti todennusvirheeseen. Tämä yhdistelmä on yleinen VPN-yhteyksillä, eikä se harvoin tarkoita, että verkko on rikki, koska tavoitettavissa oleva kuuntelija ja hyväksytty kirjautuminen ovat kaksi eri tulosta. Identiteetti, joka tyydytti yhdyskäytävän, ei välttämättä ole se identiteetti, jonka tietokanta-asiakas tarjoaa. Sen selvittäminen, mikä tili saapui, on koko tehtävä.
Oire: tavoitettavissa oleva palvelin, hylätty kirjautuminen
Aikakatkaisu kertoo, että paketti ei koskaan saavuttanut kuuntelijaa. Todennusvirhe kertoo, että kuuntelija vastasi ja hylkäsi tunnistetiedot. Nämä kaksi viestiä lähettävät sinut eri tiimeille, ja niiden sekoittaminen tuhlaa päivän palomuurisäännöille, jotka eivät koskaan olleet ongelma.
Kun virhe on epäonnistunut kirjautuminen, lopeta porttien katselu. Jäljelle jää kysymys siitä, minkä Windows-identiteetin asiakas esitti, hyväksyikö palvelin sen ja ratkesiko se tietokantakäyttäjäksi, jolla on oikeus.
Kaksi identiteettiä, yksi tunneli
VPN-tili todentuu yhdyskäytävällä ja useimmissa käyttöönotoissa päättyy siihen. Tietokanta-asiakas esittää erikseen Windows-tokenin, joka on otettu sitä ajavasta prosessista, tai SQL-kirjautumisen, jos yhteysmerkkijono pyytää sellaista. Yhdyskäytävän paikallisella VPN-käyttäjällä ei ole mitään suhdetta toimialueeseen, jolla SQL Server on, eikä tunneli luo sellaista.
Henkilökohtaisen koneen liittäminen VPN:ään ei myöskään liitä sitä toimialueeseen. Paikallisen tilin uudelleennimeäminen ja sen salasanan sovittaminen toimialueen käyttäjään ei ole liittymismenettely, ja se tuottaa tokenin, jota toimialueen ohjauskone ei hyväksy kyseisenä käyttäjänä.
Jotkin Windowsin natiivit etäkäyttöasiakkaat voivat käyttää VPN-tunnistetietoja uudelleen verkkoresursseille, kun niiden profiili on niin määritetty. Tämä käyttäytyminen kuuluu tietylle asiakkaalle ja profiilille, ei VPN-yhteyksille yleisesti, joten varmista se käytettävälle asiakkaalle sen sijaan että olettaisit sen.
Lue tila, jota asiakas pyysi
Yhteysmerkkijono päättää, minkä todennuspolun asiakas valitsee. Integroitu suojaus käyttää Windows-tokenia; käyttäjän ja salasanan pari valitsee SQL-kirjautumisen. Ne ovat erillisiä tiloja palvelimen kokoonpanossa, ja vain yksi niistä voi olla käytössä tietylle yhteysyritykselle.
Server=tcp:sql.lab.example,1433;Database=ops;Integrated Security=SSPI;Encrypt=True;TrustServerCertificate=False;
Siirtyminen SQL-kirjautumiseen siksi, että Windows-kirjautuminen epäonnistui, on kiertotie, joka piilottaa identiteettikysymyksen, ja se vaatii yleensä joka tapauksessa uuden kirjautumisen ja salasanan luomisen. Jos käyttöönotto vaatii Windows-todennusta, pidä tila ja korjaa identiteettipolku. SQL-kirjautuminen tarvitsee myös omat oikeutensa, joten kiertotie ostaa toisen tilin ylläpidettäväksi.
Varmista myös, mikä sovellus yhdistää. Järjestelmätilinä ajettava palvelu, ajastettu tehtävä ja vuorovaikutteinen kyselyikkuna voivat esittää kolme eri tokenia samalla koneella, ja vain viimeinen vastaa sitä, mitä käyttäjä näkee ajaessaan whoami.
Kysy palvelimelta, mitä se todella näki
Palvelin voi kertoa, minkä kirjautumisen se ratkaisi ja miten yhteys todennettiin. Suorita kysely tutkittavan istunnon sisällä, koska järjestelmänvalvojan erillinen onnistunut yhteys ei todista mitään epäonnistuvasta asiakkaasta.
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;
Ensimmäinen rivi erottaa istunnon avanneen kirjautumisen tällä hetkellä voimassa olevasta suojauskontekstista, ja ne eroavat henkilöitymisen aikana. Toinen nimeää todennusjärjestelmän, joten KERBEROS, NTLM ja SQL muuttuvat näkyviksi tosiasioiksi arvausten sijaan. Yhteys, joka raportoi NTLM:n siellä missä odotit Kerberosta, on nimenratkaisu- tai SPN-ongelma, ei salasanaongelma.
Virhenumero rajaa sitä edelleen. Tila 5 tarkoittaa yleensä, että kirjautumisnimeä ei ratkaistu lainkaan, tila 8 tarkoittaa yleensä, että salasana ei täsmännyt, ja tila 11 tarkoittaa, että tunnistetiedot hyväksyttiin mutta pääsy palvelimelle epäonnistui. Pyydä järjestelmänvalvojalta tila eikä koko viestiä, koska viesti yksin on tarkoituksella epämääräinen.
| What you observe | What it suggests |
|---|---|
| Timeout, no listener | Route, firewall or wrong port |
| Login failed, state 5 | Name not resolved in the domain |
| Login failed, state 11 | Authenticated but no server access |
| Connected as NTLM | Target name or SPN mismatch |
Kun identiteetti saapuu ja Kerberos epäonnistuu silti
Jos palvelin näkee tarkoitetun Windows-identiteetin ja integroitu todennus epäonnistuu silti, ongelma on itse vaihdossa. Kerberos tarvitsee SQL-palvelutilille rekisteröidyn palvelun pääminimen ja asiakkaan, joka pyytää palvelua sitä vastaavalla nimellä. IP-osoitteella yhdistäminen ei voi vastata nimipohjaista SPN:ää, ja alias voi vastata vain, jos sekin on rekisteröity. Tarkista ensin nimi, jonka asiakas kirjoitti, koska yhteys, joka toimii isäntänimellä ja epäonnistuu IP:llä, kuvaa juuri tätä ongelmaa.
Pyydä järjestelmänvalvojaa tarkistamaan rekisteröity identiteetti ja palvelutili sen sijaan, että loisit kaksoiskappaleisia SPN:iä yrityksen ja erehdyksen kautta. Kaksoiskappaleiset rekisteröinnit aiheuttavat ajoittaisia vikoja, joita on vaikeampi diagnosoida kuin alkuperäistä ongelmaa.
Kun todennus toimii, kirjautuminen tarvitsee silti tietokantakäyttäjän ja oikeudet. Onnistunut VPN-kirjautuminen, onnistunut Windows-kirjautuminen ja oikeus lukea tiettyä taulukkoa ovat kolme erillistä tulosta, ja jokainen ansaitsee oman tarkistuksensa ennen tiketin sulkemista.