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

Обновлено: 07.07.2024

Очень часто принтер используется целой группой компьютеров, подключаясь к нему по локальной или беспроводной сети. У некоторых с этим возникают проблемы, появляется ошибка 0x0000052e при добавлении принтера или попытке подключить к нему. Проблема всегда затрагивает тех, кто использует сетевой принтер и операционную систему Windows. Что ж, сейчас мы углубленно разберем суть ошибки и способы ее исправления.

Что означает ошибка 0x0000052e?

«Ошибка входа в систему: неизвестное имя пользователя или неверный пароль».

«Не удалось подключиться к принтеру (подробности: в ходе операции произошла ошибка с кодом 0x0000052e)».

Как устранить ошибку 0x0000052e в Windows 11, 10, 7?

Нет ничего страшного в том, что не удалось подключиться к принтеру из-за ошибки 0x0000052e. Существует несколько действий, которые позволят восстановить стабильную связь с сетевым принтером.

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

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

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

Настроить диспетчер учетных данных

В Windows 10 и более новой версии операционной системы есть специальный «Диспетчер учетных данных». В нем сохраняются все пароли, в том числе к веб-сайтам, приложениям и сетям. Если добавить сюда актуальный пароль к принтеру, он будет применяться автоматически и печать будет начинаться практически сразу, после отправки документа.

Как настроить пароль:

ошибка 0x0000052e при подключении к принтеру

В 99% случаев ошибка 0x0000052e вызвана просто неправильными данными для подключения. Либо компьютер обращается не к тому серверу, либо отсутствует доступ для данного пользователя, либо допущена ошибка в пароле, либо логине. После указания корректных данных доступ к принтеру возобновится.

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

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

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

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

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

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

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


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


Как работает авторизация в 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 генерируется на основе имени пользователя. Сами данные лежат в ветке реестра HKLM\SECURITY\Cache к которому имеет доступ только система.

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


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

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


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


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

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


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

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

Вопрос

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

Выполнение начальной настройки:
Выполняется попытка поиска основного сервера.
* Проверка, является ли локальный компьютер 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-Name\DC
Пропуск всех проверок, так как сервер 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. не помогло

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

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

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

Подключение к удаленному рабочему столу 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:

Если эта проблема затрагивает одного пользователя, наиболее простым решением будет добавить этого пользователя в группу Пользователи удаленного рабочего стола. 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

Внимательно выполните действия, описанные в этом разделе. 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.

Чтобы решить эту проблему, выполните одно из указанных ниже действий: 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 до повторного выпуска 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.

Чтобы устранить эту проблему, перезапустите удаленный компьютер. 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 на соответствующем компьютере с использованием обновления за 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).

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

Чтобы устранить эту проблему до завершения обновления, просмотрите список допустимых типов подключений в обновлении 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:

Дополнительные сведения о работе с групповой политикой см. в разделе Изменение блокирующего объекта групповой политики. 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. 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.

Логинимся на компьютер с ошибкой отсутствуют серверы которые могли бы обработать запрос

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

отсутствуют серверы которые могли бы обработать запрос

Как работает авторизация в 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 генерируется на основе имени пользователя. Сами данные лежат в ветке реестра HKLM\SECURITY\Cache к которому имеет доступ только система.

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

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

отсутствуют серверы которые могли бы обработать запрос-2

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

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

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

отсутствуют серверы которые могли бы обработать запрос-3

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

отсутствуют серверы которые могли бы обработать запрос-4

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

Конфигурация компьютера > Политики > Конфигурация Windows > Параметры безопасности > Локальные политики > Параметры безопасности

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

отсутствуют серверы которые могли бы обработать запрос-5

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

Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options и найти параметр Interactive logon: Number of previous logons to cache (in case domain controller is not available)

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

Для восстановления доверительных отношений существует несколько способов. Рассмотрим их все по порядку.

Способ первый

Открываем оснастку «Active Directory Users and Computers» и находим в ней нужный компьютер. Кликаем на нем правой клавишей мыши и в контекстном меню выбираем пункт «Reset Account». Затем заходим на компьютер под локальной учетной записью и заново вводим его в домен.

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

Способ этот довольно громоздкий и небыстрый, т.к. требует перезагрузки, однако работает в 100% случаев.

Способ второй

Заходим на компьютер, которому требуется сбросить пароль, открываем командную консоль обязательно от имени администратора и вводим команду:

Netdom Resetpwd /Server:SRV1 /UserD:Administrator /PasswordD:*

где SRV1 — контролер домена, Administrator — административная учетная запись в домене. Дополнительно можно указать параметр /SecurePasswordPrompt, который указывает выводить запрос пароля в специальной форме.

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

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

Еще с помощью Netdom можно проверить наличие безопасного соединения с доменом:

Или сбросить учетную запись компьютера:

где WKS1 — рабочая станция, которой сбрасываем учетку.

Способ достаточно быстрый и действенный, однако есть одно но: по умолчанию утилита Netdom есть только на серверах с установленной ролью Active Directory Domain Services (AD DS). На клиентских машинах она доступна как часть пакета удаленного администрирования Remote Server Administration Tools (RSAT).

Способ третий

Еще одна утилита командной строки — Nltest. На компьютере, который потерял доверие, выполняем следующие команды:

Nltest /query проверить безопасное соединение с доменом;

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

Способ четвертый

PowerShell тоже умеет сбрасывать пароль копьютера и восстанавливать безопасное соеднение с доменом. Для этого существует командлет Test-ComputerSecureChannel . Запущенный без параметров он выдаст состояние защищенного канала — True или False.

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

Test-ComputerSecureChannel -Server SRV1 -Credential Contoso\Administrator -Repair

где SRV1 — контролер домена (указывать не обязательно).

Для сброса пароля также можно также воспользоваться такой командой:

Reset-ComputerMachineChannel -Server SRV1 -Credential Contoso\Administrator

Способ быстрый и удобный, не требующий перезагрузки. Но и здесь есть свои особенности. Ключ -Credential впервые появился в PowerShell 3.0. Без этого параметра командлет, запущенный из под локального пользователя, выдает ошибку доступа. Получается что данный метод можно использовать только на Windows 8 и Server 2012, ведь для остальных ОС PowerShell 3.0 пока недоступен.

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

Изменение параметров смены пароля компьютера

Смена пароля в домене происходит следующим образом:

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

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

Если настройки необходимо применить к группе компьютеров, то проще всего использовать групповую политику. Настройки, отвечающие за смену паролей, находятся в разделе Computer Configuration — Policies — Windows Settings — Security Settings — Local Policies — Security Options. Нас интересуют следующие параметры:

Disable machine account password change — отключает на локальной машине запрос на изменение пароля;

Maximum machine account password age — определяет максимальный срок действия пароля компьютера. Этот параметр определяет частоту, с которой член домена будет пытаться изменить пароль. По умолчанию срок составляет 30 дней, максимально можно задать 999 дней;

Refuse machine account password changes — запрещает изменение пароля на контролерах домена. Если этот параметр активировать, то контролеры будут отвергать запросы компьютеров на изменение пароля.

Для одиночной машины можно воспользоваться настройками реестра. Для этого в разделе HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters есть два параметра :

DisablePasswordChange — если равен 1, то запрос на обновление пароля компьютера отключен, 0 — включен.

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

И в разделе HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters , только у контролеров домена, параметр:

RefusePasswordChange — если равен 1, то запрещает контролеру домена принимать запрос на изменение пароля. Этот параметр надо задать на всех контролерах в домене.

Вот вроде и все про доверительные отношения. Как видите, доверие в домене — штука тонкая, так что старайтесь его не терять.

Читайте также: