การเข้าถึง VPN โดยไม่มีสิทธิ์เดสก์ท็อประยะไกล: สี่ประตูแยกกัน

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

สี่ประตูในลำดับคงที่

เกตเวย์ตัดสินก่อนว่าตัวตนสามารถสร้างอุโมงค์ได้หรือไม่: นโยบาย RADIUS เงื่อนไขกลุ่ม การตรวจสอบใบรับรอง การอนุญาต Access Server จากนั้นการกำหนดเส้นทางและไฟร์วอลล์ตัดสินว่าแพ็กเก็ตจากพูลอุโมงค์ไปถึงตัวรับฟัง TCP 3389 ของปลายทางหรือไม่ จากนั้นแฮนด์เชค NLA ของไคลเอนต์ตรวจสอบบัญชีกับปลายทาง หลังจากสามอย่างนี้แล้ว หน่วยงานความปลอดภัยภายในจึงตรวจสอบว่าบัญชีมีสิทธิ์เข้าสู่ระบบที่เซสชันระยะไกลแบบโต้ตอบต้องการหรือไม่

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

สิทธิ์ที่ปฏิเสธเซสชันจริง ๆ

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

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

อ่านนโยบายที่มีผล ไม่ใช่กล่องโต้ตอบภายใน

นโยบายภายในถูกเขียนทับโดย GPO ของโดเมนใด ๆ ที่กำหนดสิทธิ์เดียวกัน ดังนั้นสแนปอินภายในอาจแสดงรายการที่ดูถูกต้องในขณะที่สถานะที่มีผลแตกต่างออกไป ส่งออกสิ่งที่เครื่องใช้จริง จากนั้นค้นหาสิทธิ์และอ่าน SID แทนชื่อที่แสดง:

secedit /export /cfg C:\temp\secpol.cfg
Select-String -Path C:\temp\secpol.cfg -Pattern SeRemoteInteractiveLogonRight
gpresult /scope computer /v

ในเอาต์พุตนั้น *S-1-5-32-544 คือ Administrators และ *S-1-5-32-555 คือ Remote Desktop Users

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

ให้สิทธิ์ที่แคบที่สุดที่เหมาะสม

คำตอบปกติคือกลุ่ม Remote Desktop Users บนปลายทาง กลุ่มนี้ถือสิทธิ์โดยค่าเริ่มต้น เล็กกว่า Administrators มาก และแยก «เปิดเดสก์ท็อปได้» ออกจาก «จัดการเซิร์ฟเวอร์ได้» ที่นโยบายกำหนดสิทธิ์ใหม่อย่างชัดเจน ให้เพิ่มกลุ่มหรือบัญชีในนโยบายนั้นแทนการเพิ่มกลุ่มที่ไม่มีใครตั้งใจให้เป็นตัวควบคุมการเข้าถึง

Add-LocalGroupMember -Group "Remote Desktop Users" -Member "CORP\a.user"

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

แยกเส้นทางเครือข่ายเป็นการตัดสินใจต่างหาก

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

Get-NetFirewallRule -DisplayGroup "Remote Desktop"
Test-NetConnection -ComputerName 10.20.0.50 -Port 3389

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

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