[Samba] Samba4 pwdLastSet Attribute

[Matthieu Patou]

On 02/15/2013 05:40 AM, Thomas Simmons wrote:
> Hello Matthieu,
>
> As I understand it, this is true for all versions of AD, however the only
> version I have to test with is W2K.
Well I don't think so Microsoft made a lot of important changes with 
windows 2003 to correct many wrong decision that were made with the 
first release of AD.

You can download a 3 or 6 month copy of windows 2008r2 or Windows 2012 
to make some other tests.
>   Using ADUC and Samba4, if I reset a
> password with "user must change...", then go back into the users account
> tab and remove that check, the value gets set to -1. With this value, the
> user is not forced to change their password and the password will never
> expire. This problem was initially discovered by a script I wrote that
> emails users to notify of upcoming expiration - the -1 value threw off the
> arithmetic the script was doing to calculate the time remaining. I've not
> found a place where Microsoft explicitly states that pwdLastSet works this
> way, but both research and my own experience suggests this is how it works.
> Please see the following links:
>
> (Here a Microsoft MVP notes this behavior)
> https://groups.google.com/forum/?fromgroups=#!topic/microsoft.public.adsi.general/qUfqhn0qb6M
>
> http://powergui.org/thread.jspa?messageID=48281
>
> (See the comments here)
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms679430%28v=vs.85%29.aspx
>
> Now mind you, I like the fact that in S4 I can arbitrarily set pwdLastSet
> to any valid timestamp, and I'm not concerned with that at all. My only
> concern is that Samba is not "auto-converting" the -1 into the current
> timestamp, which leaves the user account in a state where they can login
> and their password will never expire.
Ok, sorry I might have mis-understood the problem with the 0 and the -1.

Please fill a bug report explicitly speaking about the -1 case that 
should be handled in a different way.

Matthieu.
> On Fri, Feb 15, 2013 at 3:25 AM, Matthieu Patou<mat at samba.org>  wrote:
>
>> On 01/30/2013 10:26 AM, Thomas Simmons wrote:
>>
>>> Thank you Michael. I just want to make sure this is clear for the Samba
>>> team:
>>>
>>> Using an LDAP editor, Windows Server will ONLY accept values of 0 and -1.
>>> I
>>> CANNOT manually set this attribute to a valid AD timestamp (ex.
>>> 129968051000000000). As mentioned before, setting to 0 requires the user
>>> to
>>> change the password on next logon and the 0 value IS kept. If I set it to
>>> -1 and refresh my LDAP view, I can see the value has been set to the
>>> current time. Finally, if the attribute is CURRENTLY a valid AD timestamp,
>>> it will not accept -1. I must first change the value to 0, then to -1.
>>>
>>> What is most confusing... While *I* cannot set the timestamp value to
>>> anything other than 0 or -1 on Windows with an LDAP editor, logic says
>>> ADUC
>>> must somehow do this. I assume S4 does not honor the "-1 behavior" above,
>>> yet when I reset a password WITH the "require change..." box unchecked,
>>> the
>>> value gets set properly. If ADUC is setting this value "manually" with S4,
>>> it would be doing the same with Windows Server. Of course, logic and
>>> assumption do not generally go well together :)
>>>
>>>
>>>   You're comparing Apple and Carrots, because Samba has the forest level
>> 2003 when your AD w2k so you can expect different behavior.
>> The values are set this way by ADUC, so I believe that behavior has
>> changed between FL 2000 and FL 2003.
>>
>> Matthieu.
>>
>>
>>
>>> On Wed, Jan 30, 2013 at 11:18 AM, Michael Wood<esiotrot at gmail.com>
>>> wrote:
>>>
>>>   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>
>>>>
>>>>
>> --
>> Matthieu Patou
>> Samba Team
>> http://samba.org
>>
>>


-- 
Matthieu Patou
Samba Team
http://samba.org