Назад | Перейти на главную страницу

Проводная аутентификация 802.1x после смены домена

Я пытался найти решение этой проблемы в течение последних 2 недель, и это сводит меня с ума. Надеюсь, кто-нибудь сможет мне помочь.

Мы находимся в процессе миграции клиентов Windows 7 из нескольких дочерних доменов в один корневой домен. У нас есть сценарий миграции, который объединяет их из child.domain.net в domain.net. Работает очень хорошо. Однако теперь мы сталкиваемся с проблемой, заключающейся в том, что некоторые из наших офисов используют 802.1x на наших коммутаторах, которые аутентифицируют клиентов на сервере IAS Windows 2003, который находится в корневом домене. Сервер IAS расположен в городе A и имеет контроллер домена в той же подсети, в которой он проверяет запросы. Если мы переносим клиента из города B в новый домен, процесс присоединения к домену происходит на локальном контроллере домена в городе B. ИТ-отделам требуется до 15 минут, чтобы контроллеры домена в городе A и городе B реплицировались друг с другом. После присоединения к домену клиент перезагружается и сможет пройти аутентификацию на локальном контроллере домена. Однако коммутатор запрашивает сервер IAS в городе A, разрешен ли клиенту доступ в сеть. Сервер IAS запрашивает свой локальный контроллер домена, который ничего не знает о новом объекте и отклоняет запрос, поэтому клиенту приходится ждать завершения цикла репликации.

Есть ли способ исправить это? Я надеялся, что смогу указать серверу IAS разрешить любому клиенту с полным доменным именем * .domain.net разрешить доступ без проверки учетных данных. Но все мои исследования говорят мне, что это невозможно. Я не сторонник признания поражения, поэтому я надеялся, что кто-то столкнется с той же или похожей проблемой и даст совет.

Ценю любую помощь. Спасибо.

Настроить уведомление об изменении в ссылках на сайт AD, чтобы у вас не было 15-минутной задержки репликации.

В качестве отступления: вы должны использовать такой инструмент, как ADMT, для миграции пользователей, групп и компьютеров в корневой домен. Он делает намного больше (например, серверы повторного ACL), чем описанный вами сценарий.