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 бара регистрирано главно име на услуга (SPN) за сметката на услугата SQL и клиент што ја бара услугата по име што се совпаѓа. Поврзувањето по IP-адреса не може да се совпадне со SPN заснован на име, а псевдонимот може да се совпадне само ако и тој е регистриран. Проверете го прво името што клиентот го внел, бидејќи врска што работи по име на хост, а не успева по IP, го опишува точно овој проблем.

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

Откако автентикацијата ќе проработи, најавата сѐ уште има потреба од корисник на базата и дозволи. Успешна најава VPN, успешна најава Windows и дозвола да се чита одредена табела се три одделни резултати и секој заслужува своја проверка пред да се затвори барањето.