Windows 7 конечная учетная запись указана неверно

Windows 7 конечная учетная запись указана неверно

Вопрос

Был файловый сервер srv-base, с расшаренными папками, у всех пользователей ярлыки на эти папки.

Его выключили, создали новый сервер SERV2 с этим же самым набором шар и разрешений на них.

Чтобы все ярлыки продолжали работать, создана запись CNAME «srv-base» в DNS, ссылающаяся на «SERV2.домен».

Имеем: У большинства клиентов (Windows 7) на самом деле всё работает. Но у клиентов Windows XP и Windows 8.1 при попытке перейти по ярлыку или UNC-пути к srv-base выскакивает ошибка

При обращении по IP или имени SERV2 — всё хорошо. Ответ на пинги к srv-base успешно приходят от SERV2.

Как я понял, при обращении к паке, протокол SMB передаёт имя сервера, к которому обращается. И если запрос попадает на сервер с другим именем — вылазит эта ошибка.

Можно ли как-то изменить это поведение? Ведь на Windows 7 нет этой проблемы? А то ярлыков переделывать ОЧЕНЬ много.

Ответы

Тут у вас целых две неувязки.

Во-первых, служба сервера (lanmanserver) по умолчанию проверяет имя, по которому к ней обратились. Поэтому для обращения о псевдониму (CNAME) требуется ее дополнительная настройка через реестр (и перезапуск службы).

Самый простой ее вариант — отключить эту проверку вообще:

установить параметр (типа REG_DWORD)HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\DisableStrictNameChecking = 1

Более сложный вариант — прописать псевдоним в качестве дополнительного имени:

добавить в параметр (типа REG_MULTI_SZ) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters\OptionalNames имя(имена), по которым возможно обращение к вашему серверу — srv-base и srv-base.домен

Во-вторых, если учётная запись старого сервера осталась, то в процессе аутентификации по протоколу Kerberos клиент получает билет для другого — старого — сервера. Поэтому, как минимум, удалите эту учётную запись. Лучше же, помимо этого, добавить псевдонимы в качестве дополнительных SPN учётной записи нового сервера командами

Источник

Windows 7 конечная учетная запись указана неверно

Вход в систему не произведен: конечная учетная запись указана неверно.

Однажды на работе произошла «жопа». После установки новых компьютеров в учебный отдел, вбивания их в домен, прописывания принтеров при обращении некоторых компов к сети вылетала ошибка «Вход в систему не произведен: конечная учетная запись указана неверно.» (Картинки кликабельны).

Поначалу я думаю проблемы с доменом или настройками. На всех 5 машинах перевбил в домен, с нуля настроил всю сеть, но проблема не прошла. И именно на тех двух злосчастных компах.

Я сразу заметил, что при обращении по IP адресу к машине все прекрасно работало.

А при обращении по NETBIOS и DNS имени к компу выскакивала такая ошибка.

Поначалу я не прохавал в чем проблема. Полез в инет покопался по форумам, как всегда, ничего не нашел, но наткнулся на пару путевых постов. Ребята говорили, что им помогла переустановка DNS сервера на контроллере домена, меня такая перспектива не радовала. Поэтому приключения я продолжил в одиночестве.

Поскольку проблема возникала именно при обращении к DNS серверу, начал копать его.

В nslookup начал пробивать эти имена и тут смотрю, что-то не то. Адреса не те, что у компов. В общем DNS сервер хранил не те записи о компьютерах. Короче имя компа не соответствовало DNS имени в сети.

Полезли в домен. А тут раз и адреса не совпадают. Сразу вспомнил, что по адресам 192.168.0.61 у меня был Учебный отдел. А поскольку к нам добавилась еще одна кафедра и в это же время в Учебный отдел привезли компы, я решил навести порядок в распределении IP адресов, которое красиво смотрится у нас в серверной на сетке.

DNS сервер за 2 суток не обновился и хранил старые записи. Поэтому набирая

я обращался не к компу по адресу 192.168.0.61, а к компу на новой кафедре. Отсюда и ошибка с именем пользователя.

Решается проблема 2 кликами.

В настройках нашего DNS сервера dnsmgtm.msc Открывает меню. GATEWAY (У нас так сервер называется). Меню Properties (Настройки). Там находим вкладку Advanced (Дополнительно) и включаем очистку устаревших записей DNS сервера. «Enable automatic scavenging of state records». Я поставил раз в сутки. И проблема решена. Если сразу не решится, то просто удаляем записи о глючных компах из DNS оснастки. Они сами появятся заново, при перезагрузке тех рабочих машин.

Комментарии