Nega VPN orqali SQL Server hali ham NTLM ga qaytadi?

Ulanishingiz ishlayapti, kirish qabul qilinmoqda va hamma Kerberos kutgan paytda SQL Server NTLM dan foydalanmoqda. Bu natija VPN nuqsoni emas, chunki tunnel faqat yo'l beradi; sxemani mijoz so'ragan nom, katalogda ro'yxatga olingan prinsipal va mijoz haqiqatan olishga muvaffaq bo'lgan chipta belgiladi. Uch shart bir vaqtda bajarilishi kerak va qaysi biri yon berganini sessiyaning o'zi aytadi. Kimdir xizmat prinsipal nomini tahrirlashdan oldin buni o'qing.

Sessiya siz haqiqatan olgan sxemani nomlaydi

Autentifikatsiya sxemasi server yoki tunnelga emas, ulanishga tegishli, shuning uchun tekshiruv sizni qiziqtirgan sessiya ichida bajarilishi kerak. Quyidagi so'rovni hisobotni yaratgan bir xil mijoz, vosita va hisobdan bajaring, natija yoniga maqsad nomi va transportni yozib qo'ying.

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

Ma'lumotlar bazasi xostidagi mahalliy SSMS oynasidan olingan qator butunlay boshqa ulanishni tasvirlaydi, shuning uchun so'rov mijoz tomondan bajarilishi kerak. Natijani vaqt belgisi bilan saqlang, chunki uni o'qiydigan keyingi odam qachon olinganini so'raydi. Bir nechta ilova bitta yakuniy nuqtani baham ko'rsa, har biridan namuna oling, chunki ikki ilova o'rtasidagi ma'lumot manbasi farqi ko'pincha butun hikoya.

Birinchi shart: nom SPN ga mos keladimi?

Kerberos nomlangan xizmatni autentifikatsiya qiladi, shuning uchun mijoz katalogdan bitta aniq prinsipal uchun chipta so'raydi. TCP provayderi uchun hujjatlashtirilgan shakl MSSQLSvc/ bo'lib, undan keyin to'liq kvalifikatsiyalangan xost nomi va standart nusxa uchun port keladi. Nomlangan nusxa MSSQLSvc/db01.corp.example:SQLPROD ni ro'yxatga oladi, bunda suffiks raqam o'rniga nusxa nomi. Tinglovchiga taxallus, boshqa joyda hal qilinadigan CNAME yoki yalang'och IP manzil orqali yetib borish so'ralgan nomni o'zgartiradi va mos prinsipalga ega bo'lmagan so'rovning qaytaradigan chiptasi yo'q.

Shuning uchun bitta ilova bir tarmoqda ishlaydi va boshqasida orqaga chekinadi: DNS javobi, taxallus yozuvi yoki hosts yozuvi mijoz ishlatgan nomni o'zgartirdi. Ro'yxatga tegishdan oldin so'ralgan nomni katalogda mavjud nom bilan solishtiring.

Ikkinchi shart: SPN to'g'ri hisobdami?

SPN SQL xizmatini ishga tushiruvchi hisobga tegishli bo'lishi kerak, mijoz hisobiga emas va tasodifan kompyuter obyektiga ham emas. SQL Server ishga tushganda xizmat hisobida ularni yozish ruxsati bo'lsa, o'z SPN larini ro'yxatga olishi mumkin, bu qulay va xizmat hisobi o'zgargandan keyin nusxa qanday paydo bo'lishini ham tushuntiradi.

Katalogdan kutgan nomni so'rang, so'ngra hisob haqiqatan nimalarga egaligini sanab chiqing. Qaysi obyekt yozuvni saqlashi nom o'rmonda biror joyda bor-yo'qligidan muhimroq. Mos kelmaslik kirish hech qachon muammo bo'lmaganini bildiradi va Microsoft ning SPN qo'llanmasi shakllar va domen administratori yozuvni yaratishi kerak bo'lgan holatlarni hujjatlashtiradi.

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

Yana bitta yozuv qo'shish xavfsiz tajriba emas. Nusxa yoki ziddiyatli ro'yxatga olish ishlab turgan mijozlarni buzishi mumkin, shuning uchun o'zgartirishdan oldin egalikni tekshiring va keyin yana tekshiring.

Uchinchi shart: mijoz chipta ola oladimi?

To'g'ri SPN foydasiz, agar mijoz domen kontrolleriga yetib bora olmasa yoki ishlatish mumkin bo'lgan hisob ma'lumotlari kontekstiga ega bo'lmasa. Ayirboshlash VPN orqali KDC va DNS ni talab qiladi va faqat SQL portini yo'naltiruvchi tunnel aynan shu qadamda muvaffaqiyatsiz bo'ladi. Yetib borish qobiliyati ularning oldidagi tarmoq devoridan emas, bir xil mashina va bir xil hisobdan tekshirilishi kerak.

Chipta keshini mashinada va ilovani ishga tushiruvchi hisob ostida tekshiring. Yuqori oynadan olingan butun mashina ro'yxati boshqa foydalanuvchi sifatida ishlayotgan xizmat haqida hech narsa demaydi va o'sha foydalanuvchi uchun bo'sh kesh noqulaylik emas, topilma.

klist
klist -li 0x3e7

So'ngra orqaga chekinish nima qilishi mumkinligini hal qiling. Agar siyosat Kerberos ni talab qilsa, NTLM ochiq rad etilishi kerak, chunki jim orqaga chekinish konfiguratsiya xatosini talabni buzadigan ishlaydigan ulanishga aylantiradi. Agar NTLM ba'zi ilovalar uchun maqbul bo'lib qolsa, ularni nomlang va har bir NTLM sessiyasini hodisa deb hisoblashni to'xtating.

Ishga tushirgichni o'zgartirish bitta o'zgaruvchi, tuzatish emas

SSMS ni boshqa hisob ma'lumotlari bilan ishga tushirish kutilmagan chiquvchi identifikatsiyani davolashi mumkin, bu muammoning haqiqiy sinfi. Bu maqsad nomi, ro'yxatga olish yoki chipta yo'li haqida hech narsani isbotlamaydi va server qabul qilgan narsani o'zgartirmaydi.

Taqqoslashni nazorat ostida saqlang: bir xil yakuniy nuqta, bir xil provayder, ma'lum bajarish konteksti, so'ngra sxemasini tekshiradigan yangi ulanish. Qabul qilingan kirish va uning ma'lumotlar bazasidagi ruxsatlarini alohida tasdiqlang, chunki kirish va autentifikatsiya turli sabablarga ko'ra muvaffaqiyatsiz bo'ladi.

Kerberos talab qilinganda birinchi yo'l nima uchun chekinganini yozib qo'ying, bitta tuzatish qo'llang va so'rovni o'sha mijozdan qayta bajaring. Ishga tushirgich o'zgarganidan keyin muvaffaqiyatli so'rov kirishning isboti va autentifikatsiya talabi bajarilganining isboti hali emas.