4

Can someone spot a mistake in the Powershell command trying to extract pwdLastSet from Active Directory for some users?

For some accounts it works:

PS C:\> get-aduser -filter "name -like 'Admin*'" -Properties pwdLastSet | Select -first 1 name,pwdLastSet  | format-list

name       : Administrator
pwdLastSet : 131254235816382539

For some it doesn't:

PS C:\> get-aduser -filter "name -like 'G*Ol*'" -Properties pwdLastSet | Select -first 1 name,pwdLastSet  | format-list


name       : Grzegorz Olędzki
pwdLastSet :

What needs to be noted, that the property seems to be set when retrieved from GUI: Properties dialog of the same user

The problem consistently affects multiple accounts, so I suspect there's something I simply don't understand.

GrzegorzOledzki
  • 998
  • 6
  • 21
  • 1
    Are you running powershell as an administrator? This can happen if your instance isn't elevated. Some password policies are likely hidden from you (GPO). – Colyn1337 Dec 09 '16 at 10:04
  • @Colyn1337 - you are a genius! I was logged in as an administrator account, but what was missing is "Run as administrator" when opening the powershell window! I suggest you put that as answer, as this truly solves the problem. – GrzegorzOledzki Dec 09 '16 at 10:15
  • 1
    I'm pretty sure that local elevation has nothing to do with querying AD - at least, I can find no reference for this. This "solution" may be a red herring. – Bill_Stewart Dec 10 '16 at 17:48

3 Answers3

4

Double check and ensure you're running powershell as an administrator. This problem can occur if your instance isn't elevated as some password policies (GPO) are likely hidden.

Colyn1337
  • 2,397
  • 2
  • 23
  • 40
  • Can you elaborate on the specifics of how this attribute might not be readable by a domain user? (I tested reading this attribute using a standard domain user and it worked fine.) – Bill_Stewart Dec 09 '16 at 15:16
  • @Bill_Stewart. Just to clarify, I haven't tried with a standard domain user, but the actual suggestion that helped me was to run powershell with "Run as administrator" option. But being logged in as the very same domain account to Windows. Obviously, your request for more information is perfectly valid. – GrzegorzOledzki Dec 09 '16 at 20:39
  • I can't reproduce with non-elevated user. I can always read the attribute. Local elevation should have no effect on the problem at all (this is because you are reading an attribute from AD, and elevation affects the local computer only). – Bill_Stewart Dec 09 '16 at 21:07
  • @Bill_Stewart i have just two controllers and I can see the same problem GrzegorzOledzki has. If i run script locally without admin rights its not shown. If i run it remotly it works fine. – MadBoy May 30 '17 at 19:48
  • @Bill_Stewart i have very similar issue and elevating permissions fixes it. I dont understand why it would work that way thou. https://serverfault.com/q/852781/32063 – MadBoy May 30 '17 at 19:49
  • The key is locally vs. remotely. In general you should not be logged onto a domain controller to run these commands because you have to elevate for numerous operations, which leads to a bad habit of opening elevated command/PowerShell windows on a domain controller. – Bill_Stewart May 30 '17 at 21:37
1

If the pwdLastSet value is null/blank, that means that the user has to change their password at the next logon. Un-ticking the box in users properties would show you a date

Lev1Athan
  • 11
  • 1
-1

Here is a function you can use to test:

function Get-PwdLastSet {
  param(
    [parameter(Mandatory=$true)] [String] $sAMAccountName
  )
  $searcher = [ADSISearcher] "(&(pwdLastSet=*)(sAMAccountName=$sAMAccountName))"
  $searcher.PropertiesToLoad.AddRange(@("pwdLastSet","sAMAccountName"))
  $searchResult = $searcher.FindOne()
  if ( $searchResult ) {
    $pwdLastSet = $searchResult.Properties["pwdlastset"][0]
    if ( $pwdLastSet -gt 0 ) {
      [DateTime]::FromFileTime($pwdLastSet)
    }
    else {
      "Password is expired"
    }
  }
}

If this script fails to read the pwdLastSet attribute, the only explanation I can think of is that the user running the script lacks permission to read that attribute from Active Directory. AFAIK, that attribute should be readable by default to all members of Domain Users, so it may be that the Active Directory object permissions have been changed from the defaults.

Bill_Stewart
  • 258
  • 1
  • 7
  • 3
    Thanks for helping. But I am not sure if it addresses the problem. The function simply returns nothing for the faulty accounts, and a date (as expected) for the 'proper ones': http://pastebin.com/vMMVvsvs – GrzegorzOledzki Dec 08 '16 at 23:19
  • First, don't use parentheses `( )` to call functions in PowerShell (it is valid syntactically but wrong semantically). The proper way to execute the function is just `Get-PwdLastSet grz`. Secondly, step through the function in the ISE debugger and see 1) if the `$searchResult` variable gets populated, and 2) what the value of the `$pwdLastSet` variable gets set to (`$null`?). – Bill_Stewart Dec 09 '16 at 00:13
  • thanks for the hint. I made a separate question to cover that: http://serverfault.com/q/819763/32017. I think I know the answer now, but feel free to provide your explanation. I appreciate your help. This is how I learn. Great! – GrzegorzOledzki Dec 09 '16 at 10:29
  • Note that I carefully worded this answer as something "you can use to test"--i.e., it may aid in troubleshooting the problem. – Bill_Stewart Dec 10 '16 at 19:28