none
msDS-UserPasswordExpiryTimeComputed returning "01.01.1601 01:00:00" for most users

    Question

  • Good Day!

    I've just noticed that this command:

    Get-ADUser -filter {Enabled -eq $True -and PasswordNeverExpires -eq $False} –Properties “DisplayName”, “msDS-UserPasswordExpiryTimeComputed” |
    Select-Object -Property “Displayname”,@{Name=“ExpiryDate”;Expression={[datetime]::FromFileTime($_.“msDS-UserPasswordExpiryTimeComputed”)}} | CLIP

    returns lines like that for most of my users:

    Displayname ExpiryDate                                                                 
    ----------- ----------                                                                 
    FirstName Givenname 01.01.1601 01:00:00  

    With "most" i mean almost all of them. Only Exceptions are User with Domain- Admin rights and two (imo) random users.

    Logon and such works as always.

    I can't imagine what could have caused this. I've been playing around with our password-expiration-reminder script but i wouldn't know how it could be the reason.

    The Attribute "pwdlastset" is fine for alle users. 

    Reseting the Password over ADUC creates a "right" msDS-UserPasswordExpiryTimeComputed value.

    Do you have any idea what causes this?

    Thanks!


    • Edited by chrschtian Thursday, January 5, 2017 2:03 PM
    Thursday, January 5, 2017 1:42 PM

Answers

  • I believe that should only happen if pwdLastSet is 0 for the user. If the password never expires or SmartcardLogonRequired is set, then msDS-UserPasswordExpiryTimeComputed should be the largest 64-bit value allowed.

    Edit: In my domain every user with msDS-UserPasswordExpiryTime Computed of 1/1/1601 (plus or minus a few hours due to time zone) has pwdLastSet equal to 0. This means they must change their password at the next logon.


    Richard Mueller - MVP Enterprise Mobility (Identity and Access)


    Thursday, January 5, 2017 2:43 PM

All replies

  • I believe that should only happen if pwdLastSet is 0 for the user. If the password never expires or SmartcardLogonRequired is set, then msDS-UserPasswordExpiryTimeComputed should be the largest 64-bit value allowed.

    Edit: In my domain every user with msDS-UserPasswordExpiryTime Computed of 1/1/1601 (plus or minus a few hours due to time zone) has pwdLastSet equal to 0. This means they must change their password at the next logon.


    Richard Mueller - MVP Enterprise Mobility (Identity and Access)


    Thursday, January 5, 2017 2:43 PM
  • Hi Richard,

    thanks for your reply!

    sadly, thats not the case in my AD. I've got over 300 of these 1/1/1601. i checked some of them in details and all had a correct pwdLastSet value (not 0).

    Any other ideas?

    Monday, January 9, 2017 6:38 AM
  • Hi,
    I am checking how the issue going, I saw that you have marked Richard’s reply as answer, can I think that the problem is fixed? If you still have any questions, please feel free to contact us.
    Appreciate for your feedback.
    Best regards,
    Wendy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Thursday, January 12, 2017 1:49 AM
    Moderator