Как разблокировать доменный компьютер

Обновлено: 04.07.2024

Возможные причины блокировки пользователя в Active Directory

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

Из основных причин блокировки можно выделить:

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

Где настраивается политика блокировки учетных записей

Открываем редактор групповой политики, создаем новую политику, называем ее например Account Lockout Policy и щелкаем на нее правой кнопкой мыши и выбираем «Изменить».

Ставим время до сброса счетчика блокировки на 30 минут
Пороговое значение блокировки – 5 ошибок входа в систему
Продолжительность блокировки учетной записи – 30 минут.

Закрываем, применяем политику на домен и на целевой машине запускаем gpupdate /force

Как выяснить причину блокировки учетной записи

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

Снова открываем редактор групповой политики, создаем политику Audit Policy открываем ее и переходим по такому пути.

Конфигурация компьютера -> Политики -> Конфигурация Windows -> Параметры безопасности -> Локальные политики -> Политика аудита

Нам нужно включить аудит входа в систему, именно данная политика генерирует события 4771 и 4624. Настраиваем ее на «Успех и отказ».

Так же нужно задать политику аудита событий входа в систему на «Успех и отказ», а так же «Аудит управления учетными записями», чтобы видеть события 4740.

Принудительно обновляем политику и запускаем gpupdate /force на целевой машине

Какие события отслеживать в журнале безопасность

При некорректном вводе данных генерируется событие 4740, на всех контроллерах домена если он не один. С кодами отказов Kerberos:

6 – имя пользователя не существует
12 – Ограничение времени входа в систему
18 – Учетная запись деактивирована, заблокирована или истек срок ее действия
23 – Истек срок действия пароля пользователя
24 – Предварительная аутентификация не удалась(неверный пароль)
32 – Истек срок действия тикета
37 – Время компьютера давно не синхронизировалось с доменным

и кодами ошибок NTLM

Код ошибки (десятичная система) — Код ошибки (16-ричная система) — Описание

3221225572 — С0000064 — Такого имени пользователя не существует
3221225578 — С000006А — Верное имя пользователя, но неверный пароль
3221226036 — С0000234 — Учетная запись пользователя заблокирована
3221225586 — С0000072 — Учетная запись деактивирована
3221225583 — С000006Е — Пользователь пытается войти в систему вне обозначенного периода времени
3221225584 — С0000070 — Ограничение рабочей станции
3221225875 — С0000193 — Истек срок действия учетной записи
3221225585 — 0000071 — Истек срок действия пароля
3221226020 — С0000224 — Пользователь должен поменять пароль при следующем входе в систему

Как расследовать причину блокировки

Открываем журнал событий и идем в журнал безопасность (Security)» именно в нем собираются EventID которые могут помочь определить причину блокировки. Там очень много событий, так что отфильтруем их с помощью «Filter Current Log (Фильтр текущего журнала)», она позволит нам выбрать только те события, которые нам нужны. В поле Logged указываем за какой срок нужны данные, в поле Event ID указываем 4740 и нажимаем «Ок»

В отфильтрованных записях с помощью поиска (Find) находим имя интересующей нас учетной записи. В итоге должны отфильтроваться события по указанному логину с кодом 4740 в котором можно найти причину блокировки, например в поле Caller Computer Name будет указано имя компьютера с которого идут феилд логоны и который этим вызывает блокировку. Затем нужно перейти на этот компьютер и смотреть евент логи там, чтобы определить почему данная машина пытается залогиниться под некорректными кредами.

В событиях 4740 можно встреть еще такие причины блокировки как имя сервера, где происходит блокирование Exchange сервер организации – это значит, что проблема в Outlook, почтовом мобильном клиенте или его календарем. Чтобы расследовать данную блокировку нужно смотреть логи IIS на Exchange сервере. Так же можно использовать команду Get-ActiveSyncDeviceStatistics в PowerShell, чтобы увидеть проблемные мобильные устройства.

Microsoft ALTools

У компании Microsoft есть собственный инструмент для помощи в устранения проблем с блокировкой учетных записей - Microsoft Account Lockout and Management Tool (AlTools.exe). Download Account Lockout Status (LockoutStatus.exe) from Official Microsoft Download Center.

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

Запустите LockoutStatus.exe > File > Select target > Введите имя учетной записи и домен > OK

Он покажет все статусы связанные с блокировкой по данному аккаунту.

Инструмент EventCombMT

EventCombMT Tool собирает определенные события с нескольких различных серверов в одно центральное место.

Запустите EventCombMT.exe > Щелкните правой кнопкой мыши на поле Select to search > Выберите Get DCs in Domain > Отметьте контроллеры домена для поиска. - Нажмите меню Searches (Поиск) > Built In Searches (Встроенный поиск) > Account Lockouts (Блокировка учетных записей).

Другие причины блокировок пользовательских учетных записей

Если проблема локаута кроется в сервисах Google Workspaces (Gmail, Gdrive…) то в логах будет отображаться, что феилд логоны идут с компьютера WORKSTATION. Так же подробную информацию о блокировке можно посмотреть в событии 4771. Там можно найти Керберос коды, которые были описаны выше и IP адрес устройства с которого идут фейлд логоны.

Если в полях Caller Computer Name ивента 4770 и Client Address 4771 пусто – это значит что вас скорее всего брутфорсят!

Чтобы определить источник фейлд логонов в этом случае необходимо включить netlogon и смотреть его логи.

NETLOGON Netlogon - это процесс Windows Server, который аутентифицирует пользователей и другие службы в домене. Включите ведение журнала Netlogon: Пуск > Выполнить > введите:

nltest /dbflag:2080ffff > OK

После перезапуска службы Netlogon соответствующая активность может быть записана в %windir%/debug/netlogon.log.

Можно так же разобрать журналы Netlogon с помощью скрипта:

type netlogon.log |find /i "0xC000006A" > failedpw.txt type netlogon.log |find /i "0xC0000234" > lockedusr.txt

Внимание! Не забудьте отключить Netlogon после того, как вы зафиксировали события, так как производительность системы может быть немного снижена из-за процесса дебаггинга. Отключите ведение журнала Netlogon:

Пуск > Выполнить > введите:
nltest /dbflag:0 > OK

В логах можно найти айпишники тех компьютеров, с которых идут скрытые фейлд логоны, это могут быть терминальные сервера или RDP на которые ведется атака по перебору паролей.

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

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

Еще полезным будет изучение события 4625, там вы можете обнаружить процесс, из-за которого происходит блокировка учетных записей. Используйте Process Hacker или Process Monitor для просмотра учетных данных активных процессов.

Проблемой блокировки может быть планировщик задач Windows - возможно, есть задача, настроенная на запуск с использованием учетной записи, пароль к которой поменялся.

На локальной машине могут быть сохраненные учетные данные, найти которые можно так:

Пуск> Выполнить > rundll32 keymgr.dll, KRShowKeyMgr > OK.

Пуск> Выполнить > введите: netplwiz > OK Перейдите на вкладку Дополнительно, а затем нажмите Управление паролями.

Блокировку может вызывать сессия сервера терминалов с устаревшими учетными данными. Для отключения RDP сессии выполните следующие команды в командной строке (Win+R > "cmd"), заменив "server_ip", "name" и "password" на необходимые учетные данные:

net use \\server_ip /USER:name password

Это позволит вам войти на удаленный сервер без использования RDP.

query session /server:name

Замените "name" на имя сервера. Здесь вы получите идентификатор сессии.

reset session id /server:server_ip

Это завершает активную сессию на удаленном сервере.

Блокировку учетки может вызывать репликация AD, когда обновление пароля не было реплицировано на все контроллеры домена. Для принудительной репликации выполните следующую команду на вашем DC:

Локальный вход в систему или домен после перезагрузки компьютера под управлением операционной системы Windows, если никто не вошел в систему, может быть невозможен.

Компьютер используется и заблокирован.
Только или администратор может снять блокировку компьютера.
Для снятия блокировки нажмите Ctrl-Alt-Del.

Компьютер заблокирован. Снять блокировку может только или администратор.

Компьютер используется и заблокирован.
Снять блокировку может только домен\имя_пользователя или администратор.
Для снятия блокировки нажмите Ctrl-Alt-Del.

Компьютер заблокирован. Снять блокировку может только домен\имя_пользователя или администратор.

