Andrew, can you please have a look at this?

*** Bug 10992 has been marked as a duplicate of this bug. ***

This could be related to "idmap_ldb:use rfc2307 = yes" or a bug in the classic upgrade.

I have a domain with that was provisioned with 4.0.x, upgraded to 4.1
and running current master now. This works fine, I'll test with v4-2-test
but I guess this would also work...

I can't reproduce this with v4-2-test => no blocker of 4.2.0.

I have run into this bug. Our domain was provisioned by classicupgrade going from 3.6.x to 4.0.0. We've since upgraded through every 4.0.x and 4.1.x version. I am currently trying to upgrade from 4.1.16 to 4.2.0.

I decided to restore from the 4.1.16 backup that I took before the upgrade, however I can setup a VM for testing.

I had the same problem when upgrading to 4.2.0. The domain has been provisioned by using classicupgrade going from a 3.6.x NT4-style domain to an 4.1.0 AD domain. I had to revert back to 4.1.17 to keep our production environment going.

I also have this problem after classicupgrade, will this related to secrets.tdb?
The following secrets.tdb is dump from classicupgrade(some are mask):
[root@linux01 kelvinyip]# tdbdump /usr/local/samba/private/secrets.tdb
{
key(23) = "SECRETS/PROTECT/IDS/ICS"
data(5) = "TRUE\00"
}
{
key(19) = "SECRETS/DOMGUID/ICS"
data(16) = ",X\XX\XX\XX\XXXX\XX\XXXX\0D\81\97\F0"
}
{
key(15) = "SECRETS/SID/ICS"
data(68) = "\01\04\00\00\00\00\00\05\15\00\00\00\E9\F1-\XX\XX\XX\XX\XX\XX\XX\XX\XX\00\00\00\00\00\00\00\00\00\00\00\00\00\                                                        00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00"
}

The following secrets.tdb is dump from new dc promption:
[root@linux Samba-Migrate]# tdbdump /usr/local/samba/private/secrets.tdb
{
key(39) = "SECRETS/SALTING_PRINCIPAL/DES/TEST1.LOC"
data(31) = "host/linux.test1.loc@TEST1.LOC\00"
}
{
key(38) = "SECRETS/MACHINE_LAST_CHANGE_TIME/TEST1"
data(4) = "O\F0%U"
}
{
key(38) = "SECRETS/MACHINE_SEC_CHANNEL_TYPE/TEST1"
data(4) = "\06\00\00\00"
}
{
key(25) = "SECRETS/PROTECT/IDS/TEST1"
data(5) = "TRUE\00"
}
{
key(30) = "SECRETS/MACHINE_PASSWORD/TEST1"
data(181) = "+d>!bxiFH=hInDPC.]<o:;$f~L%MAF,oB[KPnm(nRJxJ1?K8),7Db+Mh<y5q:MiSF@[7kB8;Bkd3au6J:BDG9I8CT,G%;>_jSE>HzMcU.&bhab,E.NQc78=BrIRdBF?LNjJ                                  VTlHIBVF&fDshQ#=PlDzK;ZgVdQqMYr?nvFGT$e_%TVPDB0gl\00"
}
{
key(21) = "SECRETS/DOMGUID/TEST1"
data(16) = "\8D\86]rH\E0wI\91\82\81\9C\92\07\93\9D"
}
{
key(17) = "SECRETS/SID/TEST1"
data(68) = "\01\04\00\00\00\00\00\05\15\00\00\00\E62\E67,\85^\93\92\A6\F5\F7\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\0                                  0\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00"
}

Seems my guess is correct, Samba4.2 can start now. I tried in my testing environment, and will try in production later.
I tried to dump the password through: 
ldbsearch --url=/usr/local/samba/private/secrets.ldb
Copy the "secrets" from the screen.

