Опять я вынужден обратиться за помощью. Чёрт те что творится, я уже не знаю, куда копать и что делать. Задолбали меня уже эти неявные проблемы, при кажущемся благополучии. При этом информации в сети, как всегда, очень мало. Я честно всё посмотрел, перед тем, как снова сюда написать.
Вот, полюбуйтесь на снимки экрана. Суть такова - я пытаюсь из сети 192.168.10.0 подключиться по удалённому рабочему столу к машине xxx-hv-01, которой соответствует адрес 192.168.30.10. При этом к виртуальным машинам 192.168.30.1, 30.2, 30.3 точно так же. Ошибка вылазит такая. Кэш чистил, перезагружал компьютер, всё то же самое. При этом если заходить по адресу, то он пустит.
Инфраструктура сети 192.168.10.0 построена на vSphere, а 192.168.30.0 на Hyper-V. Соответственно, DNS сервера в сети 192.168.10.0 с Active Directory 192.168.10.12 и 192.168.10.13 (соответственно, для vSphere 192.168.128.112 и 192.168.128.113), а в сети 192.168.30.0 с Active Directory 192.168.30.2 и 192.168.30.3.
Более того, в совершенный тупик меня завела вторая ошибка. Какое время не соответствует? Я проверял и перепроверял всё, всё соответствует, время на хостах правильно!
Вот меня насторожило время на гипервизорах, синхронно с NTP 192.168.128.112 и 192.168.128.113. Вот, допустим дата.
19.11.2019 15:10
На гипервизоре
Tuesday, November 19, 2019, 10:10:45 UTC
Я обрадовался было, что нашёл проблему, но знакомый мне пояснил следующее, что 15:10 это UTC+5, а 10.10 это UTC+0, то есть всё верно. А мне кажется, что это бред. Придумали тоже идиотские стандарты, потом выкручивайся.
Что делать, не представляю. Всё перепроверил, часовые пояса, время, стоят верно. Что ещё не так? Как мне верно выстроить для подсетей обновление по NTP, чтобы вопрос этот закрыть?
Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера XXXX-hv-01$. Использовалось целевое имя TERMSRV/XXXX-HV-01. Это означает, что целевому серверу не удалось расшифровать билет, предоставленный клиентом. Это возможно, когда целевое SPN-имя зарегистрировано на учетную запись, отличную от учетной записи, используемой конечной службой. Убедитесь, что целевое SPN-имя зарегистрировано только на учетную запись, используемую сервером. Эта ошибка также может возникать, если пароль целевой службы отличается от пароля, заданного для нее в центре распространения ключей Kerberos. Убедитесь, что пароли в службе на сервере и в центре распространения ключей совпадают. Если имя сервера задано не полностью и конечный домен (PGFA.LOCAL) отличается от домена клиента (PGFA.LOCAL), проверьте эти два домена на наличие учетных записей серверов с одинаковыми именами или используйте для идентификации сервера полное имя.
