Как управлять учетными записями пользователей в active directory. часть 2: перемещение и переименование пользователей

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

Программные средства Account Lockout Status

EventCombMT.exe собирает и фильтрует события из журналов событий контроллеров домена. Этот инструмент имеет встроенный поиск блокировок учетных записей. Он собирает идентификаторы событий, связанных с определенными блокировками учетных записей, в отдельном текстовом файле, который затем можно экспортировать.
LockoutStatus.exe проверяет все контроллеры домена в домене и сообщает вам, когда в последний раз была заблокирована целевая учетная запись и с какого контроллера домена. Кроме того, этот инструмент дает информацию о текущем статусе заблокированной учетной записи и количестве попыток ввода неверного пароля.
Ведение журнала Netlogon используется для отслеживания событий Netlogon и NT LAN Manager (NTLM). Включение регистрации событий в журнале Netlogon на всех контроллерах домена — это эффективный способ изолировать заблокированную учетную запись и увидеть причину блокировки. Для анализа журналов Netlogon используется NLParse.exe, который является одним из инструментов блокировки учетной записи.
Acctinfo предоставляет дополнительные свойства в ADUC (пользователи и компьютеры Active Directory), например lastLogon (последний вход) и Password Expires (истечение пароля). В частности, с этой надстройкой вы получите дополнительную вкладку в ADUC, которая называется «Дополнительная информация об учетной записи». Она помогает определять и устранять проблемы с блокировкой учетных записей, а также изменять пароль пользователя на контроллере домена на сайте этого пользователя.

PowerShell

Это можно сделать с помощью командлета Get-EventLog и следующей команды:
Либо вы можете использовать функцию Get-UserLockoutStatus для устранения проблем с постоянной блокировкой учетных записей. Функция ищет на всех контроллерах домена такую информацию о пользователях, как статус блокировки учетной записи, количество вводов неверных паролей, время последнего ввода неверного пароля и время, когда последний раз устанавливался пароль.

Восстановление контроллера домена в режиме «non-authoritative»

Собираясь восстанавливать контроллер домена, необходимо сначала определить, будет ли достаточен режим «non-authoritative» или потребуется воспользоваться режимом «authoritative». Разница между этими двумя режимами заключается в том, что при режиме восстановлении «non-authoritative» контроллер домена понимает, что он был в течение некоторого времени отключен. Поэтому он позволяет другим контроллерам домена обновить его базу данных, внеся в нее последние изменения, произошедшие во время его отсутствия. При «authoritative» восстановлении контроллер считает, что только на нем имеется истинно верная база данных, поэтому именно он получает полномочия на обновление баз данных других контроллеров домена на основе своих данных.

В большинстве сценариев восстановления вам потребуется режим «non-authoritative», поскольку в среде имеется несколько контроллеров домена. Кроме того, «authoritative» восстановление контроллера домена может привести к новым проблемам. Именно на этом основана логика Veeam Backup & Replication: по умолчанию выполняется «non-authoritative» восстановление DC, поскольку считается, что инфраструктура выстроена с избыточностью и включает в себя несколько контроллеров домена. Чтобы выполнить «authoritative» восстановление с помощью Veeam, необходимо осуществить некоторые дополнительные действия, которые описаны ниже.

ПРИМЕЧАНИЕ. Еще один распространенный вариант действий при отказе контроллера домена — распределить его роли между другими контроллерами и очистить метаданные, если восстановление маловероятно. В этом случае вы поручаете другим DC выполнять функции отказавшего, и вам не нужно его восстанавливать.

Давайте вернемся к файлам резервных копий, которые были описаны в предыдущей статье. Восстановить контроллер домена из резервной копии Veeam Backup & Replication очень легко. Для этого нужно:

Выбрать мастер восстановления в пользовательском интерфейсе
Найти нужный контроллер домена
Выбрать в меню восстановления вариант восстановления ВМ целиком (Restore Entire VM)
Затем указать точку восстановления
Выбрать исходное или новое место восстановления
Завершить процедуру

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

Восстановление файлов и жестких дисков ВМ
Загрузка ОС в специальном режиме восстановления доменных сервисов (DSRM mode)
Применение настроек
Перезапуск в обычном режиме

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

Рис. 1. Veeam Backup & Replication: Восстановление ВМ целиком

