Hi,
how would I go about dumping tdb files in a “neutral” format,
preferably JSON?
The goal is to have a domain member functional after restoring
from a backup without re-joining. Ideally, the backed up version
does not depend on the tdb because of concerns about the
stability of the format. A backup set must remain usable despite
a multi-major version Samba update happening in between.
By trial and error I determined that
/var/lib/samba/private/{netlogon_creds_cli,secrets}.tdb are the
only files from whose removal smbd can’t recover, so those are
the files I’m currently concerned with.
Another issue is that dumping those files with the tdb tools
yields opaque binary data, e. g.
# tdbdump private/netlogon_creds_cli.tdb
{
key(43) = "CLI[UNDEF/UNDEF$]/SRV[FOO-SERVER-2008/FOO]\00"
data(96) =
"\FF\FF\0Fa\FB\E1\8C\03{\81\D3\8B\D9\D5\81\C4-\02\E8Cq\F9\A1[\F4\19\A7\22\D5\C4\A8~\B1\A6;\85;\F4\0C\CC\B6\86\99\8C\FF\9E\9A\17\02\00\00\00\06\00\00\00\00\00\00\00\06\00\00\00UNDEF\00\00\00\07\00\00\00\00\00\00\00\07\00\00\00UNDEF$\00\00\00\00\00\00"
}
How stable are those values? Is there a way to destructure them
for the backup to reconstruct them during restore in case the
format changes?
What about portability? Are tdb contents platform independent? Is
a secrets.tdb created with 32 bit Samba usable on a 64 bit build
and vice versa?
Thanks,
Philipp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<http://lists.samba.org/pipermail/samba/attachments/20180921/957327b3/signature.sig>
On Fri, 2018-09-21 at 11:29 +0200, Philipp Gesang via samba wrote:> Hi, > > how would I go about dumping tdb files in a “neutral” format, > preferably JSON? > > The goal is to have a domain member functional after restoring > from a backup without re-joining.Do take care that the password is changed by winbindd regularly. It might not work any more.> Ideally, the backed up version > does not depend on the tdb because of concerns about the > stability of the format. A backup set must remain usable despite > a multi-major version Samba update happening in between.I understand your concern, but on the flip side we have actually been pretty conservative on that. Of course the way to assure that into the future is to add tests using current and past databases.> By trial and error I determined that > /var/lib/samba/private/{netlogon_creds_cli,secrets}.tdb are the > only files from whose removal smbd can’t recover, so those are > the files I’m currently concerned with.It should be only secrets.tdb. The netlogon_creds_cli.tdb can be re- built from the domain member password. A long time ago I posted a script to dump the machine password to stdout for the benifit of an 802.1x client, but it never had tests so didn't get in. I could see JSON working well for this also. Perhaps extend either samba-tool or net to print out the domain SID, local SID, domain member password and hostname? (There are other elements of state, like idmap values, but how far you go depends on the local configuration needs, but these would be the four most critical items). Then extend 'net join' to accept these for an offline join and 'samba- tool computer' to print out such values (not the local sid). That could really help in automation.> Another issue is that dumping those files with the tdb tools > yields opaque binary data, e. g. > > # tdbdump private/netlogon_creds_cli.tdb > { > key(43) = "CLI[UNDEF/UNDEF$]/SRV[FOO-SERVER-2008/FOO]\00" > data(96) = "\FF\FF\0Fa\FB\E1\8C\03{\81\D3\8B\D9\D5\81\C4- > \02\E8Cq\F9\A1[\F4\19\A7\22\D5\C4\A8~\B1\A6;\85;\F4\0C\CC\B6\86\99\8C > \FF\9E\9A\17\02\00\00\00\06\00\00\00\00\00\00\00\06\00\00\00UNDEF\00\ > 00\00\07\00\00\00\00\00\00\00\07\00\00\00UNDEF$\00\00\00\00\00\00" > } > > How stable are those values? Is there a way to destructure them > for the backup to reconstruct them during restore in case the > format changes?Thankfully this file and these values shouldn't be needed.> What about portability? Are tdb contents platform independent? Is > a secrets.tdb created with 32 bit Samba usable on a 64 bit build > and vice versa?Yes, tdb files are portable. Thanks for your interest and passion for improving Samba, this is really important stuff to improve. I'll get your other JSON patches in soon. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
Hi Andrew, thanks for addressing all my points. This is rather helpful. -<| Quoting Andrew Bartlett <abartlet at samba.org>, on Friday, 2018-09-21 08:23:26 AM |>-> On Fri, 2018-09-21 at 11:29 +0200, Philipp Gesang via samba wrote: > > how would I go about dumping tdb files in a “neutral” format, > > preferably JSON? > > > > The goal is to have a domain member functional after restoring > > from a backup without re-joining. > > Do take care that the password is changed by winbindd regularly. It > might not work any more.The most common scenario for restoring a backup would be inside the “window of opportunity” when the current password is still valid. Besides, knowing our customers I expect a significant number of users to disable password rotation for machine accounts in the GPO …> > By trial and error I determined that > > /var/lib/samba/private/{netlogon_creds_cli,secrets}.tdb are the > > only files from whose removal smbd can’t recover, so those are > > the files I’m currently concerned with. > > It should be only secrets.tdb. The netlogon_creds_cli.tdb can be re- > built from the domain member password.You’re right, I just ran the test again. Probably a fluke in my tests last week.> A long time ago I posted a script to dump the machine password to > stdout for the benifit of an 802.1x client, but it never had tests so > didn't get in. > > I could see JSON working well for this also. Perhaps extend either > samba-tool or net to print out the domain SID, local SID, domain member > password and hostname?Sounds promising. I’ll look into that.> (There are other elements of state, like idmap values, but how far you > go depends on the local configuration needs, but these would be the > four most critical items).> > What about portability? Are tdb contents platform independent? Is > > a secrets.tdb created with 32 bit Samba usable on a 64 bit build > > and vice versa? > > Yes, tdb files are portable.Just to be absolutely sure: This is true of both the tdb format and the binary data stored in the values? Best, Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.samba.org/pipermail/samba/attachments/20180924/297db7ae/signature.sig>
Hi again, -<| Quoting Andrew Bartlett <abartlet at samba.org>, on Friday, 2018-09-21 08:23:26 AM |>-> On Fri, 2018-09-21 at 11:29 +0200, Philipp Gesang via samba wrote: >> The goal is to have a domain member functional after restoring >> from a backup without re-joining. > > Do take care that the password is changed by winbindd regularly. It > might not work any more.I’m revisiting this issue right now. Specifically, I’m looking for a means to have another process notified of a password change completed by winbindd. I had no luck so far skimming the man pages and source for hooks I could use. Any advice would be appreciated. Thank you! Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.samba.org/pipermail/samba/attachments/20181024/6f9c5570/signature.sig>