Вопрос: Запрос Powershell lastlogondate (lastlogontimestamp) возвращает в основном пустые значения (не соответствующие значению ADSIedit для соответствующего пользовательского атрибута)


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

get-aduser -filter * -property * | ft name, lastlogondate

Я заметил, что только небольшая часть пользователей имеет значение даты входа в систему, а подавляющее большинство - пустое. Эти активные пользователи регистрируются каждый день. Насколько я понимаю, lastlogondate - это своего рода псевдоним powershell, который преобразует значение атрибута пользователя lastlogontimestamp из большого целого в читаемую дату. У меня был успех с этим запросом в прошлом, и снова он отлично работает для некоторых пользователей. Я пошел в ADSIedit и обнаружил, что все пользователи имеют значение в lastlogontimestamp. Несмотря на это, если я прямо запрошу это значение, я все равно буду пустым в PS для каждого пользователя, о котором идет речь:

get-aduser -filter * -property * | ft name, lastlogontimestamp

Это поведение верно для всех 3 контроллеров домена в домене. Я сбит с толку. Это часть более крупного сценария, который сообщает и действует на учетных записях пользователей, которые не вошли в систему дольше, чем X дней, и работали нормально ежеквартально до сегодняшнего дня. Сегодня, когда я запускал его, я заметил, что в отчете появилось очень мало пользователей, так как в поиске и устранении неполадок я включил наиболее простой запрос, чтобы посмотреть, что он будет делать. Бланк времени, возвращаемый в powershell, определенно ошибочен и почему так мало пользователей отображаются в моем отчете как устаревшие (сценарий исключает пустые значения входа в систему), но я не знаю, почему значение в PS пусто, а значение в редакторе ADSI для конкретного пользователя определенно заселен. Это относится и к нескольким другим атрибутам, таким как «logoncount», и только для тех затронутых пользователей (большинство), в то время как у немногих пользователей, которые работают правильно, нет никаких отступов между атрибутом ADSI и тем, что показывает PS вообще.

Все 3 DC в этом примере - 2012 R2, и я заметил, что это поведение также происходит в учетных записях пользователей в меньшем смешанном домене, который у нас есть (2008 и 2012 гг.), Но остался незамеченным, потому что вряд ли кто-то из них проживает там, поэтому не так много фокус.

Еще одна важная вещь, если я запустил эту команду PS с учетными записями компьютеров Get-ADcomputer вместо Get-ADuser, у меня таких проблем нет, все компьютеры сообщают о lastlogondate правильно без пробелов.

Любая помощь, прежде чем я позвоню в Microsoft?


6
2018-04-22 19:40


Источник


Является ли это странное поведение согласованным во всех контроллерах домена? Вы можете использовать -Server параметр для задания определенного DC - Mathias R. Jessen
Да, мне не удалось заставить команду -server работать, но я вручную выполнил запрос на каждом контроллере домена и проверил ADSIedit на каждом контроллере домена, и поведение было согласованным. - Frustrated_IT_guy
В качестве теста я создал одного совершенно нового пользователя теста. Вход на сервер в домене, так как это тестовый пользователь для создания метки времени. Проверено, что атрибут ADSI существует на DC для lastlogontimestamp. Затем я запускаю запрос Powershell: get-aduser -filter 'name -like "testIT"' -property * | ft name, lastlogondate и lastlogondate пуст - Frustrated_IT_guy
Если вы используете DSQUERY из того же приглашения вы получаете те же результаты, что и из Get-ADUser или той же информацией, которую вы видите в ADSIEdit? Пытаться dsquery * -limit 0 -filter "objectClass=user" -attr name lastLogonTimestamp, - Adi Inbar
Adi Я выполнил вашу команду и вернул правильные значения lastlogontimestamp для всех КОМПЬЮТЕРНЫХ СЧЕТОВ, но показывает пустые значения для затронутых пользователей (то есть некоторые пользователи имеют значения, а большинство нет), поэтому он согласуется с get-aduser тем, что он ошибочен в соответствии со значениями в ADSIedit для большинства пользователей. - Frustrated_IT_guy


Ответы:


Ади был прав, это какая-то проблема с разрешениями. Я действительно разрешил это только сейчас, когда коллега выполнил запрос и получил правильные результаты, однако он использовал свой собственный аккаунт для входа. Я добавил, что он «работал как администратор», чтобы поднять консоль PS. Когда я это сделал, он работал правильно. Я понятия не имею, как мне никогда не приходилось делать это в прошлом, а также я администратор домена и, следовательно, местный администратор в DC, но что бы то ни было. Теперь он работает с использованием расширенной подсказки PS. Для записи я пошел в ADSIedit с моей обычной учетной записью и не запускал поднятый сеанс ..... Странно, но я возьму его.


2
2018-04-24 18:05