Компьютеры в домене не доступны по сети (ICMP, RDP, из AD), хотя сеть есть
 

Среда:
- локальная сеть предприятия
- коммутаторы ProCurve 2510G
- ядро сети ProCurve 5406ZL
- 320 машин (ось XP, Vista, 7) в составе домена
- Контроллер домена MS Windows Server 2003 R2
- DNS, DHCP, AD
- Kaspersky Open Space Security

Условия:
- управление из AD
- управление по RDP
- инвентаризация и лицензионный аудит Total Network Inventory 2

Проблема:
Некоторые компьютеры не доступны по сети: ICMP, RDP и в сетевом окружении не отображаются.
В AD компьютер есть, но управление не возможно.
(Аппаратные и программные характеристики разные)
Сеть есть, интернет есть, другие компьютеры в сети находит.

Пример:
Аппаратные характеристики
- Intel core 2 Quard Q9400
- DDR2 2 Gb
- Atheros AR8121/AR8113/AR8114 PCI-E Ethernet
- NVIDIA Quadro FX 3800
Программные характеристики
- Windows 7
- Kaspersky - прописаны в разрешенных все VLAN предприятия, разрешены ICMP, RDP
- Брандмауэр - разрешены ICMP, RDP; (вкл/выкл неважно)
- Сетевое обнаружение включено
- GPO (пк) - по этим протоколам ограничений нет
- GPO (пользователь) - ограничения на запуск ПО, кроме системного, разрешенного и наших скриптов.
- Службы DNS-клиента, публикации ресурсов для обнаружения функций, обнаружения протокола SSDP и узла универсальных PNP включены.

Проверяла в DHCP, DNS все в порядке. Удаляла записи связанные с ним, переподключала сеть, чтобы адрес обновить, но получает тот же.
Переименовала, переввела в домен.
Назначала статику.
Выполнила полную проверку с обновленными базами: вирусов не обнаружено

В домене не пингуется (имя/IP неважно), по другим протоколам разумеется тоже не доступен.
Без домена пингуется по крайней мере из своей VLAN.


Как решить эту проблему?

Baste, в Безопасном режиме с загрузкой сетевых драйверов проблема есть?

Отключение брандмауэра и удаление Касперского не помогает?
Остается не так много вариантов. Политики IPsec не настроены?

Посмотрите ошибки/предупреждения в журнале событий.
Как пример

нет.

Брандмауэр отключала, эффекта нет.
Касп не удаляла - когда машина не в домене - все впорядке.

Не пробовала, с точки зрения пользователя все нормально: инет есть, сетка есть, доступ к файлсерверу есть. Отвлекать человека от работы без видимой для него причины - череповато.

Ошибки/предупреждения отдельных приложений, которые к сетке отношения не имеют.

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

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

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

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

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