При подключении к домену произошла следующая ошибка конечная учетная запись указана неверно

При выделении одной подсети (основной домен) в другой поддомен (новый домен) в этом же лесу произошла странная ошибка. Пользователи из основного домена не видят на сервере нового домена общие папки. Компьютеры с Windows XP ничего не сообщают, а просто показывают пустое содержимое общих папок. А по «net view \dcgs») получаю «Ошибка 5. Отказано в доступе».

А Windows Server 2008 и другие более поздние операционные системы конкретно сообщают об ошибке:

Нет доступа к \dcgs. Возможно, у вас нет прав на использование этого сетевого ресурса.
Обратитесь к администратору этого сервера для получения соответствующих прав доступа.
Вход в систему не произведен: конечная учетная запись указана неверно.

Самое интересное, что по IP-адресу список общих папок прекрасно отображается:

\192.168.200.1

а при отображении по NetBIOS и DNS именам появляется вышеупомянутая ошибка. Скорее всего проблема в DNS. Поэтому опишу более полное решение — как со стороны клиента, так и со стороны DNS-сервера.

Шаг 1. Клиент

На стороне клиента необходимо выполнить следующие шаги:

1. На сервере DNS удалить старые записи, что мешают правильному сопоставлению.
2. На клиенте (откуда осуществляется доступ) очистить DNS-кэш командой.

ipconfig /flushdns

3. С помощью nslookup на клиенте проверить, что имя разрешается в правильный IP-адрес. Иногда, проблема неправильного разрешения может быть в файле hosts и ему подобных.
4. Необходимо завершить текущий сеанс на клиенте и снова войти. Теперь к общим ресурсам должен быть доступ.

В большинстве случаев этого оказывается достаточно. Но рекомендую выполнить шаги 2-4.

Шаг 2. Клиент

Иногда, после проделанных действий ошибка может снова появится. Причина может быть в DNS-суффиксах подключения:

C:Documents and Settingsuser>nslookup
Default Server:  dcgs.gs.k43.guap.ru
Address:  192.168.200.1

> dcgs
Server:  dcgs.gs.k43.guap.ru
Address:  192.168.200.1

Non-authoritative answer:
Name:    dcgs.guap.ru
Address:  194.226.199.245

>
C:Documents and Settingsuser>ipconfig /all

Настройка протокола IP для Windows

        Имя компьютера  . . . . . . . . . : COMP16
        Основной DNS-суффикс  . . . . . . : k43.guap.ru
        Тип узла. . . . . . . . . . . . . : неизвестный
        IP-маршрутизация включена . . . . : нет
        WINS-прокси включен . . . . . . . : нет
        Порядок просмотра суффиксов DNS . : k43.guap.ru
                                            gs.k43.guap.ru

Локальная сеть - Ethernet адаптер:

        DNS-суффикс этого подключения . . : gs.k43.guap.ru
        Описание  . . . . . . . . . . . . : Intel(R) PRO/100 VE Network Connecti
on
        Физический адрес. . . . . . . . . : 00-11-22-33-44-55
        Dhcp включен. . . . . . . . . . . : да
        Автонастройка включена  . . . . . : да
        IP-адрес  . . . . . . . . . . . . : 192.168.200.2
        Маска подсети . . . . . . . . . . : 255.255.255.0
        Основной шлюз . . . . . . . . . . : 192.168.200.1
        DHCP-сервер . . . . . . . . . . . : 192.168.200.1
        DNS-серверы . . . . . . . . . . . : 192.168.200.1
        Аренда получена . . . . . . . . . : 12 декабря 2012 г. 9:53:24
        Аренда истекает . . . . . . . . . : 20 декабря 2012 г. 9:53:24

В данном примере сперва использовался другой DNS-сервер домена k43.guap.ru, а не текущего домена gs.k43.guap.ru. Машина находится в двух доменах, и выполнен вход под пользователем из другого домена. Так или иначе это приводится к «неправильному» порядку DNS-суффиксов.

