Are all the users connecting from Windows only or do you have Linux
clients ? If all the clients are Windows only that should make
things a lot simpler.
Last year I went through a similar migration. I had the old domain
(lets call it "CLASSIC") using Samba 4.x domain controllers in
"classic/NT4" mode. I had a new AD domain with Win 2012 R2 server
DC-
lets call this domain "NEWAD." This had to support both windows and
linux clients. I had already created all the users as well as key
groups in the new domain. I needed an AD domain to support MS
Exchange and domain trusts between AD and Samba just did not work reliable.
In my case, I moved my samba file servers (and windows servers, and
linux clients, and windows clients) from the classic domain to the new
domain, rather than setup new servers. However I did setup test
samba systems in the new domain to work out the config and resolve bugs
in advance. You may need to give yourself a few weeks for testing.
If you only have windows clients then you could probably bypass the SSSD
config by updating /etc/nsswitch.conf with
passwd: files winbind
group: files winbind
My samba servers are solaris so sssd is not used.
You may want to use the rsync command for copying files from server to
another. This shd preserve permissions and also allows you to do
incremental updates. Incremental updates are great if the initial copy
does not complete, or if you need to do some of the copying during the
week and then have a very short downtime to switch which is the
"official" machine for that data. I had installed l unix services
on
the AD controller in the new domain, which let me set the userID and
groupID numbers to match those in the old domain. That hugely reduce
the number of file permissions I had to fix afterwards. You also need
to make sure that you set a GroupID number for the "Domain Users"
group
and that that is everyones default group. If you are using idmap_ad
for idmapping this may not be the case. I was not.
I have linux clients in my environment. That adds additional complexity
because you have to make sure that both servers and clients are
configured to use NFS with kerberos. And you have to make sure the
file permissions are kept consistent between users.
I believe SMB1 vs SMB2 is independent of the domain architecture, unless
your old server is running a really old version of Samba. I would
set min and max server protocol versions for SMB2.
On 08/01/18 08:39, Edouard Guigné via samba wrote:> Hello everyone,
>
> I plan to change an old samba share (SMB1) configured on an Samba PDC
> "old NT4 Style" server.
> For that plan, I choose to migrate domain from the old NT4 domain to
> on Microsoft Active Directory (Windows 2012 R2) set with posix
> attributes rfc2307, and then change the old Samba share with a new
> linux box (centos 7) with winbind, sssd configured against Microsoft AD.
> At this occasion, I hope to upgrade from SMB1 to SMB2 or above.
>
> I imagine to do the following :
> 1. Change domain for all workstation from old NT4 to new Microsoft AD
> (but keep user access to old SMB1 Samba share via windows server login
> scripts).
> 2. Configured a new linux box against AD (centos 7, I am used with
> this linux).
> 3. Copy all datas from old share to new share (common share + homedir).
> 4. Copy / Synchronize acls from old share with getfacl, and set acls
> on new share with setfacl.
> 5. Change windows server login scripts to enable new samba share on
> user session instead of old SMB1 share.
>
> I appreciate any advices for theses steps of migration, because I
> never did it before.
> Is there tools or methods to copy/synchronize datas between old SMB1
> share to new share ? And get/set acls on files ?
>
> Best Regards,
> Ed
>
>