VPN се повезује, али SQL Server одбија Windows аутентификацију

Тунели се подижу, сервери одговарају на ping, а пријава у базу и даље не успева са грешком аутентификације. Та комбинација је честа на VPN везама и ретко значи да је мрежа покварена, јер доступан слушалац и прихваћена пријава су два различита резултата. Идентитет који је задовољио гејтвеј није нужно идентитет који нуди клијент базе. Утврдити који је налог стигао је цео задатак.

Симптом: доступан сервер, одбијена пријава

Истек времена вам каже да пакет никада није стигао до слушаоца. Грешка аутентификације каже да је слушалац одговорио и одбио акредитиве. Те две поруке вас шаљу различитим тимовима, а њихово мешање троши дан на правила заштитног зида која никада нису била проблем.

Када је грешка неуспела пријава, престаните да гледате портове. Остаје питање који је Windows идентитет клијент представио, да ли га је сервер прихватио и да ли се разрешио у корисника базе са дозволом.

Два идентитета, један тунел

Налог за VPN се аутентификује на гејтвеју и у већини распоређивања ту се завршава. Клијент базе одвојено представља Windows токен, узет из процеса који га извршава, или SQL пријаву ако је тражи ниска за повезивање. Локални VPN корисник на гејтвеју нема никакву везу са доменом који хостује SQL Server, а тунел је не ствара.

Повезивање личног рачунара са VPN-ом га такође не придружује домену. Преименовање локалног налога и усклађивање његове лозинке са корисником домена није поступак уписа и ствара токен који контролер домена неће прихватити као тог корисника.

Неки изворни Windows клијенти за даљински приступ могу поново да користе VPN акредитиве за мрежне ресурсе када је њихов профил тако конфигурисан. Такво понашање припада одређеном клијенту и профилу, а не VPN везама уопште, зато га проверите за клијента који се користи уместо да га претпостављате.

Прочитајте режим који је клијент затражио

Ниска за повезивање одлучује којим путем аутентификације клијент иде. Интегрисана безбедност користи Windows токен; пар корисник и лозинка бира SQL пријаву. То су одвојени режими у конфигурацији сервера и само један од њих може бити омогућен за дати покушај повезивања.

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

Прелазак на SQL пријаву зато што је Windows пријава неуспела је заобилазно решење које скрива питање идентитета и обично ипак захтева стварање нове пријаве и лозинке. Ако распоређивање захтева Windows аутентификацију, задржите режим и поправите пут идентитета. SQL пријава такође треба сопствене дозволе, па заобилазно решење купује други налог за одржавање.

Такође потврдите која се апликација повезује. Сервис који ради под системским налогом, заказани задатак и интерактивни прозор упита могу представити три различита токена на истом рачунару, а само последњи одговара ономе што корисник види када покрене whoami.

Питајте сервер шта је заиста видео

Сервер вам може рећи коју је пријаву разрешио и како се веза аутентификовала. Покрените упит унутар сесије која се истражује, јер администраторова одвојена успешна веза ништа не доказује о клијенту који не успева.

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;

Први ред разликује пријаву која је отворила сесију од безбедносног контекста који сада важи, а они се разликују под имперсонацијом. Други наводи шему аутентификације, па KERBEROS, NTLM и SQL постају видљиве чињенице уместо нагађања. Веза која пријављује NTLM тамо где сте очекивали Kerberos је проблем разрешавања имена или SPN-а, а не проблем лозинке.

Број грешке додатно сужава. Стање 5 обично значи да име пријаве уопште није разрешено, стање 8 обично значи да се лозинка није поклопила, а стање 11 значи да су акредитиви прихваћени, али приступ серверу није успео. Тражите од администратора стање, а не целу поруку, јер је сама порука намерно неодређена.

Када идентитет стигне, а Kerberos и даље не успева

Ако сервер види жељени Windows идентитет, а интегрисана аутентификација и даље не успева, проблем је у самој размени. Kerberos захтева име сервисног принципала регистровано за налог SQL сервиса и клијента који тражи сервис под именом које му одговара. Повезивање по IP адреси не може да одговара SPN-у заснованом на имену, а алијас може да одговара само ако је и он регистрован. Прво проверите име које је клијент унео, јер веза која ради по имену хоста и не успева по IP-у описује управо овај проблем.

Замолите администратора да прегледа регистровани идентитет и налог сервиса уместо да ствара дупликате SPN-а методом покушаја и грешке. Дупликат регистрације стварају повремене кварове које је теже дијагностиковати од изворног проблема.

Када аутентификација проради, пријава и даље треба корисника базе и дозволе. Успешна VPN пријава, успешна Windows пријава и дозвола за читање одређене табеле су три одвојена резултата и сваки заслужује сопствену проверу пре него што се тикет затвори.