Безопасность windows учетные данные введены неверно или отсутствует связь с сервером

Учетные данные введены неверно или отсутствует связь с сервером выполняющим аутентификацию windows 7

Общие обсуждения

Доброго времени суток.

Учетные данные, использованные для подключения к xxx.xxx.xxx.xxx, недопустимы. Введите новые учетные данные.

Через Hyper-V входим без проблем.

Кто-то сможет подсказать откуда ростут проблемы?

Все ответы

Например, из-за отсутствия у учетной записи права на вход в систему через службу удаленных рабочих столов. Право это определяется политикой, при обычной настройке оно есть у групп Администраторы и Пользователи служб удаленных столов, кроме того в политике можно установить явный запрет на этот тип входа (проверьте всё это).

А вообще, для выяснения точной причины проблем со входом в систему включайте(через политику) аудит неудачных попыток входа в систему и смотрите журнал событий Безопасность.

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

Аудит пишет следующее:

Учетной записи не удалось выполнить вход в систему.

Учетная запись, которой не удалось выполнить вход:
ИД безопасности: NULL SID
Имя учетной записи: Администратор
Домен учетной записи: MOS1SKRIST1

Сведения об ошибке:
Причина ошибки: Неизвестное имя пользователя или неверный пароль.
Состояние: 0xC000006D
Подсостояние: 0xC0000064

Источник

Учетные данные введены неверно или отсутствует связь с сервером выполняющим аутентификацию windows 7

Всем привет, сегодня расскажу как можно попасть на компьютер в домене Adctive Directory, у которого при попытке залогиниться выскакивает сообщение отсутствуют серверы которые могли бы обработать запрос на вход в сеть, в итоге вы не можете на него попасть и естественно выполнить задачу. Бывает такое, при первой попытке авторизации, или же после того как вы сходили на обед, а возвратившись с него вы обнаружили свою проблему. Думаю для начинающих системных администраторов это будет полезно, будет большее понимание как это работает и как это чинить.

Что означает отсутствуют серверы обработки

И так у меня есть сервер с установленной на него операционной системой Windows Server 2012 R2, При попытке на него попасть у меня выскочило сообщение, отсутствуют серверы которые могли бы обработать запрос на вход в сеть. Смысл его заключается в том, что при попытке проверить ваш логин и пароль, серверу не удалось связаться с контроллером домена.

Как работает авторизация в Active Directory

У вас есть учетная запись в домене, вы пытаетесь войти на сервер, локально или удаленно, тут разницы нет. Сервер передает эти данные на ближайший контроллер домена, чтобы удостовериться есть ли такой пользователь или нет. Если по какой то причине, сервер не может установить связь с DC, то вы получаете отказ во входе. Если еще детальнее, то в Windows есть библиотека GINA (Graphical Identification and Authentication), она видит, что вы ввели логин и пароль, после чего она обращается к контроллеру Active Directory. За процесс аутентификации пользователя или компьютера по сети, отвечают два протокола NTLM (библиотека MSV1_0.dll) и Kerberos (библиотека Kerberos.dll). Ели бы у нас была не AD, то мы бы обращались к службе LSA (Local Security Authority), а та уже в свою очередь направила бы запрос в локальную базу данных SAM-базу для аутентификации пользователя а тот уже возвращает процессу Winlogon токен доступа.

Причины этого всего это ошибка в сетевом соединении между вашим сервером и контроллером домена и как вывод нужно проверить

Заходим на сервер когда отсутствует связь с сервером

Сразу отмечу, что данный метод будет работать только если вы до этого логинились на данный сервер, когда вы до этого входили в систему, то ваши данные были помещены в хэш локального компьютера, это поможет обойти проблему, при которой вы получили отсутствуют серверы которые могли бы обработать запрос и позволит войти. Хочу отметить, что в хэш кладется не сам логин и пароль, а результат их проверки, а если совсем точно, то хэш пароля, обработанный специальным методом salt. salt генерируется на основе имени пользователя. Сами данные лежат в ветке реестра HKLMSECURITYCache к которому имеет доступ только система.

В WIndows за кэширование отвечает параметр реестра CashedLogonsCount, найти его можно по пути

Смысл данного параметра, очень простой, все сводится к тому, что он задает количество уникальных пользователей, у которых данные можно хранить локально. По дефолту, это значение 10. Простой пример если у вас уже залогинилось 10 человек, то их хэши будут храниться локально, если 11 залогиниться то он пере затрет первого и так далее.

Если есть необходимость, поменять это значение, то групповая политика нам в помощь. Переходим в оснастку групповой политики, создаем либо новую или меняем ну уровне домена

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

Переходим в раздел

Тут вам нужно найти параметр Интерактивный вход в систему: количество предыдущих подключений к кэшу, по сути это и есть CashedLogonsCount, Сам параметр можно задать от 0 до 50. Если выставите 0, то полностью запретите локальное кэширование, это правильно с точки зрения безопасности. но не даст вам войти на компьютер при отсутствии доступа к контроллеру и покажет вам отсутствуют серверы которые могли бы обработать запрос.

В английской версии это

С точки зрения безопасности, правильно отключать данное кэширование. так как у злоумышленника есть возможность использовать данный метод, для взлома. Но есть исключения из правил, это пользователи мобильных устройств, так например для человека, который часто ездит в командировки, данное кэширование просто необходимо. Теперь вы знаете, как войти в компьютер при сообщении отсутствуют серверы которые могли бы обработать запрос на вход в сеть. Думаю вам было полезно это узнать.

Источник

Пользователь не может выполнить аутентификацию или должен выполнить ее дважды

В этой статье описаны некоторые причины проблем с аутентификацией пользователей.

Отказано в доступе (ограничение по типу входа в систему)

В этом случае пользователь Windows 10, который пытается подключиться к компьютерам с Windows 10 или Windows Server 2016, получит отказ в доступе со следующим сообщением:

Подключение к удаленному рабочему столу
Системный администратор ограничил типы входа в систему (сетевой или интерактивный), которые можно использовать. Обратитесь за помощью к системному администратору или в службу технической поддержки.

Эта проблема возникает, если для подключения к удаленному рабочему столу требуется пройти проверку подлинности на уровне сети (NLA), но пользователь не является членом группы Пользователи удаленного рабочего стола. Она также может возникать, если группе Пользователи удаленного рабочего стола не назначено право пользователя Доступ к компьютеру из сети.

Чтобы решить эту проблему, выполните одно из указанных ниже действий.

Изменение членства пользователя в группах или назначенных ему прав

Если эта проблема затрагивает одного пользователя, наиболее простым решением будет добавить этого пользователя в группу Пользователи удаленного рабочего стола.

Если пользователь уже является членом этой группы (или если проблема возникает у нескольких членов группы), проверьте конфигурацию прав пользователей на удаленном компьютере Windows 10 или Windows Server 2016.

Отказано в доступе (удаленный вызов к базе данных SAM отклонен)

Такое поведение обычно возникает, если контроллеры домена работают под управлением Windows Server 2016 или более поздней версии, а пользователи пытаются подключиться с помощью настраиваемого приложения для подключения. В частности, отказ в доступе получат приложения, которым требуется доступ к сведениям профиля пользователя в Active Directory.

Такое поведение обусловлено изменением в Windows. В Windows Server 2012 R2 и более ранних версиях, когда пользователь выполняет вход на удаленный рабочий стол, диспетчер удаленных подключений (RCM) обращается к контроллеру домена (DC), чтобы запросить конфигурацию, относящуюся к удаленному рабочему столу, в объекте пользователя в доменных службах Active Directory (AD DS). Эта информация отображается на вкладке «Профиль служб удаленных рабочих столов» в окне свойств объекта пользователя в оснастке MMC «Пользователи и компьютеры Active Directory».

Начиная с Windows Server 2016 RCM больше не запрашивает объект пользователя в AD DS. Если требуется, чтобы RCM обращался к AD DS из-за того, что вы используете атрибуты служб удаленных рабочих столов, вам нужно вручную разрешить отправку запросов.

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

Чтобы разрешить прежнее поведение RCM на сервере узла сеансов удаленных рабочих столов, настройте следующие записи реестра и перезапустите службу Службы удаленных рабочих столов:

Чтобы разрешить устаревшее поведение RCM на сервере, отличающемся от сервера RDSH, настройте эти записи реестра и следующую дополнительную запись (затем перезапустите службу).

Дополнительные сведения об этом поведении см. в статье базы знаний № 3200967 Changes to Remote Connection Manager in Windows Server (Внесение изменений в диспетчер удаленных подключений в Windows Server).

Пользователю не удается выполнить вход с помощью смарт-карты

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

Не удается войти в систему с помощью смарт-карты в филиале с контроллером домена только для чтения (RODC)

Эта проблема возникает в развертываниях, в которых задействован сервер RDSH на сайте филиала, где используется RODC. Сервер RDSH размещен в корневом домене. Пользователи на сайте филиала относятся к дочернему домену и используют смарт-карты для проверки подлинности. Контроллер домена RODC настроен на кэширование паролей и принадлежит к группе с разрешением реплицировать пароли RODC. Когда пользователи пытаются выполнить вход в сеанс на сервере RDSH, они получают сообщение, например: «Неудачная попытка входа в систему. Указано неверное имя пользователя или другие неверные личные данные.»

Эта проблема связана с тем, как корневой контроллер домена и RDOC управляют шифрованием учетных данных пользователей. Корневой контроллер домена использует ключ шифрования, чтобы зашифровать учетные данные, а RODC предоставляет ключ расшифровки клиенту. Если пользователь получает ошибку «Недопустимо», значит два ключа не совпадают.

Чтобы решить эту проблему, выполните одно из указанных ниже действий:

Учтите, что эти решения предполагают наличие компромисса между производительностью и уровнем безопасности.

Пользователь не может войти на компьютер с Windows Server 2008 с пакетом обновления 2 (SP2) с помощью смарт-карты

Эта проблема возникает, когда пользователи выполняют вход в систему компьютера Windows Server 2008 с пакетом обновления 2 (SP2), на котором установлено обновление KB4093227 (2018.4B). Когда пользователи пытаются выполнить вход с помощью смарт-карты, они получают отказ в доступе с сообщениями, например: «Действительные сертификаты не найдены. Убедитесь, что эта карта вставлена правильно и плотно сидит в разъеме». В то же время на компьютере Windows Server регистрируется событие приложения с сообщением «При получении цифрового сертификата с вставленной смарт-карты произошла ошибка: неправильная подпись.»

Чтобы устранить эту проблему, обновите на компьютере ОС Windows Server до повторного выпуска 2018.06 B (обновление KB4093227). См. статью Description of the security update for the Windows Remote Desktop Protocol (RDP) denial of service vulnerability in Windows Server 2008: April 10, 2018 (Описание обновления системы безопасности для защиты протокола RDP в Windows от уязвимости службы в Windows Server 2008 (10 апреля 2018 г.).

Не удается оставаться в системе, вход в которую выполнен с помощью смарт-карты, и служба удаленных рабочих столов зависает

Эта проблема возникает, когда пользователи входят в систему компьютера Windows или Windows Server с обновлением KB4056446. Возможно, сначала пользователю удается войти в систему с помощью смарт-карты, но потом он получает сообщение об ошибке SCARD_E_NO_SERVICE. Удаленный компьютер может перестать отвечать.

Чтобы устранить эту проблему, перезапустите удаленный компьютер.

Чтобы устранить эту проблему, обновите систему на удаленном компьютере, установив соответствующее исправление:

Если удаленный компьютер заблокирован, пользователю нужно дважды ввести пароль

Эта проблема может возникать, когда пользователь пытается подключиться к удаленному рабочему столу под управлением Windows 10 версии 1709 в развертывании, где для подключений по протоколу RDP не требуется использовать NLA. Если в таком случае удаленный рабочий стол оказался заблокированным, пользователю нужно ввести свои учетные данные дважды при подключении.

Чтобы устранить эту проблему, обновите Windows 10 версии 1709 на соответствующем компьютере с использованием обновления за 30 августа 2018 г. — KB4343893 (ОС сборки 16299.637).

Пользователю не удается войти, при этом отображаются сообщения «Ошибка аутентификации» и «Защита CredSSP от атак с использованием криптографического оракула»

Когда пользователи пытаются войти с использованием любой версии Windows (начиная с Windows Vista с пакетом обновления 2 (SP2) или Windows Server 2008 с пакетом обновления 2 (SP2)), они получают отказ в доступе и такие сообщения:

Ошибка «Исправление шифрования CredSSP» ссылается на набор обновлений системы безопасности, выпущенный в марте, апреле и мае 2018 г. CredSSP — это поставщик проверки подлинности, который обрабатывает запросы проверки подлинности для других приложений. Обновление за 13 марта 2018 г., 3B и все последующие обновления подверглись эксплойту, когда злоумышленник мог передать учетные данные пользователя для выполнения кода в целевой системе.

В исходные обновления была добавлена поддержка нового объекта групповой политики «Защита от атак с использованием криптографического оракула», который может иметь следующие настройки:

Этот параметр не следует развертывать, пока все узлы поддержки в удаленном расположении не будут поддерживать последнюю версию.

В обновлении за 8 мая 2018 г. значение для параметра по умолчанию «Защита от атак с использованием криптографического оракула» изменилось с «Уязвимо» на «Устранено». После реализации этого изменения клиенты Удаленного рабочего стола, на которых были установлены обновления, не могут подключаться к серверам без этого обновления (или к обновленным серверам, которые еще не были перезапущены). Подробные сведения об обновлениях CredSSP см. в статье базы знаний KB4093492.

Чтобы устранить эту проблему, обновите и перезапустите все системы. Полный список обновлений и дополнительные сведения об уязвимостях см. в разделе CVE-2018-0886 | CredSSP Remote Code Execution Vulnerability (CVE-2018-0886 | Уязвимость CredSSP, допускающая удаленное выполнение кода).

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

Изменение этих групповых политик делает развертывание менее защищенным. Мы рекомендуем использовать их только временно (или вообще не использовать).

Дополнительные сведения о работе с групповой политикой см. в разделе Изменение блокирующего объекта групповой политики.

После обновления клиентских компьютеров некоторым пользователям приходится выполнять вход дважды

Если пользователи входят на Удаленный рабочий стол с помощью компьютера под управлением Windows 7 или Windows 10 версии 1709, им сразу же отображается запрос на повторный вход. Эта проблема возникает, если на клиентском компьютере установлены следующие обновления:

Чтобы устранить эту проблему, убедитесь, что на компьютерах, к которым подключаются пользователи, (а также серверы RDSH или RDVI) установлены все обновления в том числе за июнь 2018 г. К ним относятся следующие обновления:

Пользователям запрещается доступ к развертыванию, которое использует Remote Credential Guard с несколькими брокерами подключений к удаленному рабочему столу

Эта проблема возникает в развертываниях с высоким уровнем доступности, в которых используются не менее двух брокеров подключений к удаленному рабочему столу и Remote Credential Guard в Защитнике Windows. Пользователям не удается войти на удаленные рабочие столы.

Эта проблема связана с тем, что Remote Credential Guard использует Kerberos для проверки подлинности, а также запрещает использовать NTLM. Но в конфигурации с высоким уровнем доступности и балансировкой нагрузки брокеры подключений к удаленному рабочему столу не могут поддерживать операции Kerberos.

Если нужно использовать конфигурации с высоким уровнем доступности и балансировкой нагрузки брокеров подключений к удаленному рабочему столу, эту проблему можно устранить, отключив Remote Credential Guard. Дополнительные сведения об управлении Remote Credential Guard в Защитнике Windows см. в статье Protect Remote Desktop credentials with Windows Defender Remote Credential Guard (Защита учетных данных удаленного рабочего стола с помощью Remote Credential Guard в Защитнике Windows).

Источник

Учетные данные введены неверно или отсутствует связь с сервером выполняющим аутентификацию windows 7

Общие обсуждения

Доброго времени суток.

Учетные данные, использованные для подключения к xxx.xxx.xxx.xxx, недопустимы. Введите новые учетные данные.

Через Hyper-V входим без проблем.

Кто-то сможет подсказать откуда ростут проблемы?

Все ответы

Например, из-за отсутствия у учетной записи права на вход в систему через службу удаленных рабочих столов. Право это определяется политикой, при обычной настройке оно есть у групп Администраторы и Пользователи служб удаленных столов, кроме того в политике можно установить явный запрет на этот тип входа (проверьте всё это).

А вообще, для выяснения точной причины проблем со входом в систему включайте(через политику) аудит неудачных попыток входа в систему и смотрите журнал событий Безопасность.

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

Аудит пишет следующее:

Учетной записи не удалось выполнить вход в систему.

Учетная запись, которой не удалось выполнить вход:
ИД безопасности: NULL SID
Имя учетной записи: Администратор
Домен учетной записи: MOS1SKRIST1

Сведения об ошибке:
Причина ошибки: Неизвестное имя пользователя или неверный пароль.
Состояние: 0xC000006D
Подсостояние: 0xC0000064

Источник

Устранение неполадок с потоком рабочего стола ошибка недопустимых учетных данных

Симптом

Поток, который выполнял работу с учетной записью AAD, не проходит с кодами ошибок «InvalidConnectionCredentials» или «WindowsIdentityIncorrect».

Причина

Есть несколько причин, по которым при использовании учетной записи AAD может возникнуть такая ошибка:

Учетные данные учетной записи, введенные в подключение, могут не совпадать с данными на компьютере.

Устройство может не быть присоединенным к AAD (или гибридным присоединенным к AAD) для поддержки проверки подлинности AAD.

Возможно, учетная запись AAD не синхронизируется с компьютером.

Решение

Для начала убедитесь, что устройство подключено к AAD или присоединено к домену.

Откройте командную строку.

Запуск команды «dsregcmd/Status»

Проверка раздела «состояние устройства»

Убедитесь, что одно из значений «DomainJoined» или «AzureAdJoined» — «Да».

Если это не так, учетная запись AAD не может использоваться, если устройство не подключено, ознакомьтесь с документацией Майкрософт о том, как присоединиться к устройству.

Затем укажите учетную запись AAD для использования в конфигурации компьютера:

Откройте вкладку «Параметры» и выберите пункт «учетные записи».

Выберите «доступ к работе или учебным заведениям»

Убедитесь в том, что вы видите текст с сообщением «подключено к Azure AD». Учетная запись, на которую она сообщает, может использоваться в соединении.

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

Нажмите кнопку «сведения», чтобы выбрать подключение Azure AD в окне «доступ к работе или учебным заведениям».

Откроется экран, описывающий сведения о подключении и состояние синхронизации устройства. В конце этой кнопки появится кнопка «синхронизировать», а затем дождаться завершения этого процесса.

В четвертом — убедитесь в том, что настроенная учетная запись AAD может входить на устройство:

Попробуйте войти на компьютер с помощью учетной записи AAD, указанной в предыдущем шаге.

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

Наконец, убедитесь в том, что поток правильно настроен с использованием правильного имени пользователя и пароля. Это очень похоже на учетную запись на вашем компьютере.

Источник

Как узнать сетевой пароль своего компьютера и где его отключить?

Здравствуйте, дорогие друзья! Сегодняшняя тема будет для тех, кто пользуется компьютерными локальными сетями. При попытке подключения к любому ПК из группы необходимо постоянно прописывать специальный код – сетевой пароль. Бывают ситуации, когда эти данные забываются. Для такого случая я здесь – наша статья расскажет, как узнать сетевой пароль на самых популярных нынче ОС – Windows 7 и 10.

Где можно управлять паролями?

Например, вам нужно выполнить настройку общего доступа к принтеру в сети, а операционная система при этом запрашивает код доступа. Как узнать сетевой пароль своего компьютера, где вообще его можно найти?

Чтобы получить доступ ко всем паролям на ПК под Windows 7 и 10, нужно:

• Вызываем приложение «Выполнить» комбинацией кнопок Win + R;
• Прописываем команду netplwiz;
• Откроется окошко «Учетные записи пользователей»;
• Перейдите на вкладку «Дополнительно»;
• Нажмите «Управление паролями», чтобы получить доступ ко всем хранящимся на этом компьютере паролям.

Здесь можно удалить или поменять данные, добавить учетную запись.

Если у вас Windows XP, команда для «Выполнить» будет другая – control userpasswords2.

Как посмотреть?

Как узнать сетевой пароль от домашней группы (сам код), расскажу на примере Windows 10:

• В «Панели управления» режим просмотра ставим по категориям;
• Переходим в раздел «Сеть и Интернет»;
• Заходим в «Домашнюю группу»;
• В ее настройках ищем пункт «Показать или распечатать пароль домашней группы»;

• Переписываем нужные данные на листочек или запоминаем.

Пока писала, поняла, что у пользователей часто возникают проблемы при просмотре кода. Если у вас тоже не получается узнать пароль от локальной сети по моей инструкции, напишите в комментарии!

Возможная проблема

Бывает такое, что код не установлен, а система все равно его требует. Или выскакивает сообщение, что сетевой пароль указан неверно, хотя он точно правильный. Что делать в таком случае (на примере «семерки»):

• Чтобы запустить редактор локальной групповой политики, открываем «Выполнить» и прописываем gpedit.msc;
• Теперь поочередно заходим в разделы из следующего списка: «Конфигурация компьютера» – «Конфигурация Windows» – «Параметры безопасности» – «Локальные политики» – «Параметры безопасности» – «Сетевая безопасность: уровень проверки подлинности LAN Manager»;
• Отмечаем пункт «Отправлять LM и NTML…».

Этот способ решения проблемы работает не на всех версиях Windows 7!

Как убрать запрос на ввод кода?

Видео-инструкции по теме раздела смотрите тут:

Если в вашей домашней группе всего несколько устройств, и вы уверены в ее безопасности, ввод кода можно убрать. Как отключить запрос сетевого пароля на Windows 7/10, расскажу сейчас:

• Заходим в «Панель управления»;
• Режим просмотра ставим на «Крупные значки»;
• Переходим в раздел «Центр управления сетями…»;
• В дополнительных параметрах (раздел слева) ищем «Общий (текущий профиль)»;
• Ищем «Общий доступ к общедоступным папкам» и ставим галочку напротив «Включить общий доступ…»;
• Выбираем строку «Общий доступ с парольной защитой»;
• Отмечаем пункт «Отключить общий доступ с парольной защитой»;
• Сохраняем изменения соответствующей кнопкой.

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

Как не сохранять?

Можно сделать, чтобы операционная система не сохраняла коды. В какой ситуации это может пригодиться, не знаю, но такая инструкция есть (на примере Windows 7):

• В «Панели управления» зайдите в раздел «Администрирование»;
• Откройте «Локальная политика безопасности»;

• Нажмите «Параметры безопасности», перейдите на вкладку «Локальные политики», а затем в «Параметры безопасности»;
• В списке справа найдите строку «Сетевой доступ: не разрешать хранение паролей…», кликните ПКМ и перейдите в «Свойства»;

• На вкладке «Параметр локальной безопасности» поставьте галочку у пункта «Отключен»;

• После выполненных операций сохраните изменения кнопкой OK.

Вот такая сложная тема. На «десятке» узнать сетевой пароль намного проще, чем на «семерке». У Windows 7 много версий, и что работает на одной, для другой не подходит. Но у вас всегда есть команда WiFiGid, которая постарается решить любой вопрос. Спасибо за доверие!

Введите сетевые учетные данные в Windows 10 [ЛУЧШИЕ РЕШЕНИЯ]

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

Это достойная защита, но несколько пользователей сообщали об определенных проблемах, когда их просили ввести сетевые учетные данные в Windows 10.

Исправить проблемы с сетевыми учетными данными в Windows 10

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

• Введите сетевые учетные данные, имя пользователя или пароль неверны – . Эта ошибка может появиться, если ваш пароль неверен. Чтобы устранить эту проблему, попробуйте ввести учетные данные для входа в учетную запись Microsoft.
• Введите сетевые учетные данные Windows 8, 7 . Это сообщение может появляться практически в любой версии Windows. Если у вас возникла эта проблема в Windows 8 или 7, вы должны знать, что большинство наших решений могут быть применены к обеим этим системам.
• Сетевые учетные данные Windows 10 неверны . Иногда вы можете получить сообщение о том, что ваши учетные данные неверны. Чтобы решить эту проблему, вам, возможно, придется изменить свои политики безопасности.
• Ввод сетевых учетных данных запрещен . Иногда вы можете получить сообщение об отказе в доступе к сети вместе с запросом сетевых учетных данных. Чтобы устранить эту проблему, попробуйте отключить определенные службы и проверьте, помогает ли это.
• Введите общую папку с учетными данными сети – . Эта ошибка обычно возникает при попытке доступа к общей папке. Тем не менее, вы должны быть в состоянии решить проблему с помощью одного из наших решений.
• Сетевые учетные данные запрашивают пароль . Если вас продолжают спрашивать о сетевых учетных данных, возможно, проблема связана с вашей учетной записью. Просто создайте новую учетную запись пользователя и проверьте, решает ли это вашу проблему.

Решение 1. Проверьте, правильно ли назначены ваши IP-адреса.

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

По словам пользователей, ваш IP-адрес может быть установлен на автоматический, и это может иногда вызывать проблемы с сетевыми учетными данными, поэтому обязательно проверьте, установлены ли статические IP-адреса ваших сетевых устройств.

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

Возникли проблемы со статическим IP-адресом? Посмотрите здесь, чтобы решить это быстро.

Решение 2. Введите имя пользователя и пароль своей учетной записи Microsoft

Windows 10 в значительной степени зависит от вашей учетной записи Microsoft, и, поскольку вы можете использовать свою учетную запись Microsoft для входа в Windows 10, вы также можете использовать ее для доступа к другим сетевым устройствам в вашей локальной сети.

Пользователи сообщили, что вы можете исправить проблемы с сетевыми учетными данными, просто введя имя пользователя и пароль своей учетной записи Microsoft вместо имени пользователя и пароля своей локальной учетной записи.

Важно отметить, что многие проблемы в сети вызваны вредоносными программами, различными скриптами и ботами . Вы можете обезопасить себя, установив Cyberghost (77% флэш-продаж) , лидера на рынке VPN. Он защищает ваш компьютер от атак во время просмотра, маскирует и управляет вашим IP-адресом и блокирует любой нежелательный доступ.

Не можете войти в свою учетную запись Microsoft? Не паникуйте, у нас есть идеальное решение.

Решение 3. Введите имя компьютера в поле имени пользователя

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

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

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

Решение 4. Используйте имя пользователя и пароль для входа в Windows 10

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

Это ограничение в основном касается пользователей, которые входят в Windows 10 с помощью ПИН-кода, поэтому, если вам нужно получить доступ к другим файлам и поделиться ими с другими, вы можете временно прекратить использование ПИН-кода для входа в систему.

Если ваш PIN-код не работает должным образом, вы можете найти причину проблемы с помощью этой статьи.

Решение 5. Добавьте сетевые учетные данные другого ПК в Credentials Manager

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

После получения всей этой информации вы можете добавить ее в диспетчер учетных данных, выполнив следующие действия:

1. Нажмите Windows Key + S и введите учетные данные . Выберите в меню Диспетчер учетных данных .
   
2. Убедитесь, что выбран учетные данные Windows . Нажмите Добавить учетные данные Windows .
   
3. Введите имя компьютера, к которому вы хотите получить доступ, имя пользователя и пароль, связанные с этим именем пользователя.
   
4. Когда вы закончите, нажмите ОК .

После добавления информации о другом компьютере в диспетчер учетных данных вы сможете получить к нему доступ без проблем.

Вся необходимая информация о Диспетчере учетных данных находится здесь!

Решение 6 – Изменить расширенные настройки общего доступа

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

1. Нажмите значок сети на панели задач и выберите Настройки сети и Интернета .
   
2. Нажмите Параметры общего доступа .
   
3. Найдите свой сетевой профиль и перейдите в раздел Соединения домашней группы . Убедитесь, что выбрано Разрешить Windows управлять подключениями к домашней группе (рекомендуется) .
   
4. Нажмите Сохранить изменения .

Если ваша панель задач не работает, посмотрите здесь.

Несколько пользователей сообщили, что вы можете решить эту проблему, просто изменив следующие дополнительные параметры общего доступа:

1. Откройте окно Расширенные настройки общего доступа .
2. Теперь разверните раздел Все сети .
   
3. В разделе Общий доступ, защищенный паролем , выберите Отключить общий доступ, защищенный паролем . Нажмите кнопку Сохранить изменения .
   

После внесения этих изменений проблема должна быть полностью решена.

Решение 7 – Измените ваши политики безопасности

Иногда на вашем компьютере может появиться сообщение Введите сетевые учетные данные из-за политик безопасности. Однако вы можете легко изменить эти политики, если вы являетесь администратором на своем ПК.

Чтобы изменить политики безопасности, вам нужно сделать следующее:

1. Нажмите Windows Key + R и введите secpol.msc . Теперь нажмите Enter или нажмите ОК .
   
2. Когда откроется окно Локальная политика безопасности , на левой панели перейдите к Локальные политики> Параметры безопасности . На правой панели дважды нажмите Аккаунты: ограничить использование локальных учетных записей пустыми паролямитолько для входа в консоль .
   
3. Теперь выберите Отключено в меню и нажмите Применить и ОК .
   

После внесения этих изменений проблема с этим сообщением должна быть полностью решена, и все снова начнет работать.

Решение 8 – Изменить ваши услуги

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

1. Нажмите Windows Key + R и введите services.msc . Теперь нажмите Enter или нажмите ОК .
   
2. Когда откроется окно Службы , найдите Диспетчер учетных данных в списке и дважды щелкните его.
   
3. Откроется окно свойств. Установите для Тип запуска значение Отключено и нажмите кнопку Стоп , чтобы остановить службу. Теперь нажмите Применить и ОК .
   

Как только вы остановите службу, проверьте, решена ли проблема.

Нужна дополнительная информация об услугах и как их отключить? Посмотрите здесь.

Решение 9 – Установите частную связь

В случае, если вы не знакомы, есть два типа подключений, Public и Private, и каждый раз, когда вы подключаетесь к новой сети, вас попросят настроить сеть как Public или Private.

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

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

1. На панели задач нажмите значок сети и выберите Настройки сети и Интернета .
2. Теперь выберите Изменить свойства подключения .
   
3. Теперь установите для Сетевого профиля значение Личное .
   

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

Решение 10 – Создать новую учетную запись пользователя

Если у вас возникли проблемы с сообщением Введите сетевые учетные данные , вы можете решить проблему, просто создав новую учетную запись пользователя. Это довольно просто, и вы можете сделать это, выполнив следующие действия:

1. Откройте Настройки приложения . Вы можете сделать это быстро с помощью сочетания клавиш Windows Key + I .
2. Когда откроется Приложение настроек , перейдите в раздел Аккаунты .
   
3. Выберите Семья и другие люди на левой панели. Теперь нажмите Добавить кого-то еще на этот компьютер .
   
4. Выберите У меня нет информации для входа этого человека .
   
5. Выберите Добавить пользователя без учетной записи Microsoft .
   
6. Введите нужное имя пользователя и нажмите кнопку Далее , чтобы продолжить.
   

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

Если у вас возникли проблемы с доступом к приложению «Настройки», вы можете посмотреть здесь. Если срок действия вашей учетной записи истек, выполните следующие действия, чтобы возобновить работу.

Решение 11. Изменение параметров учетной записи пользователя

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

1. Нажмите Windows Key + R и введите netplwiz . Теперь нажмите Enter или нажмите ОК .
   
2. Снимите флажок Пользователи должны ввести имя пользователя и пароль для использования этого компьютера . Теперь нажмите ОК и Применить , чтобы сохранить изменения.
   
3. Перезагрузите компьютер, чтобы изменения вступили в силу.
4. После повторного входа повторите те же шаги, но на этот раз включите Пользователи должны ввести параметр имени пользователя и пароля и сохранить изменения.

После этого проблема должна быть полностью решена, и настройка защиты паролем будет работать как надо.

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

Если у вас есть еще вопросы, не стесняйтесь оставлять их в разделе комментариев ниже.

ЧИТАЙТЕ ТАКЖЕ

• Как защитить устройство Windows 10 в общедоступной сети Wi-Fi
• Исправлено: Windows 10 не может подключиться к этой сети
• Исправлено: сетевой протокол отсутствует в Windows 10
• Исправлено: беспроводная сеть показывает «Не подключен», но Интернет работает
• Исправлено: код ошибки «0x80070035» во внутренней сети в Windows

В WIndows за кэширование отвечает параметр реестра CashedLogonsCount, найти его можно по пути.

Смысл данного параметра, очень простой, все сводится к тому, что он задает количество уникальных пользователей, у которых данные можно хранить локально. По дефолту, это значение 10. Простой пример если у вас уже авторизировались 10 человек, то их хэши будут храниться локально, если 11 авторизировались то он пере затрет первого и так далее.

Если есть необходимость, поменять это значение, то групповая политика в помощь. Переходим в оснастку групповой политики, создаем либо новую или меняем на уровне домена.

Для примера ее нужно распространить на весь домен, а по умолчанию в AD создается Default Domain Policy политика, правым кликом по ней и выбираем изменить.

Переходим в раздел
Нужно найти параметр Интерактивный вход в систему: количество предыдущих подключений к кэшу, по сути это и есть CashedLogonsCount.

Сам параметр можно задать от 0 до 50.

Если выставить 0, то полностью запретите локальное кэширование, это правильно с точки зрения безопасности.

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

С точки зрения безопасности, правильно отключать данное кэширование, так как у злоумышленника есть возможность использовать данный метод, для взлома. Но есть исключения из правил, это пользователи мобильных устройств, так например для человека, который часто ездит в командировки, данное кэширование просто необходимо. Теперь вы знаете, как войти в компьютер при сообщении отсутствуют серверы которые могли бы обработать запрос на вход в сеть.
———

В благодарность за информацию посмотрите рекламу, может что-то заинтересует) Отключите антибаннер в вашем браузере.

