Mac ของคุณส่งบัญชี Windows ผิดผ่าน RDP

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

ตรวจสอบรายการก่อนแตะพวงกุญแจ

บัญชี VPN และบัญชี Windows เป็นคนละเรื่องกัน

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

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

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

เปิดรายการเชื่อมต่อ ไม่ใช่พวงกุญแจทั้งหมด

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

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

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

ใช้รูปแบบบัญชีที่ผู้ดูแลระบบให้มา

พิมพ์บัญชีตามที่ออกให้ทุกประการ ในรูปแบบที่สภาพแวดล้อมคาดหวัง: DOMAIN\user สำหรับโดเมนสไตล์ NetBIOS หรือ user principal name หากไดเรกทอรีใช้สิ่งนั้น จากนั้นบันทึกไว้กับพีซีนี้และลองเชื่อมต่ออย่างตั้งใจหนึ่งครั้ง

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

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

การเชื่อมต่อล้มเหลวก่อนเข้าสู่ระบบเป็นความผิดพลาดอีกแบบ

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

ในทางกลับกัน การปฏิเสธบัญชีอย่างชัดเจนไม่ใช่หลักฐานว่า DNS เสียหรือควรผ่อนการตรวจสอบใบรับรอง การเปลี่ยนแปลงเหล่านั้นทำให้การเชื่อมต่ออ่อนแอลงและมักปล่อยการปฏิเสธไว้ที่เดิม

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

ปล่อยการเชื่อมต่ออัตโนมัติไว้ตามเดิม

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

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