В настройках сетевого адаптера, в настройках протокола Интернета (TCP-IP), на вкладке «Общие» нажимаем кнопку «Дополнительно» и указываем нужный порядок DNS-суффиксов:

После этого проверяем правильность разрешения:

C:Documents and Settingsuser>ipconfig /all

Настройка протокола IP для Windows

        Имя компьютера  . . . . . . . . . : COMP16
        Основной DNS-суффикс  . . . . . . : k43.guap.ru
        Тип узла. . . . . . . . . . . . . : неизвестный
        IP-маршрутизация включена . . . . : нет
        WINS-прокси включен . . . . . . . : нет
        Порядок просмотра суффиксов DNS . : gs.k43.guap.ru
                                            k43.guap.ru

Локальная сеть - Ethernet адаптер:

        DNS-суффикс этого подключения . . : gs.k43.guap.ru
        Описание  . . . . . . . . . . . . : Intel(R) PRO/100 VE Network Connecti
on
        Физический адрес. . . . . . . . . : 00-11-22-33-44-55
        Dhcp включен. . . . . . . . . . . : да
        Автонастройка включена  . . . . . : да
        IP-адрес  . . . . . . . . . . . . : 192.168.200.2
        Маска подсети . . . . . . . . . . : 255.255.255.0
        Основной шлюз . . . . . . . . . . : 192.168.200.1
        DHCP-сервер . . . . . . . . . . . : 192.168.200.1
        DNS-серверы . . . . . . . . . . . : 192.168.200.1
        Аренда получена . . . . . . . . . : 12 декабря 2012 г. 11:49:57
        Аренда истекает . . . . . . . . . : 20 декабря 2012 г. 11:49:57

C:Documents and Settingsuser>nslookup
Default Server:  dcgs.gs.k43.guap.ru
Address:  192.168.200.1

> dcgs
Server:  dcgs.gs.k43.guap.ru
Address:  192.168.200.1

Name:    dcgs.gs.k43.guap.ru
Address:  192.168.200.1

>

Шаг 3. DNS-сервер

На DNS-сервере следует проверить интерфейсы по которым прослушивают клиентов:

Поскольку в DNS создаются записи типа A для интерфейсов отмеченных галочками, то теоретически может возникнуть следующая ситуация. Пусть DNS-сервер прослушивает по двум адресам: 192.168.200.1 и 169.254.0.17. Когда клиент разрешает имя сервера в IP-адрес, то ему может попасться любой адрес из указанных. Если настройками брандмауэра стоит разрешение на подключение к 192.168.200.1, а на остальное запрет, то при получении адреса 169.254.0.17 клиент не сможет подключиться к DNS-серверу. Или если второй адрес использовался как RAS-подключение (суть модемное соединение), но при обрыве связи этот адрес более не доступен, но клиент его закешировал, то снова возникнет проблема подключения.

Шаг 4. DNS-сервер

Этот шаг необязательный. В настройках DNS-сервера имеется полезная галочка:

• Заходим в свойства DNS-сервера.
• В окне «Имя сервера — свойства» выбираем вкладку «Дополнительно».
• Ставим галочку «Разрешить автоматическое удаление устаревших записей». По-умолчанию, стоит период 7 дней. Выбираем наиболее предпочтительный.

Теперь все сведения об устаревших записях выбудут удалены автоматически.

Рекомендую также посмотреть:
http://social.technet.microsoft.com/Forums/ru/ws2008r2ru/thread/22601e1b-4cca-44a7-930f-d0c20500e86f

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)HKLMSYSTEMCurrentControlSetServicesLanmanServerDisableStrictNameChecking = 1

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

добавить в параметр (типа REG_MULTI_SZ) HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceslanmanserverparametersOptionalNames имя(имена), по которым возможно обращение к вашему серверу — 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 оснастки. Они сами появятся заново, при перезагрузке тех рабочих машин.

Комментарии