samba3upgrade migration results, issues, questions
urushkin at telros.ru
Fri May 4 05:46:19 MDT 2012
04.05.2012 09:42, Sergey Urushkin написал:
> 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 ( 188.8.131.52.4.1.7184.108.40.206 NAME 'sambaMaxPwdAge'
> DESC 'Maximum password age, in seconds (default: -1 => never
> expire passwords)'
> EQUALITY integerMatch
> SYNTAX 220.127.116.11.4.1.1418.104.22.168.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.
Tried that patch (patch ... && make clean && ./configure.developer &&
make && make install && samba-tool domain samba3upgrade ...), nothing
changed, I see the same error in logs.
I'll be glad to test any new ones.
Also, I found another workaround much simpler than 'samba-tool user
# samba-tool domain passwordsettings show
Maximum password age (days): 2592000
# samba-tool domain passwordsettings set --max-pwd-age=30
After this all problems gone away. Even if the bug will be fixed, I
think it's a good idea to put this info into the wiki (like "if you're
using an old s4 version ...").
Backing to the small domain... seems it's not the same bug.
There I have max-pwd-age=0, but the problem still exists. Using
ldbsearch I found that all accounts "accountExpires" attribute is set to
"116444735990000000" (23:59:59 - 01.01.1970).
Setting it to a lager value e.g. "136444735990000000" (2033y) fixes
account. So, I tried to view s3.0 tdb account via s3.6 pdbedit tool:
Unix username: pc106
Account Flags: [U ]
User SID: S-1-5-21-2558268738-2209604249-3907695097-3026
Primary Group SID: (NULL SID)
Full Name: Samba_User &
Home Directory: \\fw\pc106
Logon time: 0
Logoff time: 9223372036854775807 seconds since the Epoch
Kickoff time: 9223372036854775807 seconds since the Epoch
Password last set: Fri, 15 Apr 2011 10:17:59 MSK
Password can change: Fri, 15 Apr 2011 10:17:59 MSK
Password must change: never
Last bad password : 0
Bad password count : 0
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
As you can see Logoff/Kickoff values are very strange and 'primary group
sid' is null. That's about all users.
It is an old-old "magic" samba 3.0.x db provisioned by another person a
long time ago on FreeBSD 4.4 :)
More information about the samba-technical