ทำไม SQL Server ผ่าน VPN ยังคงถอยกลับไปใช้ NTLM?

การเชื่อมต่อของคุณทำงาน การเข้าสู่ระบบได้รับการยอมรับ และ SQL Server ใช้ NTLM ขณะที่ทุกคนคาดหวัง Kerberos ผลลัพธ์นั้นไม่ใช่ข้อบกพร่องของ 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 ของตนเองเมื่อเริ่มทำงานได้หากบัญชีบริการมีสิทธิ์เขียน ซึ่งสะดวกและยังอธิบายว่าทำไมจึงเกิดรายการซ้ำหลังเปลี่ยนบัญชีบริการ

ถามไดเรกทอรีถึงชื่อที่คุณคาดหวัง จากนั้นแสดงรายการสิ่งที่บัญชีเป็นเจ้าของจริง วัตถุใดถือรายการนั้นสำคัญกว่าว่าชื่อมีอยู่ที่ใดที่หนึ่งในฟอเรสต์หรือไม่ การไม่ตรงกันหมายความว่าการเข้าสู่ระบบไม่เคยเป็นปัญหา และ คู่มือ SPN ของ Microsoft อธิบายรูปแบบและกรณีที่ผู้ดูแลโดเมนต้องสร้างรายการ

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

การเพิ่มอีกรายการไม่ใช่การทดลองที่ปลอดภัย รายการซ้ำหรือการลงทะเบียนที่ขัดแย้งอาจทำให้ไคลเอนต์ที่ทำงานอยู่เสียหาย ดังนั้นตรวจสอบความเป็นเจ้าของก่อนการเปลี่ยนแปลงและตรวจซ้ำหลังจากนั้น

เงื่อนไขที่สาม: ไคลเอนต์ได้ตั๋วหรือไม่?

SPN ที่ถูกต้องไม่มีประโยชน์หากไคลเอนต์เข้าถึงโดเมนคอนโทรลเลอร์ไม่ได้หรือไม่มีบริบทข้อมูลรับรองที่ใช้ได้ การแลกเปลี่ยนต้องใช้ KDC และ DNS ผ่าน VPN และอุโมงค์ที่กำหนดเส้นทางเฉพาะพอร์ต SQL จะล้มเหลวในขั้นตอนนี้พอดี ต้องทดสอบการเข้าถึงจากเครื่องและบัญชีเดียวกัน ไม่ใช่จากไฟร์วอลล์ที่อยู่ข้างหน้า

ตรวจสอบแคชตั๋วบนเครื่องและภายใต้บัญชีที่รันแอปพลิเคชัน รายการทั้งเครื่องจากหน้าต่างที่ยกระดับไม่ได้บอกอะไรเกี่ยวกับบริการที่รันเป็นผู้ใช้อื่น และแคชว่างสำหรับผู้ใช้นั้นเป็นการค้นพบไม่ใช่ความไม่สะดวก

klist
klist -li 0x3e7

จากนั้นตัดสินใจว่าการถอยกลับทำอะไรได้บ้าง หากนโยบายกำหนดให้ใช้ Kerberos ต้องปฏิเสธ NTLM อย่างชัดเจน เพราะการถอยกลับอย่างเงียบ ๆ เปลี่ยนข้อผิดพลาดในการกำหนดค่าเป็นการเชื่อมต่อที่ทำงานได้ซึ่งละเมิดข้อกำหนด หาก NTLM ยังยอมรับได้สำหรับบางแอปพลิเคชัน ให้ระบุชื่อและเลิกปฏิบัติต่อทุกเซสชัน NTLM เป็นเหตุการณ์

การเปลี่ยนตัวเรียกใช้เป็นตัวแปรเดียว ไม่ใช่การแก้ไข

การเริ่ม SSMS ภายใต้ข้อมูลรับรองอื่นสามารถรักษาตัวตนขาออกที่ไม่ตั้งใจ ซึ่งเป็นประเภทปัญหาจริง ไม่ได้พิสูจน์สิ่งใดเกี่ยวกับชื่อเป้าหมาย การลงทะเบียน หรือเส้นทางตั๋ว และไม่เปลี่ยนสิ่งที่เซิร์ฟเวอร์ยอมรับ

รักษาการเปรียบเทียบให้อยู่ในการควบคุม: จุดปลายเดียวกัน ผู้ให้บริการเดียวกัน บริบทการทำงานที่รู้จัก จากนั้นคือการเชื่อมต่อใหม่ที่คุณตรวจสอบรูปแบบ ยืนยันการเข้าสู่ระบบที่ยอมรับและสิทธิ์ในฐานข้อมูลแยกกัน เพราะการเข้าถึงและการตรวจสอบล้มเหลวด้วยเหตุผลต่างกัน

เมื่อกำหนดให้ใช้ Kerberos ให้บันทึกว่าเหตุใดเส้นทางแรกจึงถอยกลับ ใช้การแก้ไขหนึ่งอย่าง และรันคิวรีอีกครั้งจากไคลเอนต์เดิม คิวรีที่สำเร็จหลังการเปลี่ยนตัวเรียกใช้เป็นหลักฐานของการเข้าถึง และยังไม่ใช่หลักฐานว่าข้อกำหนดการตรวจสอบได้รับการตอบสนอง