Categoryinfo ошибка безопасности parentcontainserrorrecordexception

Операционная система: Windows 7 64bit (недавно переустановил)

Версия PowerShell 3.0

Моя учётная запись единственная в системе имеет права админа

Понадобилось запустить скрипты powerShell (написанные мною). При запуске скрипта (F5) PowerShell ISE ругается следующим сообщением:

«Невозможно загрузить файл D:Test.ps1, так как выполнение сценариев отключено в этой системе. Для получения дополнительных сведений см. about_Execu
tion_Policies по адресу http://go.microsoft.com/fwlink/?LinkID=135170.
    + CategoryInfo          : Ошибка безопасности: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : UnauthorizedAccess»

Запустил консоль PowerShell (64bit) с правами админа: установил executionpolicy на Unrestricted

Перезагрузил ПК, в консоли PowerShell проверил политику безопасности (get-executionpolicy), получил ответ: Unrestricted

Запустил PowerShell ISE, создал новый скрипт, вставил в него код из двух строк, сохранил на диске. Нажал Выполнить (F5) — получил такую же ошибку:

«Невозможно загрузить файл D:Test2.ps1, так как выполнение сценариев отключено в этой системе. Для получения дополнительных сведений см. about_Execu
tion_Policies по адресу http://go.microsoft.com/fwlink/?LinkID=135170.
    + CategoryInfo          : Ошибка безопасности: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : UnauthorizedAccess»

Перезагружался несколько раз уже, устанавливал разные политики — всё без результатно. В чём может быть проблема? Раньше до переустановки Windows всё работало. Версия Ос была такая же, обновления стояли все последние, версия powershell была 2.0 (в ней устанавливалась
политика на RemoteSigned) и после этого powershell был обновлён до 3.0. Но по-прежнему скрипты работали без проблем.

Невозможно загрузить файл c:scriptsMyScript.ps1, так как выполнение
 сценариев отключено в этой системе. Для получения дополнительных сведений
 см. about_Execution_Policies по адресу https:/go.microsoft.com/fwlink/?LinkID=135170.
    + CategoryInfo          : Ошибка безопасности: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : UnauthorizedAccess

File c:scriptsMyScript.ps1 cannot be loaded because running scripts is disabled on
 this system. For more information, see about_Execution_Policies at
 https:/go.microsoft.com/fwlink/?LinkID=135170.
    + CategoryInfo : SecurityError: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

Сообщение говорит о том, что не хватает прав для запуска скрипта — работает текущая политика безопасности PowerShell. Существуют следующие уровни настройки безопасности: AllSigned, Bypass, Default, RemoteSigned, Restricted, Undefined, Unrestricted. Самое распространенное состояние политики, когда появляется такая ошибка — Restricted.

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

powershell Set-ExecutionPolicy Unrestricted

Чтобы узнать текущее состояние политики, запустите следующую команду:

powershell Get-ExecutionPolicy

В этой статье мы покажем, как отслеживать события блокировки учетных записей пользователей на котроллерах домена 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

Или:

Get-ADUser avivanov2 -Properties Name,Lockedout, lastLogonTimestamp,lockoutTime,logonCount,pwdLastSet | Select-Object Name, Lockedout,@{n='LastLogon';e={[DateTime]::FromFileTime($_.lastLogonTimestamp)}},@{n='lockoutTime';e={[DateTime]::FromFileTime($_.lockoutTime)}},@{n='pwdLastSet';e={[DateTime]::FromFileTime($_.pwdLastSet)}},logonCount

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

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

Search-ADAccount -UsersOnly -lockedout

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

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

Get-ADUser -Identity aaivanov | Unlock-ADAccount

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

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

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

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

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

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

События блокировки пользователей EventID 4740, 4625

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

• Audit Account Lockout
• Audit Logon
• Audit Logoff

Затем перейдите в раздел Account Management и включите политику:

• Audit User Account Management: Success

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

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

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

(Get-AdDomain).PDCEmulator

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

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

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

Если в поле Computer Name указано неизвестное имя компьютера/устройства, который не резолвится в вашей сети через DNS (недоменный компьютер, или не Windows устройство с поддержкой Kerberos аутентфикации), вы можете получить IP адрес этого устройства. Для этого нужно включить следующие параметры аудита в Default Domain Controller Policy. Перейдите в раздел Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Configuration и настройте следующие параметры:

Account Logon

• Audit Kerberos Authentication Service: Success, Failure
• Audit Kerberos Service Ticket Operations: Success, Failure

Logon/Logoff

• Audit Special Logon: Success, Failure

Откройте журнал Event Viewer -> Security и включите фильтр по Event ID 4740 и 4741. Обратите внимание, что теперь перед появлением события блокировки пользователя (4740) появляется событие 4771 (неуспешная kerberos аутентфикация) от Kerberos Authentication Service. В нем указано имя пользователя, который пытался выполнить аутентификацию и IP адрес устройства (поле Network Information -> Client Address), с которого пришел запрос.

Если удаленное устройство использует NTLM для аутентификации в домене, нужно выполнить поиск события EventID 4625 (неуспешная NTLM аутентификация) на контроллерах домена (оно появится только на DC, через который была выполнена попытка аутентифицироваться через NTLM).

Откройте последнее найденное событие с EventID 4625 для вашего пользователя (Account name). Здесь видно, что при попытке выполнить NTLM аутентификацию (Authentication Package: NTLM, Logon Process: NtLmSsp) учетная запись была заблокирована (
Failure Reason: Account locked out, Status: 0xC0000234
). В описании события указаны как имя компьютера (Workstation Name), так и его IP адрес (Source Network Address).

Если вы не можете найти событие блокировки пользователя в журнале Event Viewer, можно включить расширенный лог netlogon на контроллере домена. Выполните команду:

nltest /dbflag:2080ffffff

Перезапустите службу Netlogon

net stop netlogon && net start netlogon

Выполните поиск в файле netlogon.log событий:

• 0xc000006a – An invalid attempt to login has been made by the following user
• 0xc0000234 – The user account has been automatically locked because too many invalid logon attempts or password change attempts have been requested.

Можно найти события блокировки пользователя a.berg в файле netlogon.log с помощью команды:

type C:Windowsdebugnetlogon.log | findstr a.berg| findstr /i "0xC000006A"

В данном примере видно, что пользователь a.berg блокируется с устройства DESKTOP-74G6LB.

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

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

$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 {$_.Properties[1].value + ' ' + $_.TimeCreated}

Аналогичным образом можно опросить из PowerShell все контроллеры домена в Active Directory:

$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 {$_.Computer + " " +$_.Properties[1].value + ' ' + $_.TimeCreated}
}

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

Для поиска источника блокировки пользователя можно использовать графическую утилиту Microsoft Account Lockout and Management Tools —
Lockoutstatus.exe
(скачать ее можно тут). Данная утилита проверяет статус блокировки учетной записи на всех контроллерах домена.

Запустите утилиту 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;
• Ярлыки с настроенным режимом
  RunAs
  (используется для запуска от имени другого пользователя);
• В службах Windows, которые настроены на запуск из-под доменной учетной записи;
• Сохранённые пароли в менеджере паролей в панели управления (Credential Manager). Выполните команду
  rundll32.exe keymgr.dll, KRShowKeyMgr
  и удалите сохраненные пароли;

  Пароли пользователей могут быть сохранены в контексте SYSTEM. Чтобы вывести их, нужно запустить командную строку от имени SYSTEM с помощью
  psexec -i -s -d cmd.exe
  и выполнить команду
  rundll32 keymgr.dll,KRShowKeyMgr
  чтобы открыть список сохраненных паролей для NT AUTHORITYSYSTEM.

• Программы, которые хранят и используют закэшировнный пароль пользователя;
• Браузеры;
• Мобильные устройства (например, использующееся для доступа к корпоративной почте);
• Программы с автологином или настроенный автоматический вход в Windows;
• Незавершенные сессии пользователя на других компьютерах или терминальных RDS фермах или RDP серверах (поэтому желательно настраивать лимиты для RDP сессий);
• Сохраненные пароли для подключения к Wi-FI сетям (WPA2-Enterprise 802.1x аутентификацию в беспроводной сети);
• Если пользователь недавно сменил пароль и забыл его, вы можете сбросить его.

Совет. Существует ряд сторонних утилит (в основном коммерческих) позволяющих администратору выполнить проверку удаленной машины и детектировать источник блокировки учетных записей. В качестве довольно популярного решения отметим 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

Затем обновите настройки групповых политик на клиенте:

gpupdate /force

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

An account failed to log on.
Failure Reason: Account locked out.

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

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

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