как узнать где залогинен пользователь Ad

Вход и выход из системы (logon/logoff)

Event Id — Описание

528 или 4624 — Успешный вход в систему529 или 4625 — Отказ входа в систему – Неизвестное имя пользователя или неверный пароль 530 или 4625 Отказ входа в систему – Вход в систему не был осуществлен в течение обозначенного периода времени531 или 4625 — Отказ входа в систему – Учетная запись временно деактивирована 532 или 4625 — Отказ входа в систему – Срок использования указанной учетной записи истек533 или 4625 — Отказ входа в систему – Пользователю не разрешается осуществлять вход в систему на данном компьютере 534 или 4625 или 5461 — Отказ входа в систему – Пользователь не был разрешен запрашиваемый тип входа на данном компьютере535 или 4625 — Отказ входа в систему – Срок действия пароля указанной учетной записи истек539 или 4625 — Отказ входа в систему – Учетная запись заблокирована540 или 4624 — Успешный сетевой вход в систему (Только Windows 2000, XP, 2003)

Идентификатор события блокировки учётной записи 4740

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

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

Если аутентификация на PDC завершается неудачно, он отвечает на первый DC, что аутентификация невозможна. Если количество неудачных проверок подлинности превышает значение, установленное для домена в политике Account Lockout Threshold (Пороговое значение блокировки), учётная запись пользователя временно блокируется.

Похожее: Как работает безопасная сделка на юле —

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

(Get-AdDomain).PDCEmulator

События блокировки учётной записи домена можно найти в журнале безопасности на контроллере домена. Чтобы его увидеть, запустите Event Viewer («Просмотр событий»), его можно открыть в командной строке:

eventvwr.msc

В окне Event Viewer («Просмотр событий») перейдите по пути Event Viewer (Local) → Windows Logs → Security (в русскоязычной версии это Просмотр событий (локальный) → Журналы Windows → Безопасность).

В Event Viewer («Просмотр событий») отфильтруйте журнал безопасности по Event ID («Код события») указав значение 4740, для этого нажмите Filter Current Log («Фильтр текущего журнала») и введите в поле <

Как отследить, какой процесс блокирует учётную запись домена

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

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

Подключённые сетевые диски (через net use);
Работы Windows Task Scheduler (Планировщика заданий Windows);
Службы Windows, настроенные для запуска из учётной записи домена;
Сохранённые учётные данные в Credential Manager (Диспетчере учётных данных) (в Панели управления);
Браузеры;
Мобильные устройства (например, те, которые используются для доступа к корпоративному почтовому ящику);
Программы с автоматическим входом или настроенная функция автоматического входа в Windows;
Отключённые/незанятые сеансы RDP на других компьютерах или серверах RDS (поэтому рекомендуется установить ограничения для сеансов RDP);

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

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

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

В русскоязычной версии это соответственно: Конфигурации компьютера → Конфигурация Windows → Параметры безопасности → Локальные политики → Политика аудита:

Аудит отслеживания событий: Успех, Отказ
Аудит событий входа в систему: Успех, Отказ

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

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

На русском это:

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

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

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

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

Вы также можете вывести список событий с кодом 4625 в PowerShell:

Get-WinEvent -FilterHashtable @{ LogName='Security'; Id='4625'; }

Следующую команду вы можете использовать для вывода событий блокировки для конкретного пользователя (впишите его вместо MiAl):

Get-WinEvent -FilterHashtable @{ LogName='Security'; Id='4625'; Data="MiAl" }

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

Get-WinEvent -FilterHashtable @{ LogName='Security'; Id='4625'; Data="MiAl" } | Format-List

Эта команда аналогична предыдущей, но покажет события только за последние 2 дня:

$Date = (Get-Date).AddDays(-2); Get-WinEvent -FilterHashtable @{ LogName='Security'; Id='4625'; Data="MiAl"; StartTime=$Date; } | Format-List

Связанные статьи:

Коды отказов kerberos

