Поддержка пользователей 05. Учётные записи и пароли: сброс, блокировка, профиль

Note

Материал сверен с официальной документацией (Microsoft Learn и support.microsoft.com; ссылки — в конце статьи). Примеры вывода — иллюстрации: на вашем компьютере значения и формат могут отличаться. Перед работой на боевых компьютерах проверьте шаги на тестовой машине.

«Не могу войти» — самое частое обращение в поддержку, и за ним стоит не одна причина, а целая россыпь. Вот как это звучит у пользователя:

«Пишет, что пароль неверный, хотя я его не менял»;
«Учётная запись заблокирована» или «Срок действия пароля истёк»;
«В офисе захожу, дома не получается» (или наоборот);
«Не удалось установить доверительные отношения между рабочей станцией и доменом»;
«Зашёл, а рабочий стол пустой и моих файлов нет».

У каждой фразы свой набор проверок, а задача одна: вернуть человеку доступ, не отдав его постороннему и не потеряв данные. Мы пройдём по порядку: уточнить → проверить состояние записи → выбрать причину → исправить → проверить → записать в заявку. Речь о доменных учётных записях на Windows 11.

Что нужно знать заранее

Поддержка пользователей 01: линии поддержки, права helpdesk1 и admin-lab, правила работы с паролями.
Windows Server с нуля 03: домен и контроллер домена (DC, domain controller — сервер, который хранит учётные записи и проверяет пароли), время в домене.
Windows Server с нуля 05: пользователи, группы и делегирование. Там тестовый помощник назван helper1, у нас это helpdesk1: создайте его так же и добавьте в GG-HelpDesk, которой на подразделении (OU, organizational unit) Staff делегирован сброс паролей.
Windows Server с нуля 12: политика блокировки и чтение событий безопасности.
Среда: домен lab.example, контроллеры DC1 и DC2, компьютер PC1, сотрудники ivanov и petrova. Команды модуля ActiveDirectory выполняют в Windows PowerShell 5.1 на компьютере с RSAT (Remote Server Administration Tools, средства удалённого администрирования сервера).
Шаги с пометкой «(вторая линия)» требуют прав администратора: первая линия передаёт их вместе с результатами проверок. Пароль администратора вводят по правилу из Поддержка пользователей 02.

Три состояния записи часто путают. Заблокирована (lockout): число неверных паролей превысило допустимое, и система закрыла вход. Отключена (disabled): администратор запретил вход. Пароль истёк (expired): закончился срок действия, заданный политикой. Лечатся они по-разному, поэтому сначала выясните, какое состояние у вас.

Правила безопасности

Общие правила (не просить пароль, проверять личность до сброса, не входить под чужой записью) — в Поддержка пользователей 01. Здесь три добавления (практика автора):

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

Шаг 1. Уточните, что именно происходит

Попросите дословный текст ошибки (лучше скриншот) и спросите:

какой записью входит: доменной (LAB\ivanov или ivanov@lab.example) или локальной на компьютере;
где находится: в офисной сети, дома, в поездке;
что менялось: пароль, компьютер ремонтировали, восстанавливали из копии или откатывали виртуальную машину к контрольной точке (снимку);
есть ли та же проблема у коллег и на других компьютерах.

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

Что видит пользователь	Вероятная причина	Раздел
«Неверный пароль»	опечатка, раскладка, старый пароль, блокировка	шаг 2
Сообщение о блокировке, об истёкшем пароле, об отключённой записи	состояние записи	шаги 2 и 3
Входит в офисе, а вне сети нет; сообщение о недоступном домене	нет связи с контроллером, кэш входа	шаг 4
«The trust relationship between this workstation and the primary domain failed» (в русской Windows текст переведён)	нарушен канал безопасности компьютера	шаг 5
Отказ при заведомо верном пароле, особенно после замены батарейки или на виртуальной машине	расхождение часов	шаг 6
«We can't sign into your account», пустой рабочий стол	временный профиль	шаг 7
Вошёл, но не открываются почта или сетевой диск	в системе сохранён старый пароль	шаг 2

Если не удаётся вход по ПИН-коду Windows Hello, проверьте вход паролем: неполадка может быть только в ПИН-коде.

Шаг 2. Состояние записи: блокировка, отключение, срок пароля

Чтение каталога доступно первой линии. Найдите заблокированных и тех, у кого истёк пароль:

Search-ADAccount -LockedOut -UsersOnly |
    Select-Object Name, SamAccountName
Search-ADAccount -PasswordExpired -UsersOnly |
    Select-Object Name, SamAccountName
Get-ADUser -Identity ivanov | Select-Object Name, Enabled

Пример вывода первой команды:

Name        SamAccountName
----        --------------
Ivan Ivanov ivanov

Если ivanov в списке нет, запись не заблокирована. Если Enabled равно False, запись отключена: включать её самим не нужно, сначала выясните у руководителя или в кадрах, почему (возможно, сотрудник уволен или в отпуске).

Разблокировка — вторая линия, если право не делегировано отдельно: в списке типовых задач мастера делегирования такой задачи нет, а у GG-HelpDesk делегирован только сброс пароля. Если Unlock-ADAccount отвечает отказом в доступе, передайте разблокировку администратору:

Unlock-ADAccount -Identity ivanov
Search-ADAccount -LockedOut -UsersOnly

Во втором выводе ivanov быть уже не должно. Если политика задаёт длительность блокировки, запись разблокируется и сама (Windows Server с нуля 12), но человеку ждать незачем.

Почему блокируется снова (вторая линия)

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

Источник подскажет событие 4740 («учётная запись заблокирована») в журнале безопасности: в поле Caller Computer Name записан компьютер, с которого пришли неверные пароли. Событие создаётся на контроллерах, рядовых серверах и рабочих станциях (для локальной записи искать нужно на самом компьютере) при включённом аудите управления учётными записями. Начните с контроллера с ролью эмулятора PDC (эмулятор основного контроллера домена; в лаборатории это DC1; практика автора), затем проверьте остальные. Права на журнал безопасности есть обычно у второй линии:

Get-WinEvent -ComputerName DC1 -FilterHashtable @{
    LogName = 'Security'; Id = 4740, 4771
    StartTime = (Get-Date).AddHours(-2)
} -MaxEvents 5 | Format-List TimeCreated, Message

Пример вывода (сокращён, в русской Windows подписи переведены):

TimeCreated : 04.11.2026 9:12:41
Message     : A user account was locked out.
              Account That Was Locked Out:
                  Account Name:         ivanov
              Additional Information:
                  Caller Computer Name: PC2

Здесь неверные пароли пришли с PC2: источник ищите там. Причину отказа при входе в домене покажет событие 4771: так контроллер фиксирует отказ в проверке пароля по протоколу Kerberos (протоколу проверки подлинности в домене). Оно создаётся только на контроллерах при включённом аудите службы проверки подлинности Kerberos, а нужное поле называется Failure Code:

Failure Code	Что означает	Что делать
`0x18`	неверный пароль	раскладка, Caps Lock, старый пароль
`0x17`	пароль истёк	сброс пароля (шаг 3)
`0x25`	расхождение часов (Clock skew too great)	шаг 6
`0x12`	учётные данные отозваны	проверить, не отключена, не заблокирована и не просрочена ли запись

Когда проверка идёт по NTLM (NT LAN Manager, старый протокол), её фиксирует другое событие — 4776: оно есть в таблице аудита Windows Server с нуля 12, там же разобрано 4625 — неудачный вход на самом компьютере.

Сохранённые старые пароли

Windows запоминает пароли для сайтов, сетевых ресурсов и программ в Диспетчере учётных данных (Credential Manager). Откройте его вводом «диспетчер учётных данных» в поиске на панели задач, раздел «Учётные данные Windows» (есть и «Учётные данные веб-сайтов»). Записи с устаревшим паролем удаляют и подключаются заново: новый пароль вводит сам пользователь. Запишите названия удаляемых записей: восстановить удалённую запись можно, только введя пароль снова.

Шаг 3. Сбросьте пароль

Сброс нужен, когда пароль забыт или истёк, а сам пользователь его сменить не может. Порядок:

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

$new = Read-Host -AsSecureString 'Временный пароль для ivanov'
Set-ADAccountPassword -Identity ivanov -Reset -NewPassword $new
Set-ADUser -Identity ivanov -ChangePasswordAtLogon $true

Параметр -Reset позволяет обойтись без старого пароля. Read-Host -AsSecureString не показывает ввод на экране и не оставляет пароль в истории команд; если пароль не проходит политику, команда вернёт ошибку, и придумайте другой. Заблокированную запись разблокируют отдельно, как в шаге 2: Unlock-ADAccount выполняют, только если право делегировано.

Передайте пароль голосом. Если человек вне офиса, сначала нужна связь с контроллером (практика автора), иначе временный пароль не примется. Пользователь входит, Windows просит задать новый пароль.
Проверьте, что человек вошёл, а Search-ADAccount -LockedOut -UsersOnly не показывает его запись.
Предупредите: пароль нужно обновить на телефоне, в почтовых программах и в Диспетчере учётных данных, иначе старый пароль заблокирует запись снова.

Для облачных сервисов (например, Microsoft 365) и многофакторной проверки (MFA) правила сброса свои: уточните их у администратора.

Шаг 4. Вход без связи с контроллером: кэшированные данные

Когда компьютер не может связаться с контроллером, пользователь всё же может войти под кэшированными учётными данными (cached credentials): Windows хранит данные входа доменных пользователей локально, чтобы человек мог работать вне офиса. Поэтому ноутбук дома обычно пускает, а компьютер, на котором этот пользователь ещё ни разу не входил при доступном контроллере, — нет.

Что видит пользователь:

вход выполнен, но показано сообщение, что контроллер домена недоступен и вход выполнен по кэшированным данным, а изменения профиля могут быть недоступны. Это не ошибка, а предупреждение; проверяйте связь (дальше);
«The system can't log you on now because the domain <имя домена> isn't available» (в русской Windows текст переведён): в кэше этой записи нет. Так бывает, если человек ещё не входил на этом компьютере при доступном контроллере, если кэш отключён политикой, если его вытеснили другие пользователи или если пользователь состоит в группе Protected Users, чьи учётные данные не кэшируются (Windows Server с нуля 12).

Размер кэша задаёт политика Interactive logon: Number of previous logons to cache (in case domain controller is not available) в разделе Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options. Значения — от 0 до 50, для клиентов по умолчанию кэшируются данные 10 разных пользователей: при входе одиннадцатого вытесняется самая старая запись. При значении 0 кэширование выключено. Политика связана с безопасностью, поэтому на первой линии её не меняют.

Отсюда практическое правило (вывод автора, не цитата документации): после смены пароля первый вход лучше выполнить при доступном контроллере, например в офисе, чтобы локальные данные не отстали от каталога. А если «в офисе работает, дома нет», сначала проверьте связь с контроллером (Поддержка пользователей 06 и Сети с нуля 07): без DNS-записей домена компьютер контроллер не найдёт.

Шаг 5. «Доверительные отношения нарушены» (вторая линия)

Компьютер в домене тоже имеет учётную запись с паролем: им он доказывает контроллеру, что он «свой». Защищённое соединение компьютера с контроллером называется каналом безопасности (secure channel). Если пароли компьютера на нём и в каталоге разошлись, канал ломается.

Признаки: войти доменной записью нельзя и выдаётся текст о доверительных отношениях; можно войти локальной записью или (если есть) по кэшу; в журнале «Система» (System) на компьютере есть событие NETLOGON с кодом 3210. Первая линия фиксирует признаки и передаёт заявку. Вторая линия проверяет (консоль от имени администратора, вход на компьютер локальным администратором):

Get-WinEvent -FilterHashtable @{
    LogName = 'System'; ProviderName = 'NETLOGON'; Id = 3210
} -MaxEvents 3
Test-ComputerSecureChannel -Verbose

Вторая команда возвращает True, если канал в порядке, и False, если нет (параметр -Verbose добавляет пояснение). Командлет описан в документации для Windows PowerShell 5.1, в нём его и запускайте. Пароль локального администратора выдаётся по вашей процедуре: в лаборатории из Windows Server с нуля 12 Windows LAPS (Local Administrator Password Solution, управление паролем локального администратора) включён только для серверов.

Почему пароли разошлись

Возможны две ситуации: на компьютере пароль старее, чем в каталоге, либо каталог старее компьютера. Вторая случается, когда контроллер восстановили из копии или нарушена репликация; с компьютера её, как правило, не вылечить: сначала администраторы приводят в порядок каталог. Для первой типичные причины — откат виртуальной машины к контрольной точке (снимку), восстановление компьютера из резервной копии или откат к точке восстановления: спросите, не делали ли что-то из этого. Если признаки одновременно у нескольких компьютеров, не чините их по одному, а передайте администратору: вероятно, дело в каталоге.

