samba3upgrade migration results, issues, questions

[Sergey Urushkin]

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 ( 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.
>
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
setexpiry' looping:

# 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
NT username:         
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
HomeDir Drive:       
Logon Script:        
Profile Path:        
Domain:               DOMAIN
Account desc:        
Workstations:        
Munged dial:         
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 :)

Thanks

-- 
Best regards,
Sergey Urushkin