Учитывая следующую лабораторную настройку:
HOST1 on Windows Server 2012 R2 (host running Hyper-V, joined test.local domain, static IP)
DC1 on Windows Server 2012 (VM under Hyper-V on HOST1, AD and DNS roles, all defaults with test.local domain)
DC2 on Windows Server 2012 (VM under Hyper-V on HOST1, secondary AD)
DHCP1 on Windows Server 2012 (VM under Hyper-V on HOST1, DHCP role)
HOST2 on Windows Server 2012 R2 (host running Hyper-V, joined test.local domain, static IP)
DC3 on Windows Server 2012 (VM under Hyper-V on HOST2, secondary AD)
DHCP2 on Windows Server 2012 (VM under Hyper-V on HOST2, DHCP role)
Оба хоста в одной подсети и домашний маршрутизатор, все брандмауэры отключены. Сначала установили физические хосты, затем виртуальные машины. Установил роли, создал новый домен, присоединил все виртуальные машины, присоединился к хостам, несколько раз перезапустился, все в порядке.
Проблема: при попытке RDP на HOST1 вчера из моего окна Windows 8.1, как обычно с пользователем Domain Admin (test \ Administrator), никакой радости. Соединение принято, но я могу принять сертификат, открывается RDP-соединение и на удаленном компьютере появляется сообщение: «Другой пользователь. Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом». и отключается примерно через 30 секунд.
Если я использую учетную запись локального администратора (HOST1 \ Administrator), я могу войти в систему нормально. Кроме того, разрешен вход на HOST2 с тем же пользователем-администратором домена (test \ Administrator).
Можно исправить (иногда!), Перезагрузив оба хоста пару раз. Таким образом, похоже, что компьютеры и учетные записи все еще находятся в AD (нет необходимости повторно присоединяться или сбрасывать пароли).
Почему так происходит? С чего начать поиск неисправностей? Попытка понять основную причину, а не просто быстрое решение.
Сначала проверьте простые вещи. Убедитесь, что время совпадает на всех компьютерах (должно быть, так как это Hyper-V, но это быстро проверить). В противном случае проверка подлинности Kerberos может завершиться ошибкой, а неудачный вход в систему с компьютера может привести к отправке сообщения о доверии, если на самом деле проблема не в доверии. Кроме того, убедитесь, что DNS-серверы, указанные в параметрах IP-адреса хоста, которые вы статически настроили, являются контроллерами домена по той же причине.
После этого попробуйте запустить сеанс RDP с подключением по IP-адресу вместо имени хоста. Если это работает, значит, у вас проблема либо с сертификатами, либо с согласованием протокола безопасности, который используется в соединении.
Вы сказали, что должны принять сертификат перед подключением. Можете ли вы указать причину, по которой вам предлагается принять его? Если сертификат выпущен доменом, ему уже следует доверять.