[Baste]

Вспомнила еще некоторые подробности истории с компьютером из примера.

Так уж сложилось, что тестового стенда у нас нет, как и времени на полноценное тестирование проектов.
Этот комп попал к нам на переустановку системы и так как пользователь уходил в отпуск грех было этим не воспользоваться.
Тестировала поведение машины при недоступности DC (отключала учетку в AD) с 5 кэшированными входами.

По данному случаю выводы были печальными:
1. Вход в систему ограничен не количеством, а сроком действия билета Kerberos (у нас 7 дней).
2. До окончания срока действия билета система не обращается к DC даже если он доступен.
3. После окончания срока действия билета получаем ошибку "Не удалось установить доверительные отношения с сервером".
4. Переименование/переввод в домен не удаляют из AD, DNS и DHCP записи о таком компьютере.

Если я правильно понимаю, это и есть причина появления в нашей сети вот таких непингуемых компьютеров и призраков в AD.

Так происходит не всегда, но достаточно часто.
Кэш настраивали до меня, ньюансов не знаю, появились вопросы:
1. Почему клиент не проверяет доступность DC?
2. Если настроить более частую очистку кэша и уменьшить срок действия билета Kerberos, машины начнут проверять доступность DC или мы получим еще больше проблем?
3. Почему после окончания срока действия билета не выдается новый?