POWERSHELL : Get-AdUser as NT AUTHORITY AccountExpirationDate properties blank

As domain admin

get-aduser -Filter { GivenName
-like 'us')} -searchbase "DC=dom,DC=com" -properties * | Select SamAccountName, SurName, GivenName, @{Label='CurrentDate';Expression={get-date} }, AccountExpires, AccountExpirationDate

It s OK.

SamAccountName        : us
SurName               : us
GivenName             : us
CurrentDate           : 20/02/2024 15:02:19
AccountExpires        : 133537212000000000
AccountExpirationDate : 01/03/2024 00:00:00

But as NT AUTHORITY\System user, output is

SamAccountName        : us
SurName               : us
GivenName             : us
CurrentDate           : 20/02/2024 15:02:19
AccountExpires        : 
AccountExpirationDate :

Expirations are blank. It was working few weeks ago. To test as SYSTEM, i use this command :

PsExec.exe -i -s C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Have you got a clue? Thanks.

Solution

As mentioned in the comments, a process running under the system context will assume the machine's domain identity for authenticated network calls - and regular computer accounts have little reason to read the accountExpires of any account, since the only computers that should care about its value for operational purposes are Domain Controllers, so likely haven't been granted read access to it.

While it might be tempting to update the ACLs in the directory store to allow this random computer you're currently running your reporting tasks on to read the attribute value, I'd strongly caution against that - instead, create a new dedicated user account in AD, and use the credentials of that new account to query the directory in your script.

If you need to grant the new account additional permissions, make sure you follow the AGDLP model:

Create a new global or universal security group in AD, name it for the task being performed:
- eg. MT-AccountReporters
Create 1 or more domain-local security group(s) in AD, name each one for the permission(s) being delegated:
- eg. DLG-UserAccDetails-R
Grant each of the required permissions to the corresponding groups from the previous step
Make the user account a member of MT-AccountReports group, then make the MT-AccountReports group a member of DLG-UserAccDetails-R (and any other delegation group created for this above)

This may sounds slightly overkill, but by separating delegation of permissions sets from the tasks the grantees need to perform, you'll now be able to implement other task delegations in the future without worrying about lifecycle maintenance of the ACLs