Здесь можно прочитать о восстановлении «на голое железо» резервной копии с помощью Veeam Endpoint Backup. Вам потребуется заранее подготовленный аварийный загрузочный диск Veeam и доступ к самой резервной копии (на USB-носителе или сетевом диске). Помните, что в данном случае особая логика Veeam Backup & Replication использоваться не будет. После восстановления с помощью Veeam Endpoint Backup ваш контроллер домена загрузится в режиме восстановления. Вам нужно будет решить, хотите ли вы менять ключи реестра или сразу перезапустите ВМ в обычном режиме. Возможно, эта статья базы знаний будет полезна.

Рис. 2. Veeam Endpoint Backup: восстановление «на голое железо»

Распространенные причины блокировки в Active Directory

TechNet

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

руководства по лучшим учебным материалам по Active Directoryразницу между пользователями и компьютерами в Active Directoryспособ работы служб Active Directoryразницу между AD и LDAP

Средство просмотра журнала Windows PowerShell

Центр администрирования Active Directory — это инструмент пользовательского интерфейса, который представляет собой надстройку Windows PowerShell. в Windows Server 2012 и более новых ит администраторы могут использовать ADAC для изучения Windows PowerShell Active Directory командлетов с помощью средства просмотра журнала Windows PowerShell. При выполнении действий в пользовательском интерфейсе пользователь видит эквивалентную команду Windows PowerShell в средстве просмотра журнала Windows PowerShell. Это позволяет администраторам создавать автоматические сценарии и сокращать повторяющиеся задачи, тем самым повышая производительность ИТ-ресурсов. кроме того, эта функция сокращает время на изучение Windows PowerShell для Active Directory и повышает уверенность пользователей в соответствии со своими сценариями автоматизации.

при использовании средства просмотра журналов Windows PowerShell в Windows Server 2012 или более поздней версии примите во внимание следующее

чтобы использовать средство просмотра скриптов Windows PowerShell, необходимо использовать Windows Server 2012 или более новую версию ADAC

Примечание

Диспетчер сервера можно использовать для установки средства удаленного администрирования сервера (RSAT), чтобы использовать правильную версию центр администрирования Active Directory для управления корзиной через пользовательский интерфейс.

Дополнительные сведения об установке RSAT см. в статье средства удаленного администрирования сервера.
Получите базовое представление о Windows PowerShell. Например, вам нужно знать принципы конвейерной передачи в Windows PowerShell. Дополнительные сведения о конвейерной передаче в Windows PowerShell см. в разделе Конвейерная передача и конвейер в Windows PowerShell.

Пошаговое руководство по использованию средства просмотра журнала Windows PowerShell

В следующей процедуре вы используете средство просмотра журнала Windows PowerShell в центре администрирования Active Directory для создания сценария Windows PowerShell. Прежде чем приступить к этой процедуре, удалите пользователя test1 из группы group1.

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

щелкните значок Windows PowerShell правой кнопкой мыши, выберите команду запуск от имени администратора и введите dsac.exe , чтобы открыть ADAC.
Щелкните Управление, Добавить узлы перехода и выберите соответствующий целевой домен в диалоговом окне Добавление узлов перехода, а затем нажмите кнопку ОК.
Разверните область Журнал Windows PowerShell внизу окна центра администрирования Active Directory.
Выберите пользователя test1.
Нажмите кнопку Добавить в группу… в области задачи .
Перейдите в группу group1 и нажмите кнопку ОК в диалоговом окне.
Перейдите в область Журнал Windows PowerShell и найдите только что созданную команду.
Скопируйте эту команду и вставьте ее в предпочтительный редактор для создания сценария.

Например, вы можете изменить команду, чтобы добавить другого пользователя в группу group1 или чтобы добавить пользователя test1 в другую группу.

Структура OU в Active Directory

В небольших инфраструктурах AD (20-50 пользователей) необязательно создавать новые OU, можно все складывать в дефолтные контейнеры в корне (Users и Computer). В большой инфраструктуре желательно разделить все объекты на разные контейнеры. В основном используется иерархический дизайн Organizational Unit в AD, по географическому или функциональному принципу.

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

Жизненный цикл объекта Active Directory

Итак, почему же так важно понимать, как функционируют старые системы? Потому что современная логика и привычная функциональность в этих случаях неприменимы. До появления Windows Server 2008 R2 жизненный цикл объектов Active Directory выглядел следующим образом:

Рис. 1. Жизненный цикл объекта AD

