Windows по умолчанию сохраняет (кэширует) учетные данные доменных пользователей при успешном входе на компьютер. Благодаря этому пользователь сможет войти на свой компьютер под своим доменным аккаунтом, даже если контроллеры домена Active Directory недоступны или компьютер не подключен к сети (офлайн). В этой статье мы рассмотрим особенности использования кешированных учетных данных (Cached Credentials) пользователей в Windows
Кэширование учетных данных пользователя для входа в Windows
Пользователь сможет войти на оффлайн компьютер под своей доменной учетной записью, если он ранее хотя бы один раз успешно аутентифицировался на этом устройстве. При входе на доменный компьютер, хеш доменного имени пользователя и пароля сохраняются в реестре. Если домен Active Directory не доступен, Windows рассчитывает хэш введенного имени и пароля пользователя, и проверяет есть ли такой хэш в реестре. Если хеш найден, пользователю разрешается локальный вход на компьютер даже при отсутствии связи с контроллером домена.
Сохраненные пароли хранятся в ветке реестра HKEY_LOCAL_MACHINE\Security\Cache (файл
%systemroot%\System32\config\SECURITY
). Каждый сохранённый хэш содержится в Reg_Binary параметре NL$x (где x – индекс кэшированных данных).
Содержимое этой ветки реестра можно посмотреть с помощью regedit.exe, если запустить его от имени SYSTEM с помощью утилиты psexec (у администратора нет доступа к этому разделу реестра).
PsExec.exe -i -s regedit.exe
В реестре могут хранятся несколько хэшей доменных учетных записей, который входили на это компьютер ранее. По умолчанию сохраняются хэши десяти (10) последних пользователей.
Такой хэш хранится в реестре бессрочно (никогда не истекает, в отличии от доменных паролей), пока не будет перезатерт новым хэшем (когда пользователь входит на компьютер с новым паролем), или следующим пользователем (при превышении лимита хранимых кешей).
Если в локальном кэше для пользователя нет сохранённых учетных данных, то при входе на офлайн компьютер, появится сообщение:
There are currently no logon servers available to service the logon request.
Отсутствуют серверы, которые могли бы обработать запрос на вход в сеть.
- Logon Type 12: CachedRemoteInteractive – удаленное подключение с использованием кэшированных учетных данных
- Logon Type 13: CachedUnlocked – разблокировка экрана компьютера после бездействия с помощью кэшированного пароля
Настройка Cached Credentials с помощью групповых политик
С помощью групповых политик можно настроить некоторые параметры кэширования учетных данных пользователей в Windows.
Изменить максимальное количество хранящийся кэшированных записей с учетными данными можно через параметр GPO. logon: Number of previous logons to cache (in case domain controller is not available) (Интерактивный вход в систему: количество предыдущих подключений к кэшу в случае отсутствия доступа к контроллеру домена), который находится в разделе Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options.
Значение по-умолчанию 10 (в реестре хранятся данные десяти последних вошедших на
Если задать 0, это запретит Windows кэшировать учетные данные пользователей. В этом случае при недоступности домена, при входе пользователя появится ошибка “Отсутствуют серверы, которые могли бы обработать запрос на вход в сеть”.
При входе под сохраненными данными, пользователь не видит, что контроллер домена не доступен. С помощью GPO можно вывести уведомление о входе под кэшированными данными. Для этого нужно включить политику Report when logon server was not available during user logon (Сообщать, когда сервер входа недоступен при входе пользователя) в разделе Computer configuration -> Policies -> Administrative templates -> Windows Components -> Windows Logon Options.
В этом случае при входе пользователя в трее будет появляться уведомление:
Не удается подключиться к серверу входа (контроллеру домена). Вход выполнен с помощью ранее сохраненных сведений об учетной записи.
A domain controller for your domain could not be contacted. You have been logged on using cached account information. Changes to your profile since you last logged on might not be available.
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/Current Version/Winlogon
- ValueName: ReportControllerMissing
- Data Type: REG_SZ
- Values: TRUE
Безопасность кэшированных учетных данных в Windows
Локальное кэширование данных аутентификации данных несет ряд рисков безопасности. Злоумышленник, получив физический доступ к компьютеру/ноутбуку с кэшированными данными, может с помощью брутфорса расшифровать хэш пароля (тут все зависит от сложности и длины пароля, для сложных паролей время подбора огромное). Поэтому не безопасно кешировать данные для входа учетных записей с правами локального администратора (или, тем более, доменного администратора).
Для уменьшения рисков безопасности, можно отключить кэширование учетных записей на офисных компьютерах и компьютерах администраторов. Для мобильных устройств желательно уменьшить количество кэшируемых аккаунтов до 1. Т.е. даже если администратор заходил на компьютер и его учетные данные попали в кэш, при входе пользователя-владельца устройства, хэш пароля администратора будет очищен.
Можно создать в домене отдельные политики по использованию кэшированных учетных данных для разных устройств и категорий пользователей (например, с помощью GPO Security filters, WMI фильтров, или распространению настроек параметра реестра CashedLogonsCount через GPP Item level targeting).
- Для мобильных пользователей –
CashedLogonsCount = 1
Для обычных компьютеров –CashedLogonsCount = 0
Такие политики снизят вероятность получения хэша привилегированных пользователей с персональных компьютеров.
Можно добавить привилегированные учетные записи пользователей (администраторов) во встроенную доменную группу Protected Users (доступен для доменов с функциональным уровнем Windows Server 2012 R2 и выше). Для таких пользователей запрещено локальное сохранение кэшированных данных.
Если пользователи используют кешированный вход на компьютеры, а потом устанавливают VPN туннель в корпоративную сеть, они могут столкнуться с периодической блокировкой своей учетной записи в домене. Это будет происходить, если сохраненный локально пароль не соответствуеть паролю пользователя в домене (например, когда пользователь изменил его согласно настройкам политики паролей в домене). Для предотвращения такого сценария нужно настроить Windows, чтобы она запускала VPN туннель до входа пользователя в компьютер.
Очистка кэшированных учетных данных в Windows
Для очистки кэшированных данных для входа нужно удалить NL$## записи в реестре. Но делать это вручную не удобно, т.к. потребует запуска команды удаления от имени SYSTEM.
Если нужно очистить все сохраненные cashed credentials, нужно просто включить политику Interactive logon: Number of previous logons to cache (in case domain controller is not available) и задать значение 0 (описано выше).
После обновления настроек GPO командой
gpupdate /force
, информация кэшированные учетные данные в реестре будут удалены.
После этого можно отключить политику, или вернуть значение по умолчанию 10. После этого учетные данные всех последующих входов будут автоматически кэшироваться.
Спасибо за Ваши статьи.
Очень подробно расписаны проблемы и варианты их решения.
Поддерживаю комментарий выше. Спасибо за статьи! Очень помогают мне как начинающему.
Ок. Мерси, очень интересно! Но ткните пальцем, плиз, где задается срок хранения кэшированного пароля ? У нас часто бывают ситуации, комп долго был в отключке или проблемы с сетью и войти нет возможности (локальные админы отключены, кэш «обнулился»). Где задать, чтобы кеш паролей доменных учеток админов не обнулялся ?
Пароль в кэше хранится бессрочно пока не будет перезатерт следующим.
Спасибо! Ну, то есть, я правильно понял — срок хранения пароля в кеше нигде не может быть установлен (политики, реестр) на какое-то заданное значение.
Верно!
Есть варианты кроме VPN дать пользователю синхронизировать пароль на вход?
А то уже поменял например через OWA а на вход старый и оутлук иногда брутфорсит сервер старым паролем.
Ответ на вопрос содержится в вопросе. Синхронизация происходит только при подключении к доменной сети, например через VPN) Мы решили вопрос через информирование юзеров об особенностях работы на удаленке и, в т.ч. как менять пароль, чтобы не получить блокировку.
Может Azure AD? ИЛИ RODC на хостинге или в том же Azure.
Azure AD — не подойдет, он для плоской синхронизации данных в тенант Azure.
RODC наружу, не представляю реализацию. .
Присмотритесь к RAS, поддерживает постоянный VPN. Даже до входа пользователя в систему, можно управть через GPO. Ссылка на конфигурацию и обзор технологии
https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/always-on-vpn-deploy-deployment
RAS VPN от Microsoft
Статья рассчитана на новых администраторов.
Насколько я помню эта фишка была вроде в 2003 винде.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc755473(v=ws.10)
И она работает только локально, а вот по рдп не зайдешь или есть способ?
Гениальное предложение хранить 1 пароль! И вот:
— что-то глюкануло и машина не входит в домен (бывало и не раз);
— или есть у тебя образ машины годовалой давности, а домена уже нет;
— или текущая [ОС\винчестер] [сломалась\заглючила\вирусы\хакеры] и есть у тебя образ машины месячной давности, и домен есть, но войти в него невозможно — за месяц утеряны доверительные отношения;
И что делать? Для того, чтобы дать команды — надо обладать правами админа на компе. Войти админом на компе не получится — машина не видит домен или домена вообще нет. Переустанавливать всё на компе? А если компов несколько?
Надо хорошо подумать о последствиях, прежде чем выбирать такой путь.
А как описанные ситуации связаны с хранением хэша? При восстановлении доверия вы все равно вводите пароль DA. Если нет сетевого доступа к контроллеру с локальной машины (машина вне сети предприятия) хэша DA там и не должно быть.
Администратору всегда приходится выбирать между удобством и безопасностью. Эти пункты обчно противоречат друг другу. Хранить хэш пароля учетки с правами администратора на всек компьютерах домена не слишком-то безопасно.
И не пойму, в чем проблема войти под локальным админом? Пароль локального администратора можно безопасно хранить в AD через тот же LAPS (https://winitpro.ru/index.php/2015/05/07/ms-local-administrator-password-solution-upravlenie-parolyami-lokalnyx-administratorov-v-domene/)
Либо всегда есть вариант со сбросом пароля лок админа, не думаю что описанные вами случаи происходят ежедневно
Почему не написали, что редактор реестра нужно запустить от имени системы, чтобы увидеть cache.
Скачать утилиту psexec и запустить редактор реестра: psexec.exe -i -d -s c:\windows\regedit.exe
Только после этого раскроется ветка — SECURITY.
Добрый день. Подскажите пожайлуста. Есть 1домен, 3 сайта AD Sites and Services ( по ип привязаны к географическому расположению). Хочу убрать 2 DC из одного сайта, но пока просто выключить, не удаляя. Как понимаю, запрос с клиентской машины в этом сайте будет от ДНС получать ип этих 2 КД, которые не отвечают. Т.е. не залогиниться на эти компы. Как заставить осуществить поиск инфх ДС по инфм сайтам?? Как вариант в ADSS создать новый сайт с ип-подсетью кторая включит все 3 локации ??? Спасибо.
Клиенты при недоступности DC в своем сайте через DCLocator найдут контроллеры домена в других сайтах. Да это будет долгий вход, но клиента на компьютер пустит. Главное, чтобы клиенты смотрели на живой DNS сервер. Например в качестве alternate для них можно задать DC в центральном сайте (офисе)
Либо, если вы не хотите автоперебора DC, вам ничего не мешает привязать подсеть клиентов к другому сайту с живыми DC. Основное, чтобы на клиентах работал DNS