How to Get a List of Expired User Accounts and Expiration Date in AD Using PowerShell
How to Get a List of Expired User Accounts with PowerShell
One of the most important tasks that an Active Directory administrator performs is ensuring that expired user accounts are reported in a timely manner and that action is taken to immediately remove or disable them. Note that user accounts for which you set an expiration date are only created temporarily. For example, you might have created several user accounts to allow vendors to log on to the Active Directory. Similarly, you might have created user accounts for contractors. If you wish to see what accounts have expired, execute the following PowerShell command:
Note the use of the Search-ADAccount PowerShell cmdlet again but with a different switch this time. The switch that we use is AccountExpired. As the name suggests, the AccountExpired switch helps you to collect user accounts that have expired.
How to Get Account Expiration Date Using PowerShell
To get AD account expiration date for all enabled users in your Active Directory you can use Get-ADUser cmdlet with an -AccountExpirationDate property. Run the following script in PowerShell ISE on your Windows Server:
You will get and expiration date and time for a complete list of your AD users.
If you need a summary for a specific group you need to modify the script by adding -SearchBase parameter. You can pipe data to .csv file (e.g. to import it to Excel or open in text editor) by adding |export-csv <Path> –NoTypeInformation
Assuming we need to export list of account expiry dates for “IT” organizational unit of enterprise.com domain, expression we will execute on DC will be following:
Summing up, with minimal Microsoft Powershell scripting skills Search-ADAccount, combined with Get-ADUser can help you to solve many ad-hoc AD cleanup and analysis tasks.
Need more PowerShell scripts for Active Directory? Find all the top wanted PowerShell commands for Active Directory in one blog post.
Get-ADUser AccountExpirationDate
У меня возникли некоторые трудности с выводом даты истечения срока действия учетной записи от некоторых пользователей нашей AD.
Это код, который я использую:
Проблема в том, что когда у меня есть пользователь в AD, который не установил срок действия, он отображается пустым. Я хочу, чтобы он показывал «Никогда не истекает», потому что это так. Когда я проверяю пользователя с датой истечения срока действия, он показывает мне точную дату окончания срока действия.
Я также попробовал с if if заявление, но пока не повезло.
С уважением, Ральф
2 ответа
Другой способ — запросить свойство LDAP accountExpires , представляющее собой числовое значение.
Если это свойство пользователя равно 0 или 9223372036854775807, то срок действия учетной записи никогда не истекает.
Powershell find users expiring in 7 days
However when I make the following change, it seems to have some trouble and I end up getting an empty CSV file. Ultimately I want account expiring in 7 days, not more, not less.
$a = (get-date).AddDays(7) ; Search-ADAccount -AccountExpiring -TimeSpan «7» | Select-Object SamAccountName,AccountExpirationDate | Sort-Object AccountExpirationDate | Where-Object <$_.AccountExpirationDate -like $a >| Export-Csv 7_days.csv
Can someone let me know what I am doing wrong? I have tried moving the «Where-Object <$_.AccountExpirationDate -like $a >» piece around, or «-match» instead of «-like» , however these havn’t landed me much success. Where am I going wrong with this?
Accountexpires ad что это
Многие помнят то чувство, когда компания расширяется до тех размеров, когда рабочих групп недостаточно, и поднимается первый домен Active Directory: «О, уж теперь-то все будет как следует!» Ан нет, домен потихонечку разрастается, создаются новые учетки, блокируются старые, добавляются, удаляются компьютеры, девушки выходят замуж, меняют фамилии и, в конце концов, база данных службы каталогов выглядит, как полный швах. В этом топике мы наладим связь между базой Active Directory и кадровой системой предприятия, а также создадим механизм для поддержания данных сотрудников в AD в актуальном состоянии.
Первым делом, мы опишем требования, которые мы должны предъявить к учетным записям сотрудников. А эти требования мы постараемся прикинуть, исходя из потребностей пользователя. Не секрет, что многие корпоративные системы, использующие аутентификацию через Active Directory, для отображения и в своих админках, и просто в ходе работы зачастую используют разнообразные поля учетных записей AD: это и Sharepoint, и Citrix, и многие-многие другие. В качестве примера такой системы я возьму известный всем MS Outlook, да не полностью, а лишь его адресную книгу, которая черпает свои данные напрямую из Active Directory.
Механизм
Само собой ясно, что для того, чтобы связать персону из кадровой системы и персону из Active Directory, необходимо иметь некий идентификатор, связывающий эти две записи. Обычно таким идентификатором является табельный номер сотрудника, он присваивается при приеме на работу и более никогда не меняется, вместе с тем, я встречался с ситуациями, когда и табельный номер не статичен, в этом случае такой идентификатор следует выдумать.
Сведения о пользователе Active Directory не исчерпываются сведениями, которые можно увидеть в оснастке Active Directory Users and Computers (устоявшееся сокращение ADUC), причем очень далеко не исчерпываются. На самом деле объект пользователя имеет триллион атрибутов, и эти атрибуты даже могут быть добавлены администратором схемы. Например, есть такой атрибут, как carLicense, содержащий информацию о водительском удостоверении, или drink, характеризующий любимый напиток пользователя. В общем, Microsoft в этом смысле предусмотрела многое.
Использовать в моем примере я буду атрибуты employeeID для хранения идентификатора пользователя, и flags, для чего именно, сообщу чуть позже.
К делу
Первым делом следует проставить employeeID, который у нас представляет табельный номер, всем пользователям. Если пользователей мало, то сделать это проще всего через ADSI Edit, если их чуть больше, то можно прикрутить скрипт для прописывания, например вот так. А если пользователей много, расстановку идентификаторов необходимо делегировать, хочется приятный интерфейс и используются дополнительные фенечки, то можно создать вот такую дополнительную вкладку в ADUC:
впрочем, создание такой вкладки это само по себе тема для отдельного топика.
Второе тонкое место в том, что иногда случается так, что для некоторых людей менять следует только некоторые атрибуты. Есть, например, у нас сотрудник, назовем его Кудрымунбеков Садруддин Фатхулларович, но все его называют просто Сан Саныч. А есть генеральный директор, должность которого в кадрах записана не иначе, как Генеральный Директор Открытого Акционерного Общества Дальней Космической Связи «Рога И Копыта», которого в AD лучше бы просто оставить точно со связью, но точно без рогов и копыт. Таким образом, мы видим необходимость в закладывании в логику работы нашего приложения некоторых исключений, а хранить эти исключения мы будем там же, в Active Directory в атрибуте flags. Этот атрибут имеет величину в четыре байта, а значит, устанавливая тот или иной бит в то или иное значение, мы сможем при необходимости запомнить аж 32 исключения. Впрочем, использовать мы все равно будем только шесть.
Переходим к реализации на powershell:
Создадим тестовую среду, абсолютно произвольно присвоим имена учетным записям:
Теперь запускаем скрипт с параметрами. Разумеется, его можно зашедулить и выполнять по расписанию, только не забыть учетной записи, от имени которой выполняется задание, присвоить право входа в качестве пакетного задания:
Как видим, после выполнения, мы получили хорошие читаемые имена, отличные должности и великолепные наименования компаний:
Конечно, путем неглубокой модификации скрипта, мы можем заполнять пользователю все: от телефонов и адресов до пресловутых любимых напитков, был бы источник. А если скрипт запускать с определенной регулярностью, то мы добиваемся того, что все данные о пользователях будут актуальны.
upd Подправил маленькую ошибочку, перенес обнуление флажков во внутрь цикла
Аудит учетных записей пользователей в Active Directory
Аудит учетных записей пользователей в Active Directory
Постановка проблемных вопросов
В определенный момент времени наступает то критическое состояние для списка пользователей локальной сети предприятия, когда нежелание остановиться и провести анализ его содержимого может повлечь большие затраты и проблемы, нежели своевременное проведение работ по аудиту и устранению выявленных недостатков.
О чем идет речь? Речь о следующем. В организациях, где число сотрудников, работающих с компьютерной техникой, превышает 100 человек, администрированием занимаются, как правило, два-три сотрудника. Не все они в силу различных обстоятельств с достаточным педантизмом относятся к работе по внесению во вновь создаваемые учетные записи информации о владельцах. Кроме того, администраторы обычно:-) не включены в список тех сотрудников, которым обязаны сообщать об увольнениях. Два этих обстоятельства являются основными причинами, из-за которых и происходит накопление учетных записей «мертвых душ».
Попробуем провести некоторую систематизацию наиболее значимых и очевидных проблем для списка пользователей Active Directory.
Во-первых, лишние записи в списке пользователей, которые могут быть:
• учетными записями уволенных сотрудников;
• учетными записями работающих сотрудников, которыми не пользуются и владельцы которых уже вряд ли помнят имена для входа в сеть (не говоря уже о паролях:-));
• учетными записями заблокированных пользователей, для которых администратор выполнил первый шаг перед удалением, но так и не закончил процедуру;
• учетными записями, созданными для тестирования, которые обычно имеют достаточно высокие привилегии и которые администратор забыл удалить, после того как процесс тестирования был завершен.
Во-вторых, к недопустимым можно отнести те учетные записи, которые однозначно не идентифицируют владельца, т.е. дополнительная информация в которых не позволяет назвать человека, определить его должность и подразделение, выяснить, как с ним можно связаться (конечно же, речь здесь не идет о стандартных учетных записях типа «Администратор», «Administrator», «Guest», «Гость», и др).
И, в-третьих, выполнение требований политики безопасности предприятия подразумевает, что усилия и администраторов, и пользователей должны быть направлены на то, чтобы учетная запись использовалась только ее владельцем. То есть, если протокол выполнения операций работы с какой-либо из программ показал, что пользователь вошел под учетной записью Иванова Ивана Ивановича, то абсолютно нерационально будет тратить время на дополнительные разборки с ситуациями, когда выясняется, что учетной записью пользуются (из-за недостаточных знаний компьютера или обычной лени) все сотрудники отдела, в котором трудится пять человек.
Обзор возможностей по работе с учетными записями
Попробуем перечислить те возможности, которые есть под руками у администратора для работы с учетными записями пользователей в Active Directory, и то, насколько они могут быть использованы для проведения аудита.
Оснастка Active Directory — пользователи и компьютеры (которую можно найти в разделе Администрирование на сервере). Замечательная возможность для добавления, редактирования свойств и удаления пользователей домена, но, к сожалению, достаточно бесполезная в вопросах проведения ревизии и аудита. К положительным моментам можно отнести возможность проведения экспорта списка пользователей, в который можно включить такие поля, как Имя входа пользователя, Имя, Выводимое имя, Фамилия, Изменен. Отметим, что поле Изменен показывает время и дату последних изменений для учетной записи администратором (производилась коррекция настроек) или владельцем (смена пароля).
Системная утилита Net.exe. С помощью этой утилиты вы можете обеспечить работу с данными конкретного пользователя (вариант вызова — Net user) — получить дату и время последней регистрации в сети, а также определить, когда завершается срок действия пароля.
Программы-сканеры, задача которых заключается в сборе информации о состоянии локальной сети или конкретного компьютера. Среди наиболее интересных программ в плане получения информации о пользователях отметим CFI LANguard Network Security Scanner (ver 3.1.5). Она предоставляет возможность получения достаточно подробной информации об учетных записях: дата и время последней регистрации; данные о том, когда пароль будет просрочен; количество регистраций пользователя в сети; значение индекса попыток входа с некорректным паролем. Кроме того, программа позволяет на основании данных двух сохраненных протоколов сканирования сформировать отчет о расхождениях и получить перечень заведенных и удаленных учетных записей. Справедливости ради отметим, что программа имеет существенные недостатки особенно для русскоязычной категории пользователей, так как некорректно обрабатывает русские названия (в именах и дополнительных параметрах учетных записей и пр.). Кроме того, отсутствует возможность сохранить в отдельном файле информацию о найденных расхождениях в списках учетных записей.
Перейдем теперь к рассмотрению утилит, которые, на наш взгляд, предоставляют возможность получения наиболее полной информации по пользователям, — Ldifde.exe и Csvde.exe.
Первая утилита позволяет экспортировать данные из Active Directory в файл формата LDIF. Стандарт файла LDIF определен в рекомендациях RFC-2849 для импорта и экспорта данных из каталогов LDAP, таких, как Active Directory. После экспорта данных можно использовать LDIF-файл для импорта тех же объектов в другой каталог LDAP.
Csvde.exe — утилита, аналогичная Ldifde.exe (параметры вызова идентичны), в которой используется другой формат хранения данных в текстовом файле — значения разделяются запятыми (CSV-формат). Данный формат поддерживается программой Microsoft Excel, понимающей файлы в CSV-формате, а также Microsoft Access.
Таблица 1. Описание некоторых полей учетных записей LDAP-каталога