Удаление объекта Active Directory не приводит к его физическому удалению. Как вы, возможно, знаете, Active Directory скрывает удаленный объект, меняя значение атрибута isDeleted на TRUE. Затем большинство атрибутов объекта сбрасывается, а сам объект переименовывается и перемещается в специальный контейнер (CN=Deleted Objects). С этого момента объект получает статус «tombstone», и стандартные средства Active Directory не знают о его существовании. В этом специальном состоянии объект находится в течение установленного периода (60 дней в Windows Server 2000/2003 и 180 дней в Windows 2003 SP1/2008). Это делается, чтобы гарантировать успешное выполнение репликации данных в системе. По окончании отведенного времени существования в состоянии «tombstone» осуществляется вызов специального процесса (так называемый сборщик мусора), который физически удаляет объект из базы данных.

И вот здесь возникает вопрос: если «tombstone» объект не удаляется физически в течение некоторого времени, нельзя ли его восстановить? Коротко говоря — можно. Хотя такой механизм удаления объектов не был предназначен для использования в качестве временной корзины, а удаленные объекты не предполагалось восстанавливать, технически это возможно. Далее я расскажу, как это можно сделать.

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

систему для отслеживания количества пользователей доменном лесу

Первые шаги

Убедитесь, что на контроллерах доменов и клиентских компьютерах установлены самые новые пакеты обновлений и исправлений.
Настройте компьютеры для сбора данных:
- включите аудит на доменном уровне;
- включите ведение журнала Netlogon;
- включите ведение журнала Kerberos.
Анализируйте данные из файлов журналов событий и файлов журнала Netlogon. Это поможет определить, где и по какой причине происходят блокировки.
Проанализируйте журналы событий на компьютере, который генерирует блокировки учетной записи, чтобы определить причину.

Типы восстановления Active Directory: полномочное и неполномочное

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

Authoritative Restore (полномочное или авторитативное восстановление) – после восстановления объектов AD выполняется репликация с восстановленного DC на все остальные контроллеры в домене. Этот тип восстановления используется в сценариях, когда упал единственный DC или все DC одновременно (например, в результате атаки шифровальщика или вируса), или когда по домену реплицировалась поврежденная база NTDS.DIT. В этом режиме у всех восстановленных объектов AD значение USN (Update Sequence Number) увеличивается на 100000. Таким образом восстановленные объекты будут восприняты всеми DC как более новые и будут реплицированы по домену. Полномочный способ восстановления нужно использовать очень аккуратно!!!
При полномочном восстановлении вы потеряете большинство изменений в AD, произошедших с момента создания бэкапа (членство в группах AD, атрибуты Exchange и т.д.).
Non-authoritative Restore (неполномочное или не-авторитиативное восстановление) – после восстановления базы AD этот контроллер сообщает другим DC, что он восстановлен из резервной копии и ему нужны последние изменения в AD (для DC создается новый DSA Invocation ID). Этот способ восстановления можно использовать на удаленных площадках, когда сложно сразу реплицировать большую базу AD по медленному WAN каналу; или когда на сервере имелись какие-то важные данные или приложения.

Пример делегирование административных полномочий

«Поддержка»

Для начала следует на контроллере домена открыть оснастку «Active Directory – пользователи и компьютеры». Здесь необходимо создать глобальную группу безопасности, члены которой смогут присоединять компьютеры пользователей к домену. Другими словами, эта группа будет выглядеть следующим образом:Рис. 1. Свойства группы, отвечающей за присоединение компьютеров к домену

Следующим делом необходимо указать, что компьютеры присоединять к домену могут только лишь пользователи, входящие в созданную на предыдущем этапе глобальную группу безопасности. Для этого следует открыть оснастку «Управление групповой политикой» и перейти к редактору GPME для созданного по умолчанию объекта GPO «Default Domain Controllers Policy», который располагается в подразделении «Domain Controllers».
В отобразившейся оснастке следует перейти к узлу «Конфигурация компьютера\Политики\Конфигурация Windows\Параметры безопасности\Локальные политики\Назначение прав пользователей» и локализовать параметр политики, который называется «Добавление рабочих станций к домену». Открыв диалоговое окно данного параметра политики, вы сразу сможете обнаружить, что по умолчанию там указана группа «Прошедшие проверку», благодаря которой присоединять компьютеры к домену может каждый пользователь. Теперь, для того, чтобы разрешить присоединять к домену компьютеры только пользователям из группы безопасности «Поддержка», следует удалить группу, указанную в этом параметре политики по умолчанию, а затем при помощи кнопки «Добавить пользователя или группу» и диалога поиска объектов Active Directory, следует добавить созданную ранее глобальную группу безопасности. Процесс добавления такой группы изображен на следующей иллюстрации:Рис. 2. Изменение группы, отвечающей за присоединение компьютеров к домену