Код ошибки — Причина

6 — Имя пользователя не существует12 — Ограничение рабочей машины; ограничение времени входа в систему18 — Учетная запись деактивирована, заблокирована или истек срок ее действия23 — Истек срок действия пароля пользователя24 — Предварительная аутентификация не удалась; обычно причиной является неверный пароль32 — Истек срок действия заявки.

Коды ошибок ntlm

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

3221225572 — C0000064 — Такого имени пользователя не существует3221225578 — C000006A — Верное имя пользователя, но неверный пароль3221226036 — C0000234 — Учетная запись пользователя заблокирована3221225586 — C0000072 — Учетная запись деактивирована3221225583 — C000006F — Пользователь пытается войти в систему вне обозначенного периода времени (рабочего времени)

3221225584 — C0000070 — Ограничение рабочей станции3221225875 — C0000193 — Истек срок действия учетной записи3221225585 — C0000071 — Истек срок действия пароля3221226020 — C0000224 — Пользователь должен поменять пароль при следующем входе в систему

Локально при входе пользователя

Можно создать политику, которая будет запускать скрипт при входе и экспортировать в CSV. Сам файл CSV может находится на удаленном компьютере. Следующая команда сделает это записав данные в конец существующий файл (т.е. не перезапишет файл):

Получится примерно следующий вид файла:

Мониторим пользователей ad на коленке и бесплатно

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

ПО такое есть, оно сложное и обычно стоит денег. Будем клепать свое и на коленке.

Найти время последнего входа в систему с помощью powershell

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

Для этого вам нужно использовать Модуль Active Directory для Windows PowerShell.

Установите этот модуль и импортируйте его в сеанс PowerShell:

Import-Module ActiveDirectory

Определить дату последнего входа в систему linux — сайт одного devopsa

Команда lastlog хранит информацию о последнем входе пользователя в систему, но он предоставит информацию только по тем логам, которые имеются в файле wtmp. Записи в данном файле делаются в двоичном формате, так что просматривать их можно только с помощью специальных команд. Думаю многие из Вас обращали внимание на то, что когда Вы авторизируетесь в консоли, на экране появляется примерно следующее сообщение:

Last login: Wed Nov 11 13:19:44 on ttys002

Эта строка формируется утилитой login, которая после авторизации пользователя обращается к файлу /var/log/lastlog, извлекает оттуда информацию о предыдущем успешном входе, выдает ее на экран, а затем обновляет запись в файле lastlog. В отличие от файла /var/log/lastlog, который содержит записи о времени последнего входа в систему каждого пользователя, в файле /var/log/wtmp запоминаются все входы и выходы пользователей в систему с момента создания этого файла.

Что бы посмотреть данные по конкретному пользователю необходимо использовать следующую команду last xxx, где ххх — логин пользователя. А использование команды сортировки head с параметром 5 в свою очередь поможет Вам отобразить на экране только 5 последних результатов:

last | head -5

root pts/0 193.178.187.30 Wed Nov 11 14:21 still logged in
tuto ftpd3292 ::ffff:176.104.0 Wed Nov 11 11:11 - 11:15 (00:04)
tuto ftpd29523 ::ffff:176.104.0 Tue Nov 10 18:58 - 19:03 (00:04)
naturcok ftpd23502 ::ffff:176.104.0 Tue Nov 10 13:55 - 13:55 (00:00)
naturcok ftpd20228 ::ffff:176.104.0 Tue Nov 10 13:50 - 13:55 (00:05)

Как “глубоко” Вы можете просмотреть историю последних команд зависит от того как долго существует файл wtmp. Например, Вы можете использовать утилиту logrotate, которая следит за файлами протоколов и обеспечивает так называемую ротацию этих файлов в случае, если они превысили указанный размер (или по истечению указанного временного интервала). Также она позволяет поддерживать более одного wtmp файл и имеет запись в logrotate.conf наподобие этой:

/var/log/wtmp {
monthly
create 0664 root utmp
minsize 1M
rotate 1
}

Даже имея несколько файлов wtmp, данные некоторых Ваших пользователей могут просто не отобразиться. Если в результате индивидуальной проверки пользователя Вы никаких данных по нем не получили, то это означает, что записей по конкретному пользователю в файле wtmp нет. Чтобы узнать дату создания файла wtmp, следует ввести в консоли last mia:

last mia

wtmp begins Thu Sep 17 16:10:00 2022

Лучшим способом найти информацию о последнем входе в систему для каждого пользователя является использование команды lastlog. Если какой-либо из пользователей никогда не авторизировался в системе, то вместо имени терминала и времени последнего входа будет указана строка **Never logged in**. Если результат вывода будет состоять из большого количества строк, то можете использовать еще и команду more, которая в отличие от команды less, выведет содержимое файла на экран отдельными страницами. Результат будет выглядеть примерно так:

lastlog | more

Username Port From Latest
root pts/0 xxx.xxx.xxx.xxx Wed Nov 11 14:21:59  0200 2022
bin **Never logged in**
daemon **Never logged in**
adm **Never logged in**
ispmaster pts/0 xxx.xxx.xxx.xxx Thu Nov 5 17:00:44  0200 2022

Многие из нас возможно будут удивлены, увидев, что bin, daemon, adm и другие служебные учетные записи никогда не авторизировались в системе. Это и в самом деле так, и означает лишь только то, что для оболочек, назначенных в момент регистрации пользователей (login shells), задан параметр /sbin/nologin, что делает авторизацию невозможной. Остальные данные по входам показывают дату и время системы, с которой была осуществлена авторизация.

Чтобы создать список всех учетных записей, которые никогда не входили в систему, стоит использовать следующий набор команд. С командой lastlog мы уже знакомы и я на ней подробно останавливаться не буду, дальше стоит добавить утилиту grep для поиска по ключевому слову, в нашем случаи это слово Never, а для того, чтобы выводился только первый столбец с данными, можно воспользоваться утилитой awk со следующим синтаксисом — ‘{print $1}’:

lastlog | grep Never | awk '{print $1}'
bin
daemon
adm
. . .
ntp
user1819
user1939

Записи в lastlog перечислены согласно идентификаторов пользователей (User identifier — UID) — от суперпользователя (root) до пользователя с самым большим значением UID в Вашем файле /etc/passwd. Это связано с форматом самого файла lastlog. В отличие от большинства лог-файл Unix, в файле lastlog для записи логов каждого пользователя резервируется отдельное место, и в свою очередь место каждой записи проиндексировано по UID. После этого файлы будут фиксированного размера, особенно если Ваша система имеет аккаунты с наивысшим лимитом своего возможного диапазона UID — такого как 16-битный UID 65536. Также при этом образуется большой объем неиспользуемого пространства, правда только в том случаи если Ваши идентификаторы не являются строго последовательными. Если же Ваша система поддерживает 32-битные UIDы, файл может быть очень большим и иметь 4 294 967 296 (232) различных значений идентификаторов.

Каждая запись в файле lastlog содержит имя пользователя, имя терминала, с которого вошел пользователь и время последнего входа в систему. Запись для суперпользователя (UID 0) в верхней части файла может иметь следующий вид:

od -xc /var/log/lastlog | more

0000000 fba3 563d 7470 2f73 0030 0000 0000 0000
243 373 = V p t s / 0       
0000020 0000 0000 0000 0000 0000 0000 0000 0000
               
0000040 0000 0000 3138 392e 2e35 3831 2e34 3532
    8 1 . 9 5 . 1 8 4 . 2 5
0000060 0034 0000 0000 0000 0000 0000 0000 0000
4               
0000100 0000 0000 0000 0000 0000 0000 0000 0000

