VPN savienojas, bet SQL Server noraida Windows autentifikāciju

Tuneļi ceļas, serveri atbild uz ping, un pieteikšanās datubāzē joprojām neizdodas ar autentifikācijas kļūdu. Šī kombinācija VPN savienojumos ir izplatīta un reti nozīmē, ka tīkls ir salauzts, jo sasniedzams klausītājs un pieņemta pieteikšanās ir divi dažādi rezultāti. Identitāte, kas apmierināja vārteju, ne vienmēr ir tā identitāte, ko piedāvā datubāzes klients. Noskaidrot, kurš konts ieradās, ir viss darbs.

Simptoms: sasniedzams serveris, noraidīta pieteikšanās

Taimauts jums saka, ka pakete nekad nav sasniegusi klausītāju. Autentifikācijas kļūda saka, ka klausītājs atbildēja un noraidīja akreditācijas datus. Šie divi ziņojumi jūs sūta pie dažādām komandām, un to sajaukšana iztērē dienu ugunsmūra noteikumiem, kas nekad nav bijuši problēma.

Kad kļūda ir neizdevusies pieteikšanās, pārtrauciet skatīties uz portiem. Paliek jautājums, kādu Windows identitāti klients uzrādīja, vai serveris to pieņēma un vai tā tika atrisināta uz datubāzes lietotāju ar atļauju.

Divas identitātes, viens tunelis

VPN konts autentificējas vārtejā un lielākajā daļā izvietojumu ar to arī beidzas. Datubāzes klients atsevišķi uzrāda Windows pilnvaru, kas ņemta no procesa, kurš to izpilda, vai SQL pieteikšanos, ja to pieprasa savienojuma virkne. Vārtejas lokālajam VPN lietotājam nav nekādu saišu ar domēnu, kurā mitinās SQL Server, un tunelis tādas saites nerada.

Personālā datora pievienošana VPN to arī nepievieno domēnam. Lokālā konta pārdēvēšana un tā paroles pielāgošana domēna lietotājam nav reģistrācijas procedūra, un tā rada pilnvaru, ko domēna kontrolieris nepieņems kā šo lietotāju.

Daži Windows vietējie attālinātās piekļuves klienti var atkārtoti izmantot VPN akreditācijas datus tīkla resursiem, ja to profils ir tā konfigurēts. Šī uzvedība pieder konkrētam klientam un profilam, nevis VPN savienojumiem kopumā, tāpēc pārbaudiet to izmantotajam klientam, nevis pieņemiet.

Nolasiet režīmu, ko klients pieprasīja

Savienojuma virkne nosaka, kuru autentifikācijas ceļu klients izvēlas. Integrētā drošība izmanto Windows pilnvaru; lietotāja un paroles pāris izvēlas SQL pieteikšanos. Tie ir atsevišķi režīmi servera konfigurācijā, un konkrētam savienojuma mēģinājumam var būt iespējots tikai viens no tiem.

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

Pāreja uz SQL pieteikšanos tāpēc, ka Windows pieteikšanās neizdevās, ir apiešanas risinājums, kas slēpj identitātes jautājumu, un parasti tomēr prasa izveidot jaunu pieteikšanos un paroli. Ja izvietojums prasa Windows autentifikāciju, saglabājiet režīmu un izlabojiet identitātes ceļu. SQL pieteikšanai vajadzīgas arī savas atļaujas, tāpēc apiešanas risinājums nopērk otru kontu, kas jāuztur.

Pārbaudiet arī, kura lietojumprogramma savienojas. Pakalpojums, kas darbojas kā sistēmas konts, ieplānots uzdevums un interaktīvs vaicājuma logs tajā pašā datorā var uzrādīt trīs dažādas pilnvaras, un tikai pēdējā atbilst tam, ko lietotājs redz, palaižot whoami.

Pajautājiet serverim, ko tas patiesībā redzēja

Serveris var pateikt, kuru pieteikšanos tas atrisināja un kā savienojums autentificējās. Izpildiet vaicājumu pētāmajā sesijā, jo atsevišķs veiksmīgs administratora savienojums neko nepierāda par klientu, kuram neizdodas.

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;

Pirmā rinda atšķir pieteikšanos, kas atvēra sesiju, no šobrīd spēkā esošā drošības konteksta, un tie atšķiras personificēšanas laikā. Otrā nosauc autentifikācijas shēmu, tāpēc KERBEROS, NTLM un SQL kļūst par redzamiem faktiem, nevis minējumiem. Savienojums, kas ziņo NTLM tur, kur jūs gaidījāt Kerberos, ir nosaukumu atrisināšanas vai SPN problēma, nevis paroles problēma.

Kļūdas numurs to vēl vairāk sašaurina. 5 stāvoklis parasti nozīmē, ka pieteikšanās vārds vispār netika atrisināts, 8 stāvoklis parasti nozīmē, ka parole neatbilda, un 11 stāvoklis nozīmē, ka akreditācijas dati tika pieņemti, bet piekļuve serverim neizdevās. Lūdziet administratoram stāvokli, nevis visu ziņojumu, jo ziņojums pats par sevi ir apzināti neskaidrs.

Kad identitāte ierodas un Kerberos joprojām neizdodas

Ja serveris redz paredzēto Windows identitāti un integrētā autentifikācija joprojām neizdodas, problēma ir pašā apmaiņā. Kerberos nepieciešams reģistrēts pakalpojuma galvenais nosaukums (SPN) SQL pakalpojuma kontam un klients, kas pieprasa pakalpojumu ar tam atbilstošu nosaukumu. Savienojoties ar IP adresi, nevar atbilst uz nosaukumu balstītam SPN, un aizstājvārds var atbilst tikai tad, ja arī tas ir reģistrēts. Vispirms pārbaudiet nosaukumu, ko klients ierakstīja, jo savienojums, kas darbojas pēc resursdatora nosaukuma un neizdodas pēc IP, apraksta tieši šo problēmu.

Lūdziet administratoram pārskatīt reģistrēto identitāti un pakalpojuma kontu, nevis veidot dublētus SPN ar mēģinājumiem un kļūdām. Dublētas reģistrācijas rada periodiskus traucējumus, kurus diagnosticēt ir grūtāk nekā sākotnējo problēmu.

Kad autentifikācija darbojas, pieteikšanai joprojām vajadzīgs datubāzes lietotājs un atļaujas. Veiksmīga VPN pieteikšanās, veiksmīga Windows pieteikšanās un atļauja lasīt konkrētu tabulu ir trīs atsevišķi rezultāti, un katrs ir pelnījis savu pārbaudi pirms biļetes aizvēršanas.