Зависший кэш паролей как тихий виновник сбоев доступа к ресурсам

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

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

Откуда берётся рассинхрон между свежими правами и старым кэшем

Чтобы понимать, что чистить, полезно разобраться, какие именно слои памяти участвуют в проверке доступа. В доменной сети основную работу делает протокол Kerberos. При входе пользователь получает специальный билет, своего рода пропуск, который потом предъявляется всем ресурсам вместо пароля. Эти билеты складываются в локальный кэш и действуют ограниченное время. Пока билет валиден, система не ходит лишний раз к контроллеру домена, экономя сеть и время.

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

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

Очистка билетов Kerberos через утилиту klist

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

klist

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

klist purge

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

Когда обычной очистки мало и нужен системный сеанс

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

klist -li 0x3e7 purge

Этот идентификатор 0x3e7 соответствует сеансу локальной системы. Команда полезна в ситуациях, когда сетевая служба или фоновый процесс держится за устаревший билет, а пользователь даже не догадывается, что где-то в недрах системы тлеет старый пропуск. Без сброса именно этого сеанса проблема будет возвращаться снова и снова, сколько ни чисти пользовательский кэш.

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

ipconfig /flushdns
nbtstat -RR
klist purge

Здесь первая команда чистит кэш DNS, вторая обновляет регистрацию имён NetBIOS, третья сбрасывает билеты. Такой залп разом снимает целый класс проблем, когда компьютер ломится не на тот адрес или предъявляет не тот пропуск. После него стоит повторить операцию, которая не получалась, и в значительной части случаев она проходит гладко.

Сброс сохранённых паролей сетевых подключений

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

cmdkey /list

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

cmdkey /delete:fileserver

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

Как отличить, какой именно кэш виноват, и не лечить вслепую

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

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

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

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

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

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

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

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

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

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

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

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