Причина

У подобного поведения могут быть следующие причины:

Для экранной заставки по умолчанию установлено использование несуществующей программы экранной заставки.

Использована поврежденная экранная заставка, защищенная паролем.

Решение

Внимание! В этом разделе, описании метода или задачи содержатся сведения об изменении реестра. Однако неправильное его изменение может привести к серьезным проблемам. Поэтому такие действия следует выполнять очень внимательно. Чтобы обеспечить дополнительную защиту, создайте резервную копию реестра. Это позволит восстановить реестр при возникновении неполадок. Дополнительные сведения о создании резервной копии и восстановлении реестра см. в следующей статье базы знаний Майкрософт:

322756 Как создать резервную копию и восстановить реестр в Windows
Для устранения этой проблемы используйте другую неповрежденную и установленную локально программу заставки (например, Logon.scr).

Запустите редактор реестра (Regedit32.exe).

Найдите значение в следующем разделе реестра:

В меню Правка выберите пункт Строка, введите logon.scr и нажмите кнопку ОК.

Найдите параметр ScreenSaverIsSecure.

В меню Правка выберите пункт Строка, введите 0 и нажмите кнопку ОК.

Закройте редактор реестра.

ВРЕМЕННОЕ РЕШЕНИЕ

Для решения этой проблемы воспользуйтесь соответствующим способом.

Нажмите сочетание клавиш CTRL+ALT+DELETE для снятия блокировки.

Введите учетные данные последнего вошедшего в систему пользователя и нажмите кнопку ОК.

После исчезновения диалогового окна Снятие блокировки компьютера нажмите клавиши CTRL+ALT+DELETE и войдите в систему, как обычно.

С помощью средства выключения в наборе Microsoft Windows Resource Kit выключите заблокированный компьютер. На заблокированном компьютере отображается диалоговое окно Завершение работы системы, но перезагрузка компьютера не происходит.

По истечении времени завершения работы отображается диалоговое окно Операционная система Windows.

До активизации экранной заставки нажмите сочетание клавиш CTRL+ALT+DELETE и войдите в систему обычным образом.

ПРИМЕЧАНИЕ. Если для входа в систему не используется ни один из этих способов, необходимо перезагрузить компьютер и войти в систему до запуска программы экранной заставки.

26.05.2020

Active Directory, PowerShell

комментария 74

В этой статье мы покажем, как отслеживать события блокировки учеток пользователей на котроллерах домена Active Directory, определять с какого компьютера и из какой конкретно программы постоянно блокируется учетная запись пользователя. Для поиска источника блокировки аккаунтов пользователей можно использовать журнал безопасности Windows, скрипты PowerShell или утилиту Account Lockout and Management Tools (Lockoutstatus.exe).

Учетная запись пользователя заблокирована и не может быть использована для входа в сеть

Политика безопасности учетных записей в большинстве организаций требует обязательного блокирования учетной записи пользователя в домене Active Directory, если он несколько раз подряд ввел неправильный пароль. Обычно учетная запись блокируется контроллером домена на несколько минут (5-30), в течении которых вход пользователя в домен невозможен. Через определение время (задается в политике безопасности домена), учетная запись пользователя автоматически разблокируется. Временная блокировка учетной записи позволяет снизить риск подбора пароля (простым брутфорсом) к учетным записям пользователей AD.

Если учётная запись пользователя в домене заблокирована, то при попытке входа в Windows появляется предупреждение:

Учетная запись пользователя заблокирована и не может быть использована для входа в сеть The referenced account is currently locked out and may not be logged on to ….

Как проверить, что аккаунт пользователя AD заблокирован?

Вы можете проверить, что аккаунт заблокирован в графический консоли ADUC или с помощью комнадлета Get-ADUser из модуля Active Directory для PowerShell:

Get-ADUser -Identity aaivanov -Properties LockedOut,DisplayName | Select-Object samaccountName, displayName,Lockedout

Учетная запись сейчас заблокирована и не может быть использована для авторизации в домене (Lockedout = True).

Можно вывести сразу все заблокированные аккаунты в домене с помощью Search-ADAccount:

Вы можете вручную снять блокировку учетной записи с помощью консоли ADUC, не дожидаясь автоматической разблокировки. Для этого в свойствах учетной записи пользователя на вкладке Account, включите опцию Unlock account. This account is currently locked out on this Active Directory Domain Controller (Разблокируйте учетную запись. Учетная запись на этом контроллере домена Active Directory на данный момент заблокирована) и сохраните изменения.

Также можно немедленно разблокировать учетную запись с помощью следующей команды PowerShell:

Get-ADUser -Identity aaivanov | Unlock-ADAccount

Информацию о времени блокировки учетной записи, количестве неудачных попыток набора пароля, времени последней успешной авторизации можно получить в свойствах учетной записи в консоли ADUC на вкладке редактора атрибутов или с помощью PowerShell

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

Политики блокировки учетных записей и паролей обычно задаются сразу для всего домена политикой Default Domain Policy в консоли gpmc.msc. Интересующие нас политики находятся в разделе Computer Configuration -> Windows Settings -> Security Settings -> Account Policy -> Account Lockout Policy (Конфигурация Windows -> Параметры безопасности -> Политики учетных записей -> Политики блокировки учетных записей). Это политики:

Accountlockoutthreshold (Пороговое значение блокировки) – через сколько неудачных попыток набора пароля учетная запись должна быть заблокирована;
Account lockout duration (Продолжительность блокировки учетной записи) – на какое время будет заблокирована учетная запись (по истечении этого времени блокировка будет снята автоматически);
Reset account lockout counter after (Время до сброса счетчика блокировки)– через какое время будет сброшен счетчик неудачных попыток авторизации.