При выполнении команды lastlog на некоторых компьютерах в определенных случаях может возникнуть впечатление, что команда «зависла». Это происходит в силу того, что даже если в системе зарегистрировано всего два пользователя (root и user), в файле /var/log/lastlog все равно отведено место для максимально возможного числа пользователей, которые могут работать в системе. Поэтому в файле /var/log/lastlog могут иметься большие промежутки между номерами идентификаторов работавших в системе пользователей. Поскольку при просмотре таких интервалов программа не выводит информацию на экран, и возникает впечатление «зависания». Потому не спешите нажимать кнопки и закрывать консоль, а дождитесь ответа команды.

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

Полезные ключи командлета get-adcomputer

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

Import-Module activedirectory

Теперь можно получить справку по команду Get-ADComputer, через команду:

Get-Help Get-ADComputer

Как видите, у команды очень много ключей и богатые возможности.

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

Get-ADComputer -Identity DESKTOP-2C4R0V6

В данном выводе команды вы увидите основные значения:

Если вам вдруг не хватает данных, то вы можете вывести все доступные поля.

Get-ADComputer -Identity DESKTOP-2C4R0V6 -Properties *

Если хотите вывести конкретные поля, то выполните вот такую конструкцию, через | перечисляются нужные поля

Get-ADComputer -identity DESKTOP-2C4R0V6 -Properties * | FT Name, LastLogonDate -Autosize

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

Get-ADComputer -Filter * -Properties * | FT Name, LastLogonDate -Autosize

Выберем все компьютеры с операционной системой Windows 10

Get-ADComputer -Filter { OperatingSystem -Like ‘*Windows 10*’ } -Properties OperatingSystem | Select Name, OperatingSystem | Format-Table -AutoSize | Out-File C:Scriptserver_system.txt

На выходе получаем файл со списком компьютеров.

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

Политики аудита входа в систему для контроллеров домена

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

Audit Account Lockout
Audit Logon
Audit Logoff

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

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

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

Обратите внимание, что для использования параметров «Конфигурация расширенной политики аудита» также необходимо в Локальной политике безопасности (secpol.msc) включить по пути Параметры безопасности → Локальные политики → Параметры безопасности параметр «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии)».

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

Политики блокировки учётных записей обычно устанавливаются в Default Domain Policy для всего домена с помощью оснастки gpmc.msc. Необходимые политики можно найти в Computer configuration→ Policies→ Windows Settings → Security Settings → Account Policies → Account Lockout Password (в русскоязычной версии это соответственно Конфигурация компьютера → Политики → Конфигурация Windows → Параметры безопасности → Политики учетных записей → Политика блокировки учётной записи). Это следующие политики:

Account Lockout Threshold (Пороговое значение блокировки) – количество неудачных попыток входа в систему (с неправильным паролем), которое может быть выполнено пользователем до блокировки его учётной записи;
Account Lockout Duration (Продолжительность блокировки учётной записи) — как долго будет заблокирована учётная запись, если пользователь несколько раз ввёл неверный пароль;
Reset account lockout counter after (Время до сброса счётчика блокировки) — количество минут, по истечении которых счётчик порога блокировки учётной записи будет сброшен.

Чтобы защитить учётные записи пользователей вашего домена от взлома пароля, рекомендуется использовать надёжные пароли пользователей в AD (длина пароля не менее 8 символов и включение требований к сложности пароля). Это настраивается в разделе Password Policy («Политика паролей»):

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

То есть пользователь заявляет, что никогда не ошибался при вводе пароля, но его учётная запись по каким-то причинам заблокирована. Администратор может разблокировать аккаунт вручную по запросу пользователя, но через некоторое время ситуация может повториться.

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

Получаем в powershell активных сессий пользователей ad и их компьютеров

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

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

Навигация по посту

Разница между отключённой, просроченной и заблокированной учётной записью

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

аккаунт отключён
аккаунт просрочен
пользователь ограничен определённым временем или компьютером для входа

Отключённые аккаунты (disabled)

