Кэш входов в систему отключен
При входе на компьютер с доменной учетной записью пользователь вводит свои учетные данные, которые передаются на ближайший контроллер домена для проверки подлинности. Если в сетевом окружении отсутствуют доступные контроллеры домена, то учетные данные проверить некому и в систему пользователь войти не сможет.
Чтобы избежать подобной ситуации, после успешного входа в систему учетные данные пользователя сохраняются в кэш на локальном компьютере. Это позволяет войти в систему с доменными учетными данными и получить доступ к ресурсам локального компьютера даже при отсутствии подключения к домену.
Примечание. Если быть точным, то кэшируются не сами учетные данные (логин и пароль), а результат их проверки. Еще точнее система хранит хэш пароля, модифицированный при помощи соли (salt), которая в свою очередь, генерируется на основе имени пользователя. Кэшированные данные хранятся в разделе реестра HKLM\SECURITY\Cache, доступ к которому имеет только система.
За возможность кэширования отвечает параметр реестра CashedLogonsCount, находящийся в разделе HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon. Этот параметр определяет количество уникальных пользователей, чьи учетные данные сохраняются локально. По умолчанию значение параметра равно 10, что означает следующее: учетные данные сохраняются для последних 10 пользователей, заходивших в систему, а при входе на компьютер одиннадцатого пользователя учетные данные первого пользователя будут перезаписаны.
Управлять значением CashedLogonsCount можно централизованно, с помощью групповых политик. Для этого необходимо создать новый GPO (или открыть существующий), перейти в раздел 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).
По умолчанию данный параметр не определен (Not Defined), соответственно на всех компьютерах используется дефолтное значение. Для его изменения надо включить параметр и указать необходимое значение в пределах от 0 до 50. Значение, равное 0, означает запрет на кэширование учетных данных, соответственно при этом значении вход в систему при недоступности контроллера домена невозможен.
Поскольку теоретически при наличии физического доступа к компьютеру у злоумышленника есть возможность воспользоваться сохраненными учетными данными, то для повышения безопасности рекомендуется отключать локальное кэширование. Исключение могут составить пользователи мобильных устройств (ноутбуков, планшетов и т.п.), которые пользуются устройствами как на работе, так и вне ее. Для таких пользователей количество кэшированных входов можно задать в пределах 1-2. Этого вполне достаточно для работы.
И в завершение пара важных моментов:
• Для того, чтобы учетные данные были закешированы необходимо, чтобы пользователь хотя-бы раз зашел на компьютер под своей доменной учетной записью при доступном контроллере домена.
• Довольно часто параметр CashedLogonsCount трактуют как количество входов в систему при отсутствии доступа к домену. Это не так, и если учетные данные пользователя закешированы локально, то он сможет заходить в систему неограниченное количество раз.
Не удалось выполнить вход в систему, поскольку домен <ИМЯ_ДОМЕНА> недоступен
По умолчанию в домене, число входов на рабочую станцию в отсутствии связи с домен контроллером равно 10 раз вне зависимости, какая у Вас используется операционная система (Windows XP, Windows 7 и более старшие модели)
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\Winlogon\
Запущенный редактор реестра (Win + R и набрать regedit) для просмотра текущего значения :
Специально для таких сотрудников рекомендую создать отдельное подразделение (OU) в домене и поместить в неё имена компьютеров. И увеличить это значение до максимально возможного, т.е. пятидесяти (50).
Заходим на домен контроллер (dc1.polygon.local) под учётной записью ekzorchik (входит в группу Domain Admins).
Запускаем оснастку управления групповыми политиками – Group Policy Management :
«Start» – «Control Panel» – «Administrative Tools» – «Group Policy Management», далее развернём узел «Group Policy Objects» (Объекты групповой политики)
В моём случае это будет подразделение IT (в Вашем случаем создавайте/выбирайте нужное Вам).
Создадим групповую политику и назовём её: GPO_CacheLogonCount.
И так у нас создан шаблон, который по умолчанию привязан к контейнеру IT и применяем на всех пользователей прошедших проверку (Authenticated Users), но т.к. у нас отдельное подразделение добавим конкретно те имена компьютеров, которые работает вне домена с ноутбуками .
Должно получиться вот так:
Location : IT
Security Filtering : WXP86.polygon.local – станция которая обладаем возможности работать вне домена (ноутбук).
Заметка: Для удобства рабочие станции можно объединять в группы.
Т.к. политика будет распространяться на компьютеры, то редактируем соответствующий раздел:
«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)» (Интерактивный вход в систему: количество предыдущих подключений к кэшу (в случае отсутствия доступа к контроллеру домена)
Все политика настроена. Чтобы все изменения применились, следует перезагрузить компьютер, чтобы изменения вступили в силу.
И так, что мы имеем, увеличено количество входа в рабочую станцию вне офиса. А политикой мы разграничиваем тем сотрудникам, которые имеют согласование начальства работать удалённо или в командировках. Надеюсь, данный материал будет полезен всем заинтересованным лицам. На этом всё, удачи.
Используйте прокси ((заблокировано роскомнадзором, используйте vpn или proxy)) при использовании Telegram клиента:
Поблагодари автора и новые статьи
будут появляться чаще :)
Карта МКБ: 4432-7300-2472-8059
Большое спасибо тем кто благодарит автора за практические заметки небольшими пожертвованиями. С уважением, Олло Александр aka ekzorchik.
Предполагается, что клиентский компьютер имеет кэшированных заблокированной учетной записи в среде под управлением Windows Server 2008 R2 Active Directory доменных службах (AD DS). При попытке войти на компьютер с помощью смарт-карты, поведение отличается от поведения, возникающая при входе в систему, используя имя пользователя и пароль.
Рассмотрим следующие сценарии.
Пользователь не может войти в систему. Ваша учетная запись отключена. Обратитесь к системному администратору.
Отключите компьютер от среды AD DS, а затем повторите попытку входа.
Пользователь не может войти в систему. Домен недоступен. Повторите попытку позже.
Отключите компьютер от среды AD DS.
В этом случае вход в систему выполняется успешно, с помощью кэшированных учетных данных.
Причина
Решение
Сведения об исправлении
Существует исправление от корпорации Майкрософт. Однако данное исправление предназначено для устранения только проблемы, описанной в этой статье. Применяйте это исправление только в тех случаях, когда наблюдается проблема, описанная в данной статье. Это исправление может проходить дополнительное тестирование. Таким образом если вы не подвержены серьезно этой проблеме, рекомендуется дождаться следующего пакета обновления, содержащего это исправление.
Если исправление доступно для скачивания, имеется раздел "Пакет исправлений доступен для скачивания" в верхней части этой статьи базы знаний. Если этот раздел не отображается, обратитесь в службу поддержки для получения исправления.
Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Для получения полного списка телефонов поддержки и обслуживания клиентов корпорации Майкрософт, или для создания отдельного запроса на обслуживание, посетите следующий веб-сайт Майкрософт:
Примечание. В форме "Пакет исправлений доступен для скачивания" отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.
Предварительные условия
Это исправление необходимо использовать Пакет обновления 1 (SP1) для Windows Server 2008 R2. Сведения о получении пакета обновления Windows Server 2008 R2 просмотреть .
Система Windows может работать как автономно, так и в составе домена в роли сервера или рабочей станции.
Кэшированный вход в домен
Система Windows может работать как автономно, так и в составе домена в роли сервера или рабочей станции. Когда пользователь заходит на рабочую станцию, являющуюся частью домена, он может войти либо под локальным пользователем, либо под пользователем домена.При входе в домен пользователю необходимо знать следующую информацию: имя пользователя, пароль и доменное имя. Доменное имя, как правило, можно выбрать из выпадающего списка, который содержит название всех доменов, в которые входит система.
После ввода пользователем всей необходимой информации, система хеширует предоставленный пароль и по сети сверяет полученный хеш с хешем, хранящимся на контроллере домена в файле ntds.dit. Процедурой аутентификации руководит процесс lsass.exe.
В первую очередь LSASS проверяет, доступен ли контроллер домена. Если контроллер доступен, то процесс сверяет хеши паролей и, в зависимости от результата, разрешает или запрещает пользователю вход в систему.
Если же ни один контроллер домена недоступен, то легитимному пользователю домена не удастся войти в систему. Чтобы избежать подобных ситуаций, Microsoft задействовала в Windows механизм кэшированного входа в домен.
Microsoft дает такой комментарий о механизме:
В локальный кэш заносятся сведения обо всех предыдущих входах пользователей в систему, что позволяет им при последующих попытках войти в систему в случае отсутствия доступа к контроллеру домена […]
Следовательно, даже если контроллер домена недоступен, доменный пользователь все равно сможет зайти в систему. Требуется только, чтобы выполнилось два уcловия: пользователь удачно входил в систему ранее, и на системе включена политика кэширования входа в домен. На следующем скриншоте показано, где именно конфигурируется политика кэширования:
Локальные параметры безопасности (secpol.msc) / Локальные политики / Параметры безопасности / Интерактивный вход в систему: количество предыдущих подключений к кэшу (в случае отсутствия доступа к контроллеру домена)
(Local Security Policy (secpol.msc) / Local Policies / Security Options / Interactive logon: Number of previous logons to cashe (in case domain controller is unavailable))
Значение параметра политики вы также можете прочесть из ключа реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\CashedLogonCount. По умолчанию на системах Windows XP и выше в кэш заносятся сведения о 10 предыдущих входах. Информация о кэшированных входах хранится в кустах реестра HKEY_LOCAL_MACHINE/Security/CACHE/NL$X , где X – число. Получить доступ к кустам можно либо под пользователем Local System, либо с помощью специальных утилит.
Получение информации о кэшированном входе в домен
Хешированные пароли предыдущих входов в систему можно получить либо из файлов реестра, либо из памяти процесса lsass.exe.Чтобы получить хеши в оффлайн-режиме скопируйте системные файлы SYSTEM и SECURITY из реестра с помощью reg.exe/regedit.exe или посредством службы теневого копирования томов, как описывалось в первой статье. Извлечь информацию о кэшированных входах в домен из полученных файлов SYSTEM и SECURITY можно утилитами Cain & Abel, creddump от Брендана Долана-Гавита (Brendan Dolan-Gavitt) или Windows Password Recovery от passcape.
Также существует множество утилит, которые сольют информацию о кэшированном входе в домен, внедрившись в процесс lsass.exe. На 32-битных архитектурах вы можете воспользоваться fgdump, PWDumpX или cachedump от Арно Пилона (Arnaud Pilon). Последняя утилита стабильно работает и на последних версиях Windows. К сожалению, ни одна из бесплатных утилит не будет работать на 64-разрядных системах. Поэтому в подобных случаях, если на целевой 64-разрядной системе вам удастся запустить Meterpreter, то воспользуйтесь лучше модулем пост-эксплойта из Metasploit Framework.
Ниже показан результат работы cachedump на входящей в домен системе Windows:
C:\>cachedump.exe –v
Service not found. Installing CacheDump Service (C:\cachedump.exe -s)
CacheDump service successfully installed.
Service started.
user:2d9f0b052932ad18b87f315641921cda:lab:lab.internal
Service currently active. Stopping service.
Service successfully removed.
Какие угрозы влечет за собой получение информации из кэшированных входов в домен
Рассмотрим ситуацию, подобную ситуации с получением секретов LSA: допустим, вы скомпрометировали входящую в домен систему и получили доступ к командной строке с правами Local System. Никакой информации об учетных данных доменных пользователей в секретах LSA нет. Что же тогда делать дальше? Проверьте, кэширует ли система информацию о предыдущих входах пользователя в домен, и если да, то слейте кэш.В отличие от NT- и LM-хешей паролей, информацию из кэша нельзя напрямую использовать для аутентификации на других машинах. Хеши паролей можно взломать и получить пароль в незашифрованном виде, чтобы в дальнейшем аутентифицироваться на нужной машине. Более подробно о взломе хешей я расскажу в другой статье.
Сам по себе механизм кэшированного входа в домен достаточно полезен, поскольку он облегчает работу администраторов сети, когда контроллер домена по какой-либо причине недоступен. Но с точки зрения безопасности, такой механизм, безусловно, несет в себе угрозу безопасности.
Описанные в этой статье утилиты я добавил в таблицу. Буду рад вашим отзывам и предложениям!
Читайте также: