Когда забытый сохранённый пароль запирает живого человека из системы

Есть категория неполадок, которые сводят с ума своей нелогичностью. Учётная запись пользователя блокируется сама собой, по нескольку раз на дню, без всякой видимой причины. Человек приходит утром, вводит верный пароль, а система отвечает, что запись заблокирована. Администратор разблокирует, через час всё повторяется. Пользователь клянётся, что неверный пароль не вводил, и он не врёт. А виновник тем временем сидит где-то в недрах системы, тихо и методично долбясь в контроллер с устаревшим паролем, накручивая счётчик неудачных попыток до тех пор, пока запись не запрётся.

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

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

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

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

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

Добавляет сложности и то, как устроена политика блокировки. Запись запирается не от единственной ошибки, а после нескольких неудачных попыток за отведённый промежуток, и через какое-то время счётчик сбрасывается сам. Из-за этого блокировки приходят не подряд, а волнами: набралось достаточно попыток, запись заперлась, администратор разблокировал, счётчик пошёл заново. Эта прерывистость и сбивает с толку, создавая ложное впечатление случайности там, где на деле работает вполне размеренный механизм, привязанный к ритму обращений затаившегося источника.

Первый шаг диагностики это осмотр локального хранилища

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

cmdkey /list

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

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

cmdkey /delete:server

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

Когда сохранённых паролей много и нужна массовая чистка

Бывает, что на машине скопились десятки устаревших записей, особенно после массовой смены паролей в организации, и перебирать их по одной мучительно. Тогда применяют цикл командной строки, который сам проходит по списку и вычищает подходящие записи. Чтобы убрать разом все сохранённые пароли терминальных подключений, как самые частые источники блокировок, используют конструкцию с фильтром:

for /F "tokens=1,2 delims= " %G in ('cmdkey /list ^| findstr "target=TERMSRV"') do cmdkey /delete %H

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

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

Расследование через журнал безопасности и поиск источника

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

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

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)} | Format-List TimeCreated, Message

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

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

Профилактика и привычки, которые избавляют от блокировок

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

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

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

Редкие источники и автоматизация поиска через PowerShell

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

schtasks /query /fo LIST /v | findstr /i "Запуск от имени пользователя"

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

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

Get-CimInstance Win32_Service | Where-Object {$_.StartName -like "*\*"} | Select-Object Name, StartName, State

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

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

Объектная природа PowerShell позволяет не просто собрать данные, но и сразу отфильтровать их по нужным признакам, выделив, например, все неудачные попытки конкретного пользователя за последние сутки с указанием источников. Полученная сводка нередко сразу указывает на виновное устройство, превращая многочасовой розыск в короткий автоматизированный отчёт. Это тот случай, когда вложение времени в скрипт окупается многократно, ведь блокировки учётных записей в крупной организации это не разовое происшествие, а регулярная докучливая работа.

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