none
Не проходит аутентификацию на мигрированной рабочей станции через "сетевое окружение" RRS feed

  • Вопрос

  • День добрый. Планирую миграцию из 2000 в 2003 при помощи ADMT3.0, тестирую виртуальную лабораторную конфигурацию.
    Всё совсем простенько, old.local на win2000sp4, new.local на win2003x64sp2, клиенты на xpsp3. На обоих dc по днсу, смотрят друг на друга через форвард. Ну и на всякий случай, плюс чтобы не порождать "domain list is creating" даже дхцп раздаёт оба днса клиентам. Всё действо ведется в одной подсети.
    Мигрейшн гайд прочтён и всё проделывается в соответствие с ним. Трасты подняты, сама миграция проходит хорошо. Возникает следующая проблема:
    1) Допустим, clientxp мигрирован в clientxp.new.local
    Всё у него хорошо, все профили и шары транслируются, и он сам имеет доступ ко всем ещё немигрированным станциям обычным способом.
    2) Но, пытаясь с другого clientxp2 через "сетевое окружение" добраузиться на clientxp, получаем отлуп "Logon Failure: The target account name is incorrect". В логах clientxp получаем
    Logon Failure:
     	Reason:		Unknown user name or bad password
     	User Name:	
     	Domain:		
     	Logon Type:	3
     	Logon Process:	Kerberos
     	Authentication Package:	Kerberos
     	Workstation Name:	-
    Независимо от того, каким пользователем влогинены на clientxp2 - включая обоих доменных рутов.
    Если же стучимся напрямую через \\clientxp.new.local или ip-адрес, всё хорошо и доступ получаем.
    Причину, судя по всему, я нагуглил - учётная запись clientxp остаётся в старом AD. Как только мы её оттуда убиваем, без всяких ребутов мгновенно начинает доступ через "сетевое окружение" работать.
    Теперь вопросы:
    1) а, собственно, так и надо делать? В гайде-то ничего про это не сказано.
    2) даже при описанном решении в "сетевом окружении" остаётся "призрак" станции в старом домене, причем отзывается на ура - почему? Если исчезнет, то через какое время?
    3) как вообще следует проводить миграцию DNS? про это в гайде как бы тоже ничего нет. Смущает то, что клиентам, которые уже в новом домене, DHCP от старого раздаёт суффикс старого домена помимо прочего. Нормально ли будет по окончании миграции просто вычеркнуть старый днс из дхцп и подменить этот сам дхцп на его свежепоставленного собрата?

    P.S. Почему-то на одной из попыток миграции (я перегонял станцию назад руками и делал несколько раз миграцию для экспериментов) получилась такая бяка ещё: в новом домене, если смотреть через "пользователи и компьютеры", в свойствах учётной записи clientxp числилось DNS-имя clientxp.OLD.local (поменять его средствами гуя, конечно, никак). Нет идей, как так могло получиться?
    11 августа 2009 г. 14:01

Ответы

  • 1. Отмигрировали в новый домен, все работает, старый тихо потушили, на этапе миграии удалять не нужно.
    2. Смотрите в сторону  netbios, computer browser  можно почитать тут http://www.networkdoc.ru/windows-2000/sluzhba-computer-browser.html
    3.Необходимо, используя групповые политики, изменить сетевые настройки на перемещаемых компьютерах, определить  порядок добавления ДНС суффиксов.
    • Помечено в качестве ответа bromi 13 августа 2009 г. 6:16
    11 августа 2009 г. 14:41

Все ответы

  • 1. Отмигрировали в новый домен, все работает, старый тихо потушили, на этапе миграии удалять не нужно.
    2. Смотрите в сторону  netbios, computer browser  можно почитать тут http://www.networkdoc.ru/windows-2000/sluzhba-computer-browser.html
    3.Необходимо, используя групповые политики, изменить сетевые настройки на перемещаемых компьютерах, определить  порядок добавления ДНС суффиксов.
    • Помечено в качестве ответа bromi 13 августа 2009 г. 6:16
    11 августа 2009 г. 14:41
  • 1. Так пользователи в процессе миграции обломаются с шарами на смигрированных ресурсах, там же везде идёт UNC \\server, а не \\server.domain
    Вообще, нагугливается по данной ошибке довольно много случаев и ответов, что причиной ошибки является одинаковое имя в сорс и таргет доменах, к примеру, вот: http://www.searchmarked.com/windows/how-to-deal-with-login-failure-the-target-account-name-is-incorrect-on-a-windows-file-share.php
    Про керберос там тоже в комментах пишут, но, по правде, я в керберосе понимаю очень мало.
    На clientxp2, действительно, в логе имеется тоже самое:
    The kerberos client received a KRB_AP_ERR_MODIFIED error from the server CLIENTXP$.  This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named  machine accounts in the target realm (NEWDOMAIN.LOCAL), and the client realm.   Please contact your system administrator.
    Что как бы намекает на то, что удалять всё же нужно. Или авторы мигрэйшн гайда предполагают, что все пользователи уже давно не пользуются нэйборхудом и пишут полные FQDN? :)

    2. Ага, почитаю
    3. Ну, после миграции праймари суффикс-то становится вроде как правильный. Суффикс старого домена остаётся только на коннекшн-бейзед, подозреваю, это не должно повредить?
    11 августа 2009 г. 14:50
  • Мне кажется у Вас проблема с доступом при миграции из-за одной подсети для двух доменов.

    К примеру мы мигрировали по 1000 рабочих станций внеделю, это были разные подсети, DNS Forward + WINS Replication+трасты+Enable SID History и если бы у клиентов отваливались ресурсы нам бы быстренько шею намылили. :-) Миграция была как с NT4 так и с 2000 :-)

    11 августа 2009 г. 16:19
  • 1. Отмигрировали в новый домен, все работает, старый тихо потушили, на этапе миграии удалять не нужно.
    2. Смотрите в сторону  netbios, computer browser  можно почитать тут http://www.networkdoc.ru/windows-2000/sluzhba-computer-browser.html
    3.Необходимо, используя групповые политики, изменить сетевые настройки на перемещаемых компьютерах, определить  порядок добавления ДНС суффиксов.
    Поразмыслив, решил проблему методом добавления обоих, таки, старого и нового, ДНС-суффиксов в политике старого домена. То есть, как я понимаю, когда нейборхуд или там net use начинают работать чисто через днс, у них всё хорошо. Если же комп они нашли по нетбиосу - то ключ кербероса выписывается криво.

    UPD: Что примечательно, теперь ПЕРВЫЙ раз после ребута клиент всё равно выдаёт ошибку кербероса, записывает её в лог, если тут же попробовать ещё раз, или просто в следующий раз - уже авторизация проходит нормально. Забавно. Видимо поочередно суфиксы пробует, что ли.
    • Изменено bromi 13 августа 2009 г. 6:34 update
    13 августа 2009 г. 6:20