PIV ล็อกอินล้มเหลวบน Windows EAP-TLS? ตรวจสอบเส้นทางการลงนาม

แสดงใบรับรองของบัตร PIV ในทุกไดอะล็อกของ Windows แล้วการล็อกอิน VPN ก็ยังล้มเหลวได้ เพราะการมองเห็นกับการใช้งานได้เป็นคุณสมบัติที่ต่างกัน ใบรับรองเป็นวัตถุสาธารณะ การล็อกอินต้องอาศัยการทำงานกับกุญแจส่วนตัวที่บัตรดำเนินการตามกฎการเข้าถึงของตนเอง ระหว่างสองข้อเท็จจริงนี้มีสี่ขั้นตอนที่ล้มเหลวได้สี่แบบต่างกัน: การเลือกโปรไฟล์ การเลือกใบรับรอง การลงนามในเครื่อง และการตรวจสอบฝั่งเซิร์ฟเวอร์ การไล่ทีละขั้นตามลำดับจะเปลี่ยนข้อผิดพลาดแฮนด์เชกแบบกว้าง ๆ ให้เป็นคำถามเฉพาะสำหรับผู้ที่ดูแลส่วนถัดไป

เริ่มจากโปรไฟล์และวิธี EAP

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

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

ยืนยันว่าเลือกใบรับรองใด

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

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

ทดสอบการทำงานของกุญแจโดยไม่เดา PIN

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

certutil.exe -scinfo
certutil.exe -store -user My
Get-WinEvent -LogName Application -MaxEvents 40 | Where-Object ProviderName -like '*Ras*'

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

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

อ่านทั้งสองฝั่งของแฮนด์เชก

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

รวบรวมเหตุการณ์ของ Windows และเหตุการณ์ฝั่งเซิร์ฟเวอร์ที่มีการประทับเวลาตรงกัน แล้วระบุว่าฝั่งใดสร้างความล้มเหลวครั้งแรก RFC 5216 อธิบายขั้นตอนการพิสูจน์ความเป็นเจ้าของใน EAP-TLS และการแจ้งเตือนแฮนด์เชกทั่วไปไม่ได้ระบุสาเหตุของกุญแจในเครื่องด้วยตัวเอง การเปรียบเทียบการประทับเวลาคือสิ่งที่เปลี่ยนบันทึกสองชุดให้เป็นลำดับ

รักษาขอบเขตให้ตรงในรายงาน

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

ใบรับรองซอฟต์แวร์เพื่อการเปรียบเทียบชั่วคราวเป็นการทดสอบของผู้ดูแลระบบที่ชอบด้วยกฎหมาย แต่เปลี่ยนรูปแบบข้อมูลรับรองและการรับประกัน จึงควรอยู่ในการเปลี่ยนแปลงที่ได้รับอนุมัติ ไม่ใช่ทางลัดเงียบ ๆ ในการผลิต วินัยเดียวกันใช้กับการลอง PIN และการออกข้อมูลรับรองใหม่ก่อนที่จะรู้ว่าขั้นตอนใดล้มเหลว บัตรทดแทนที่ล้มเหลวเหมือนกันเป็นหลักฐานราคาแพงว่าปัญหาไม่เคยอยู่ที่บัตร