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

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

Поначалу я думаю проблемы с доменом или настройками. На всех 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 оснастки. Они сами появятся заново, при перезагрузке тех рабочих машин.

Комментарии

Благодарю автора за идею. Очень полезная информация.
Удачи, и новых отличных идей

Комментарий от Настя [ Апрель 6, 2012, 08:36 ]

Большое спасибо была таже проблема не печатал принтер перенастроил обращение с имён на ip адреса теперь всё супер))))

Комментарий от Татарин [ Сентябрь 7, 2012, 14:48 ]
Комментарий от Vadim [ Октябрь 3, 2012, 09:50 ]
Комментарий от Михаил [ Ноябрь 27, 2012, 14:14 ]
Комментарий от yurvasya [ Февраль 11, 2013, 15:14 ]

Вот спасибо так спасибо! Тоже голову ломали сегодня 🙂

Комментарий от Игорь [ Февраль 21, 2013, 09:57 ]

Где тут лайк оставить?

Комментарий от Akill [ Ноябрь 7, 2013, 03:31 ]
Комментарий от Евгений [ Март 7, 2014, 10:38 ]

Наконец-то наткнулся на толковое решение, а то везде какую-то билиберду пишут и просят логи с найстроками сети 🙂 Спасибо!

Комментарий от Андрей [ Июнь 19, 2014, 16:10 ]

А мне не помагло :((
Галочку потавил, по ИП обращение проходит, а по имени нет. Nslookup возвращает все корректно.

Комментарий от Леонид [ Август 13, 2014, 14:11 ]

Спасибо! Всё логично, но всего знать невозможно… СПАСИБО!

Комментарий от Auger [ Сентябрь 2, 2014, 10:34 ]

Спасибо бро! Очень выручил!

Комментарий от Евгений [ Март 11, 2016, 06:36 ]

Компьютеры с общими сетевыми папками и принтерами динамические IP присваивать не рекомендуется. Присваивайте им фиксированные статические IP

Комментарий от Алексей [ Апрель 24, 2018, 09:45 ]

Не поленился, решил оставить комментарий за полезную информацию! Спасибо автору

Комментарий от Павлов Василий [ Май 14, 2018, 18:02 ]

ОГРОМНОЕ спасибо за реально полезную информацию!

Чаще всего при работе с сетью встречаются одни и те же проблемы, вопросы о которых задают на форумах. Зачастую, решения внятного там так и не находят.

С переходом на Windows 7 многие из проблем решились, т.к. авторы сборок стали меньше глубоко копаться в системных настройках: менять системные настройки, политики безопасности, параметры реестра. Ведь чаще всего, проблемы в работе сети были вызваны именно применением всевозможных сборок 🙂

Именно поэтому опишу типовые проблемы, которые чаще всего встречаются при доступе в сетевым ресурсам сетей на базе Windows.

Сетевые ошибки Windows

Итак, по умолчанию в стандартной Windows XP Professional доступ к сетевым ресурсам без пароля запрещен. В бездоменной сети или необходимо создать пользователей с одинаковыми паролями для на всех машинах, или же включить учетные записи гостей, после чего обязательно расшарить ресурс или для пользователя «Все» (если используется авторизация через Гостя) или же назначить тех пользователей, которые будут авторизоваться на на машине (в случае авторизации по имени пользователя и паролю).

И здесь могут возникнуть 2 типовые ошибки:

  • Вход в систему не произведен. Имеются ограничения, связанные с учетной записью.
  • Вход в систему не возможен: выбранный режим входа для данного пользователя на этом компьютере не предусмотрен.

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

Решение

Вход в систему не произведен. Имеются ограничения, связанные с учетной записью.

Необходимо изменить: Панель управления > Администрирование > Локальные параметры безопасности > Локальные политики > Назначение прав пользователя > Отказ в доступе к компьютеру из сети.

Из списка пользователей там необходимо удалить всех, кроме SUPPORT_*. Это позволит подключаться к машине под аккаунтом Гость (если на включена локально).

Вход в систему не возможен: выбранный режим входа для данного пользователя на этом компьютере не предусмотрен.

Необходимо изменить: Панель управления > Администрирование > Локальные параметры безопасности > Локальные политики > Параметры безопасности > Учетные записи: ограничить использование пустых паролей только для консольного входа.

Изменить на Выключен. Это позволит входить на компьютер по сети от имени пользователя с пустым паролем и без включенной учетной записи Гостя.

среда, 5 декабря 2012 г.

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

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

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

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

Шаг 1. Клиент

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

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

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

Шаг 2. Клиент

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

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

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

Шаг 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-сервер

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

Комментарий от Aziz [ Сентябрь 12, 2018, 09:03 ]