Безопасность windows учетные данные введены неверно или отсутствует связь с сервером

Запарился с одной проблемой, помогите, а то кирдык мне наступает (

Пришел две недели назад в новую организацию. Есть домен с одним КД (server на SBS 2003), также есть сетка с обычной рабочей группой. Практически все ХП проф. версия, есть пара ноутбуков с хоум версией (они мне не позволили всех присоединить к домену). Раньше из внешней сети люди заходили на шары бухгалтерского компа через учетку гостя (ИмяДоменагость). Сейчас при попытке зайти на комп Buh в домене из внешней сети выдается сообщение:

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

С каких пор и из-за чего перестало выходить окно ввода имени пользователя и пароля неизвестно.

На другие компьютеры в домене с внешней сети доступ есть, пинг на Buh проходит, с Buh-а есть доступ и в домен и во внешнюю сеть.

http://support.microsoft.com/kb/292822/ru
+ кучу того что в гугле нашел. вроде все проверил: адм. шары на бухе есть,в администировании: «доступ по сети» включает группу все и гость, отказ в доступе по сети-никого. Голова пухнет уже

DNS сервер один на компе Server, WINS-а нет.

на Buh-е поиск пользователей происходит только в контейнере Buh а не в домене, только что заметил.

Сообщения: 131
Благодарности: 13

» width=»100%» style=»BORDER-RIGHT: #719bd9 1px solid; BORDER-LEFT: #719bd9 1px solid; BORDER-BOTTOM: #719bd9 1px solid» cellpadding=»6″ cellspacing=»0″ border=»0″>Источник

Безопасность windows учетные данные введены неверно или отсутствует связь с сервером

Всем привет, сегодня расскажу как можно попасть на компьютер в домене Adctive Directory, у которого при попытке залогиниться выскакивает сообщение отсутствуют серверы которые могли бы обработать запрос на вход в сеть, в итоге вы не можете на него попасть и естественно выполнить задачу. Бывает такое, при первой попытке авторизации, или же после того как вы сходили на обед, а возвратившись с него вы обнаружили свою проблему. Думаю для начинающих системных администраторов это будет полезно, будет большее понимание как это работает и как это чинить.

Что означает отсутствуют серверы обработки

И так у меня есть сервер с установленной на него операционной системой Windows Server 2012 R2, При попытке на него попасть у меня выскочило сообщение, отсутствуют серверы которые могли бы обработать запрос на вход в сеть. Смысл его заключается в том, что при попытке проверить ваш логин и пароль, серверу не удалось связаться с контроллером домена.

Как работает авторизация в Active Directory

У вас есть учетная запись в домене, вы пытаетесь войти на сервер, локально или удаленно, тут разницы нет. Сервер передает эти данные на ближайший контроллер домена, чтобы удостовериться есть ли такой пользователь или нет. Если по какой то причине, сервер не может установить связь с DC, то вы получаете отказ во входе. Если еще детальнее, то в Windows есть библиотека GINA (Graphical Identification and Authentication), она видит, что вы ввели логин и пароль, после чего она обращается к контроллеру Active Directory. За процесс аутентификации пользователя или компьютера по сети, отвечают два протокола NTLM (библиотека MSV1_0.dll) и Kerberos (библиотека Kerberos.dll). Ели бы у нас была не AD, то мы бы обращались к службе LSA (Local Security Authority), а та уже в свою очередь направила бы запрос в локальную базу данных SAM-базу для аутентификации пользователя а тот уже возвращает процессу Winlogon токен доступа.

Причины этого всего это ошибка в сетевом соединении между вашим сервером и контроллером домена и как вывод нужно проверить

Заходим на сервер когда отсутствует связь с сервером

Сразу отмечу, что данный метод будет работать только если вы до этого логинились на данный сервер, когда вы до этого входили в систему, то ваши данные были помещены в хэш локального компьютера, это поможет обойти проблему, при которой вы получили отсутствуют серверы которые могли бы обработать запрос и позволит войти. Хочу отметить, что в хэш кладется не сам логин и пароль, а результат их проверки, а если совсем точно, то хэш пароля, обработанный специальным методом salt. salt генерируется на основе имени пользователя. Сами данные лежат в ветке реестра HKLMSECURITYCache к которому имеет доступ только система.

В WIndows за кэширование отвечает параметр реестра CashedLogonsCount, найти его можно по пути

Смысл данного параметра, очень простой, все сводится к тому, что он задает количество уникальных пользователей, у которых данные можно хранить локально. По дефолту, это значение 10. Простой пример если у вас уже залогинилось 10 человек, то их хэши будут храниться локально, если 11 залогиниться то он пере затрет первого и так далее.

Если есть необходимость, поменять это значение, то групповая политика нам в помощь. Переходим в оснастку групповой политики, создаем либо новую или меняем ну уровне домена

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

Переходим в раздел

Тут вам нужно найти параметр Интерактивный вход в систему: количество предыдущих подключений к кэшу, по сути это и есть CashedLogonsCount, Сам параметр можно задать от 0 до 50. Если выставите 0, то полностью запретите локальное кэширование, это правильно с точки зрения безопасности. но не даст вам войти на компьютер при отсутствии доступа к контроллеру и покажет вам отсутствуют серверы которые могли бы обработать запрос.

В английской версии это

С точки зрения безопасности, правильно отключать данное кэширование. так как у злоумышленника есть возможность использовать данный метод, для взлома. Но есть исключения из правил, это пользователи мобильных устройств, так например для человека, который часто ездит в командировки, данное кэширование просто необходимо. Теперь вы знаете, как войти в компьютер при сообщении отсутствуют серверы которые могли бы обработать запрос на вход в сеть. Думаю вам было полезно это узнать.

Источник

Безопасность windows учетные данные введены неверно или отсутствует связь с сервером

Вопрос

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

В домен ввести ПК тоже не получается:»Не удается подключится к контроллеру домена Active Directory для домена. По результатам диагностики dcdiag /v полагаю, что слетели службы каталогов. Результат прилагаю ниже. Подскажите пожалуйста каким образом можно восстановить контроллер, бэкап контроллера не делался в сети один контроллер. Может имеются какие утилиты тестирования и восстановления?

Диагностика сервера каталогов

Выполнение начальной настройки:
Выполняется попытка поиска основного сервера.
* Проверка, является ли локальный компьютер dc сервером каталогов.
Основной сервер = dc
* Подключение к службе каталога на сервере dc.
* Определен лес AD.
Collecting AD specific global data
* Сбор сведений о сайте.
Calling ldap_search_init_page(hld,CN=Sites,CN=Configuration,DC=xxx,DC=lan,LDA
P_SCOPE_SUBTREE,(objectCategory=ntDSSiteSettings).
The previous call succeeded
Iterating through the sites
Looking at base site object: CN=NTDS Site Settings,CN=Default-First-Site-Name
,CN=Sites,CN=Configuration,DC=xxx,DC=lan
Getting ISTG and options for the site
* Выполнение идентификации всех серверов.
Calling ldap_search_init_page(hld,CN=Sites,CN=Configuration,DC=xxx,DC=lan,LDA
P_SCOPE_SUBTREE,(objectClass=ntDSDsa).
The previous call succeeded.
The previous call succeeded
Iterating through the list of servers
Getting information for the server CN=NTDS Settings,CN=DC,CN=Servers,CN=Defau
lt-First-Site-Name,CN=Sites,CN=Configuration,DC=xxx,DC=lan
objectGuid obtained
InvocationID obtained
dnsHostname obtained
site info obtained
All the info for the server collected
* Идентификация всех перекрестных ссылок NC.
* Найдено 1 DC (контроллеров домена). Проверка 1 из них.
Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

Выполнение основных проверок

Сервер проверки: Default-First-Site-NameDC
Пропуск всех проверок, так как сервер DC не отвечает на запросы службы
каталогов.
Проверка пропущена по запросу пользователя: Advertising
Проверка пропущена по запросу пользователя: CheckSecurityError
Проверка пропущена по запросу пользователя: CutoffServers
Проверка пропущена по запросу пользователя: FrsEvent
Проверка пропущена по запросу пользователя: DFSREvent
Проверка пропущена по запросу пользователя: SysVolCheck
Проверка пропущена по запросу пользователя: KccEvent
Проверка пропущена по запросу пользователя: KnowsOfRoleHolders
Проверка пропущена по запросу пользователя: MachineAccount
Проверка пропущена по запросу пользователя: NCSecDesc
Проверка пропущена по запросу пользователя: NetLogons
Проверка пропущена по запросу пользователя: ObjectsReplicated
Проверка пропущена по запросу пользователя: OutboundSecureChannels
Проверка пропущена по запросу пользователя: Replications
Проверка пропущена по запросу пользователя: RidManager
Проверка пропущена по запросу пользователя: Services
Проверка пропущена по запросу пользователя: SystemLog
Проверка пропущена по запросу пользователя: Topology
Проверка пропущена по запросу пользователя: VerifyEnterpriseReferences
Проверка пропущена по запросу пользователя: VerifyReferences
Проверка пропущена по запросу пользователя: VerifyReplicas

Проверка пропущена по запросу пользователя: DNS
Проверка пропущена по запросу пользователя: DNS

Выполнение проверок разделов на: xxx
Запуск проверки: CheckSDRefDom
. xxx- пройдена проверка CheckSDRefDom
Запуск проверки: CrossRefValidation
. xxx- пройдена проверка CrossRefValidation

Источник

Безопасность windows учетные данные введены неверно или отсутствует связь с сервером

Вопрос

Есть несколько серверов 2008R2.

Ответы

Согласно сторонним форумам, в качестве временного решения помогает в локальной политике применить:

Это изменение должно помочь в случае установки обновления KB3002657, как временное решение.

P.S. так пишут на сторонних форумах.

Все ответы

Этого обновления я в списке не нашел, хотя сегодня поставил ВСЕ обновления на все сервера. и не могу точно сказать с какого момента это произошло, потому как сервера ввел в домен только вчера. Но при выводе серверов из домена, подключение работает нормально. И к тому же, на сам DC я захожу, по RDP.

И так же я могу к ним подключиться под учеткой локального админа, а доменного нет.

Спасибо, перед обращением сюда я читал эти статьи, они не к моему случаю. У меня нет проблем с сохранением учетных данных, к тому же я создавал разные учетки с правами доменных админов и пытался подключаться с разных компов, со всех учеток та же ситуация..

а логи выдают вот это

Похоже на проблему, которая воспроизводиться после установки обновления KB3002657

P.S. в качестве временного решения, выше указано статье указывают на удаление обновления KB3002657 со всех контроллеров домена.

Похоже на проблему, которая воспроизводиться после установки обновления KB3002657

P.S. в качестве временного решения, выше указано статье указывают на удаление обновления KB3002657 со всех контроллеров домена.

Удаление этого КВ не помогло (((

Очень похожая проблема

На другие сервера домена захожу под любой админской учеткой

Захожу под локальным админом. Удаляю профили пользователей под которыми не пускает. не помогло.

Удаляю обновление KB3002657. не помогло

Удаляю все установленные сегодня обновления. ждем-с

Источник

Пользователь не может выполнить аутентификацию или должен выполнить ее дважды User can’t authenticate or must authenticate twice

В этой статье описаны некоторые причины проблем с аутентификацией пользователей. This article addresses several issues that can cause problems that affect user authentication.

Отказано в доступе (ограничение по типу входа в систему) Access denied, restricted type of logon

В этом случае пользователь Windows 10, который пытается подключиться к компьютерам с Windows 10 или Windows Server 2016, получит отказ в доступе со следующим сообщением: In this situation, a Windows 10 user attempting to connect to Windows 10 or Windows Server 2016 computers is denied access with the following message:

Подключение к удаленному рабочему столу Remote Desktop Connection:
Системный администратор ограничил типы входа в систему (сетевой или интерактивный), которые можно использовать. The system administrator has restricted the type of logon (network or interactive) that you may use. Обратитесь за помощью к системному администратору или в службу технической поддержки. For assistance, contact your system administrator or technical support.

Эта проблема возникает, если для подключения к удаленному рабочему столу требуется пройти проверку подлинности на уровне сети (NLA), но пользователь не является членом группы Пользователи удаленного рабочего стола. This issue occurs when Network Level Authentication (NLA) is required for RDP connections, and the user is not a member of the Remote Desktop Users group. Она также может возникать, если группе Пользователи удаленного рабочего стола не назначено право пользователя Доступ к компьютеру из сети. It can also occur if the Remote Desktop Users group has not been assigned to the Access this computer from the network user right.

Чтобы решить эту проблему, выполните одно из указанных ниже действий. To solve this issue, do one of the following things:

Изменение членства пользователя в группах или назначенных ему прав Modify the user’s group membership or user rights assignment

Если эта проблема затрагивает одного пользователя, наиболее простым решением будет добавить этого пользователя в группу Пользователи удаленного рабочего стола. If this issue affects a single user, the most straightforward solution to this issue is to add the user to the Remote Desktop Users group.

Если пользователь уже является членом этой группы (или если проблема возникает у нескольких членов группы), проверьте конфигурацию прав пользователей на удаленном компьютере Windows 10 или Windows Server 2016. If the user is already a member of this group (or if multiple group members have the same problem), check the user rights configuration on the remote Windows 10 or Windows Server 2016 computer.

Отказано в доступе (удаленный вызов к базе данных SAM отклонен) Access denied, A remote call to the SAM database has been denied

Такое поведение обычно возникает, если контроллеры домена работают под управлением Windows Server 2016 или более поздней версии, а пользователи пытаются подключиться с помощью настраиваемого приложения для подключения. This behavior is most likely to occur if your domain controllers are running Windows Server 2016 or later, and users attempt to connect by using a customized connection app. В частности, отказ в доступе получат приложения, которым требуется доступ к сведениям профиля пользователя в Active Directory. In particular, applications that access the user’s profile information in Active Directory will be denied access.

Такое поведение обусловлено изменением в Windows. This behavior results from a change to Windows. В Windows Server 2012 R2 и более ранних версиях, когда пользователь выполняет вход на удаленный рабочий стол, диспетчер удаленных подключений (RCM) обращается к контроллеру домена (DC), чтобы запросить конфигурацию, относящуюся к удаленному рабочему столу, в объекте пользователя в доменных службах Active Directory (AD DS). In Windows Server 2012 R2 and earlier versions, when a user signs in to a remote desktop, the Remote Connection Manager (RCM) contacts the domain controller (DC) to query the configurations that are specific to Remote Desktop on the user object in Active Directory Domain Services (AD DS). Эта информация отображается на вкладке «Профиль служб удаленных рабочих столов» в окне свойств объекта пользователя в оснастке MMC «Пользователи и компьютеры Active Directory». This information is displayed in the Remote Desktop Services Profile tab of a user’s object properties in the Active Directory Users and Computers MMC snap-in.

Начиная с Windows Server 2016 RCM больше не запрашивает объект пользователя в AD DS. Starting in Windows Server 2016, RCM no longer queries the user’s object in AD DS. Если требуется, чтобы RCM обращался к AD DS из-за того, что вы используете атрибуты служб удаленных рабочих столов, вам нужно вручную разрешить отправку запросов. If you need RCM to query AD DS because you’re using Remote Desktop Services attributes, you must manually enable the query.

Внимательно выполните действия, описанные в этом разделе. Follow the steps in this section carefully. Неправильное изменение реестра может привести к серьезным проблемам. Serious problems might occur if you modify the registry incorrectly. Перед внесением изменений создайте резервную копию реестра для его восстановления в случае возникновения проблем. Before you modify it, back up the registry for restoration in case problems occur.

Чтобы разрешить прежнее поведение RCM на сервере узла сеансов удаленных рабочих столов, настройте следующие записи реестра и перезапустите службу Службы удаленных рабочих столов: To enable the legacy RCM behavior on a RD Session Host server, configure the following registry entries, and then restart the Remote Desktop Services service:

Чтобы разрешить устаревшее поведение RCM на сервере, отличающемся от сервера RDSH, настройте эти записи реестра и следующую дополнительную запись (затем перезапустите службу). To enable the legacy RCM behavior on a server other than a RD Session Host server, configure these registry entries and the following additional registry entry (and then restart the service):

Дополнительные сведения об этом поведении см. в статье базы знаний № 3200967 Changes to Remote Connection Manager in Windows Server (Внесение изменений в диспетчер удаленных подключений в Windows Server). For more information about this behavior, see KB 3200967 Changes to Remote Connection Manager in Windows Server.

Пользователю не удается выполнить вход с помощью смарт-карты User can’t sign in using a smart card

В этом разделе рассматриваются три типичных сценария, когда пользователь не может войти на удаленный рабочий стол с помощью смарт-карты. This section addresses three common scenarios where a user can’t sign in to a remote desktop using a smart card.

Не удается войти в систему с помощью смарт-карты в филиале с контроллером домена только для чтения (RODC) Can’t sign in with a smart card in a branch office with a read-only domain controller (RODC)

Эта проблема возникает в развертываниях, в которых задействован сервер RDSH на сайте филиала, где используется RODC. This issue occurs in deployments that include an RDSH server at a branch site that uses a RODC. Сервер RDSH размещен в корневом домене. The RDSH server is hosted in the root domain. Пользователи на сайте филиала относятся к дочернему домену и используют смарт-карты для проверки подлинности. Users at the branch site belong to a child domain, and use smart cards for authentication. Контроллер домена RODC настроен на кэширование паролей и принадлежит к группе с разрешением реплицировать пароли RODC. The RODC is configured to cache user passwords (the RODC belongs to the Allowed RODC Password Replication Group). Когда пользователи пытаются выполнить вход в сеанс на сервере RDSH, они получают сообщение, например: «Неудачная попытка входа в систему. When users try to sign in to sessions on the RDSH server, they receive messages such as «The attempted logon is invalid. Указано неверное имя пользователя или другие неверные личные данные.» This is either due to a bad username or authentication information.»

Эта проблема связана с тем, как корневой контроллер домена и RDOC управляют шифрованием учетных данных пользователей. This issue is caused by how the root DC and the RDOC manage user credential encryption. Корневой контроллер домена использует ключ шифрования, чтобы зашифровать учетные данные, а RODC предоставляет ключ расшифровки клиенту. The root DC uses an encryption key to encrypt the credentials and the RODC gives the client the decryption key. Если пользователь получает ошибку «Недопустимо», значит два ключа не совпадают. When a user receives the «invalid» error, that means the two keys don’t match.

Чтобы решить эту проблему, выполните одно из указанных ниже действий: To work around this issue, try one of the following things:

Учтите, что эти решения предполагают наличие компромисса между производительностью и уровнем безопасности. Be advised that all of these solutions require compromises in either performance or security level.

Пользователь не может войти на компьютер с Windows Server 2008 с пакетом обновления 2 (SP2) с помощью смарт-карты User can’t sign in to a Windows Server 2008 SP2 computer using a smart card

Эта проблема возникает, когда пользователи выполняют вход в систему компьютера Windows Server 2008 с пакетом обновления 2 (SP2), на котором установлено обновление KB4093227 (2018.4B). This issue occurs when users sign in to a Windows Server 2008 SP2 computer that has been updated with KB4093227 (2018.4B). Когда пользователи пытаются выполнить вход с помощью смарт-карты, они получают отказ в доступе с сообщениями, например: «Действительные сертификаты не найдены. When users attempt to sign in using a smart card, they are denied access with messages such as «No valid certificates found. Убедитесь, что эта карта вставлена правильно и плотно сидит в разъеме». Check that the card is inserted correctly and fits tightly.» В то же время на компьютере Windows Server регистрируется событие приложения с сообщением «При получении цифрового сертификата с вставленной смарт-карты произошла ошибка: At the same time, the Windows Server computer records the Application event «An error occurred while retrieving a digital certificate from the inserted smart card. неправильная подпись.» Invalid Signature.»

Чтобы устранить эту проблему, обновите на компьютере ОС Windows Server до повторного выпуска 2018.06 B (обновление KB4093227). См. статью Description of the security update for the Windows Remote Desktop Protocol (RDP) denial of service vulnerability in Windows Server 2008: April 10, 2018 (Описание обновления системы безопасности для защиты протокола RDP в Windows от уязвимости службы в Windows Server 2008 (10 апреля 2018 г.). To resolve this issue, update the Windows Server computer with the 2018.06 B re-release of KB 4093227, Description of the security update for the Windows Remote Desktop Protocol (RDP) denial of service vulnerability in Windows Server 2008: April 10, 2018.

Не удается оставаться в системе, вход в которую выполнен с помощью смарт-карты, и служба удаленных рабочих столов зависает Can’t stay signed in with a smart card and Remote Desktop Services service hangs

Эта проблема возникает, когда пользователи входят в систему компьютера Windows или Windows Server с обновлением KB4056446. This issue occurs when users sign in to a Windows or Windows Server computer that has been updated with KB 4056446. Возможно, сначала пользователю удается войти в систему с помощью смарт-карты, но потом он получает сообщение об ошибке SCARD_E_NO_SERVICE. At first, the user may be able to sign in to the system by using a smart card, but then receives a «SCARD_E_NO_SERVICE» error message. Удаленный компьютер может перестать отвечать. The remote computer may become unresponsive.

Чтобы устранить эту проблему, перезапустите удаленный компьютер. To work around this issue, restart the remote computer.

Чтобы устранить эту проблему, обновите систему на удаленном компьютере, установив соответствующее исправление: To resolve this issue, update the remote computer with the appropriate fix:

Если удаленный компьютер заблокирован, пользователю нужно дважды ввести пароль If the remote PC is locked, the user needs to enter a password twice

Эта проблема может возникать, когда пользователь пытается подключиться к удаленному рабочему столу под управлением Windows 10 версии 1709 в развертывании, где для подключений по протоколу RDP не требуется использовать NLA. This issue may occur when a user attempts to connect to a remote desktop running Windows 10 version 1709 in a deployment in which RDP connections don’t require NLA. Если в таком случае удаленный рабочий стол оказался заблокированным, пользователю нужно ввести свои учетные данные дважды при подключении. Under these conditions, if the remote desktop has been locked, the user needs to enter their credentials twice when connecting.

Чтобы устранить эту проблему, обновите Windows 10 версии 1709 на соответствующем компьютере с использованием обновления за 30 августа 2018 г. — KB4343893 (ОС сборки 16299.637). To resolve this issue, update the Windows 10 version 1709 computer with KB 4343893, August 30, 2018—KB4343893 (OS Build 16299.637).

Пользователю не удается войти, при этом отображаются сообщения «Ошибка аутентификации» и «Защита CredSSP от атак с использованием криптографического оракула» User can’t sign in and receives «authentication error» and «CredSSP encryption oracle remediation» messages

Когда пользователи пытаются войти с использованием любой версии Windows (начиная с Windows Vista с пакетом обновления 2 (SP2) или Windows Server 2008 с пакетом обновления 2 (SP2)), они получают отказ в доступе и такие сообщения: When users try to sign in using any version of Windows from Windows Vista SP2 and later versions or Windows Server 2008 SP2 and later versions, they’re denied access and recieve messages like these:

Ошибка «Исправление шифрования CredSSP» ссылается на набор обновлений системы безопасности, выпущенный в марте, апреле и мае 2018 г. «CredSSP encryption oracle remediation» refers to a set of security updates released in March, April, and May of 2018. CredSSP — это поставщик проверки подлинности, который обрабатывает запросы проверки подлинности для других приложений. CredSSP is an authentication provider that processes authentication requests for other applications. Обновление за 13 марта 2018 г., 3B и все последующие обновления подверглись эксплойту, когда злоумышленник мог передать учетные данные пользователя для выполнения кода в целевой системе. The March 13, 2018, «3B» and subsequent updates addressed an exploit in which an attacker could relay user credentials to execute code on the target system.

В исходные обновления была добавлена поддержка нового объекта групповой политики «Защита от атак с использованием криптографического оракула», который может иметь следующие настройки: The initial updates added support for a new Group Policy Object, Encryption Oracle Remediation, that has the following possible settings:

Этот параметр не следует развертывать, пока все узлы поддержки в удаленном расположении не будут поддерживать последнюю версию. This setting should not be deployed until all remote hosts support the newest version.

В обновлении за 8 мая 2018 г. значение для параметра по умолчанию «Защита от атак с использованием криптографического оракула» изменилось с «Уязвимо» на «Устранено». The May 8, 2018 update changed the default Encryption Oracle Remediation setting from Vulnerable to Mitigated. После реализации этого изменения клиенты Удаленного рабочего стола, на которых были установлены обновления, не могут подключаться к серверам без этого обновления (или к обновленным серверам, которые еще не были перезапущены). With this change in place, Remote Desktop clients that have the updates can’t connect to servers that don’t have them (or updated servers that have not been restarted). Подробные сведения об обновлениях CredSSP см. в статье базы знаний KB4093492. For more information about the CredSSP updates, see KB 4093492.

Чтобы устранить эту проблему, обновите и перезапустите все системы. To resolve this issue, update and restart all systems. Полный список обновлений и дополнительные сведения об уязвимостях см. в разделе CVE-2018-0886 | CredSSP Remote Code Execution Vulnerability (CVE-2018-0886 | Уязвимость CredSSP, допускающая удаленное выполнение кода). For a full list of updates and more information about the vulnerabilities, see CVE-2018-0886 | CredSSP Remote Code Execution Vulnerability.

Чтобы устранить эту проблему до завершения обновления, просмотрите список допустимых типов подключений в обновлении KB4093492. To work around this issue until the updates are complete, check KB 4093492 for allowed types of connections. Если нет других осуществимых альтернатив, можете попробовать один из следующих методов: If there are no feasible alternatives you may consider one of the following methods:

Изменение этих групповых политик делает развертывание менее защищенным. Changing these group policies reduces your deployment’s security. Мы рекомендуем использовать их только временно (или вообще не использовать). We recommend you only use them temporarily, if at all.

Дополнительные сведения о работе с групповой политикой см. в разделе Изменение блокирующего объекта групповой политики. For more information about working with group policy, see Modifying a blocking GPO.

После обновления клиентских компьютеров некоторым пользователям приходится выполнять вход дважды After you update client computers, some users need to sign in twice

Если пользователи входят на Удаленный рабочий стол с помощью компьютера под управлением Windows 7 или Windows 10 версии 1709, им сразу же отображается запрос на повторный вход. When users sign in to Remote Desktop using a computer running Windows 7 or Windows 10, version 1709, they immediately see a second sign-in prompt. Эта проблема возникает, если на клиентском компьютере установлены следующие обновления: This issue happens if the client computer has the following updates:

Чтобы устранить эту проблему, убедитесь, что на компьютерах, к которым подключаются пользователи, (а также серверы RDSH или RDVI) установлены все обновления в том числе за июнь 2018 г. To resolve this issue, ensure that the computers that the users want to connect to (as well as RDSH or RDVI servers) are fully updated through June, 2018. К ним относятся следующие обновления: This includes the following updates:

Пользователям запрещается доступ к развертыванию, которое использует Remote Credential Guard с несколькими брокерами подключений к удаленному рабочему столу Users are denied access on a deployment that uses Remote Credential Guard with multiple RD Connection Brokers

Эта проблема возникает в развертываниях с высоким уровнем доступности, в которых используются не менее двух брокеров подключений к удаленному рабочему столу и Remote Credential Guard в Защитнике Windows. This issue occurs in high-availability deployments that use two or more Remote Desktop Connection Brokers, if Windows Defender Remote Credential Guard is in use. Пользователям не удается войти на удаленные рабочие столы. Users can’t sign in to remote desktops.

Эта проблема связана с тем, что Remote Credential Guard использует Kerberos для проверки подлинности, а также запрещает использовать NTLM. This issue occurs because Remote Credential Guard uses Kerberos for authentication, and restricts NTLM. Но в конфигурации с высоким уровнем доступности и балансировкой нагрузки брокеры подключений к удаленному рабочему столу не могут поддерживать операции Kerberos. However, in a high-availability configuration with load balancing, the RD Connection Brokers can’t support Kerberos operations.

Если нужно использовать конфигурации с высоким уровнем доступности и балансировкой нагрузки брокеров подключений к удаленному рабочему столу, эту проблему можно устранить, отключив Remote Credential Guard. If you need to use a high-availability configuration with load-balanced RD Connection Brokers, you can work around this issue by disabling Remote Credential Guard. Дополнительные сведения об управлении Remote Credential Guard в Защитнике Windows см. в статье Protect Remote Desktop credentials with Windows Defender Remote Credential Guard (Защита учетных данных удаленного рабочего стола с помощью Remote Credential Guard в Защитнике Windows). For more information about how to manage Windows Defender Remote Credential Guard, see Protect Remote Desktop credentials with Windows Defender Remote Credential Guard.

Источник

Видео

Rdp учетные данные использованные для подключения недопустимы

При попытке подключения по RDP с компьютера, под управлением Windows 10, НЕ входящего в домен, к компьютеру, находящемуся в домене, с использованием любой смарт-карты, включая Рутокен, возникает ошибка «Недопустимые учетные данные. Учетные данные, использованные для подключения к xxx.xxx.xx.xxx, недопустимы. Введите новые учетные данные. Попытка входа в систему неудачна».

Проблема начала возникать с 11 октября после установки обновления Microsoft KB5006670.

Установку нужно производить на той машине с которой производится попытка подключения по RDP (клиентская машина).

1. В зависимости от версии операционной системы, выберите установочный файл:

2. Откройте строку «Выполнить» (сочетание клавиш Win+R) и наберите gpedit.msc

3. В разделе «Административные шаблоны» должен появиться раздел KB5004296 с подразделом с названием версии ОС.

4. Запускаем его двойным щелчком и переводим его в состояние «Отключено».

5. После произведения настроек перезагрузите компьютер.

Источник

Rdp учетные данные использованные для подключения недопустимы

Общие обсуждения

Доброго времени суток.

Столкнулись с такой проблемой — при подключение к виртуальному серверу, через RDP, по внешнему IP, выдает следующую ошибку:

Учетные данные, использованные для подключения к xxx.xxx.xxx.xxx, недопустимы. Введите новые учетные данные.

Через Hyper-V входим без проблем.

Кто-то сможет подсказать откуда ростут проблемы?

• Изменен тип Petko Krushev Microsoft contingent staff, Moderator 4 сентября 2014 г. 6:12

Все ответы

Например, из-за отсутствия у учетной записи права на вход в систему через службу удаленных рабочих столов. Право это определяется политикой, при обычной настройке оно есть у групп Администраторы и Пользователи служб удаленных столов, кроме того в политике можно установить явный запрет на этот тип входа (проверьте всё это).

А вообще, для выяснения точной причины проблем со входом в систему включайте(через политику) аудит неудачных попыток входа в систему и смотрите журнал событий Безопасность.

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

Аудит пишет следующее:

Учетной записи не удалось выполнить вход в систему.

Субъект:
ИД безопасности: NULL SID
Имя учетной записи: —
Домен учетной записи: —
Код входа: 0x0

Учетная запись, которой не удалось выполнить вход:
ИД безопасности: NULL SID
Имя учетной записи: Администратор
Домен учетной записи: MOS1SKRIST1

Сведения об ошибке:
Причина ошибки: Неизвестное имя пользователя или неверный пароль.
Состояние: 0xC000006D
Подсостояние: 0xC0000064

Сведения о процессе:
Идентификатор процесса вызывающей стороны: 0x0
Имя процесса вызывающей стороны: —

Сведения о сети:
Имя рабочей станции: WORKSHOP
Сетевой адрес источника: —
Порт источника: —

Сведения о проверке подлинности:
Процесс входа: NtLmSsp
Пакет проверки подлинности: NTLM
Промежуточные службы: —
Имя пакета (только NTLM): —
Длина ключа: 0

Источник

RDP не принимает логин и пароль от Microsoft account?

Есть Desktop с Windows 10 1909. На нем настроена учетная запись Microsoft (не локальный пользователь). При настройке RDP и вводе заведомо верных данных(пользователя и пароль) пишет: «Не верный пользователь или пароль». Создавал локального пользователя и попытался подключиться через него — все работает. Не могу понять почему не получается авторизоваться через учетную запись Майкрософт.

P.S На учетной записи Майкрософт включена авторизация по Пин-Коду.

P.P.S Логин формата — account@outlook.com. Пароль конечно же установлен, это же учетная запись Microsoft. Включена двухфакторная аутентификация.

• Вопрос задан более двух лет назад
• 11022 просмотра

Средний 1 комментарий

***Обновление***
Еще один вариант. Просто отключить пин код и авторизоваться в учетке майкрософт по паролю(не использовать аутентификатор майкрософт. Дело, видимо, в том, что при чистой установке авторизовываясь в учетке майкрософт по мобильному аутентификатору, а не по паролю, он не подгружает пароль и соответственно не хранит ХЭШИ пароля(возможно ошибаюсь).
***Конец обновления***
Нашел решение. Итак, все кто столкнется с этой проблемой нужно сделать следующее:
1) В меню «Параметры Windows» перейти в «Учетные записи» и в подпункте «Ваши данные» нажать «Войти вместо этого с локальной учетной записью»
Винда сначала попросит ввести новый локальный пароль для учетки, а потом выйти из учетки. Следуем ее совету.
2) Вводим локальный пароль и заходим в учетку. Проходим по пути что в первом пункте и нажимаем «Войти с учетной записью Майкрософт».
Далее винда попросит ваши учетные данные, вводим их и вуа-ля, теперь вы можете подключиться к своему компьютеру посредством RDP. Чтобы посмотреть Ваш «логин» для RDP перейдите в «Управление компьютером» —> «Локальные пользователи» —> «Пользователи». Найдите там свою учетную запись (пример: buhpc). Именно это имя и будет служить вашим логином для авторизации по RDP, а пароль будет такой как у учетной записи Майкрософт.
Пример:
Пользователь: buhpc
Пароль: пароль от учетной записи Майкрософт

P.S Я опустил в данном посте о добавлении этой учетки либо в группу Администраторы, либо Пользователи удаленного рабочего стола, ибо это и так понятно.

Источник

Rdp учетные данные использованные для подключения недопустимы

Этот форум закрыт. Спасибо за участие!

Лучший отвечающий

Вопрос

Есть несколько серверов 2008R2.

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

Причем, если я подключаюсь с телефона/планшета с помощью RD client — подключение проходит нормально.. а с Win7/8.1 — нет

Ответы

Согласно сторонним форумам, в качестве временного решения помогает в локальной политике применить:

Это изменение должно помочь в случае установки обновления KB3002657, как временное решение.

P.S. так пишут на сторонних форумах.

Best Regards, Andrei .
Microsoft Certified Professional

Все ответы

Уточните пожалуйста, проблема начало воспроизводиться после мартовских обновлений?
Также уточните присутствует ли в списке установленных обновлений, обновление kb3039976 ?

Best Regards, Andrei .
Microsoft Certified Professional

• Предложено в качестве ответа Dmitriy Vereshchak Microsoft contingent staff 13 марта 2015 г. 9:47

Этого обновления я в списке не нашел, хотя сегодня поставил ВСЕ обновления на все сервера. и не могу точно сказать с какого момента это произошло, потому как сервера ввел в домен только вчера. Но при выводе серверов из домена, подключение работает нормально. И к тому же, на сам DC я захожу, по RDP.

И так же я могу к ним подключиться под учеткой локального админа, а доменного нет.

Best Regards, Andrei .
Microsoft Certified Professional

Спасибо, перед обращением сюда я читал эти статьи, они не к моему случаю. У меня нет проблем с сохранением учетных данных, к тому же я создавал разные учетки с правами доменных админов и пытался подключаться с разных компов, со всех учеток та же ситуация..

а логи выдают вот это

Best Regards, Andrei .
Microsoft Certified Professional

Похоже на проблему, которая воспроизводиться после установки обновления KB3002657

P.S. в качестве временного решения, выше указано статье указывают на удаление обновления KB3002657 со всех контроллеров домена.

Best Regards, Andrei .
Microsoft Certified Professional

Best Regards, Andrei .
Microsoft Certified Professional

Похоже на проблему, которая воспроизводиться после установки обновления KB3002657

P.S. в качестве временного решения, выше указано статье указывают на удаление обновления KB3002657 со всех контроллеров домена.

Best Regards, Andrei .
Microsoft Certified Professional

Удаление этого КВ не помогло (((

Best Regards, Andrei .
Microsoft Certified Professional

Очень похожая проблема

Накатил последние обновления (компьютер с TMG), перезагружаюсь — «не верные учетные данные»

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

На другие сервера домена захожу под любой админской учеткой

ок. Перезагружаюсь еще раз. Опа — не пускает под обоими админскими учетками

Захожу под локальным админом. Удаляю профили пользователей под которыми не пускает. не помогло.

Удаляю обновление KB3002657. не помогло

Удаляю все установленные сегодня обновления. ждем-с

Источник

Не сохраняются пароли для RDP подключений

Встроенный RDP клиент Windows (mstsc.exe) позволяет сохранить на компьютере имя и пароль пользователя, который использовался для подключения. Благодаря этому пользователю не нужно каждый раз вводить пароль для подключения к удаленному RDP компьютеру/серверу. В этой статье мы рассмотрим, как настроить возможность сохранения учетных данных для RDP подключения в Windows 10 / Windows Server 2012 R2/2016 и что делать, если несмотря на все настройки, у пользователей не сохранятся пароли для RDP подключения (пароль запрашивается каждый раз)

Настройки сохранения пароля для RDP подключения

По умолчанию Windows разрешает пользователям сохранять пароли для RDP подключений. Для этого в окне клиента RDP (mstsc) пользователь должен ввести имя удаленного RDP компьютера, учетную запись и поставить галку “Разрешить мне сохранять учетные данные” (Allow me to save credential). После того, как пользователь нажимает кнопку “Подключить”, RDP сервер запрашивает пароль и компьютер сохраняет его в Windows Credential Manager (не в .RDP файл).

В результате при следующем подключении к удаленному RDP серверу под этим же пользователь, пароль автоматически берется из Credential Manager и используется для RDP-авторизации.

Как вы видите, если для данного компьютера имеется сохраненный пароль, в окне RDP клиента указано:

Если вы подключаетесь с компьютера, включенного в домен, к компьютеру/серверу, который находится в другом домене или рабочей группе, по-умолчанию Windows не разрешает пользователю использовать сохраненный пароль RDP подключения. Несмотря на то, что пароль для подключения сохранен в Credentials Manager, система не позволяет его использовать, каждый раз требуя от пользователя вводить пароль. Также Windows не разрешает использовать сохраненный пароль для RDP, если вы подключаетесь не под доменной, а под локальной учетной записью.

При попытке RDP подключения с сохраненным паролем в этой ситуации появляется окно с ошибкой:

Your Credentials did not work
Your system administrator does not allow the use of saved credentials to log on to the remote computer CompName because its identity is not fully verified. Please enter new credentials.

Или (в русской редакции Windows 10):

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

Вы можете изменить эти настройки на компьютере, с которого выполняется RDP подключение:

1. 1. Откройте редактор локальной GPO, нажав Win + R ->gpedit.msc ;
   2. В редакторе GPO перейдите в раздел Computer Configuration –> Administrative Templates –> System –> Credentials Delegation (Конфигурация компьютера -> Административные шаблоны -> Система -> Передача учетных данных). Найдите политику с именем Allow delegating saved credentials with NTLM-only server authentication (Разрешить делегирование сохраненных учетных данных с проверкой подлинности сервера только NTLM);
   3. Дважды щелкните по политике. Включите политику (Enable) и нажмите на кнопку Показать (Show);
   4. В открывшемся окне нужно будет указать список удаленных компьютеров (серверов), для которых будет разрешено использовать сохранные пароли для RDP подключения.Список удаленных компьютеров нужно указать в следующих форматах:
      • TERMSRV/server1 — разрешить использование сохранённых паролей для RDP подключения к одному конкретному компьютеру/серверу;
      • TERMSRV/*.winitpro.ru — разрешить RDP подключение ко всем компьютерам в домене winitpro.ru;
      • TERMSRV/* — разрешить использование сохранённого пароля для подключения к любым компьютерам.

   

   Теперь при выполнении RDP подключения клиент mstsc сможет использовать сохранённый пароль.

   

   С помощью локального редактора групповых политик вы сможете переопределить политику только на локальном компьютере. В том случае, если вы хотите, чтобы эта политика разрешения использования сохраенных паролей для RDP подключения действовала на множество компьютеров домена, используете доменные политики, которые настраиваются с помощью консоли gpmc.msc.

   Что делать, если в Windows не сохраняется пароль для RDP подключения?

   Если вы настроили Windows по инструкции выше, но клиент все равно при каждом повторном RDP подключении требует ввести пароль следует проверить следующее:

   1. В окне RDP подключения нажмите на кнопку “Показать параметры” и убедитесь, что опция “Всегда запрашивать учетные данные” (Always ask for credentials) не выбрана;
   2. Если вы используете для подключения сохранённый RDP файл, проверьте, что параметр “prompt for credentials” равен 0 ( prompt for credentials:i:0 );
   3. Откройте редактор GPO gpedit.msc, перейдите в раздел Конфигурация компьютера -> Компоненты Windows -> Службы удаленных рабочих столов -> Клиент подключения к удаленному рабочему столу (Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Connection Client). Параметр “Запретить сохранение паролей” (Do not allow passwords to be saved) должен быть не задан или отключен. Также убедитесь, что он отключен в результирующей политике на вашем компьютере (html отчет с применёнными настройками доменных политик можно сформировать с помощью gpresult);
   4. Удалите все сохраненные пароли в менеджере паролей Windows (Credential Manager). Наберите control userpasswords2 и в окне “Учетные записи пользователей” перейдите на вкладку “Дополнительно” и нажмите на кнопку “Управление паролями”; В открывшемся окне выберите “Учетные данные Windows”. Найдите и удалите все сохраненные RDP пароли (начинаются с TERMSRV/…).

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

Источник