[Samba] Samba4 pwdLastSet Attribute

[Michael Wood]

Hi

This seems worth reporting to samba-technical, so I've copied my reply there.

On 30 January 2013 18:01, Thomas Simmons <twsnnva at gmail.com> wrote:
> 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

-- 
Michael Wood <esiotrot at gmail.com>