Soočeni z naslednjo napako pri povezavi RDP z oddaljenim strežnikom v domeni AD. Po določitvi pravilnega uporabniškega imena in gesla se je pojavilo okno z napako (spodaj) in okno rdp odjemalca zaprto.
Oddaljeno namizje ne more preveriti identitete oddaljenega računalnika, ker obstaja časovna ali datumska razlika med računalnikom in oddaljenim računalnikom. Prepričajte se, da je ura računalnika nastavljena na pravilen čas, nato pa poskusite znova povezati. Če se težava ponovno pojavi, se obrnite na skrbnika omrežja ali lastnika oddaljenega računalnika.
V ruski različici sistema Windows napaka izgleda tako:
Seja oddaljenega namizja ne more preveriti pristnosti oddaljenega računalnika, ker je bila med tem računalnikom in oddaljenim računalnikom odkrita časovna ali trenutna razlika. Preverite, ali je ura računalnika pravilno nastavljena, in poskusite ponovno povezati. Če se težava še vedno pojavlja, se obrnite na skrbnika sistema ali lastnika oddaljenega računalnika..Kot izhaja iz besedila napake, odjemalec RDP ni mogel overiti z Kerberosom, ker časovna razlika med lokalnim in oddaljenim računalnikom presega 5 minut. V mojem primeru se je to izkazalo napačno: z odpiranjem konzole oddaljenega strežnika prek ILO sem poskrbel, da sta časovni in časovni pas na obeh računalnikih enaka (in prejeta z istega strežnika NTP).
Lahko poskusite preveriti čas v oddaljenem računalniku z ukazom:
neto čas \\ naslov IP oddaljenega računalnika
Za vsak slučaj lahko izvedete ročno sinhronizacijo časa in znova zaženete storitev w32time:
w32tm / config / manualpeerlist: vaš_ntp_server_ip NTP, 0x8 / syncfromflags: priročnik
net stop w32time & neto start w32time & w32tm / resync
Drugi razlogi, zaradi katerih se lahko izgubi čas v računalniku, so obravnavani v članku..
Namig. Če je oddaljeni strežnik navidezen, preverite, ali je v nastavitvah VM časovna sinhronizacija z gostiteljskim hipervizorjem onemogočena.Če imate fizični dostop do oddaljenega računalnika (imel sem dostop prek konzole ILO), na oddaljenem računalniku preverite nastavitve strežnika DNS v nastavitvah omrežnega adapterja. Prepričajte se tudi, da je določen strežnik DNS dostopen z oddaljenega strežnika. Najlažji način za to je z ukazom:
nslookup strežnik_ime DNSServername
Če se strežnik DNS ne odzove, preverite, ali je z njim vse v redu ali poskusite določiti drug strežnik DNS.
Če se na oddaljenem računalniku uporablja več omrežnih adapterjev, preverite pravilno usmerjanje pri dostopu do strežnika DNS. Morda računalnik poskuša dostopati do strežnika DNS prek drugega omrežnega adapterja v drugem podomrežju.
Poskusite se povezati z oddaljenim računalnikom proti severu prek odjemalca RDP po naslovu IP namesto celotnega FQDN imena DNS. V tem primeru Kerberos med avtorizacijo ne bo uporabljen.
Preverite ukaz zaupanja z domeno AD z izvajanjem ukaza PowerShell:
Test-ComputerSecureChannel
S pravim zaupanjem bi moral vrniti True.
Če želite povrniti zaupanje z domeno, lahko uporabite ukaz:
Test-ComputerSecureChannel -Repair -Vrednost corp \ adminname
Če pride do napake: "Test-ComputerSecureChannel: Ni mogoče ponastaviti gesla za varni kanal za računalniški račun v domeni. Operacija ni uspela z naslednjo izjemo: strežnik ne deluje", Preverite razpoložljivost krmilnika domene s strežnika in razpoložljivost odprtih vrat za domeno in skrbniške storitve z orodjem portqry.
Preverite, ali je varnostni nivo RDP nastavljen na enako raven varnosti v nastavitvah protokola RDP na lokalnem in oddaljenem strežniku. Ta parameter je mogoče nastaviti prek gumba »Zahtevajte uporabo posebne stopnje varnosti za oddaljene povezave RDP"(Za oddaljene povezave (RDP) zahtevajte uporabo posebnega varnostnega sloja) pod Konfiguracija računalnika -> Administrativne predloge -> Komponente Windows -> Storitve oddaljenega namizja -> Gostitelj seje za oddaljeno namizje -> Varnost (Konfiguracija računalnika -> Politike \ Upravne predloge -> Komponente Windows -> Storitve oddaljenih namiznih računalnikov -> Oddaljeni Gostitelj namiznega seje -> Varnost) z izbiro manj varnega Rdp raven po analogiji s člankom. Ali pa prek nastavitve registra HKLM \ System \ CurrentControlSet \ Control \ Terminal Server \ WinStation \ RDP-Tcp \ SecurityLayer.
Priporočam tudi, da se prepričajte, da težava ni povezana z nedavnimi spremembami protokola CredSSP..
