Hi all,
I want to migrate an existing AD (not in NS7, but a samba server on Debian) into NS8. Does anyone here know how this can be accomplished?
Goal is to have NS8 as the new domain controller and switch off the old one, without having to change anything on the clients.
Thank you!
Tbh, this is going to be extremely hard, unless NS8 comes to havr a VPN module.
Especially if they arr not within the same local host.
Overall I think @Andy_Wismer would be better placed to advice you, but you’ve not really given any details of your setup, so it’s hard to tell.
there’s really no migration like that. Samba has it’s own LDAP server built in. so each install creates it’s own certificate chain. so you’ll need to un-join and re-join the windows clients at least, and accept the new certs on the non-windows machines.
As to a VPN module, I don’t know where that comes into play, so I’ll just leave that be.
I wouldn’t even bother with trying to make it transparent. Just tell them “This is a new version”, changes incoming. We are here to upgrade the network to the latest release, secure it, etc. Changes incoming…
this is actually a great way to inform a new implementation
Hi All
@jaywalker:
I’ll assume a typical local SME setup here.
This is true in the fact that there is no supported migration.
However, it is possible to do such a migration and it would work…
An AD running on NS7 can be migrated (supported!), and clients do not need to be modified, if IP, DNS and AD names are conform (especially for network drives).
For starters, the Samba AD used in NethServer 7 is fully MS Windows AD 2012 compatible.
This would allow joining eg a Windows Server as another AD controller.
This could also be another Samba server. And one could be promoted, the other demoted / removed…
Typical MS method.
A second method: Linux / Samba doesn’t use a Registry like MS, the info is all in text files somewhere.
The key part of AD is the SID, this CAN be copied!
If IP, Hostname, FQDN, AD-FQDN and SID correspond, you will have a successful migration.
A few words of caution:
Before doing anything, a working backup is a must!
None of the above should be used / attempted on a live Samba AD.
Using a Hypervisor like Proxmox can make the whole effort easier and faster.
Check and double check all used FQDNs, IPs, SIDs and folder permissions!
A rule of thumb from my side:
Above twenty users, I would migrate and save work with clients.
Less than 10, I would attempt a clean new installation.
Those in between would depend on the exact situation…
My 2 cents
Andy
The VPN module mentionned by @oneitonitram comes from the fact that his NS7 AD is in a hosted environment, and NS8 (At a different hoster) can’t contact that NS7 to migrate…
A bad choice to have the AD in the cloud, with no real access option.
It has no consequence for any normal, local setup.
Hi Andy,
thank you, this is valuable input. The AD is currently served by a Debian server with plain samba. I know how to do “join another dc to the network, transfer fsmo, sync sysvol, and demote the old one” on pure Linux/samba systems, and have done this successfully several times in the past. The new server would be in the same local network, so I do not see a need for VPN here.
Of course, before trying such a transition I would take a snapshot of the VMs involved such that restore is possible.
Where I do not have experience is how to perform such a transition in NS8. How do I get the samba container running without creating its own domain, such that I can join the existing one? And is there anything I need to take care for such that NS8 can use the migrated domain correctly for all of its internal applications?
It would probably be easier to “migrate” your Samba first to NS7, then let the Migration Tool take care of migrating the whole AD correctly to NS8.
A tip:
Your data does NOT have to be in NS7 samba folders for migration, the folders can be left empty for starters.
Nothing stops you from rsynching the user and group data (files) directly from your present Debian to the new NS8 later on. You could even use a Windows Client and “copy” them over, to make sure permissions are intact.
As you already seem familiar with using VMs, this does make work MUCH easier. Snapshots, fast Backups / Restore and Cloning does make the task easier, and atomic step restore would be possible. I’ld possibly use 2 NS7 VMs for the task.
Depending on your Hypervisor, a NS7 install would need promisious mode for the NIC, Proxmox sets this as standard, you would need to verify this for VMWare ESXi, Hyper-V or Xen. AFAIK, ESXi needs manual intervention for this.
NS7 is easy to join to an existing AD, as “member” server. Promoting NethServer AD is not in the GUI, nor documented, but does work. Here cloning / snapshotting helps, until you get it “just right”!
I can’t help yet with such a direct migration to NS8, as I haven’t attempted it myself (yet).
But I can confirm that the NS7 to NS8 gets you a working AD on NS8, and clients aren’t the wiser!
PM me, if you need direct help.
My 2 cents
Andy
Tbh Andy that’s not the main reason why migration is impossible. I can easily deploy another ns8 host on the same node with same local ip range where the NS7 is hosted. Easy.
The problem is, there are other NS7 hosts which were connected to the previous NS7 ad host.
Once I migrate NS7 AD to NS8 AD the other NS7 hosts would still need a way to communicate to the new NS8 AD, untill I migrate them to NS8 as well. and since they are all not in the same location, server or host, it is difficult.
Does it now make sense to you @Andy_Wismer.
Equally I have been building the same modules I am using on my NS8 installs for NS8 to make the migration seamless for me. Whichever way a NS7 to NS8 VPN is necessary, untill I figure out a magic way of getting it done
That what you refered to by Jack (laidback_01):
“Just tell them “This is a new version”, changes incoming. We are here to upgrade the network to the latest release, secure it, etc. Changes incoming…”
would work easily for you, why not use that simple method - after all, these are apparently your employees…
But you started with your interjection about a VPN, and no one understood what relevance a VPN has to a NS8 migration. No one “needs” a VPN for migration in a normal case…