• PowerShell - Проверяем флаг защиты доменных OU от случайного удаления

    24.08.2011 Автор:Алексей Максимов
    10 038 Просмотров 10 комментариев

    imageВ оснастке Active Directory Users and Computers (dsa.msc) открыв свойства любого OU на закладке Object можно наблюдать флаг “Protect object from accidental deletion” (Защитить объект от случайного удаления). В библиотеке “Best Practices Analyzer for Active Directory Domain Services” есть хорошая заметка на тему управления этим флагом через PowerShell - AD DS: All OUs in this domain should be protected from accidental deletion

    Для того чтобы получить перечень всех OU на которых не установлен флаг защиты выполним скриптоблок:

    # Переменная $LDAPPathOU – ADSI путь к контейнеру внутри которого будем производить поиск OU (в формате distinguishedName)

    #

    $LDAPPathOU = "OU=ImportantOUs,DC=holding,DC=com"

    Import-Module ActiveDirectory

    Get-ADOrganizationalUnit -filter * -SearchScope Subtree -SearchBase $LDAPPathOU -Properties ProtectedFromAccidentalDeletion | Where {$_.ProtectedFromAccidentalDeletion -match "False"} | Select name, DistinguishedName | Format-Table –AutoSize


    Для того чтобы на всех незащищённых OU сразу выставить данный флаг немного изменим скриптоблок до следующего вида:

    $LDAPPathOU = "OU=ImportantOUs,DC=holding,DC=com"

    Import-Module ActiveDirectory

    Get-ADOrganizationalUnit -filter * -SearchScope Subtree -SearchBase $LDAPPathOU -Properties ProtectedFromAccidentalDeletion | Where {$_.ProtectedFromAccidentalDeletion -match "False"} | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true

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

  • SCOM 2007 R2 - Аудит изменений доменных групп безопасности

    03.08.2011 Автор:Алексей Максимов
    5 039 Просмотров 2 комментария

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

    Для решения этой задачи воспользуемся возможностями SCOM и на примере доменной группы “Domain Admins” создадим правила, которые будут отслеживать события, регистрируемые в журнале “Security” на контроллерах домена в момент добавления и удаления пользователей в эту доменную группу безопасности.

    Читать далее...

  • RSAT для Windows 7 и закладка Dial-In в ADUC

    25.03.2011 Автор:Алексей Максимов
    5 962 Просмотров 2 комментария

    При попытке включить удалённый доступ пользователю через VPN наткнулся на занятную ситуацию…Так выглядят свойства пользовательской доменной учетной записи в оснастке «Active Directory Users and Computers» (DSA.MSC) запущенной в Windows 7 SP1 с включённой опцией отображения Дополнительных компонент (меню View > Advaced Features):

    clip_image001

    А если открыть эту же оснастку с Windows Server 2008 R2, то мы видим на одну вкладку больше

    clip_image002

    Читать далее...

  • Запрос авторизации Outlook при переключении БД Exchange или перезагрузке ноды NLB

    28.02.2011 Автор:Алексей Максимов
    15 180 Просмотров 16 комментариев

    imageБыло замечено, что при выполнении процедуры переключения активной копии БД Exchange Server 2010 в группе DAG с одного сервера на другой (Database Switchover), а так же при проверке механизма аварийного переключения (Database Failover) на клиентах Outlook 2007/2010 происходит кратковременный разрыв соединения с сервером Exchange, сопровождаемый появлением окна авторизации для ввода имени пользователя и пароля. При этом, если без ввода учетных данных просто перезапустить Outlook, - соединение успешно восстанавливается. После проведения изыскательных мероприятий выяснилось то, что клиент Outlook в момент кратковременной потери MAPI (RPC) соединения c активным экземпляром БД Exchange пытается использовать альтернативный метод доступа – RPC over HTTP, то есть пытается использовать встроенный механизм мобильного клиента Outlook Anywhere. И в нашем случае это происходит из-за того, что на стороне серверов клиентского доступа компонента Outlook Anywhere настроена на использование Basic Authentication.

    Одним из методов решения данной проблемы может быть отключение использования встроенного механизма Outlook Anywhere в клиентах Outlook, включённого по умолчанию. Для этого в Outlook откроем свойства учетной записи > «Другие настройки» > перейдём на закладку «Подключение» и отключим флажок «Подключение к Microsoft Exchange по протоколу HTTP»:

    image

    Если стоит задача отключить данный механизм массово на всех клиентах, то можно это выполнить, например, с помощью доменных групповых политик – GPO. При попытке использовать ADMX шаблоны групповых политик в домене Windows Server 2008/2008 R2 имеющихся в комплекте с MS Office 2007/2010 вы можете убедиться в том, что они не имеют параметров для настройки мобильного клиента Outlook.
    В базе знаний Microsoft можно найти две статьи описывающие проблему невозможности настройки параметров мобильного клиента Outlook c помощью стандартных шаблонов GPO:

    В этих статьях нам доступны для загрузки шаблоны GPO в уже устаревшем формате – *.adm. Мы можем воспользоваться средством ADMX Migrator для того чтобы сконвертировать полученные ADM файлы в формат ADMX.

    После конвертации из каждого файла *.adm мы получим по два файла – *.admx (шаблон GPO) и *.adml (файл языкового описания для шаблона GPO).
    Зададим полученным файлам соответствующие имена:

    • Для Outlook 2007: outlk12_961112.admx и outlk12_961112.adml
    • Для Outlook 2010: outlk14_2426686.admx и outlk14_2426686.adml

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

    В файле outlk12_961112.adml строку, описывающую отображаемое имя раздела GPO:

    <string id="L_MicrosoftOfficeOutlook12-Article961112">Article 961112 Policy Settings</string>

    заменим на строку:

    <string id="L_MicrosoftOfficeOutlook12-Article961112">Microsoft Office Outlook 2007 KB961112</string>

    В файле outlk14_2426686.adml строку, описывающую отображаемое имя раздела GPO:

    <string id="L_MicrosoftOfficeOutlook">Microsoft Outlook 2010</string>

    заменим на строку:

    <string id="L_MicrosoftOfficeOutlook">Microsoft Outlook 2010 KB2426686</string>

    Скопируем полученные в результате шаблоны outlk12_961112.admx и outlk14_2426686.admx в каталог центрального доменного хранилища шаблонов GPO - \domain.com\SYSVOL\domain.com\Policies\PolicyDefinitions
    Языковые файлы outlk12_961112.adml и outlk14_2426686.adml скопируем в это же размещение в подкаталог en-us.

    После этого, при работе с оснасткой редактирования доменных групповых политик Group Policy Management Editor (gpmc.msc) у нас появится возможность задавать соответствующие параметры:

    image

    Для того чтобы полностью отключить попытки Outlook использовать протокол HTTP, параметр RPC/HTTP Connection Flags должен быть включён и его значение должно быть установлено в No Flags:

    image

    После вступления в силу данного параметра GPO, для всех клиентских профилей будет добавлено соответствующее значение в куст реестра HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\12.0\Outlook\RPC (для Outlook 2007) или HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\RPC (для Outlook 2010):

    image

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

    image

    В развитие темы запросов авторизации Outlook можно также отметить то, что из практики замечено то, что в некоторых случаях перезагрузка одной из нод NLB кластера, обслуживающего массив Client Access Array, так же может порождать подобную проблему. Поэтому в случае если в рабочее время нам потребуется выполнить обслуживание серверов Client Access входящих в NLB кластер с необходимостью их перезагрузки, - перед выполнением перезагрузки в оснастке Network Load Balancing Manager соответствующий сервер желательно перевести в режим DRAINSTOP

    image

    При этом после перезагрузки нода NLB будет автоматически включаться в работу кластера если в оснастке NLB Manager в свойствах этого хоста значение параметра Default state установлено в Starded:

    image

    Дополнительная информация:

    Обновление 20.02.2018

    По просьбам трудящихся, у которых не получается самостоятельно сконвертировать ADM шаблоны, добавляю ссылку на готовые файлы: KB961112 & KB2426686 ADMX

  • AD DS – Выбор DC для операции ввода в домен с помощью PowerShell командлета Add-Computer

    03.02.2011 Автор:Алексей Максимов
    14 842 Просмотров 3 комментария

    imageВ большой доменной инфраструктуре AD DS с большим количеством сайтов можно столкнуться с ситуацией, когда при вводе в домен новых компьютеров в сайте с единственным контроллером RODC операция ввода в домен происходит не на ближайшем RWDC а на отдалённом. Это приводит к тому, что перед тем как можно будет начать использовать в домене такой компьютер, потребуется выждать репликацию от удалённого DC до местного RODC. Избежать данной ситуации можно используя утилиту NETDOM, явным образом указывая ближайший контроллер домена, на котором мы хотим произвести процедуру джойна:

    image

    Но так как по умолчанию в клиентских системах этой утилиты нет, хочется воспользоваться каким-то подручным средством без выполнения дополнительным манипуляций. И тут нам на помощь приходит PowerShell с командлетом Add-Computer… но когда я решил воспользоваться им на практике, то выяснилось что встроенный хелп PowerShell об этом командлете (равно как и сайт TechNet Script Center) о чём-то нам не договаривает.

    Попытка выполнить ввод в домен строго по описанию не сработала, то есть при использовании командлета в виде…

    Add-Computer -DomainName 'MYDOM' -Credential 'MYDOMadmin' -OUPath 'OU=Clients,OU=Branch,DC=mydom,DC=com' -Server 'MYDOMBestDC' -PassThru –Verbose

    … приводила к ошибке, которая фиксировалась в логе NetSetup.LOG (расположен в каталоге C:Windowsdebug) примерно в следующем виде:

    02/03/2011 11:43:51:403 ----------------------------------------------------

    02/03/2011 11:43:51:403 NetpDoDomainJoin

    02/03/2011 11:43:51:403 NetpMachineValidToJoin: 'MyWS001'

    02/03/2011 11:43:51:403    OS Version: 6.1

    02/03/2011 11:43:51:403    Build number: 7600 (7600.win7_gdr.100618-1621)

    02/03/2011 11:43:51:403    SKU: Windows 7 Профессиональная

    02/03/2011 11:43:51:403 NetpDomainJoinLicensingCheck: ulLicenseValue=1, Status: 0x0

    02/03/2011 11:43:51:403 NetpGetLsaPrimaryDomain: status: 0x0

    02/03/2011 11:43:51:403 NetpMachineValidToJoin: status: 0x0

    02/03/2011 11:43:51:403 NetpJoinDomain

    02/03/2011 11:43:51:403    Machine: MyWS001

    02/03/2011 11:43:51:403    Domain: MYDOMBestDCMYDOM

    02/03/2011 11:43:51:403    MachineAccountOU: OU=Clients,OU=Branch,DC=mydom,DC=com

    02/03/2011 11:43:51:403    Account: MYDOMadmin

    02/03/2011 11:43:51:403    Options: 0x23

    02/03/2011 11:43:51:403 NetpLoadParameters: loading registry parameters...

    02/03/2011 11:43:51:403 NetpLoadParameters: DNSNameResolutionRequired not found, defaulting to '1' 0x2

    02/03/2011 11:43:51:403 NetpLoadParameters: DomainCompatibilityMode not found, defaulting to '0' 0x2

    02/03/2011 11:43:51:403 NetpLoadParameters: status: 0x2

    02/03/2011 11:43:51:403 NetpValidateName: checking to see if 'MYDOM' is valid as type 3 name

    02/03/2011 11:43:53:697 NetpCheckDomainNameIsValid for MYDOM returned 0x54b, last error is 0x0

    02/03/2011 11:43:53:697 NetpCheckDomainNameIsValid [ Exists ] for 'MYDOM' returned 0x54b

    02/03/2011 11:43:53:697 NetpJoinDomainOnDs: Domain name is invalid, NetpValidateName returned: 0x54b

    02/03/2011 11:43:53:697 NetpJoinDomainOnDs: Function exits with status of: 0x54b

    02/03/2011 11:43:53:697 NetpDoDomainJoin: status: 0x54b

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

    Add-Computer -DomainName 'mydom.comBestDC' -Credential 'MYDOMadmin' -OUPath 'OU=Clients,OU=Branch,DC=mydom,DC=com' -PassThru –Verbose

    То есть вместо параметра Server можно использовать передачу имени DC в параметре DomainName. Данный способ проверен и работает как на Windows 7, так и на Windows XP SP3.

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

    Дополнительная информация для размышления:

    Windows Server TechCenter Forums - Selection of DC during a workstation join to domain operation

    Blog Jorge 's Quest For Knowledge! - DC Locator Process in W2K, W2K3(R2) and W2K8 - PART 1

  • PowerShell - Поиск неиспользуемых учетных записей пользователей и компьютеров в домене

    23.01.2011 Автор:Алексей Максимов
    17 690 Просмотров 7 комментариев

    Для быстрого поиска в домене давно не используемых учетных записей пользователей можно использовать оснастку ‘Active Directory Users and Computers’ (dsa.msc), создав в ней запрос.

    image

    Читать далее...

  • PowerShell – Поддержание групп безопасности политики репликации паролей RODC в актуальном состоянии

    20.01.2011 Автор:Алексей Максимов
    3 931 Просмотров 4 комментария

    imageПри использовании контроллеров домена «только на чтение» (RODC) для каждого RODC должна быть определена доменная группа безопасности, в которую входят учетные записи пользователей, чьи учетные данные могут реплицироваться на этот RODC. В крупной географически распределённой инфраструктуре с большим количеством контроллеров домена задача поддержания состава этих групп безопасности «в рукопашную» может стать проблемой, особенно если учесть «человеческий фактор», когда например, в каком-то из удалённых подразделений местный администратор создаёт новую учетную запись доменного пользователя, а включить в группу репликации паролей эту запись забывает. Для того чтобы исключить в данном случае «человеческий фактор», можно автоматизировать данный процесс с помощью PowerShell. Рассмотрим пример скрипта, который можно включить в планировщик задач на контроллере домена на периодическое выполнение.

    Читать далее...

  • PowerShell – Поддержание группы безопасности для Password Settings objects (PSOs) в актуальном состоянии

    19.01.2011 Автор:Алексей Максимов
    3 685 Просмотров 1 Комментарий

    imageПо мотивам применения Password Settings objects (PSOs) с нацеливанием объектов PSO на доменные группы безопасности встаёт вопрос о поддержании состава этих групп в актуальном состоянии. В моём окружении все учетные записи, находящиеся в определённом OU, должны быть включены в доменную группу безопасности, к которой применяется PSO, что само по себе уже есть критерий, по которому можно автоматизировать задачу поддержания группы в актуальном состоянии с помощью PowerShell. Представляю соответствующий скрипт.

    Читать далее...

  • AD DS - Создание нескольких политик паролей Password Settings objects (PSOs) в домене Windows Server 2008/2008 R2

    17.01.2011 Автор:Алексей Максимов
    13 466 Просмотров 7 комментариев

    imageВ службах AD DS Windows Server 2008 появился новый механизм AD DS Fine-Grained Password and Account Lockout Policy, позволяющий в рамках домена создавать несколько разных политик паролей, применяемых к конкретным доменным пользователям или доменным глобальным группам безопасности. Такой механизм может быть полезен в случае, если, например, необходимо для определенной группы пользователей иметь ослабленные/усиленные политики безопасности, отличающиеся от тех, что заданы на уровне всего домена в Default Domain Policy.

    Рассмотрим сценарий создания объекта PSO в домене соответствующего следующим критериям:

    clip_image001

    clip_image002

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

    clip_image003

     

    Создание объекта PSO с помощью MMC-оснастки Active Directory Services Interface editor (ADSI Edit)

    Откроем оснастку ADSIEDIT.MSC и подключимся к контексту именования по умолчанию нашего домена указав в поле Name FQDN имя нашего домена

    clip_image004

    Перейдём в контейнер DC=holding, DC=com -> CN=System -> CN=Password Settings Container

    clip_image005

    И в контекстном меню на контейнере Password Settings Container выберем создание нового объекта PSO (msDC-PasswordSettings)

    clip_image006

    Укажем имя нашего нового объекта PSO

    clip_image007

    Укажем значение атрибута msDS-PasswordSettingsPrecedence. Значение этого атрибута определяет приоритет в случае конфликта нескольких PSO, применяемых к одной и той же группе безопасности или пользователю.

    clip_image008

    Значение атрибута msDS-PasswordReversibleEncryptionEnabled определяет возможность обратимого шифрования пароля для учетных записей пользователей. Устанавливаем его в false как рекомендуемое.

    clip_image009

    Зададим значение атрибута msDS-PasswordHistoryLength определяющего количество неповторяемых паролей для учетных записей пользователей.

    clip_image010

    Значение атрибута msDS-PasswordComplexityEnabled, установленное нами в true, определяет включение требования соблюдения сложности паролей и является рекомендуемым.

    clip_image011

    Значение атрибута msDS-MinimumPasswordLength, установленное нами в 8, определяет минимальную длину паролей учетных записей пользователей.

    clip_image012

    Значение атрибута msDS-MinimumPasswordAge, установленное нами в 1:00:00:00 (1 день), определяет минимальный срок действия паролей учетных записей пользователей.

    clip_image013

    Значение атрибута msDS-MaximumPasswordAge, установленное нами в 90:00:00:00 (90 дней), определяет максимальный срок действия паролей учетных записей пользователей.

    clip_image014

    Значение атрибута msDS-LockoutThreshold, установленное нами в 5, определяет порог блокировки учетных записей пользователей (после 5 неудачных попыток авторизации срабатывает механизм блокировки учетной записи).

    clip_image015

    Значение атрибута msDS-LockoutObservationWindow, установленное нами в 0:00:30:00 (30 минут), определяет период сброса счетчика блокировок учетных записей пользователей.

    clip_image016

    Значение атрибута msDS-LockoutDuration, установленное нами в 0:00:30:00 (30 минут), определяет продолжительность блокировки заблокированных учетных записей пользователей.

    clip_image017

    На этом работа мастера создания PSO завершается.

    clip_image018

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

    clip_image019

    Среди списка атрибутов находим атрибут msDS-PSOAppliesTo и убедившись в том что его значение не определено, открываем его редактирование.

    clip_image020

    В окне редактирования Multi-valued Distinguished Name With Security Principal Editor нажимаем Add Windows Account и выбираем соответствующую доменную глобальную группу безопасности, которую мы создали ранее.

    clip_image021

    clip_image022

    Сохраняем свойства объекта PSO и убеждаемся в том, что привязка к соответствующей группе безопасности произведена (для этого можно проверить значение атрибута msDS-PSOApplied в свойствах самой группы безопасности).

    clip_image023

    Теперь на всех пользователей, включенных в эту группу безопасности, будут действовать параметры, заданные в нашем объекте PSO независимо от текущих настроек в Default Domain Policy.

    Создание объекта PSO с посмощью CLI-утилиты LDIF Directory Exchange (LDIFDE)

    Помимо создания объекта PSO через оснастку ADSIEDIT.MSC, мы можем создать его с помощью утилиты командной строки LDIFDE. В некоторых сценариях это может быть более быстро и удобно. Для этого нам предварительно нужно подготовить файл в формате *.LDF (LDAP Data Interchange Format) следующего содержания:

    dn: CN=KOM-SRV-PSO-Users,CN=Password Settings Container,CN=System,DC=holding,DC=com
    changetype: add
    objectClass: msDS-PasswordSettings
    msDS-MaximumPasswordAge: -77760000000000
    msDS-MinimumPasswordAge:-864000000000
    msDS-MinimumPasswordLength:8
    msDS-PasswordHistoryLength:5
    msDS-PasswordComplexityEnabled:TRUE
    msDS-PasswordReversibleEncryptionEnabled:FALSE
    msDS-LockoutObservationWindow:-18000000000
    msDS-LockoutDuration:-18000000000
    msDS-LockoutThreshold:5
    msDS-PasswordSettingsPrecedence:1
    msDS-PSOAppliesTo:CN=KOM-SRV-PSO-Users,CN=Users,DC=holding,DC=com

    Обратите внимание на то, что значения атрибутов связанных со временем указываются в формате I8 (интервалы по -100 наносекунд). Преобразование в данный формат производится по следующей схеме

    Единица времени

    Множитель

    1 минута

    -60*(10^7) = - 600000000

    1 час

    -60*60* (10^7) = -36000000000

    1 день

    -24*60*60*(10^7) = -864000000000

    То есть, например, чтобы установить значение атрибута msDS-LockoutDuration равным 30 минутам, для получения значения в формате I8 нужно умножить 30 на -600000000 (в этом примере значение равно -18000000000). Более подробную информацию по этому поводу можно получить в приложении Appendix B: PSO Attribute Constraints

    После того как мы подготовили LDF файл, произведём импорт указанной в нём информации командой:

    LDIFDE -i -f NewPSO.ldf

    clip_image024

    Более подробную информацию об использовании утилиты LDIFDE можно найти в статье KB237677 - Использование средства LDIFDE для импорта и экспорта объектов каталогов в Active Directory

    Дополнительные источники информации:

    Windows Server TechCenter - AD DS Fine-Grained Password and Account Lockout Policy Step-by-Step Guide

    TechDays.ru - Active Directory: политика паролей

  • PowerShell – Поиск пользователей домена с устаревшими паролями

    15.12.2010 Автор:Алексей Максимов
    5 869 Просмотров 1 Комментарий

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

    Для этой задачи как отправную точку я использовал PS-скрипт User Counting and Password Age Checking с блога Steve Tibbetts, несколько переработав его. В частности была убрана ненужная мне в данной ситуации зависимость от командлетов Quest, добавлена возможность управления выводом отключенных учетных записей, изменён вывод  в удобоваримый вид с сортировкой по дате установки пароля, добавлена возможность установки признака смены пароля для учетных записей с «прокисшими» паролями. Вот что получилось:

    # Блок переменных

    # $LDAPPath - ADSI путь к контейнеру с доменными учетными записями пользователей (в формате LDAP://distinguishedName)

    # $CountDisabledUsers - Признак вывода сведений об отключенных учетных записях (1 или 0)

    # $PWAgeDaysLimit - Максимально возможный период действия пароля в днях

    # $PWDMustChange - Признак необходимости форсированной установки атрибута требующего смену пароля (1 или 0)

    #

    $LDAPPath = 'LDAP://OU=Domain Users,DC=mydom,DC=com'

    $CountDisabledUsers = 0

    $PWAgeDaysLimit = 90

    $PWDMustChange = 0

    #

    # Блок поиска

    #

    $RootDomainOU = [ADSI]$LDAPPath

    $Searcher = New-Object System.DirectoryServices.DirectorySearcher($RootDomainOU)

    $Filter = '(objectCategory=person)(objectClass=user)'

    If ($CountDisabledUsers -eq 0) { $Filter = $Filter + '(!(userAccountControl:1.2.840.113556.1.4.803:=2))' }

    $Filter = '(&' + $Filter + ')'

    $Searcher.Filter = $Filter

    $Searcher.PageSize = 5000

    [Void]$Searcher.PropertiesToLoad.Add("cn")

    [Void]$Searcher.PropertiesToLoad.Add("sAMAccountName")

    [Void]$Searcher.PropertiesToLoad.Add("pwdLastSet")

    $Users = $Searcher.findall()

    #

    # Блок основного вывода

    #

    $PWDays = (Get-Date).AddDays(-$PWAgeDaysLimit)

    $UsersOldPWD = $Users | Where-Object {[datetime]::FromFileTime(($_.properties.pwdlastset)[0]) -le $PWDays}

    $UsersOldPWD | Select `

    @{label='User Full Name';expression={$_.properties.cn}},`

    @{label='sAMAccountName';expression={$_.properties.samaccountname}},`

    @{label='Last Password Set';expression={[datetime]::FromFileTime(($_.properties.pwdlastset)[0])}}`

    | Sort -Property 'Last Password Set'`

    | Format-Table –AutoSize

     

    Write-Host '---------------------------------------------------'

    write-host 'Total user accounts in OU: ' $Users.Count

    write-host 'Users with passwords not changed in' $PWAgeDaysLimit 'days: ' $UsersOldPWD.Count

    Write-Host '---------------------------------------------------'

    #

    # Блок смены атрибута учетных записей

    #

    If ($PWDMustChange -eq 1) {

    Write-Host 'Set for users with old password - Change PWD at next Logon'

    If ($UsersOldPWD.Count -eq $null)

    { Write-Host 'Ops...No account needs to be changed.'}

    Else

    {

                ForEach ($User in $UsersOldPWD)

                {

                Write-Host 'Modify user:' $User.Properties.cn

                $Account=[ADSI]$User.Path

                $Account.put("pwdLastSet", 0)

                $Account.setinfo()

                }    

    }

    Write-Host '---------------------------------------------------'

    }

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

    image

Предыдущая страница Следующая страница