[Samba] LDAP/PDC migration to Samba4

[Andrew Bartlett]

On Sun, 2014-07-20 at 07:43 +0200, Davor Vusir wrote:
> 
> Den 20 jul 2014 07:25 skrev "Andrew Bartlett" <abartlet at samba.org>:
> >
> > On Sun, 2014-07-20 at 06:47 +0200, Davor Vusir wrote:
> > > Den 20 jul 2014 03:44 skrev "Marc Muehlfeld"
> <mmuehlfeld at samba.org>:
> > > >
> > > > Am 20.07.2014 03:05, schrieb Andrey Repin:
> > > > > Yes, I'm running over LDAP backend. (Made my life alot easier,
> allowing
> > > me
> > > > > transparent authentication in many places beside Samba!)
> > > > >
> > > > >> You could install a new machine with x86_64 and tell it to
> use your
> > > LDAP
> > > > >> again. If it was on the old 32-bit host, then export it
> (slapcat) and
> > > > >> import it on the new one (slapadd).
> > > > >
> > > > >> Depending on what else was in your 32-bit Samba installation,
> you maybe
> > > > >> don't have to do much more. The TDBs on the new host will be
> recreated.
> > > > >> If your old Samba server wasn't acting as a printserver with
> > > > >> preconfigured drivers, this shouldn't be a big problem.
> Because in that
> > > > >> case the settings are stored in the registry.tdb.
> > > > >
> > > > > So, what you suggest, is... dump LDAP database, import it on
> the new
> > > server,
> > > > > and just switch cases?
> > > > > That won't work, I'm afraid. The server constantly in use,
> including
> > > remote
> > > > > clients. I want the downtime to be as low as possible.
> > > >
> > > > You could do a two step switch:
> > > >
> > > > 1) Install Samba on the new 64-Bit server, copy your configs and
> change
> > > > them to use the LDAP on your old host. Stop Samba on the old
> host and
> > > > start on the new one. Samba hostname (netbios name) must be the
> same.
> > > > The real hostname and IP can differ. This should be a minimal
> downtime
> > > > (but of course has to be tested before).
> > > >
> > > >
> > > > 2) Prepare an LDAP server on the new host. Export on the old,
> import on
> > > > the new. Adapt the LDAP server IP in smb.conf. This should also
> be a
> > > > short downtime.
> > > >
> > > >
> > >
> > > Or you could create a new Samba AD DC domain, exploit the trust
> > > capabilities, copy the user accounts SID to the corresponding
> accounts
> > > SID-history in the new domain. Create appropriate access groups
> and apply
> > > them on the resources.
> > >
> > > When all is tested and set you migrate the computers.
> >
> > With the only downside being that none of the above will work.
> >
> > (sidHistory isn't supported in Samba, trusts are not supported, and
> > machines would have to be re-joined anyway).
> >
> 
> SIDHistory in S3 not supported?
> 
> Not even one-way trust anymore in S4?

The AD DC has no code to read or use the sIDHistory attribute (patches
welcome).  Any trust support in the AD DC is essentially accidental at
this point, not tested and certainly not something I would recommend as
a migration option.

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