Kumokonekta ang VPN, pero tinatanggihan ng SQL Server ang Windows authentication

Bumabangon ang mga tunnel, sumasagot ang mga server sa ping, at nabibigo pa rin ang pag-log in sa database na may error sa authentication. Karaniwan ang kombinasyong iyon sa mga link ng VPN at bihirang ibig sabihin na sira ang network, dahil ang naaabot na listener at ang tinanggap na pag-log in ay dalawang magkaibang resulta. Ang identidad na nagbigay-kasiyahan sa gateway ay hindi laging ang identidad na iniaalok ng kliyente ng database. Ang pag-alam kung aling account ang dumating ay ang buong gawain.

Ang sintomas: naaabot ang server, tinanggihan ang pag-log in

Sinasabi ng timeout na hindi kailanman naabot ng packet ang isang listener. Sinasabi ng error sa authentication na sumagot ang listener at tinanggihan ang kredensyal. Ang dalawang mensaheng iyon ay nagpapadala sa iyo sa magkaibang team, at ang paghahalo sa kanila ay nagsasayang ng isang araw sa mga patakaran ng firewall na hindi kailanman naging problema.

Kapag ang error ay nabigong pag-log in, itigil ang pagtingin sa mga port. Ang natitirang tanong ay kung aling identidad ng Windows ang iniharap ng kliyente, tinanggap ba ng server ang identidad na iyon, at naresolba ba ito sa isang user ng database na may pahintulot.

Dalawang identidad, isang tunnel

Nagpapatunay ang account ng VPN sa gateway at sa karamihan ng deployment ay nagtatapos doon. Ang kliyente ng database ay hiwalay na naghaharap ng token ng Windows, kinuha mula sa prosesong nagpapatakbo nito, o ng pag-log in sa SQL kung hinihingi ito ng connection string. Ang lokal na user ng VPN sa gateway ay walang kaugnayan sa domain na nagho-host ng SQL Server, at hindi ito nililikha ng tunnel.

Ang pagkonekta ng personal na makina sa VPN ay hindi rin ito nagdaragdag sa domain. Ang pagpapalit ng pangalan ng lokal na account at pagtutugma ng password nito sa isang user ng domain ay hindi pamamaraan ng pagpapatala, at gumagawa ito ng token na hindi tatanggapin ng domain controller bilang user na iyon.

Ang ilang native na kliyente ng remote access ng Windows ay maaaring gumamit muli ng kredensyal ng VPN para sa mga resource ng network kapag ang kanilang profile ay naka-configure nang ganoon. Ang pag-uugaling iyon ay pag-aari ng isang partikular na kliyente at profile, hindi ng mga koneksyon sa VPN sa pangkalahatan, kaya i-verify ito para sa kliyenteng ginagamit sa halip na ipagpalagay.

Basahin ang mode na hiniling ng kliyente

Ang connection string ang nagtatakda kung aling landas ng authentication ang tatahakin ng kliyente. Ginagamit ng integrated security ang token ng Windows; pinipili ng pares ng user at password ang pag-log in sa SQL. Magkaibang mode ang mga ito sa configuration ng server, at isa lamang sa kanila ang maaaring paganahin para sa isang partikular na pagtatangkang kumonekta.

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

Ang paglipat sa pag-log in sa SQL dahil nabigo ang pag-log in sa Windows ay isang pansamantalang solusyon na nagtatago ng tanong tungkol sa identidad, at karaniwang nangangailangan pa rin ito ng paggawa ng bagong pag-log in at password. Kung hinihingi ng deployment ang Windows authentication, panatilihin ang mode at ayusin ang landas ng identidad. Kailangan din ng pag-log in sa SQL ang sarili nitong mga pahintulot, kaya ang pansamantalang solusyon ay bumibili ng pangalawang account na aalagaan.

Tiyakin din kung aling application ang kumokonekta. Ang serbisyong tumatakbo bilang system account, naka-iskedyul na gawain at interactive na window ng query ay maaaring magharap ng tatlong magkaibang token sa parehong makina, at ang huli lamang ang tumutugma sa nakikita ng user kapag pinapatakbo nito ang whoami.

Itanong sa server kung ano talaga ang nakita nito

Masasabi ng server kung aling pag-log in ang naresolba nito at kung paano na-authenticate ang koneksyon. Patakbuhin ang query sa loob ng session na iniimbestigahan, dahil ang hiwalay na matagumpay na koneksyon ng administrator ay walang pinapatunayan tungkol sa kliyenteng nabibigo.

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;

Ang unang hilera ay naghihiwalay sa pag-log in na nagbukas ng session mula sa security context na umiiral ngayon, at nagkakaiba ang mga ito sa ilalim ng impersonation. Ang pangalawa ay nagpapangalan sa scheme ng authentication, kaya ang KERBEROS, NTLM at SQL ay nagiging nakikitang katotohanan sa halip na haka-haka. Ang koneksyong nag-uulat ng NTLM sa lugar kung saan inaasahan mo ang Kerberos ay problema sa pagresolba ng pangalan o SPN, hindi problema sa password.

Pinaliit pa ito ng numero ng error. Ang estado 5 ay karaniwang nangangahulugang hindi naresolba ang pangalan ng pag-log in, ang estado 8 ay karaniwang nangangahulugang hindi tumugma ang password, at ang estado 11 ay nangangahulugang tinanggap ang kredensyal ngunit nabigo ang pag-access sa server. Hilingin sa administrator ang estado sa halip na ang buong mensahe, dahil ang mensahe lamang ay sadyang malabo.

Kapag dumating ang identidad at nabibigo pa rin ang Kerberos

Kung nakikita ng server ang inaasahang identidad ng Windows at nabibigo pa rin ang integrated authentication, ang palitan mismo ang problema. Kailangan ng Kerberos ang pangunahing pangalan ng serbisyo na nakarehistro para sa service account ng SQL at isang kliyenteng humihiling ng serbisyo sa pangalang tumutugma rito. Ang pagkonekta sa pamamagitan ng IP address ay hindi maaaring tumugma sa SPN na batay sa pangalan, at ang alias ay maaaring tumugma lamang kung nakarehistro rin ito. Suriin muna ang pangalang inilagay ng kliyente, dahil ang koneksyong gumagana sa hostname at nabibigo sa IP ay inilalarawan ang eksaktong problemang ito.

Hilingin sa administrator na repasuhin ang nakarehistrong identidad at service account sa halip na gumawa ng doble na SPN sa pamamagitan ng pagsubok at pagkakamali. Ang mga dobleng rehistro ay nagdudulot ng paminsan-minsang pagkabigo na mas mahirap i-diagnose kaysa sa orihinal na problema.

Kapag gumagana na ang authentication, kailangan pa rin ng pag-log in ang isang user ng database at mga pahintulot. Ang matagumpay na pag-log in sa VPN, matagumpay na pag-log in sa Windows at pahintulot na basahin ang isang partikular na talahanayan ay tatlong magkaibang resulta, at bawat isa ay karapat-dapat sa sarili nitong pagsusuri bago isara ang ticket.