Теперь несмотря на то, что немного ранее было описано, в каких сценариях выполняется делегирование, и что в большинстве случаев делегирование выполняется на уровне подразделений, в данном случае для предоставления возможности присоединения компьютеров к домену, нам следует в оснастке «Active Directory – пользователи и компьютеры» вызвать мастер делегирования непосредственно для уровня всего домена. Следовательно, в оснастке «Active Directory – пользователи и компьютеры» необходимо в области дерева самой оснастки вызвать контекстное меню для домена и выбрать опцию «Делегирование управления», как показано ниже:Рис. 3. Вызов мастера делегирования управления

На первой странице мастера можно просто ознакомиться с основной задачей данного средства и, ввиду того, что на первой странице нельзя выполнять какие-либо действия, следует просто нажать на кнопку «Далее». На второй странице мастера, странице «Пользователи и группы», нужно локализовать группу, для которой необходимо делегировать управление. В данном примере следует нажать на кнопку «Добавить» и при помощи соответствующего диалога выбрать группу «Поддержка», как показано на следующей иллюстрации:Рис. 4. Добавление группы, для которой выполняется делегирование управления
После того, как группа будет добавлена, для перехода к следующей странице мастера следует нажать на кнопку «Далее».
Страница «Делегируемые задачи» позволяет вам определить конкретные операции, которые должны выполнять в доменных службах Active Directory пользователи или группы пользователей, которые были добавлены на предыдущей странице мастера. Так как в данном примере делегируется задача присоединения компьютеров к домену и такую задачу можно найти в предоставленном списке распространенных задач, следует напротив задачи «Присоединение компьютера к домену» установить флажок и нажать на кнопку «Далее»

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

5. Делегирование задачи присоединения компьютеров к домену для членов группы «Поддержка»

На последней странице мастер повторно проинформирует о том, что работа мастера была успешно выполнена и определенной группе пользователей было передано управление для присоединения компьютеров к домену, что, собственно, и являлось поставленной перед нами задачей:Рис. 6. Завершение процесса делегирования управления

«Поддержка»

Windows Server 8–восстановление удаленных элементов Active Directory

Впервые корзина Active Directory (AD recycle bin) появилась в 2008 R2. Перед её появлением в Windows 2008 R2 у администраторов не существовало легкого метода восстановления удаленных объектов AD. Конечно существовали как встроенные методы восстановления, так и утилиты сторонних производителей, однако они либо не восстанавливали в полном объеме все атрибуты, либо требовали значительных временных затрат.

С появлением корзины AD, которая включается средствами Powershell восстановление объектов стало несколько проще. Однако восстановление происходило либо средствами Powershell, либо необходимо было устанавливать сторонние программы, представляющие собой просто графическую оболочку для данных действий.

К счастью, в этом плане в Windows Server 8 есть значительное усовершенствование. Active Directory Administrative Center (ADAC) получил значительное кол-во новых возможностей, среди которых есть возможность восстановления удаленных элементов. Как и раньше, такие же действия можно сделать через Powershell.

Теперь корзина может быть включена через ADAC

Также для этого можно нажать правой кнопкой на домене и выбрать необходимый пункт.

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

Замечание: Необходимо знать и учитывать при включении, что после этого размер базы AD DS будет увеличен примерно на 15-20% от оригинального размера.

После включения данного функционала необходимо обновить ADAC.

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

После удаления пользователя переходим в узел Deleted Objects. Как видно из скриншота пользователь находится тут. Можно восстановить его, восстановить в другое место, просмотреть свойства.

Как вы видите объект был успешно восстановлен со всеми атрибутами.

Любой администратор, который хотя бы раз по ошибке удалял важный аккаунт, будет очень рад данной функции. Спасибо тебе, Microsoft AD Team!!

Полезная информация

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

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

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

Параметры RODC

При установке контроллера домена только для чтения (RODC) отображаются следующие параметры.

Делегированные учетные записи администратора получают локальные права администратора для RODC. Эти пользователи могут действовать с привилегиями, эквивалентными группе администраторов локального компьютера. Они не являются членами групп администраторов домена или встроенных учетных записей администраторов домена. Этот параметр полезен при делегировании администрирования филиалом без выдачи разрешения на администрирование домена. Настройка делегирования прав администратора не требуется. Дополнительные сведения см. в разделе Делегирование прав администратора.
Политика репликации паролей действует как список управления доступом (ACL). Она определяет, разрешается ли RODC кэширование пароля. После того как RODC получает запрос на вход прошедшего проверку пользователя или компьютера, он обращается к политике репликации паролей, чтобы определить, нужно ли кэшировать пароль учетной записи. После этого следующие входы под данной учетной записью станут более эффективными.

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

