[Samba] Samba4 pwdLastSet Attribute

[Thomas Simmons]

I have verified that I do not get this behavior on W2K AD. If I set "must
change..." the value gets set to 0, but when I uncheck the box it gets set
to the current time. Further testing shows anytime I manually change the
value to -1 in W2KAD, the value actually gets set to the current time. It
seems AD accepts the values 0 and -1, however -1 is always set to the
current timestamp. Also, in Active Directory I cannot manually change the
value to -1 without first changing it to 0. Hope this makes sense.

Thanks,
Thomas


On Wed, Jan 30, 2013 at 10:43 AM, Thomas Simmons <twsnnva at gmail.com> wrote:

> It seems I had that backward - checking "require change at next logon"
> sets pwdLastSet to 0 and afterward unchecking it sets it to -1. I've done
> some research and understand that the "0" value is standard. I don't
> understand the -1, however. My testing shows when this is set to -1, the
> password does not seem to be expired and the user can login without
> changing their password. Effectively, the user has a valid password that
> will never expire. Imagine this scenario.
>
> Thanks,
> Thomas
>
>
> On Wed, Jan 30, 2013 at 9:00 AM, Thomas Simmons <twsnnva at gmail.com> wrote:
>
>> Hello,
>>
>> I am in the process of updating a bunch of scripts and tools that I had
>> created for use with our Samba 3 domain. I am currently working on a script
>> that emails a password expiration warning. I have the script setup to query
>> the pwdLastSet attribute for each user. It then performs some simple math
>> to figure out when the password will expire and when the notification
>> emails should start. Everything is working for the most part, however I
>> found that if the "User must change password at next logon" box is checked
>> when an Admin resets a password, pwdLastSet gets set to -1. If I then go
>> into the account properties AFTER the reset, and uncheck this option under
>> the account tab, pwdLastSet gets changed from -1 to 0. Both of these screw
>> up my calculations. Is this normal Active Directory behavior? I can alter
>> the script to specifically look for those values and take some action if
>> this is normal behavior - I simply want to make sure. Are there any other
>> cases where pwdLastSet would not be a "proper" AD timestamp?
>>
>> Thanks,
>> Thomas
>>
>
>