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 и право да се чете определена таблица са три отделни резултата и всяко заслужава собствена проверка, преди заявката да бъде затворена.