Короткий ответ — скорее всего проблема не в «обновлении винды на клиенте», а в том, как вы переместили именно контроллёр домена. Копирование/перенос VHD контроллера домена на другой «хост» (особенно на НЕ‑виртуальную машину) легко может привести к нарушениям работы служб AD (USN‑rollback / проблема с VM‑GenerationID, разрывом репликации или нарушением работы KDC). Как следствие контроллер перестаёт корректно аутентифицировать пользователей и клиенты получают общую ошибку «Этот метод входа запрещён».
Что делать — порядок диагностики и восстановления
1) Немедленно — проверьте логи на самом контроллере домена
- Event Viewer (Категории: Directory Service, System, Netlogon, Kerberos). Ищите сообщения об ошибках репликации, о «USN rollback», упоминания VM‑GenerationID, ошибки KDC/Netlogon и ошибки аутентификации.
2) Быстрая проверка состояния DC и репликации
- На DC выполните: dcdiag /v
- repadmin /replsummary
- repadmin /showrepl
Эти команды покажут, работает ли репликация и видит ли DC других контроллеров.
3) Проверить доступность служб аутентификации
- Убедитесь, что запущены сервисы Netlogon, Kerberos (KDC), AD DS и DNS.
- Проверьте, отвечают ли порты 88 (Kerberos) и 389/636 (LDAP) на DC.
- На клиенте проверьте какой DC он видит: nltest /dsgetdc:ваш.домен
4) Проверить DNS/SRV записи контроллеров
- nslookup -type=SRV _ldap._tcp.dc._msdcs.<домен>
- на клиентах DNS должен указывать на рабочий DC.
5) Если в логах есть явные указания на USN rollback / VM‑GenerationID
- Это подтверждение классической проблемы: виртуальный DC был восстановлён/скопирован некорректно и AD обнаружил «откат» базы данных — репликация будет нарушена. Поддерживаемого «лечения» такого состояния без бэкапа зачастую нет: рекомендуется восстановить DC из корректной резервной копии (system state) либо удалить проблемный DC и заново создать/промотировать новый контроллер, а затем восстановить репликацию с рабочих контроллеров.
6) Варианты восстановления в зависимости от ситуации
- Если есть другие здоровые DC в домене: лучше удалить (или демонтировать) проблемный DC и **промотировать новый свежий сервер**; затем дать ему реплицировать AD.
- Если проблемный DC был единственным и есть бэкап system state: восстановите из бэкапа.
- Если единственный DC и бэкапа нет — придётся восстанавливать AD вручную: возможны сценарии с занятной очисткой метаданных и воссозданием новых контролеров + восстановлением объектов пользователей, что очень болезненно. В этом случае рекомендую привлекать специалиста/консультацию с доступом к логам.
7) Кратковременные меры
- Пока не восстановите рабочий DC, можно включить на клиентских ПК автономное использование кэшированных учётных данных (если оно ещё есть) — это даст пользователям возможность войти локально, но не решит проблему аутентификации к серверным ресурсам.
- Не пытайтесь «силой» менять политики аутентификации на клиенте — это временно и может ещё больше осложнить ситуацию.
Почему именно «Этот метод входа запрещён»
- Клиенты пытаются аутентифицироваться, но контроллер либо не отвечает как KDC/LDAP, либо отвергает выбранный метод (Kerberos/NTLM/SmartCard) из‑за неконсистентности состояния DC или политик, которых контроллер сейчас не может корректно применить. Поэтому сообщение выглядит именно так.
Если хотите, помогу дальше — пришлите:
- вывод dcdiag /v и repadmin /replsummary,
- фрагменты ошибок из Event Viewer (Directory Service и System) за момент загрузки и попыток входа,
- информация: был ли этот DC единственным в домене или есть другие контроллеры, был ли у вас system‑state бэкап.
С этими данными дам конкретный план восстановления.