Эмне үчүн SQL Server VPN аркылуу дагы эле NTLMге түшөт?

Сиздин байланышыңыз иштеп жатат, кирүү кабыл алынат, бирок баары Kerberos күткөндө SQL Server NTLM колдонуп жатат. Бул жыйынтык VPNдин кемчилиги эмес, анткени туннель жол гана берет; схеманы кардар сураган ат, каталогдо катталган негизги субъект жана кардар чынында ала алган билет аныктады. Үч шарт бир убакта аткарылышы керек, ал эми сессия өзү кайсынысы баш тартканын айтат. Биреү кызматтын негизги атын оңдоодон мурун муну окуңуз.

Сессия чынында алган схеманы атайт

Аутентификация схемасы байланышка таандык, серверге же туннелге эмес, ошондуктан текшерүү сизди кызыктырган сессиянын ичинде жүрүшү керек. Төмөнкү сурамды отчетту түзгөн ошол эле кардардан, куралдан жана эсептен аткарып, жыйынтыктын жанына максаттын атын жана транспортту жазып коюңуз.

SELECT session_id, auth_scheme, net_transport, client_net_address, login_name
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Маалымат базасынын хостундагы жергиликтүү SSMS терезесинен алынган сап такыр башка байланышты сүрөттөйт, ошондуктан сурам кардар тарабынан аткарылышы керек. Чыгарылышты убакыт белгиси менен сактаңыз, анткени аны окуган кийинки адам качан алынганын сурайт. Бир нече колдонмо бир акыркы чекитти бөлүшсө, ар биринен үлгү алыңыз, анткени эки колдонмо ортосундагы маалымат булагынын айырмасы көбүнчө бүт окуя.

Биринчи шарт: ат SPNге туура келеби?

Kerberos аталган кызматты аутентификациялайт, ошондуктан кардар каталогдон белгилүү бир негизги субъект үчүн билет сурайт. TCP провайдери үчүн документтелген форма MSSQLSvc/, анан толук квалификацияланган хост аты, ал эми демейки инстанция үчүн порт. Аталган инстанция MSSQLSvc/db01.corp.example:SQLPROD каттайт, мында суффикс сандын ордуна инстанциянын аты. Тыңшоочуга лакап ат, башка жерде чечилүүчү CNAME же жылаңач IP дарек аркылуу жетүү суралган атты өзгөртөт, ал эми туура келген негизги субъектиси жок сурамдын кайтара турган билети жок.

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

Экинчи шарт: SPN туура эсептеби?

SPN SQL кызматын иштеткен эсепке таандык болушу керек, кардардын эсебине эмес жана кокустан компьютер объектисине да эмес. SQL Server иштөө учурунда өзүнүн SPNдерин каттай алат, эгер анын кызмат эсебинде аларды жазууга уруксат болсо, бул ыңгайлуу жана кызмат эсеби алмашкандан кийин көчүрмө кантип пайда болорун да түшүндүрөт.

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

setspn -Q MSSQLSvc/db01.corp.example:1433
setspn -L CORP\svc-sql01

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

Үчүнчү шарт: кардар билетти такыр ала алабы?

Туура SPN пайдасыз, эгер кардар домен контроллеруна жете албаса же колдонууга жарактуу ыйгарым укук контексти жок болсо. Алмашууга VPN аркылуу KDC жана DNS керек, ал эми SQL портун гана багыттаган туннель дал ушул кадамда ийгиликсиз болот. Жетүү мүмкүнчүлүгү алардын алдындагы брандмауэрден эмес, ошол эле машинадан жана ошол эле эсептен текшерилиши керек.

Билет кэшин машинада жана колдонмону иштеткен эсептин астында текшериңиз. Жогорулатылган терезеден алынган машина боюнча тизме башка колдонуучу катары иштеген кызмат жөнүндө эч нерсе айтпайт, ал эми ошол колдонуучу үчүн бош кэш ыңгайсыздык эмес, табылга.

klist
klist -li 0x3e7

Анан чегинүү эмне кыла аларын чечиңиз. Эгер саясат Kerberos-ти талап кылса, NTLM ачык түрдө четке кагылышы керек, анткени үнсүз чегинүү конфигурация катасын талапты бузган иштеген байланышка айландырат. Эгер NTLM айрым колдонмолор үчүн жарактуу бойдон калса, аларды атаңыз жана ар бир NTLM сессиясын окуя катары кароону токтотуңуз.

Иштеткичти өзгөртүү — бир өзгөрмө, оңдоо эмес

SSMSти башка ыйгарым укук менен иштетүү кокустан чыккан идентификацияны айыктырышы мүмкүн, бул көйгөйдүн реалдуу классы. Бул максат аты, каттоо же билет жолу жөнүндө эч нерсени далилдебейт жана сервер кабыл алган нерсени өзгөртпөйт.

Салыштырманы көзөмөлдө кармаңыз: ошол эле акыркы чекит, ошол эле провайдер, белгилүү аткаруу контексти, анан схемасын текшере турган жаңы байланыш. Кабыл алынган кирүүнү жана анын маалымат базасындагы укуктарын өзүнчө ырастаңыз, анткени жетүү жана аутентификация ар кандай себептерден ийгиликсиз болот.

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