เดสก์ท็อประยะไกลไม่สามารถยืนยันตัวตนของคอมพิวเตอร์ระยะไกลได้เนื่องจากความแตกต่างของเวลา/วันที่
ฉันพบข้อผิดพลาดต่อไปนี้เมื่อพยายามเชื่อมต่อผ่าน RDP ไปยังเซิร์ฟเวอร์ระยะไกลในโดเมน AD หลังจากระบุข้อมูลประจำตัวของโดเมนที่ถูกต้องสำหรับผู้ใช้ RDP ข้อความแสดงข้อผิดพลาดปรากฏขึ้น (แสดงด้านล่าง) และปิดหน้าต่างไคลเอ็นต์ RDP
เดสก์ท็อประยะไกลไม่สามารถยืนยันตัวตนของคอมพิวเตอร์ระยะไกลได้ เนื่องจากมีเวลาหรือวันที่ต่างกันระหว่างคอมพิวเตอร์ของคุณกับคอมพิวเตอร์ระยะไกล ตรวจสอบให้แน่ใจว่าตั้งนาฬิกาของคอมพิวเตอร์เป็นเวลาที่ถูกต้อง จากนั้นลองเชื่อมต่ออีกครั้ง หากปัญหาเกิดขึ้นอีก ให้ติดต่อผู้ดูแลระบบเครือข่ายหรือเจ้าของคอมพิวเตอร์ระยะไกล
ตามที่ปรากฏจากข้อผิดพลาด ไคลเอนต์ RDP ไม่สามารถรับรองความถูกต้องโดยใช้ Kerberos เนื่องจากความแตกต่างของเวลาระหว่างคอมพิวเตอร์ในระบบและคอมพิวเตอร์ระยะไกลเกิน 5 นาที แต่ในกรณีของฉันกลับกลายเป็นว่าไม่เป็นความจริง: หลังจากเปิดคอนโซลเซิร์ฟเวอร์ระยะไกลผ่าน ILO ฉันแน่ใจว่าเวลาและเขตเวลาเหมือนกันในคอมพิวเตอร์ทั้งสองเครื่อง (และได้รับมาจากเซิร์ฟเวอร์ NTP ต้นทางเดียวกัน)
คุณสามารถลองตรวจสอบเวลาบนคอมพิวเตอร์ระยะไกลโดยใช้คำสั่งนี้:
net time \\remote-computer-IP-addressคุณสามารถซิงค์เวลาได้ด้วยตนเองในกรณีและเริ่มบริการ w32time ใหม่:
w32tm /config /manualpeerlist:your_ntp_server_ip NTP,0x8 /syncfromflags:manual
net stop w32time & net start w32time & w32tm /resync
บทความนี้จะอธิบายสาเหตุอื่นๆ บางประการที่ทำให้เวลาในคอมพิวเตอร์คลาดเคลื่อน
เคล็ดลับ หากเซิร์ฟเวอร์ระยะไกลเป็นเครื่องเสมือน ตรวจสอบให้แน่ใจว่าการซิงโครไนซ์เวลากับโฮสต์ไฮเปอร์ไวเซอร์ถูกปิดใช้งานในการตั้งค่า VM
หากคุณมีสิทธิ์เข้าถึงคอมพิวเตอร์ระยะไกล (ฉันเข้าถึงผ่านคอนโซล HPE ILO) ให้ตรวจสอบเซิร์ฟเวอร์ DNS ในการตั้งค่าอะแดปเตอร์เครือข่าย ตรวจสอบให้แน่ใจด้วยว่าคุณสามารถเข้าถึงเซิร์ฟเวอร์ DNS นี้จากเซิร์ฟเวอร์ระยะไกลของคุณ ทำได้ง่ายกว่าโดยใช้คำสั่งนี้:
nslookup some_server_name DNSServernameหากเซิร์ฟเวอร์ DNS ไม่ตอบสนอง ตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์ทำงานอย่างถูกต้อง หรือลองระบุที่อยู่เซิร์ฟเวอร์ DNS อื่น
หากใช้อะแดปเตอร์เครือข่ายหลายตัวบนคอมพิวเตอร์ระยะไกล ตรวจสอบให้แน่ใจว่าตารางเส้นทางถูกต้องเมื่อเข้าถึงเซิร์ฟเวอร์ DNS คอมพิวเตอร์อาจพยายามเข้าถึงเซิร์ฟเวอร์ DNS โดยใช้อะแดปเตอร์เครือข่ายอื่นในซับเน็ต IP อื่น
พยายามเชื่อมต่อกับคอมพิวเตอร์ระยะไกลโดยใช้ ที่อยู่ IP แทนชื่อ FQDN DNS แบบเต็มในหน้าต่างการเชื่อมต่อไคลเอนต์ RDP ในกรณีนี้ จะไม่ใช้ Kerberos สำหรับการตรวจสอบสิทธิ์
ตรวจสอบให้แน่ใจว่ามีความสัมพันธ์ที่เชื่อถือได้กับโดเมน AD โดยเรียกใช้คำสั่ง PowerShell นี้:
Test-ComputerSecureChannelหากมีความสัมพันธ์ที่เชื่อถือได้ มันจะคืนค่าเป็น True
เมื่อต้องการซ่อมแซมความสัมพันธ์ที่เชื่อถือได้กับโดเมน Active Directory คุณสามารถใช้คำสั่งนี้:
Test-ComputerSecureChannel -Repair -Credential contoso\your_admin_account_nameหากข้อผิดพลาด “
Test-ComputerSecureChannel : Cannot reset the secure channel password for the computer account in the domain. Operation failed with the following exception: The server is not operational” ปรากฏขึ้น ตรวจสอบความพร้อมใช้งานของตัวควบคุมโดเมนจากเซิร์ฟเวอร์ของคุณ และเปิดพอร์ต TCP/UDP สำหรับบริการ “โดเมนและความน่าเชื่อถือ” โดยใช้เครื่องมือ portqry
ตรวจสอบให้แน่ใจว่าได้เลือก “RDP Security Layer” เดียวกันทั้งบนคอมพิวเตอร์ในระบบและระยะไกล พารามิเตอร์นี้อาจตั้งค่าโดยใช้นโยบาย “ต้องใช้เลเยอร์ความปลอดภัยเฉพาะสำหรับการเชื่อมต่อระยะไกล (RDP)” ในส่วน GPO Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> โฮสต์เซสชันเดสก์ท็อประยะไกล -> ความปลอดภัย โดยเลือกระดับ RDP ที่ปลอดภัยน้อยกว่าตามที่อธิบายไว้ในบทความนี้ หรือใช้คีย์รีจิสทรีนี้: HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\SecurityLayer
ขอแนะนำให้ตรวจสอบให้แน่ใจว่าปัญหาไม่เกี่ยวข้องกับการเปลี่ยนแปลงล่าสุดในโปรโตคอล CredSSP