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;

Windows кирүүсү ишке ашпагандыктан SQL кирүүсүнө өтүү — инсандык суроосун жашырган убактылуу чечим, жана ал адатта жаңы кирүү менен сырсөздү түзүүнү баары бир талап кылат. Эгер жайгаштыруу 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 божомолдун ордуна көрүнүп турган фактыларга айланат. Kerberos күткөн жерде NTLM деп билдирген туташуу сырсөз көйгөйү эмес, атты чечүү же SPN көйгөйү.

Ката номери аны андан ары тарылтат. 5 абалы адатта кирүү аты такыр чечилбегенин, 8 абалы адатта сырсөз дал келбегенин, ал эми 11 абалы ырастоо документи кабыл алынган, бирок серверге кирүү ишке ашпаганын билдирет. Администратордон бүт билдирүүнү эмес, абалды сураңыз, анткени билдирүү өзү атайын бүдөмүк.

Инсандык келгенде жана Kerberos дагы эле ишке ашпаганда

Эгер сервер көздөлгөн Windows инсандыгын көрүп, интеграцияланган аутентификация дагы эле ишке ашпаса, көйгөй алмашуунун өзүндө. Kerberosко SQL кызмат эсеби үчүн катталган кызматтын негизги аты (SPN) жана кызматты ага дал келген ат менен сураган кардар керек. IP дареги аркылуу туташуу атка негизделген SPN ге дал келе албайт, ал эми псевдоним ал да катталган болсо гана дал келе алат. Баарынан мурун кардар терген атты текшериңиз, анткени хост аты менен иштеп, IP менен ишке ашпаган туташуу дал ушул көйгөйдү сүрөттөйт.

Администратордон сыноо жана ката кетирүү жолу менен кайталанган SPN жасоонун ордуна катталган инсандык менен кызмат эсебин карап чыгууну сураныңыз. Кайталанган каттоолор баштапкы көйгөйдөн диагностикалоо кыйыныраак үзгүлтүктүү бузулууларды жаратат.

Аутентификация иштегенден кийин да кирүүгө маалымат базасынын колдонуучусу жана уруксаттар керек. Ийгиликтүү VPN кирүүсү, ийгиликтүү Windows кирүүсү жана белгилүү бир таблицаны окуу уруксаты үч өзүнчө натыйжа, жана ар бири билет жабылганга чейин өзүнүн текшерүүсүнө татыктуу.