Ремонт

Ремонт выполняет администратор домена (так сказано в документации). Пароль администратора вводят по правилу из Поддержка пользователей 02: лично за компьютером организации либо на своей станции при подключении по RDP или PowerShell, но не в сеансе Быстрой поддержки (Quick Assist) и не диктуя его по телефону. На проблемном компьютере, в консоли от имени администратора:

Test-ComputerSecureChannel -Repair -Credential LAB\admin-lab

PowerShell запросит пароль указанной учётной записи. Команда удаляет и заново строит канал безопасности; после неё перезагрузите компьютер. Та же статья Microsoft о причинах расхождения паролей называет вариантом команду nltest /sc_reset:lab.example; обе выполняют от имени администратора домена. Командлет работает только на рядовых компьютерах: на контроллерах он даёт ложные ошибки, для них нужны netdom или nltest. Контроль: после перезагрузки Test-ComputerSecureChannel возвращает True, а доменная запись входит.

Повторный ввод в домен — крайняя мера: его делает администратор по описанию из Windows Server с нуля 03, после чего проверяют, что компьютер оказался в нужном OU и группах, потому что от этого зависят его политики.

Шаг 6. Время и Kerberos

Kerberos сверяет метки времени и терпит расхождение между часами клиента и контроллера не более заданного: в Default Domain Policy по умолчанию 5 минут (параметр Maximum tolerance for computer clock synchronization). Если часы ушли дальше, пользователь получает отказ, хотя пароль верный. Бывает после замены батарейки материнской платы, при неверном часовом поясе, у виртуальных машин.

Измерьте расхождение (консоль от имени администратора, вторая линия):

w32tm /stripchart /computer:DC1.lab.example /samples:3 /dataonly

Пример вывода (формат приблизительный, значения вымышлены):

Tracking DC1.lab.example [192.168.10.11:123].
09:30:00, +612.4501234s
09:30:02, +612.4488121s
09:30:04, +612.4495550s

Здесь расхождение около 612 секунд, то есть больше 5 минут. Проверьте дату, время и часовой пояс, затем выполните w32tm /resync, чтобы компьютер сверил часы немедленно. Если расхождение возвращается, проблема в источнике времени: смотрите Windows Server с нуля 03 и старую статью про синхронизацию времени в домене для Windows Server 2012.

Шаг 7. Временный профиль

Профиль — папка пользователя в C:\Users с его файлами и настройками. Если Windows не может загрузить профиль, она входит во временный: он пустой, а всё созданное в нём пропадает при выходе. Типичное сообщение: «We can't sign into your account. This problem can often be fixed by signing out of your account and then signing back in. If you don't sign out now, any files you create or changes you make will be lost» (на консоли формулировка может отличаться). В журнале «Приложение» (Application) при этом есть событие 1511 от User Profiles Service: Windows не нашла локальный профиль и вошла с временным. Для описанного там случая в качестве причины назван повреждённый локальный профиль.

Действия первой линии:

Не работайте во временном профиле. Если нужно что-то срочно сохранить, скопируйте это на сетевой ресурс или съёмный диск до выхода.
Выйдите и войдите заново. Проверьте свободное место на C: (если диск забит, см. Поддержка пользователей 04).
Если профиль не вернулся, передайте заявку второй линии с текстом сообщения и временем события 1511.

Вторая линия, прежде чем что-то менять, копирует папку профиля (например, C:\Users\ivanov) по правилам врезки «Как сохранить данные пользователя перед рискованным шагом» из Поддержка пользователей 03 и согласует это с пользователем. Исправление в документации Microsoft приведено единственное и описано для виртуальных машин Azure, поэтому действуйте осторожно: в ветке ProfileList находят запись пользователя с суффиксом .bak и удаляют её, не трогая встроенные записи S-1-5-18, S-1-5-19 и S-1-5-20. Перед правкой экспортируйте ветку (консоль от имени администратора):

if not exist C:\Temp mkdir C:\Temp
reg export "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList" ^
    C:\Temp\ProfileList.reg

Откат: reg import C:\Temp\ProfileList.reg. Файл вложите в заявку и удалите с компьютера. Если исправление не помогло, создают новый профиль и переносят в него файлы вручную (практика автора); старый профиль удаляют только после проверки, что данные на месте.