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 ต้องมีชื่อหลักของบริการที่ลงทะเบียนไว้สำหรับบัญชีบริการ SQL และไคลเอนต์ที่ขอบริการด้วยชื่อที่ตรงกัน การเชื่อมต่อด้วยที่อยู่ IP ไม่สามารถตรงกับ SPN ที่อิงชื่อได้ และนามแฝงจะตรงได้ก็ต่อเมื่อลงทะเบียนไว้ด้วย ตรวจสอบชื่อที่ไคลเอนต์พิมพ์ก่อนสิ่งอื่นใด เพราะการเชื่อมต่อที่ทำงานด้วยชื่อโฮสต์และล้มเหลวด้วย IP อธิบายปัญหานี้โดยตรง

ขอให้ผู้ดูแลระบบทบทวนตัวตนที่ลงทะเบียนไว้และบัญชีบริการ แทนการสร้าง SPN ซ้ำด้วยการลองผิดลองถูก การลงทะเบียนซ้ำทำให้เกิดความล้มเหลวเป็นระยะซึ่งวินิจฉัยได้ยากกว่าปัญหาเดิม

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