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 і дазвол чытаць пэўную табліцу — гэта тры асобныя вынікі, і кожны варты ўласнай праверкі, перш чым закрыць заяўку.