Сблъска се със следната грешка при RDP връзка с отдалечен сървър в AD домейна. След като посочите правилното потребителско име и парола на домейна, се появи прозорец с грешка (по-долу) и прозорецът на rdp на клиента се затвори.
Remote Desktop не може да потвърди самоличността на отдалечения компютър, тъй като има разлика във времето или датата между вашия компютър и отдалечения компютър. Уверете се, че часовникът на вашия компютър е настроен на точното време и след това опитайте да се свържете отново. Ако проблемът се появи отново, свържете се с вашия мрежов администратор или собственика на отдалечения компютър.
В руската версия на Windows грешката изглежда така:
Сесията за отдалечен работен плот не може да потвърди автентичността на отдалечения компютър, защото между този компютър и отдалечения компютър е открита разлика във времето или текущата дата. Проверете дали компютърният часовник е настроен правилно и опитайте да се свържете отново. Ако проблемът продължава, свържете се със системния си администратор или със собственика на отдалечения компютър..Както следва от текста за грешка, RDP клиентът не беше в състояние да се идентифицира с помощта на Kerberos, тъй като разликата във времето между локалния и отдалечения компютър надвишава 5 минути. Но в моя случай това се оказа грешно: отваряйки конзолата на отдалечения сървър през ILO, се уверих, че часовата и часовата зона на двата компютъра са еднакви (и получени от един и същ NTP сървър).
Можете да опитате да проверите времето на отдалечен компютър с командата:
нетно време \\ дистанционен компютър-IP адрес
За всеки случай можете да извършите ръчна синхронизация на времето и да рестартирате услугата w32time:
w32tm / config / manualpeerlist: your_ntp_server_ip NTP, 0x8 / syncfromflags: ръчно
net stop w32time & net start w32time & w32tm / resync
Други причини, поради които времето може да се загуби на компютъра, са разгледани в статията..
съвет. Ако отдалеченият сървър е виртуален, проверете дали синхронизирането на времето с хост хипервизора е деактивирано в настройките на VM.Ако имате физически достъп до отдалечения компютър (имах достъп през конзолата ILO), на отдалечения компютър проверете настройките на DNS сървъра в настройките на мрежовия адаптер. Уверете се също, че посоченият DNS сървър е достъпен от отдалечен сървър. Най-лесният начин да направите това е с командата:
nslookup server_name DNSServername
Ако DNS сървърът не отговори, проверете дали всичко е наред с него или опитайте да посочите друг DNS сървър.
Ако на отдалечения компютър се използват няколко мрежови адаптера, проверете правилното маршрутизиране при достъп до DNS сървъра. Може би компютърът се опитва да получи достъп до DNS сървъра чрез втори мрежов адаптер в друга подмрежа.
Опитайте да се свържете с отдалечен компютър на север чрез RDP клиента по IP адрес вместо пълния FQDN на името на DNS. В този случай Kerberos няма да бъде използван по време на разрешаването.
Проверете дали доверителната връзка с AD домейна е нарушена чрез изпълнение на командата PowerShell:
Тест-ComputerSecureChannel
С правилното доверие тя трябва да върне Истината.
За да възстановите доверието с домейн, можете да използвате командата:
Test-ComputerSecureChannel -Repair -Подписване corp \ adminname
Ако възникне грешка: „Test-ComputerSecureChannel: Не може да нулира паролата за сигурен канал за компютърния акаунт в домейна. Операцията не бе успешна със следното изключение: Сървърът не работи”, Проверете наличието на контролера на домейна от сървъра и наличието на отворени портове за услугата Домейн и доверява се с помощта на помощната програма portqry.
Проверете дали RDP защитният слой е зададен на същото ниво на защита в настройките на протокола RDP на локалния и отдалечения сървър. Този параметър може да бъде зададен чрез „Изисквайте използването на специално ниво на сигурност за отдалечени RDP връзки"(Изисквайте използването на специфичен защитен слой за отдалечени (RDP) връзки) под Конфигурация на компютъра -> Административни шаблони -> Компоненти на Windows -> Услуги за отдалечен работен плот -> Хост на отдалечен работен плот -> Защита (Конфигурация на компютъра -> Политики \ Административни шаблони -> Компоненти на Windows -> Услуги за отдалечен работен плот -> Отдалечен Хост на работната сесия -> Защита), като изберете по-малко сигурен ПРСР ниво по аналогия със статията. Или чрез настройката на системния регистър HKLM \ System \ CurrentControlSet \ Управление \ Терминален сървър \ WinStation \ RDP-Tcp \ SecurityLayer.
Препоръчвам също така да се уверите, че проблемът не е свързан с последните промени в протокола CredSSP..
