Miksi SQL Server VPN:n yli palaa silti NTLM:ään?

Yhteytesi toimii, kirjautuminen hyväksytään ja SQL Server käyttää NTLM:ää, vaikka kaikki odottivat Kerberosta. Tulos ei ole VPN:n vika, koska tunneli tarjoaa vain reitin; skeeman päättivät nimi, jota asiakas pyysi, hakemistoon rekisteröity päämies ja lippu, jonka asiakas todella pystyi hankkimaan. Kolmen ehdon on oltava voimassa yhtä aikaa, ja istunto itse kertoo, mikä niistä antoi periksi. Lue se ennen kuin kukaan muokkaa palvelun päämiesnimeä.

Istunto nimeää skeeman, jonka todella sait

Todennusskeema kuuluu yhteydelle, ei palvelimelle tai tunnelille, joten tarkistus on ajettava istunnon sisällä, joka sinua kiinnostaa. Suorita alla oleva kysely samasta asiakkaasta, työkalusta ja tilistä, jotka tuottivat raportin, ja merkitse kohdenimi ja kuljetus tuloksen viereen.

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

Rivi paikallisesta SSMS-ikkunasta tietokantapalvelimella kuvaa täysin eri yhteyttä, minkä vuoksi kysely on ajettava asiakkaan puolelta. Tallenna tuloste aikaleimalla, koska seuraava lukija kysyy, milloin se otettiin. Kun useat sovellukset jakavat yhden päätepisteen, ota näyte jokaisesta, koska tietolähteen ero kahden sovelluksen välillä on usein koko tarina.

Ensimmäinen ehto: vastaako nimi SPN:ää?

Kerberos todentaa nimetyn palvelun, joten asiakas pyytää hakemistosta lippua yhtä tiettyä päämiestä varten. TCP-tarjoajan dokumentoitu muoto on MSSQLSvc/, jota seuraa täysin kelvollinen isäntänimi ja oletusinstanssin tapauksessa portti. Nimetty instanssi rekisteröi MSSQLSvc/db01.corp.example:SQLPROD, jossa liite on numeroon sijasta instanssin nimi. Kuuntelijaan pääseminen aliaksen, muualla ratkeavan CNAME:n tai paljaan IP-osoitteen kautta muuttaa pyydettyä nimeä, eikä pyynnöllä ilman vastaavaa päämiestä ole palautettavaa lippua.

Siksi yksi sovellus toimii yhdessä verkossa ja palaa toisessa: DNS-vastaus, alias-tietue tai hosts-merkintä muutti nimeä, jota asiakas käytti. Vertaa pyydettyä nimeä siihen, mitä hakemisto sisältää, ennen kuin kosket rekisteröintiin.

Toinen ehto: onko SPN oikealla tilillä?

SPN:n on kuuluttava tilille, joka suorittaa SQL-palvelua, ei asiakkaan tilille eikä vahingossa tietokoneobjektille. SQL Server voi rekisteröidä omat SPN:nsä käynnistyksen yhteydessä, kun sen palvelutilillä on niiden kirjoitusoikeus, mikä on kätevää ja selittää myös, miten kopio syntyy palvelutilin vaihdon jälkeen.

Kysy hakemistolta odottamaasi nimeä ja luettele sitten, mitä tili todella omistaa. Se, mikä objekti pitää merkintää, on tärkeämpää kuin se, onko nimi jossain metsässä. Epäsuhta tarkoittaa, että kirjautuminen ei koskaan ollut ongelma, ja Microsoftin SPN-opas dokumentoi muodot ja tapaukset, joissa toimialueen järjestelmänvalvojan on luotava merkintä.

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

Toisen merkinnän lisääminen ei ole turvallinen koe. Kopio tai ristiriitainen rekisteröinti voi rikkoa asiakkaita, jotka toimivat, joten tarkista omistus ennen muutosta ja uudelleen sen jälkeen.

Kolmas ehto: voiko asiakas ylipäätään saada lipun?

Oikea SPN on hyödytön, jos asiakas ei pääse toimialueen ohjaimeen tai sillä ei ole käyttökelpoista tunnistetietokontekstia. Vaihto tarvitsee KDC:n ja DNS:n VPN:n kautta, ja tunneli, joka reitittää vain SQL-portin, epäonnistuu juuri tässä vaiheessa. Tavoitettavuus on testattava samalta koneelta ja samalta tililtä, ei niiden edessä olevasta palomuurista.

Tarkista lippuvälimuisti koneelta ja sen tilin alta, joka suorittaa sovellusta. Koneenlaajuinen luettelo korotetusta ikkunasta ei kerro mitään palvelusta, joka toimii toisena käyttäjänä, ja tyhjä välimuisti kyseiselle käyttäjälle on löydös eikä haitta.

klist
klist -li 0x3e7

Päätä sitten, mitä varareitti saa tehdä. Jos käytäntö vaatii Kerberosta, NTLM on hylättävä nimenomaisesti, koska hiljainen varareitti muuttaa kokoonpanovirheen toimivaksi yhteydeksi, joka rikkoo vaatimuksen. Jos NTLM pysyy hyväksyttävänä joillekin sovelluksille, nimeä ne ja lopeta jokaisen NTLM-istunnon käsitteleminen tapahtumana.

Käynnistimen vaihtaminen on yksi muuttuja, ei korjaus

SSMS:n käynnistäminen toisilla tunnistetiedoilla voi parantaa tahattoman lähtevän identiteetin, mikä on todellinen ongelmaluokka. Se ei todista mitään kohdenimestä, rekisteröinnistä tai lipun reitistä eikä muuta sitä, mitä palvelin hyväksyi.

Pidä vertailu hallittuna: sama päätepiste, sama tarjoaja, tunnettu suorituskonteksti, sitten tuore yhteys, jonka skeeman tarkistat. Vahvista hyväksytty kirjautuminen ja sen tietokantaoikeudet erikseen, koska pääsy ja todennus epäonnistuvat eri syistä.

Kun Kerberos vaaditaan, kirjaa, miksi ensimmäinen reitti antoi periksi, tee yksi korjaus ja aja kysely uudelleen samasta asiakkaasta. Onnistunut kysely käynnistimen vaihdon jälkeen on todiste pääsystä, eikä se vielä ole todiste siitä, että todennusvaatimus täyttyi.