cp -rfp /usr/local/samba/private/secrets.tdb /usr/local/samba/private/secrets2.tdb 
#Execute the tdbtool to insert the record
tdbtool
>open /usr/local/samba/private/secrets.tdb
>insert SECRETS/SALTING_PRINCIPAL/DES/ICSHK.LOCAL host/linux01.icshk.local@ICSHK.LOCAL\00
>insert SECRETS/MACHINE_LAST_CHANGE_TIME/ICS O\F0%U
>insert SECRETS/MACHINE_SEC_CHANNEL_TYPE/ICS \06\00\00\00
>insert SECRETS/MACHINE_PASSWORD/ICS #Y3Y:@[>$j)Q.6Q<9P6)3=UH5gRgF_IRfO4J&c&)d(DV)cO:Z#[iMLK%>CdILs+i?W5(KKWe-=c0@?5ShxU:h6PFK;[ho5-]rDPsJp(79LH.b?CZZ<K3Ybdh-)(g+&:&GFbdABJa+pp,OgC;AanrPkie]9IR+QfWB1,jvK,MeC!wp3D-FkyqEXGOM:jzSaYq-;)\00
>quit

Modify the parameters above if you want to give a try.

OK, this is starting to make more sense.  

Can you try running './source4/scripting/devel/chgtdcpass'

That should re-generate the passwords, and store them in the correct place. 

This looks like it is fixed in master, but in 4.2 we don't read the secrets.ldb to find the password during the upgrade case.

The thing I find most confusing is that secrets.ldb should be writing out entries into secrets.tdb due to the secrets_tdb_sync module.  We need to know why that didn't execute in the classicupgrade.

(In reply to Andrew Bartlett from comment #10)
The issue here is the secrets.tdb that is held open when we do the self join in the classicupgrade script is the OLD secrets.tdb file.

That means the DC self join password is placed in the secrets.tdb file in the Samba3 'source' directory. 

We need to either have the code from master to allow the newer of secrets.tdb or secrets.ldb to be used, or reset the secrets.tdb context held open in a static variable in secrets.c.

That could be done in the setup_self_join() code, but I don't like the side-effects.

Or we could rewrite secrets_store_machine_pw_sync() to take a db_ctx, which we would open in the secrets_tdb_sync module, but that would mean reworking the secrets_*() routines to take one, or not using those helper routines.

Andrew Bartlett

(In reply to Andrew Bartlett from comment #11)
The simple fix for this is probably to:

Reset the open secrets.tdb in the script, and run chgtdcpass internally in the classicupgrade, essentially re-running the self join.

running chgtdcpass solved the problem in my 2 test cases:

1) classicupgrade to 4.1.17 then upgraded to 4.2.1
2) classicupgrade to 4.2.1

Created attachment 11146 [details]
Have winbindd sync secrets.tdb with secrets.ldb at startup (4.2 version)

I'll update this patch with the master git commits when it is in master.  The master patch is slightly different.

Created attachment 11147 [details]
Have winbindd sync secrets.tdb with secrets.ldb at startup (master version)

Patch for master, currently in a trial autobuild.

Hello 
Sorry forma mi english, i had this problem bit y dont know how lauch a chgtdcpass.
Thanks

Comment on attachment 11147 [details]
Have winbindd sync secrets.tdb with secrets.ldb at startup (master version)

And improved version of this patch is now in master.

Created attachment 11182 [details]
Have winbindd sync secrets.tdb with secrets.ldb at startup (4.2 version)

This patch backported from master (cherry-pick not possible due to test env rename)

Comment on attachment 11182 [details]
Have winbindd sync secrets.tdb with secrets.ldb at startup (4.2 version)

LGTM ( a few whitespace errors, but that shouldn't hurt applying, but please fix those in future Andrew).

Reassigning to Karolin for inclusion in 4.2.next.

(In reply to Jeremy Allison from comment #20)
Pushed to autobuild-v4-2-test.

Pushed to v4-2-test.
Closing out bug report.

Thanks!