Bug 2614 - account_policy.tdb not upgraded automatically from 3.0.11 to 3.0.13
Summary: account_policy.tdb not upgraded automatically from 3.0.11 to 3.0.13
Status: CLOSED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts (show other bugs)
Version: 3.0.13
Hardware: All Linux
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-14 13:40 UTC by John Janosik
Modified: 2005-08-24 10:19 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Janosik 2005-04-14 13:40:30 UTC
We upgraded our Samba DCs from 3.0.11 to 3.0.13 last week and now see that some
tools are reporting the incorrect password expiration date.  Running pdbedit for
both 'maximum password age' and 'maximum password age (seconds since 1970)' fails.

[root@rchs10dc locks]# /usr/local/samba/bin/pdbedit -P "maximum password age
(seconds since 1970)"
account_policy_get: tdb_fetch_uint32 failed for field 4 (maximum password age
(seconds since 1970)), returning 0
valid account policy, but unable to fetch value!

[root@rchs10dc locks]# /usr/local/samba/bin/pdbedit -P "maximum password age"
No account policy by that name
Account policy names are :
min password length
password history
user must logon to change password
maximum password age (seconds since 1970)
minimum password age (seconds since 1970)
lockout duration
reset count minutes
bad lockout attempt
disconnect time
refuse machine password change

Dumping the tdb shows only the old name:

[root@rchs10dc locks]# ../../bin/tdbdump account_policy.tdb
<cut most output>
{
key = "maximum password age\00"
data = "\00\A7v\00"

I worked around the issue by using tdbtool to insert a new key value pair with a
key of "maximum password age (seconds since 1970)"
Comment 1 John Janosik 2005-04-14 13:59:41 UTC
Sorry I see in svn that this is already fixed.
Comment 2 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:19:06 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.