samba3upgrade migration results, issues, questions

[Sergey Urushkin]

Andrew Bartlett писал 06.05.2012 11:25:
> On Fri, 2012-05-04 at 09:42 +0400, Sergey Urushkin wrote:
>>
>> 04.05.2012 04:47, Andrew Bartlett написал:
>> > On Thu, 2012-05-03 at 17:26 +0400, Sergey Urushkin wrote:
>> >> Andrew Bartlett писал 03.05.2012 16:32:
>> >>> What was the original account policy?
>> >> sambaMaxPwdAge: 2592000
>> > This is the fundemental issue, and attached is a proposed patch.  
>> The
>> > logs you sent me privately contained the critical clue.
>> >
>> > The problem is, that this is a 7000 year password expiry.  As 
>> such, it
>> > is a little beyond what times we can print with gmtime(), which 
>> breaks
>> > down for such large dates.
>> >
>> > I've put in a clamp on returning and processing password expiry 
>> past
>> > 2038 for now, as we define TIME_T_MAX to that in for other 
>> processing.
>> >
>> > Please let me know if this solves your issue, so I can push it to
>> > master, and I thank you very much for your patience.
>> >
>> > Andrew Bartlett
>> This patch may help in some situations, but I believe there is 
>> another
>> reason for this issue.
>> Here is a part of samba.schema for openldap:
>>
>> # "maximum password age"
>> attributetype ( 1.3.6.1.4.1.7165.2.1.61 NAME 'sambaMaxPwdAge'
>>         DESC 'Maximum password age, in seconds (default: -1 => never
>> expire passwords)'
>>         EQUALITY integerMatch
>>         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
>>
>> The key words are "in seconds". So, I think the problem is that
>> samba3upgrade uses this value as a number of days, but it should be 
>> a
>> number of seconds.
>> Anyway I'll try you patch to test if it helps with a possible 
>> situation
>> you described.
>
> Thanks, this is why I'm very glad to be working with you on this.  
> Try
> this patch instead.

Yeah, it works:
# samba-tool domain passwordsettings show
Maximum password age (days): 30

And I tested all users with name beginning with a,b,c using my script 
(with kinit), all of them are good now. So, seems the big domain issue 
is fixed now, thank you Andrew.
But... When I tried to change one user's pwdlastset attribute value to 
something old - I got this:
# kinit user
user at TELROS.RU's Password:
kinit: krb5_get_init_creds: No ENC-TS found

[2012/05/06 14:16:28,  3] 
../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
   Kerberos: ENC-TS Pre-authentication succeeded -- user at TELROS.RU using 
arcfour-hmac-md5
[2012/05/06 14:16:28,  2] ../source4/auth/sam.c:214(authsam_account_ok)
   sam_account_ok: Account for user 'user at TELROS.RU' password expired!.
[2012/05/06 14:16:28,  2] ../source4/auth/sam.c:216(authsam_account_ok)
   sam_account_ok: Password expired at 'Sat Sep 27 10:54:43 1980 MSK' 
unix time.

S4's kdc should ask me to change an expired password, shouldn't it? The 
same time windows logon screen asks me about it and do changes the 
password with success (how did it know? through rpc/ntlm?) . Seems it's 
the small domain bug I've described in my another message. Could you 
take a look at it. This is really bad issue. I'm glad I've discovered 
this before migration, according to it every linux user (krb) will not 
be able to change the password when it expires.

Thank you a lot again, Andrew.

-- 
Best regards,
Sergey Urushkin