การเพิ่มผู้ใช้เข้ากลุ่ม VPN ไม่ได้ให้สิทธิ์เข้าถึงโดยตัวเอง
การเป็นสมาชิกกลุ่มเป็นเงื่อนไขเดียว ไม่ใช่การอนุญาต ดูว่าเกตเวย์จับคู่อะไรจริง อ่านบันทึกการยอมรับหรือปฏิเสธ และทดสอบทั้งสองผลลัพธ์
บัญชีอยู่ในกลุ่มที่ถูกต้อง การเข้าสู่ระบบสำเร็จ แต่การเชื่อมต่อยังถูกปฏิเสธหรือไปไม่ถึงสิ่งที่เป็นประโยชน์ การเพิ่มกลุ่มให้มากเกินกว่าที่ตั๋วขอ สมาชิกภาพเป็นเพียงอินพุตเดียว ไม่ใช่ตัวตัดสินใจ: เกตเวย์รวบรวมข้อเท็จจริง จับคู่กับนโยบายที่มีลำดับ แล้วจึงตัดสินใจ
การเป็นสมาชิกกลุ่มเป็นเงื่อนไข ไม่ใช่การอนุญาต
ใน RADIUS กลุ่มมาเป็นแอตทริบิวต์การอนุญาต และแอตทริบิวต์อธิบายเซสชัน ไม่ได้อนุญาต เซิร์ฟเวอร์ตอบ Access-Accept หรือ Access-Reject และอาจแนบ Filter-Id, Class หรือแอตทริบิวต์อุโมงค์จาก RFC 2868 ไม่มีอะไรแปลงกลุ่มเป็นสิทธิ์เต็ม
ดังนั้นชื่อกลุ่มเดียวกันจึงทำงานต่างกันบนสองระบบ Microsoft NPS ประกอบนโยบายจากเงื่อนไข ข้อจำกัด และการตั้งค่า แล้วประเมินตามลำดับ OpenVPN Access Server มีโมเดลของตัวเอง และเซิร์ฟเวอร์ชุมชนมักมอบทุกอย่างให้ client-connect หรือ client-config-dir
กฎที่ตรงกันเป็นตัวตัดสิน ไม่ใช่กลุ่มที่คุณคาดหวัง
เอนจินส่วนใหญ่หยุดที่กฎแรกที่ตรงกันหรือกฎที่เจาะจงที่สุด ถ้านโยบาย 3 ปฏิเสธและนโยบาย 7 อนุญาต เซสชันอาจล้มเหลวก่อนถึงกฎที่ปล่อยผ่าน
เงื่อนไขที่มาพร้อมกลุ่มคืออีกครึ่งหนึ่ง: สถานะอุปกรณ์ วิธีการพิสูจน์ตัวตน MFA ที่เสร็จแล้ว เครือข่ายต้นทาง หัวข้อใบรับรอง หรือช่วงเวลา ถ้าขาดข้อใด นโยบายไม่ตรงและใช้การปฏิเสธโดยปริยาย
รายละเอียดไดเรกทอรีสร้างภาพลวงเดียวกัน นโยบายตามกลุ่ม Windows อ่าน SID ในโทเคน ซึ่งมีเพียงกลุ่มความปลอดภัย กลุ่มแจกจ่ายไม่เคยปรากฏ
อ่านบันทึกการยอมรับหรือปฏิเสธก่อนแตะกลุ่ม
ถามก่อนหนึ่งข้อ: คำขอไปถึงขั้นอนุญาตหรือไม่? ใน NPS 6272 บันทึกการให้สิทธิ์ 6273 การปฏิเสธ และ 6274 คำขอที่ถูกทิ้งก่อนประเมินนโยบาย ตัวเลขสามตัวนี้แบ่งปัญหาเป็นสามการสอบสวน และเพียงหนึ่งเดียวเกี่ยวกับกลุ่ม
| What the record shows | What it means | Where to look next |
|---|---|---|
| 6272, access granted | Authentication and authorization both succeeded | Routes, split tunnel, DNS, per-resource rules |
| 6273, access denied | A policy matched and denied, or nothing matched and the default denied | The conditions of the policy that fired, in order |
| 6274, request discarded | The request never reached authorization | Shared secret, NAS client entry, proxy chain, malformed attributes |
เมื่อเข้าถึงบันทึกไม่ได้ ให้ถามเซิร์ฟเวอร์โดยตรงและอ่านคำตอบ ถ้าไม่มี Filter-Id และแอตทริบิวต์อุโมงค์ แปลว่าเซิร์ฟเวอร์ถือว่าเซสชันธรรมดาและเกตเวย์ใช้กฎของตัวเอง
radtest alice 'password' 10.0.0.5 0 testing123เทียบแอตทริบิวต์ที่ได้กับที่เกตเวย์บันทึกไว้ ไม่ใช่กับสิ่งที่ชื่อกลุ่มบอก นั่นแยกปัญหานโยบายออกจากปัญหาการบังคับใช้
การเปลี่ยนกลุ่มไม่มีผลย้อนหลัง
แอตทริบิวต์การอนุญาตถูกส่งกลับครั้งเดียวเมื่อพิสูจน์เซสชัน เกตเวย์เก็บไว้บนเซสชันและไม่อ่านไดเรกทอรีใหม่ทุกแพ็กเก็ต จึงทำให้เซสชันที่ตั้งไว้ยังทำงานหลังนำใครออกจากกลุ่ม
การเปลี่ยนจะมีผลต้องมีคำตัดสินใหม่ ไม่ใช่เพียงคีย์ใหม่ ถ้าเซิร์ฟเวอร์รองรับ RFC 5176 การส่ง Disconnect-Request หรือ CoA-Request ไปยัง UDP 3799 บังคับให้ประเมินใหม่
แก้เงื่อนไข ไม่ใช่แก้กลุ่ม
เมื่อรู้ว่านโยบายใดทำงาน การซ่อมมักเล็ก: เรียงลำดับการปฏิเสธที่บังการอนุญาตที่ต้องการใหม่ เพิ่มเงื่อนไขอุปกรณ์หรือ MFA ที่ขาด หรือเขียนกฎแคบสำหรับทรัพยากรเดียว
วงสั้นทำให้การเปลี่ยนแปลงซื่อสัตย์:
- ทำการปฏิเสธซ้ำด้วยบัญชีเดิมและบันทึก ID เหตุการณ์ก่อนเปลี่ยนสิ่งใด
- เปลี่ยนวัตถุเดียว ลำดับนโยบาย เงื่อนไขเดียว หรือกลุ่มเดียว และบันทึกว่าเป็นอันใด
- เปิดเซสชันใหม่ ยืนยันว่าการอนุญาตปรากฏในบันทึกและทรัพยากรเปิดจริง
- ทดสอบผู้ใช้ที่ยังควรถูกปฏิเสธ เพื่อไม่ให้การซ่อมขยายนโยบาย
ถ้าการอนุญาตถูกแต่ทรัพยากรไม่เปิด ปัญหาได้ย้ายไปที่การกำหนดเส้นทางหรือการแปลงชื่อ ทันทีที่การอนุญาตผ่าน แยกความผิดสองอย่างนี้