Для защиты от перебора паролей рекомендуется использовать стойкие пароли пользователей в AD (использовать длину пароля не менее 8 символов и включить требования сложности. Это настраивается в разделе Password Policy в политиках Password must meet complexity requirements и Minimum password length. Периодически нужно выполнять аудит паролей пользователей.

Ситуации, когда пользователь забыл свой пароль и сам вызвал блокировку своей учетки случаются довольно часто. Но в некоторых случаях блокировка учеток происходит неожиданно, без каких-либо видимых причин. Т.е. пользоваться “клянется”, что ничего особого не делал, ни разу не ошибался при вводе пароля, но его учетная запись почему-то заблокировалась. Администратор по просьбе пользователя может вручную снять блокировку, но через некоторое время ситуация повторяется.

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

Политики аудита входа на DC

Чтобы в журналах контроллеров домена записывались события блокировки учетных записей, нужно включить следующие подкатегории аудита на контроллерах домена в секции Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy -> Logon/Logoff:

Audit Account Lockout
Audit Logon
Audit Logoff

Проще всего включить эту политику через консоль gpmc.msc, отредактировав политику Default Domain Controller Policy, либо на уровне всего домена с помощью Default Domain Policy.

EventID 4740: событие блокировки учетной записи

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

Если пользователь ввел неверный пароль, то ближайший к пользователю контроллер домена перенаправляет запрос аутентификации на DC с FSMO ролью эмулятора PDC (именно он отвечает за обработку блокировок учетных записей). Если проверка подлинности не выполнилась и на PDC, он отвечает первому DC о невозможности аутентификации. Если количество неуспешных аутентификаций превысило значение, заданное для домена в политике Account lockout threshold, учетная запись пользователя временно блокируется.

При этом в журнале обоих контроллеров домена фиксируются событие с EventID 4740 с указанием DNS имени (IP адреса) компьютера, с которого пришел первоначальный запрос на авторизацию пользователя. Чтобы не анализировать журналы на всех DC, проще всего искать это события в журнале безопасности на PDC контроллере. Найти PDC в домене можно так:

Событие блокировки учетной записи домена можно найти в журнале Security (Event Viewer > Windows Logs) на контролере домена. Отфильтруйте журнал безопасности (Filter Current Log) по событию с Event ID 4740. Должен появиться список последних событий блокировок учетных записей контроллером домена. Переберите все события, начиная с самого верхнего и найдите событие, в котором указано, что учетная запись нужного пользователя (имя учетной записи указано в строке Account Name) заблокирована (A user account was locked out).

Примечание. В большой инфраструктуре AD, в журнале безопасности фиксируется большое количество событий, которые постепенно перезаписываются более новыми. Поэтому желательно увеличить максимальный размер журнала на DC и приступать к поиску источника блокировки как можно раньше.

Откройте данное событие. Имя компьютера (или сервера), с которого была произведена блокировка указано в поле Caller Computer Name. В данном случае имя компьютера – TS01.

Поиск компьютера/сервера, с которого блокируется пользователь с помощью PowerShell

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

$Username = ‘username1’
$Pdce = (Get-AdDomain).PDCEmulator
$GweParams = @‘Computername’ = $Pdce
‘LogName’ = ‘Security’
‘FilterXPath’ = "*[System[EventID=4740] and EventData[Data[@Name='TargetUserName']='$Username']]"
>
$Events = Get-WinEvent @GweParams
$Events | foreach

$Username = ‘username1’
Get-ADDomainController -fi * | select -exp hostname | % $GweParams = @‘Computername’ = $_
‘LogName’ = ‘Security’
‘FilterXPath’ = "*[System[EventID=4740] and EventData[Data[@Name='TargetUserName']='$Username']]"
>
$Events = Get-WinEvent @GweParams
$Events | foreach
>

Утилита Microsoft Account Lockout and Management Tools

Запустите утилиту Lockoutstatus.exe, укажите имя заблокированной учетной записи (Target User Name) и имя домена (Target Domain Name).

В появившемся списке будет содержаться список DC и состояние учетной записи (Locked или Non Locked). Дополнительно отображается время блокировки и компьютер, с которого заблокирована данная учетная запись (Orig Lock).

Атрибуты badPwdCount и LastBadPasswordAttempt не реплицируются между контролерами домена.

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

Основной недостаток утилиты LockoutStatus – она довольно долго опрашивает все контроллеры домена (некоторые из них могут быть недоступны).

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

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

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

Монтирование сетевого диска через net use (Map Drive);
В заданиях планировщика Windows (Task Scheduler);
В службах Windows, которые настроены на запуск из-под доменной учетной записи;
Сохранённые пароли в менеджере паролей в панели управления (Credential Manager);
Браузеры;
Мобильные устройства (например, использующееся для доступа к корпоративной почте);
Программы с автологином или настроенный автоматический вход в Windows;
Незавершенные сессии пользователя на других компьютерах или терминальных серверах (поэтому желательно настраивать лимиты для RDP сессий);
Если пользователь недавно сменил пароль и забыл его, вы можете сбросить его.

Совет. Существует ряд сторонних утилит (в основном коммерческих) позволяющих администратору выполнить проверку удаленной машины и детектировать источник блокировки учетных записей. В качестве довольно популярного решения отметим Account Lockout Examiner от Netwrix.

Для более детального аудита блокировок на найденном компьютере необходимо включить ряд локальных политик аудита Windows. Для этого на локальном компьютере, на котором нужно отследить источник блокировки, откройте редактор групповых политик gpedit.msc и в разделе Compute Configurations -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy включите политики:

Audit process tracking: Success , Failure
Audit logon events: Success , Failure

Дождитесь очередной блокировки учетной записи и найдите в журнале безопасности (Security) события с Event ID 4625. В нашем случае это событие выглядит так:

Из описания события видно, что источник блокировки учетной записи – процесс mssdmn.exe (является компонентом Sharepoint). Осталось сообщить пользователю о том, что ему необходимо обновить свой пароль на веб-портале Sharepoint.

После окончания анализа, выявления и наказания виновника не забудьте отключить действие включенных групповых политик аудита.

Если вы так и не смогли найти причину блокировки учетной записи на конкретном компьютере, попробуйте просто переименовать имя учетной записи пользователя в Active Directory. Это как правило самый действенный метод защиты от внезапных блокировок определенного пользователя, если вы не смогли установить источник блокировки.

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

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

Примечание. Если быть точным, то кэшируются не сами учетные данные (логин и пароль), а результат их проверки. Еще точнее система хранит хэш пароля, модифицированный при помощи соли (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 трактуют как количество входов в систему при отсутствии доступа к домену. Это не так, и если учетные данные пользователя закешированы локально, то он сможет заходить в систему неограниченное количество раз.

Читайте также: