Зіткнувся з наступною помилкою при RDP підключенні до віддаленого сервера в домені AD. Після вказівки коректних імені та пароля доменного користувача з'явилося вікно з помилкою (нижче) і вікно rdp клієнта закрилося.
Remote Desktop can not verify the identity of the remote computer because there is a time or date difference between your computer and the remote computer. Make sure your computer's clock is set to the correct time, and then try connecting again. If the problem occurs again, contact your network administrator or the owner of the remote computer.
У російській версії Windows помилка виглядає так:
Сеанс віддаленого робочого стола не може перевірити справжність віддаленого комп'ютера, оскільки виявлено відмінність у часі або поточну дату між цим комп'ютером і віддаленим комп'ютером. Перевірте, що годинник комп'ютера правильно встановлено і спробуйте виконати підключення. Якщо проблема повторюється, зверніться до системного адміністратора або власнику віддаленого комп'ютера.Як випливає з тексту помилки, 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
Інші причини через які може збиватися час на комп'ютері розглянуті в статті.
Порада. Якщо віддалений сервер - віртуальний, перевірте в налаштуваннях ВМ відключена чи синхронізація часу з хостової гіпервізором.Якщо у вас є фізичний доступ до віддаленого комп'ютера (у мене був доступ через консоль ILO), на віддаленому комп'ютера перевірте параметри DNS сервера в налаштуваннях мережевого адаптера. Також переконайтеся, що вказаний DNS сервер доступний з віддаленого сервера. Найпростіше це зробити за допомогою команди:
nslookup server_name DNSServername
Якщо DNS сервер не відповідає, перевірте, чи все з ним в порядку або спробуйте вказати інший DNS сервер.
Якщо на віддаленому комп'ютері використовується кілька мережевих адаптерів, перевірте коректність маршрутизації при доступі до DNS сервера. Можливо комп'ютер намагається отримати доступ до DNS сервера через другий мережевий адаптер в іншій підмережі.
Спробуйте підключиться до віддаленого комп'ютера північ через RDP клієнт по IP адресою замість повного FQDN DNS імені. В цьому випадку при авторизації не використовуватиметься Kerberos.
Перевірте, чи не зламалися чи довірчі відносини з доменом AD, виконавши команду PowerShell:
Test-ComputerSecureChannel
При коректних довірчі стосунки, вона повинна повернути True.
Для відновлення довірчих відносин з доменом можна використовувати команду:
Test-ComputerSecureChannel -Repair -Credential corp \ adminname
При виникненні помилки: "Test-ComputerSecureChannel: Can not reset the secure channel password for the computer account in the domain. Operation failed with the following exception: The server is not operational", Перевірте доступність контролера домену з сервера і наявність відкритих портів для служби Domain and trusts утилітою portqry.
Перевірте, що в налаштуваннях RDP протоколу на локальному і віддаленому сервері тей рівень безпеки RDP Security Layer. Даний параметр можна задати через політику "Вимагати використання спеціального рівня безпеки для віддалених підключення по протоколу RDP"(Require use of specific security layer for remote (RDP) connections) В розділі Конфігурація комп'ютера -> Адміністративно шаблони -> Компоненти Windows -> Служби віддалених робочих столів -> Вузол сеансів віддалених робочих столів -> Безпека (Computer Configuration -> Policies \ Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security), вибравши менш безпечний RDP рівень за аналогією зі статтею. Або через параметр реєстру HKLM \ System \ CurrentControlSet \ Control \ Terminal Server \ WinStations \ RDP-Tcp \ SecurityLayer.
Також рекомендую переконатися, що проблема не пов'язана з недавніми змінами в протоколі CredSSP.