Если пользователям или компьютерам не разрешено (в том числе неявно) или отказано в кэшировании пароля, кэширование не производится. Если вышеупомянутые пользователи или компьютеры не имеют доступа к доступному для записи контроллеру домена, они не могут получить доступ к ресурсам и функциональным возможностям доменных служб Active Directory. Дополнительные сведения о репликации паролей см. в разделе Политика репликации паролей. Дополнительные сведения об управлении политикой репликации паролей см. в разделе Администрирование политики репликации паролей.

Дополнительные сведения об установке контроллера домена только для чтения см. в разделе Установка контроллера домена Active Directory только для чтения для Windows Server 2012 (уровень 200).

Get-ADComputer — синтаксис использования командлета

Чтобы получать информацию из AD с помощью командлетов из модуля AD для PowerShell, вам не нужны права администратора домена. Достаточно, чтобы учётная запись, под которой запускается командлет, была членом группы «Domain Users / Authenticated Users».

Чтобы получить информацию о конкретной учётной записи компьютера в домене, укажите её имя в качестве аргумента параметра -Identity:

Get-ADComputer -Identity hackware-server

Пример вывода:

DistinguishedName : CN=HACKWARE-SERVER,OU=Domain Controllers,DC=ds,DC=hackware,DC=ru
DNSHostName       : HackWare-Server-2022.ds.hackware.ru
Enabled           : True
Name              : HACKWARE-SERVER
ObjectClass       : computer
ObjectGUID        : 77e65141-ebec-4728-a1cc-563199d86bf8
SamAccountName    : HACKWARE-SERVER$
SID               : S-1-5-21-670420343-3848213752-1643348011-1000

Get-ADComputer -Identity hackware-server -Properties *

Используя Get-Member, вы можете получить список всех свойств объекта ADComputer:

Get-ADComputer -Filter * -Properties * | Get-Member

Дата последнего входа компьютеров в сеть указана в атрибуте LastLogonDate.

Командлет Get-ADComputer позволяет отображать любые свойства компьютера в результатах выполнения команды. Удалите всю ненужную информацию, оставив только значения атрибутов Name и LastLogonDate.

Get-ADComputer -identity hackware-win -Properties * | Format-Table Name,LastLogonDate -Autosize

Итак, мы получили данные о последней регистрации в домене для отдельного компьютера. Затем вам нужно изменить команду, чтобы она отображала информацию о времени последней сетевой регистрации для всех компьютеров в домене. Для этого замените -Identity на -Filter *:

Get-ADComputer -Filter * -Properties * | Format-Table Name,LastLogonDate -Autosize

У нас получилась простая таблица, которая содержит всего 2 поля: имя компьютера и дата LastLogonData. Вы можете добавить в эту таблицу другие поля объекта ADComputer.

Чтобы отобразить информацию об объектах компьютеров в определённом OU (организационном подразделении), используйте параметр -SearchBase:

Get-ADComputer -SearchBase 'OU=Paris,DC=woshub,DC=loc' -Filter * -Properties * | Format-Table Name,LastLogonDate -Autosize

Отсортируйте результаты запроса по дате последнего входа в систему с помощью командлета Sort-Object:

Get-ADComputer -Filter * -Properties * | Sort-Object LastLogonDate | Format-Table Name,LastLogonDate -Autosize

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

Используя Get-Date, мы можем получить значение текущей даты в переменной и уменьшить его до 120 дней:

$date_with_offset = (Get-Date).AddDays(-120)

Полученную переменную даты можно использовать как фильтр запроса Get-ADComputer в поле LastLogonDate:

Get-ADComputer -Properties LastLogonDate -Filter {LastLogonDate -lt $date_with_offset } | Sort-Object LastLogonDate | Format-Table Name,LastLogonDate -Autosize

Итак, мы создали список неактивных учётных записей компьютеров, которые не регистрировались в сети более 120 дней. Используйте команду Disable-ADAccount или Set-ADComputer, чтобы отключить их.

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

Get-ADComputer -Properties LastLogonDate -Filter {LastLogonData -lt $date_with_offset } | Set-ADComputer -Enabled $false -WhatIf

Теперь вы можете отключить все неактивные учётные записи компьютеров:

Get-ADComputer -Properties LastLogonDate -Filter {LastLogonData -lt $date_with_offset } | Set-ADComputer -Enabled $false

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

Рекомендации по решению для событий и средств