[Samba] Samba4 pwdLastSet Attribute
Thomas Simmons
twsnnva at gmail.com
Fri Feb 15 06:40:11 MST 2013
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. 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.
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
>
>
More information about the samba-technical
mailing list