Suočio se sa sljedećom greškom kod RDP veze s udaljenim serverom u AD domeni. Nakon što ste naveli ispravno korisničko ime i lozinku, pojavio se prozor s pogreškom (ispod) i prozor rdp klijenta zatvoren.
Remote Desktop ne može provjeriti identitet udaljenog računala jer postoji razlika u vremenu ili datumu između vašeg i udaljenog računala. Provjerite je li sat vašeg računala postavljen na točno vrijeme, a zatim pokušajte ponovo spojiti se. Ako se problem ponovi, obratite se mrežnom administratoru ili vlasniku udaljenog računala.
U ruskoj verziji sustava Windows pogreška izgleda ovako:
Sjednica na udaljenoj radnoj površini ne može provjeriti autentičnost udaljenog računala jer je između ovog računala i udaljenog računala otkrivena razlika u vremenu ili trenutnom datumu. Provjerite je li sat računala ispravno postavljen i pokušajte ponovno povezati. Ako se problem nastavi, obratite se administratoru sustava ili vlasniku udaljenog računala..Kao što slijedi iz teksta pogreške, RDP klijent nije uspio autentificirati pomoću Kerberosa, jer vremenska razlika između lokalnog i udaljenog računala prelazi 5 minuta. Ali u mom se slučaju pokazalo da to nije u redu: otvaranjem konzole udaljenog poslužitelja putem ILO-a osigurao sam da su vremenska i vremenska zona na oba računala ista (i primljeni s istog NTP poslužitelja).
Pokušajte provjeriti vrijeme na udaljenom računalu pomoću naredbe:
neto vrijeme \\ udaljena računala-IP adresa
Za svaki slučaj možete izvršiti ručnu sinkronizaciju i ponovo pokrenuti uslugu w32time:
w32tm / config / manualpeerlist: vaš_ntp_server_ip NTP, 0x8 / syncfromflags: priručnik
net stop w32time & neto start w32time & w32tm / resync
U članku su razmotreni i drugi razlozi zbog kojih se vrijeme može izgubiti na računalu..
vijeće. Ako je udaljeni poslužitelj virtualni, provjerite je li u postavkama VM onemogućena vremenska sinkronizacija s hipervizonom domaćina.Ako imate fizički pristup udaljenom računalu (imao sam pristup putem ILO konzole), na udaljenom računalu provjerite postavke DNS poslužitelja u postavkama mrežnog adaptera. Provjerite je li i određeni DNS poslužitelj dostupan s udaljenog poslužitelja. Najlakši način za to je pomoću naredbe:
nslookup server_name DNSServername
Ako DNS poslužitelj ne reagira, provjerite je li s njim sve u redu ili pokušajte navesti drugi DNS poslužitelj.
Ako se na udaljenom računalu koristi nekoliko mrežnih adaptera, provjerite ispravnost usmjeravanja prilikom pristupa DNS poslužitelju. Možda računalo pokušava pristupiti DNS poslužitelju putem drugog mrežnog adaptera na drugoj podmreži.
Pokušajte se povezati s udaljenim računalom sjeverno preko RDP klijenta prema IP adresi umjesto punog FQDN imena DNS-a. U ovom slučaju Kerberos se neće koristiti za vrijeme autorizacije.
Provjerite je li odnos povjerenja s AD domenom pokrenut pokretanjem naredbe PowerShell:
Test-ComputerSecureChannel
S pravim povjerenjem treba vratiti True.
Da biste vratili povjerenje u domenu, možete koristiti naredbu:
Test-ComputerSecureChannel -repair -vjerni corp \ adminname
Ako dođe do pogreške: "Test-ComputerSecureChannel: Ne može se resetirati lozinka sigurnog kanala za račun računala u domeni. Rad nije uspio sa sljedećom iznimkom: Poslužitelj ne radi”, Provjerite dostupnost kontrolera domene s poslužitelja i dostupnost otvorenih portova za domenu i vjeruje usluzi pomoću Portqry uslužnog programa.
Provjerite je li sigurnosni sloj RDP postavljen na istu razinu zaštite u postavkama RDP protokola na lokalnom i udaljenom poslužitelju. Ovaj se parametar može postaviti putem "Zahtijeva korištenje posebne razine sigurnosti za udaljene RDP veze„(Zahtijeva korištenje određenog sigurnosnog sloja za daljinske (RDP) veze) u odjeljku Konfiguracija računala -> Administrativne predloške -> Komponente sustava Windows -> Usluge udaljene radne površine -> Domaćin sjednice udaljene radne površine -> Sigurnost (Konfiguracija računala -> Politike \ Administrativne predloge -> Komponente sustava Windows -> Usluge udaljene radne površine -> Udaljeni Host sjednica radne površine -> Sigurnost) odabirom manje sigurnog RDP razina prema analogiji s člankom. Ili putem postavke registra HKLM \ System \ CurrentControlSet \ Control \ Terminal Server \ WinStation \ RDP-Tcp \ SecurityLayer.
Također preporučujem da provjerite je li problem povezan s nedavnim promjenama u CredSSP protokolu..
