none
powershell и модуль ActiveDirectory RRS feed

  • Вопрос

  • Добрый день.

    Написал скрипт, который ищет "Учетные Записи" старше определённой даты. Всё хорошо, да вот только мне нужно что бы в список попадали объекты с пустым атрибутом lastLogonTimeStamp. А этого не происходит.

    Get-ADObject -filter {samaccounttype -eq 805306368 -and (lastLogonTimeStamp -eq $false)} ничему не приводит. Дело в том что Get-ADObject при пустом атрибуте lastlogonTimeStamp, не создаёт его в выводимом объекте. То есть, этого атрибута (если он пустой), нет вообще. И как указать правило "Если атрибут не существует, то пустить дальше на конвейер, а не отбросить его " ума не приложу. Поэтому задавать "lastLogonTimeStamp -eq $false" это глупость, так как эта строка подразумевает булево значение, а не проверку атрибута на существование, но у меня нет мыслей как задать фильтр.

    Ключ -Properties * отображает все заданные для объекта атрибуты. Ключевое слово "заданные" .

    Get-ADObject -filter {samaccounttype -eq 805306368} | ?{!$_.lastlogontimestamp} - тоже не катит.

    Использовать вместо модуля ActiveDirectory, по аналогичному функционалу оснастку Quest не хочется. Так как это дополнительный софт, и работает она по скорости хуже. Интерфейс [ADSI] так же не даёт результатов, подозреваю что модуль ActiveDirectory построен на этом интерфейсе. Как задать правильно фильтр чтобы на вывод попадали объекты с пустым атрибутом lastlogonTimeStamp?            

    24 августа 2015 г. 6:15

Ответы

  • just google it

    get-aduser -f {-not ( lastlogontimestamp -like "*")}

    З.Ы. lastlogontimestamp не показатель, атрибут может поменять значение и без логона юзера


    • Помечено в качестве ответа Oleg1982 24 августа 2015 г. 6:26
    • Изменено Svolotch 24 августа 2015 г. 17:08 скобку забыл
    24 августа 2015 г. 6:22

Все ответы

  • just google it

    get-aduser -f {-not ( lastlogontimestamp -like "*")}

    З.Ы. lastlogontimestamp не показатель, атрибут может поменять значение и без логона юзера


    • Помечено в качестве ответа Oleg1982 24 августа 2015 г. 6:26
    • Изменено Svolotch 24 августа 2015 г. 17:08 скобку забыл
    24 августа 2015 г. 6:22
  • Как не парадоксально но работет :). Благодарю за ответ.
    24 августа 2015 г. 6:26
  • Каким образом ? Есть УЗ которым 6 лет и lastlogontimestamp пустой . Читал статью от Microsoft где они и говорят что поиск устаревших УЗ нужно искать не по lastlogon а именно по lastlogontimestamp.

    24 августа 2015 г. 6:31
  • написано использовать lastlogontimestamp, потому что этот атрибут реплицируется между DC в отличии от lastlogon

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

    Создаем нового пользователя, атрибут ластлогонтаймстамп соответственно НЕ ЗАДАН:

    PS C:\Windows\system32> get-aduser s4utest -Properties lastlogontimestamp, logoncount

    DistinguishedName : CN=S4u2Self,OU=2,DC=contoso,DC=local
    Enabled           : True
    GivenName         :
    logoncount        : 0
    Name              : S4u2Self
    ObjectClass       : user
    ObjectGUID        : 5e477854-dae8-4302-adc6-7f2e2396cf34
    SamAccountName    : s4utest
    SID               : S-1-5-21-3735929181-1612380390-3081224696-1127
    Surname           :
    UserPrincipalName : s4utest@contoso.local

    Далее обычным пользователем смотрим эфектив пермишены на абсолютно любой файл\папку\обьект для свежесозданного пользователя. (я ограничусь получением токена из порношелла )

    PS C:\Windows\system32> new-object system.security.principal.windowsidentity("s4utest")

    AuthenticationType : Kerberos
    ImpersonationLevel : Identification
    IsAuthenticated    : True
    IsGuest            : False
    IsSystem           : False
    IsAnonymous        : False
    Name               : CONTOSO\s4utest
    Owner              : S-1-5-21-3735929181-1612380390-3081224696-1127
    User               : S-1-5-21-3735929181-1612380390-3081224696-1127
    Groups             : {S-1-5-21-3735929181-1612380390-3081224696-513, S-1-1-0, S-1-5-32-545, S-1-5-32-554...}
    Token              : 1528

    Затем смотрим значение ластлогонтаймстампа для свежесозданного пользователя и сурприз-сурприз:


    PS C:\Windows\system32> get-aduser s4utest -Properties lastlogontimestamp, logoncount

    DistinguishedName  : CN=S4u2Self,OU=2,DC=contoso,DC=local
    Enabled            : True
    GivenName          :
    lastlogontimestamp : 130848844624183656
    logoncount         : 0
    Name               : S4u2Self
    ObjectClass        : user
    ObjectGUID         : 5e477854-dae8-4302-adc6-7f2e2396cf34
    SamAccountName     : s4utest
    SID                : S-1-5-21-3735929181-1612380390-3081224696-1127
    Surname            :
    UserPrincipalName  : s4utest@contoso.local

    ТА-ДААА!!!

    Причем грят что и шарик(Sharepoint) юзает эту фишку, так что следует учитывать эту возможную "активность мертвых душ" в домене. Ну и иногда особо упорные безопастники пытаются кушать мозг неопытным админам :)

    Однако следует заметить, что атрибут обновляется только на текущее время... вернуть значение атрибута "в прошлое" нельзя.

    Подробнее:

    http://blogs.technet.com/b/askpfeplat/archive/2014/04/14/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self.aspx

    З.Ы.использованный в примере логонкаунт также не реплицируемый и на практике в нашем ключе бесполезный(на моем тестовом стенде всего 1 DC, так что я его использовал). Для получения точных данных о последнем логоне можно использовать ластлогон - вот только опрашивать нужно все DC и брать последнюю дату.

    24 августа 2015 г. 11:07
  • В том то и дело что Lastlogon не реплицируемый атрибут. А контроллеры разнесены территориально достаточно далеко. Методом эксперементов мне удалось из нескольких десятков DC, собирать актуальную информацию по lastlogon в течении часа. Но это не вариант, а больше геморрой. Так же вы забыли добавить что lastlogonTimeStamp отстаёт от lastlogon на значение атрибута msDS-LogonTimeSyncInterval который по умолчанию (если мне не изменяет память) равен 14. То бишь lastlogonTimeStamp Отстаёт на 14 дней. Что никаким образом не сказывается на поиске устаревших записей . Приведённый вами пример интересен, но в масштабах нескольких тысяч УЗ лучше иметь что то, чем ничего :).        
    24 августа 2015 г. 11:20
  •  Так же вы забыли добавить что lastlogonTimeStamp отстаёт от lastlogon на значение атрибута msDS-LogonTimeSyncInterval который по умолчанию (если мне не изменяет память) равен 14. То бишь lastlogonTimeStamp Отстаёт на 14 дней. 

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

    и не 14 дней, а  от 9 до 14 по дефолту ;-P

    про геморой согласен, но лучше день потерять потом за 5 минут долететь. Нарисовать скриптик, нехай он считает. у меня в свое время на овер 30к учеток считалось и ничо.

    24 августа 2015 г. 11:41