Realm การพิสูจน์ตัวตน VPN: เนมสเปซบัญชีใดชนะ

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

realm เลือกอะไร

เกตเวย์ได้รับชื่อผู้ใช้และต้องตัดสินใจว่าจะตรวจสอบที่ใด realm คือส่วนหนึ่งของชื่อนั้น หรือแอตทริบิวต์ข้าง ๆ ซึ่งเป็นตัวเลือกฐานข้อมูล ได้แก่ไดเรกทอรี พูล RADIUS หรือไฟล์บัญชีภายใน NPS ของ Microsoft เรียกสิ่งนี้ว่าชื่อ realm และใช้มันกำหนดเส้นทางคำขอเชื่อมต่อ ขณะที่ตัวระบุการเข้าถึงเครือข่าย EAP ก็ถือแนวคิดเดียวกันในรูปคำต่อท้ายหลังเครื่องหมาย at ใน RFC 7542 ทั้งสองเป็นตัวเลือก และไม่มีอันใดตัดสินว่าข้อมูลรับรองนั้นดีหรือไม่

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

ไวยากรณ์ของ realm ขึ้นอยู่กับการติดตั้งระบบ บริการบางแห่งต้องการชื่อที่ไม่ผ่านการคัดสรรพร้อมแอตทริบิวต์ บางแห่งต้องการ user@domain และบางแห่งคาดหวังรูปแบบที่มีแบ็กสแลชซึ่งคู่มือส่วนใหญ่ไม่กล่าวถึง

ใช้รูปแบบที่แบ็กเอนด์คาดหวัง

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

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

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

ติดตามคำขอผ่านพร็อกซี

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

grep -n -A4 '^realm' /etc/freeradius/3.0/proxy.conf
radtest '[email protected]' 'wrong-password' 10.20.30.10 0 testing123
journalctl -u freeradius --since '-10 min' | grep -iE 'realm|stripped'

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

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

บันทึกความพยายามโดยไม่รั่วไหล

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

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