Выполняя некоторые не связанные с этим проблемы (по крайней мере, я так думаю, проблемы с общим принтером), я наткнулся на ряд записей журнала событий, которые меня обеспокоили.
Machine Name: labcomputer82
Source: Security-Kerberos
Event ID: 4
Event Description:
Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED от сервера labcomputer143 $. Используемое целевое имя было RPCSS / imagemaster4.ad.domain.edu. Это указывает на то, что целевому серверу не удалось расшифровать билет, предоставленный клиентом. Это может произойти, если основное имя целевого сервера (SPN) зарегистрировано в учетной записи, отличной от учетной записи, которую использует целевая служба. Убедитесь, что целевое SPN зарегистрировано и зарегистрировано только в учетной записи, используемой сервером. Эта ошибка также может произойти, когда целевая служба использует другой пароль для учетной записи целевой службы, отличный от того, который имеет центр распространения ключей Kerberos (KDC) для учетной записи целевой службы. Убедитесь, что и служба на сервере, и KDC обновлены для использования текущего пароля. Если имя сервера не полностью определено, а целевой домен (AD.DOMAIN.EDU) отличается от клиентского домена (AD.DOMAIN.EDU), проверьте, есть ли в этих двух доменах учетные записи сервера с одинаковыми именами, или используйте полное имя для идентификации сервера.
В этом сообщении используются три имени машины. Он генерируется на labcomputer82, он пытается связаться с другой лабораторной рабочей станцией под названием labcomputer143, и рассматриваемая служба (RPCSS) относится к имени машины, с которой был создан образ для этой машины (и, возможно, также и с labcomputer143, я не уверен ). Я поднял брови, потому что машина с именем labcomputer82 пытается использовать SPN RPCSS/imagemaster4.ad.domain.edu.
Атрибут SPN на объекте компьютера в AD выглядит нормально. У него есть все названия, которые он должен иметь.
Эти машины созданы с использованием Ghost и (по крайней мере, в этом конкретном случае) sysprep был не используемый. Из более чем 3000 компьютерных объектов в нашем домене AD около 1700 из них являются рабочими местами в компьютерных лабораториях, для которых часто создаются образы, и по состоянию на сентябрь большинство из них были созданы с использованием метода Ghost / Profile-Copy вместо метода Ghost / sysprep, рекомендованного Microsoft. . Если этот отчет об ошибке является чем-то серьезным, над которым Windows спокойно работает, возможно, Kerberos сломан для этих машин и он не работает обратно на NTLMv2, я хотел бы знать, чтобы я мог добавить давление на свой диск для принятия sysprep.
Вы должны обязательно выполнить Sysprep, чтобы каждая машина имела уникальный идентификатор. Sysprep делает и другие вещи, и отсутствие Sysprep может привести к непредсказуемому отказу различных компонентов Windows.
Это то, что мы можем сделать, просто взглянув на сообщение (без сведений о sysprep). Процесс, запущенный на labcomputer82, пытался связаться с imagemaster4. Но похоже, что имя, которое он разрешил и с которым в конечном итоге установили связь, идентифицировало себя как labcomputer143. Вероятно, здесь у вас проблемы с DNS. Возможно, следует сравнить вывод nslookup imagemaster4 и labcomputer143, чтобы убедиться, что они не используют один и тот же IP-адрес.
SPN RPCSS / imagemaster4.ad.domain.edu, запрошенный labcomputer82, был представлен тому, что лабораторный компьютер 82 принял за imagemaster4. Однако оказалось, что это была машина / служба, идентифицирующая себя как labcomputer143. Очевидно, что пароли компьютерных учетных записей labcomputer143 и imagemaster4 будут отличаться. Следовательно, билет, зашифрованный с помощью imagemaster4, не будет расшифрован labcomputer143. Отсюда и ошибка.
Я рекомендую 2 вещи. 1. вы исключаете любые подозрения относительно использования sysprep. Убедитесь, что каждая машина имеет уникальный идентификатор и связывает себя в AD с уникальной учетной записью компьютера. 2. Прочтите записи блога об устранении неполадок Kerberos на http://blogs.technet.com/askds чтобы получить представление об устранении этих проблем и общих / вероятных причинах.
Детали во многом совпадают с подозрениями мавиров. Отсутствие Sysprep в создании образа диска оставило службу RPCSS убежденной, что это SPN RPCSS/imagemaster4.ad.domain.edu. Когда он попытался получить свой TGT, он связался imagemaster4.ad.domain.edu, который в то время был занят компьютером с именем labcomputer143. Что не удалось.
Это вызывало откат этих станций к NTLM.
В качестве обходного пути я добавил вытесняемую запись DNS в DNS домена для imagemaster4.ad.domain.edu (в настоящее время не обслуживается) в 127.0.0.1. После изучения журналов событий нескольких затронутых рабочих станций они теперь работают правильно для Kerberos. Это обходной путь, который перестанет работать, когда imagemaster4 присоединится к домену и зарегистрирует свои записи DNS. Но, по крайней мере, теперь у меня есть метод.
Sysprep на будущее.