VPN ulanadi, lekin SQL Server Windows autentifikatsiyasini rad etadi

Tunnellar ko'tariladi, serverlar ping'ga javob beradi, lekin ma'lumotlar bazasiga kirish hali ham autentifikatsiya xatosi bilan muvaffaqiyatsiz tugaydi. Bu birikma VPN ulanishlarida keng tarqalgan va tarmoq buzilgan degani kamdan-kam bo'ladi, chunki yetib borish mumkin bo'lgan tinglovchi va qabul qilingan kirish ikki xil natija. Darvozani qanoatlantirgan shaxs ma'lumotlar bazasi mijozi taklif qiladigan shaxs bo'lishi shart emas. Qaysi hisob kelganini aniqlash — butun ish.

Belgi: yetib borish mumkin bo'lgan server, rad etilgan kirish

Vaqt tugashi paket hech qanday tinglovchiga yetib bormaganini aytadi. Autentifikatsiya xatosi tinglovchi javob berib, ishonchnomani rad etganini aytadi. Bu ikki xabar sizni turli jamoalarga yuboradi, ularni aralashtirish esa hech qachon muammo bo'lmagan xavfsizlik devori qoidalariga bir kun sarflaydi.

Xato kirishning muvaffaqiyatsizligi bo'lsa, portlarga qarashni to'xtating. Qolgan savol: mijoz qaysi Windows shaxsini taqdim etdi, server bu shaxsni qabul qildimi va u ruxsatga ega ma'lumotlar bazasi foydalanuvchisiga aylantirildimi.

Ikki shaxs, bitta tunnel

VPN hisobi darvozada autentifikatsiyadan o'tadi va ko'pchilik joylashtirishlarda shu yerda tugaydi. Ma'lumotlar bazasi mijozi alohida Windows tokenini taqdim etadi, u uni ishga tushiradigan jarayondan olinadi, yoki ulanish satri talab qilsa SQL kirishini taqdim etadi. Darvozadagi mahalliy VPN foydalanuvchisining SQL Server joylashgan domenga hech qanday aloqasi yo'q va tunnel bunday aloqa yaratmaydi.

Shaxsiy mashinani VPN'ga ulash uni domenga ham qo'shmaydi. Mahalliy hisob nomini o'zgartirish va uning parolini domen foydalanuvchisiga moslashtirish ro'yxatga olish tartibi emas va u domen boshqaruvchisi bu foydalanuvchi sifatida qabul qilmaydigan token yaratadi.

Ba'zi mahalliy Windows masofaviy kirish mijozlari profili shunday sozlangan bo'lsa, tarmoq resurslari uchun VPN ishonchnomasini qayta ishlatishi mumkin. Bu xatti-harakat muayyan mijoz va profilga tegishli, umuman VPN ulanishlariga emas, shuning uchun taxmin qilish o'rniga ishlatilayotgan mijoz uchun tekshiring.

Mijoz so'ragan rejimni o'qing

Ulanish satri mijoz qaysi autentifikatsiya yo'lini tanlashini belgilaydi. Integratsiyalashgan xavfsizlik Windows tokenidan foydalanadi; foydalanuvchi va parol juftligi SQL kirishini tanlaydi. Bular server konfiguratsiyasida alohida rejimlar va berilgan ulanish urinishi uchun ulardan faqat bittasi yoqilgan bo'lishi mumkin.

Server=tcp:sql.lab.example,1433;Database=ops;Integrated Security=SSPI;Encrypt=True;TrustServerCertificate=False;

Windows kirishi muvaffaqiyatsiz bo'lgani uchun SQL kirishiga o'tish shaxs savolini yashiradigan vaqtinchalik yechim va u odatda yangi kirish va parol yaratishni baribir talab qiladi. Agar joylashtirish Windows autentifikatsiyasini talab qilsa, rejimni saqlang va shaxs yo'lini tuzating. SQL kirishiga ham o'z ruxsatlari kerak, shuning uchun vaqtinchalik yechim xizmat ko'rsatish uchun ikkinchi hisob sotib oladi.

Qaysi ilova ulanayotganini ham tasdiqlang. Tizim hisobi sifatida ishlaydigan xizmat, rejalashtirilgan vazifa va interaktiv so'rov oynasi bitta mashinada uch xil token taqdim etishi mumkin va faqat oxirgisi foydalanuvchi whoami ni ishga tushirganda ko'radigan narsaga mos keladi.

Serverdan aslida nima ko'rganini so'rang

Server qaysi kirishni hal qilganini va ulanish qanday autentifikatsiya qilinganini aytib berishi mumkin. So'rovni tekshirilayotgan sessiya ichida bajaring, chunki administratorning alohida muvaffaqiyatli ulanishi muvaffaqiyatsiz mijoz haqida hech narsani isbotlamaydi.

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;

Birinchi qator sessiyani ochgan kirishni hozir amaldagi xavfsizlik kontekstidan ajratadi va ular o'zini boshqa shaxs sifatida ko'rsatishda farq qiladi. Ikkinchisi autentifikatsiya sxemasini nomlaydi, shuning uchun KERBEROS, NTLM va SQL taxminlar o'rniga ko'rinadigan faktlarga aylanadi. Kerberos kutgan joyda NTLM haqida xabar beradigan ulanish parol muammosi emas, nomni hal qilish yoki SPN muammosi.

Xato raqami buni yanada toraytiradi. 5 holati odatda kirish nomi umuman hal qilinmaganini, 8 holati odatda parol mos kelmaganini, 11 holati esa ishonchnoma qabul qilingan, lekin serverga kirish muvaffaqiyatsiz bo'lganini bildiradi. Administratoridan butun xabarni emas, holatni so'rang, chunki xabarning o'zi ataylab noaniq.

Shaxs kelganda va Kerberos hali ham muvaffaqiyatsiz bo'lganda

Agar server ko'zda tutilgan Windows shaxsini ko'rsa va integratsiyalashgan autentifikatsiya hali ham muvaffaqiyatsiz bo'lsa, muammo almashinuvning o'zida. Kerberos SQL xizmat hisobi uchun ro'yxatga olingan xizmat asosiy nomini va xizmatni unga mos nom bilan so'raydigan mijozni talab qiladi. IP manzil orqali ulanish nomga asoslangan SPN bilan mos kela olmaydi va taxallus ham ro'yxatga olingan bo'lsagina mos kelishi mumkin. Eng avval mijoz tergan nomni tekshiring, chunki xost nomi bilan ishlab, IP bilan muvaffaqiyatsiz bo'ladigan ulanish aynan shu muammoni tasvirlaydi.

Administratordan sinov va xato yo'li bilan nusxa SPN yaratish o'rniga ro'yxatga olingan shaxs va xizmat hisobini ko'rib chiqishni so'rang. Nusxa yozuvlar asl muammodan ko'ra diagnostika qilish qiyinroq bo'lgan oraliq nosozliklarni keltirib chiqaradi.

Autentifikatsiya ishlagandan keyin ham kirishga ma'lumotlar bazasi foydalanuvchisi va ruxsatlar kerak. Muvaffaqiyatli VPN kirishi, muvaffaqiyatli Windows kirishi va muayyan jadvalni o'qish ruxsati uch xil natija va har biri chipta yopilishidan oldin o'z tekshiruviga loyiq.