Администратор домена может вручную отключить (деактивировать) аккаунт пользователя. Если пользователь отключён, то будет выведено сообщение:

Ваша учётная запись отключена. Обратитесь к системному администратору.

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

Заблокированные аккаунты (locked out)

Учётная запись может быть заблокирована автоматически в соответствии с политикой блокировки учётной записи организации. Если пользователь ввёл неправильный пароль более определённого количества раз (порог устанавливается политикой паролей), то его аккаунт автоматически блокируется на время, которое также устанавливается политикой паролей.

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

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

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

Если время разблокировки в групповой политике пароля установлено на 0, то такая учётная запись никогда не будет разблокирована автоматически, для её разблокировки требуется действие администратора домена.

Учётные записи с истекшим сроком действия (expired)

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

Запрет доступа по другим причинам

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

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

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

Вы не можете сейчас войти в систему из-за ограничений вашей учётной записи. Попробуйте ещё раз позже.

Данные ограничения могут перестать действовать в определённые часы или на определённых компьютерах. Эти ограничения устанавливает и снимает администратор домена.

Типы входов в систему (logon types)

Тип входа в систему — Описание

2 — Интерактивный (вход с клавиатуры или экрана системы)3 — Сетевой (например, подключение к общей папке на этом компьютере из любого места в сети или IIS вход — Никогда не заходил 528 на Windows Server 2000 и выше. См. событие 540)

4 — Пакет (batch) (например, запланированная задача)5 — Служба (Запуск службы)7 — Разблокировка (например, необслуживаемая рабочая станция с защищенным паролем скринсейвером) 8 — NetworkCleartext (Вход с полномочиями (credentials), отправленными в виде простого текст.

Часто обозначает вход в IIS с “базовой аутентификацией”) 9 — NewCredentials10 — RemoteInteractive (Терминальные службы, Удаленный рабочий стол или удаленный помощник) 11 — CachedInteractive (вход с кешированными доменными полномочиями, например, вход на рабочую станцию, которая находится не в сети)

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

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

Через некоторое время (установленное политикой безопасности домена) учётная запись пользователя автоматически разблокируется. Временная блокировка учётной записи AD снижает риск атак методом переборы (брут-форс) на пароли учётных записей пользователей AD.

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

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

В Windows на английском языке сообщение выглядит так:

The referenced account is currently locked out and may not be logged on to ….

Через powershell

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

Замечательно список мы с вами научились получать, и вы можете посмотреть время последнего обращения компьютера к контроллеру домена. Идем дальше, теперь я хочу, чтобы данные компьютеры были выключены в Active Directory и были перемещены в отведенную под это дело OU. Вот пример кода.

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

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

Через wmi

Я пробовал и другие классы, но каждый со своими проблемами. Решения так и не нашел.

Источник

Через оснастку active directory пользователи и компьютеры

Через ADUC можно получить список компьютер, по такому значению как последнее время изменения, которое по дате совпадает с параметром последнего логирования компьютера в Active Directory. Открываем active directory пользователи и компьютеры. Выбираем пункт сохраненные запросы и нажимаем создать запрос.

У вас откроется поле с созданием нового запроса к Active Directory. Задаем ему название, далее через кнопку обзор выбираем организационное подразделение, на которое следует натравить запрос, можете оставить и корень. Далее нажимаете кнопку запрос.

На вкладке пользователи выбираем пункт “Число дней со времени последнего входа в систему”, я ставлю 60 дней, так как считаю, что таких командировок нет и компьютер уже точно не присутствует в локальной сети, и нет смысла хранения его учетной записи в базе контроллера домена.

Все, все параметры заданы и можно строить запрос к базе данных AD.

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

Зайдя в свойства любого компьютера, перейдите на вкладку объект, и посмотрите поле, изменен, оно будет совпадать по дате с полем LastLogonDate. В итоге я вижу, что данный компьютер не появлялся в сети с 14 ноября 2022 года, что дает мне мысли, о его удалении из базы NTDS.dit.

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