Hello, I had tried to demote a samba DC and re-join it as a member over the weekend, but something went horribly wrong. Starting point was a samba DC which also acted as a file server. It was the single DC in that domain. I first set up a Windows 2008 R2 machine and promoted it to DC within the same domain. I then changed DNS entries on all machines to point to the new DC, transferred the FSMO roles to the new DC. Up to that point, everything worked OK for a week. Yesterday, I demoted the samba DC as lined out in the wiki, and then joined it again to the domain as a member after adjusting smb.conf. I followed the steps for provisioning a new samba server as a domain member. Joining worked, but shortly afterwards the whole domain stopped working. Logging in from a windows workstation was possible (I assume through cached credentials), but access to shares on the samba server as well as another Windows 2008 member server in the same domain did not; DNS-Server on the Windows DC did not start because it couldn't establish a connection to AD, AD service complained it could not locate the global catalog, dcdiag showed all sorts of problems. As I was unable to resolve this using my - limited - windows server skills, I finally trashed the windows DC and restored the samba private dir and smb.conf from a backup before demotion, so it was now a DC again. I seized the FSMO roles and now everything seems to work again. I do not want to go into the details of what went wrong. My question is - I overlooked to things when re-joing the samba server as a member: 1.) I left share definitions for netlogon and sysvol in the smb.conf 2.) I left the samba private dir as is after demotion Could these be the cause of these problems? I should have probably started out with an empty private dir or even complete /var/lib/samba as in a fresh installation, I guess. Is there anything else to consider when demoting and re-joining as a member? Thanks, Andreas
Hi Andreas,> I had tried to demote a samba DC and re-join it as a member over the > weekend, but something went horribly wrong. > > Starting point was a samba DC which also acted as a file server. It was > the single DC in that domain. > > I first set up a Windows 2008 R2 machine and promoted it to DC within > the same domain. I then changed DNS entries on all machines to point to > the new DC, transferred the FSMO roles to the new DC. Up to that point, > everything worked OK for a week. Yesterday, I demoted the samba DC as > lined out in the wiki, and then joined it again to the domain as a > member after adjusting smb.conf. I followed the steps for provisioning a > new samba server as a domain member. Joining worked, but shortly > afterwards the whole domain stopped working. > > Logging in from a windows workstation was possible (I assume through > cached credentials), but access to shares on the samba server as well as > another Windows 2008 member server in the same domain did not; > DNS-Server on the Windows DC did not start because it couldn't establish > a connection to AD, AD service complained it could not locate the global > catalog, dcdiag showed all sorts of problems. As I was unable to resolve > this using my - limited - windows server skills, I finally trashed the > windows DC and restored the samba private dir and smb.conf from a backup > before demotion, so it was now a DC again. I seized the FSMO roles and > now everything seems to work again.you should check if you windows DC network card had itself as a DNS server, and the Samba DC as second DNS server. If it was pointing to your Samba DC only, the symptoms are quite normal. Second, before demoting, did you check that all the partition were properly replicated. Did you check that local DNS server on your win DC was working properly? And check that all the SRV fields are properly created (_ldap._tcp, _kerberos._tcp, etc.)?> I do not want to go into the details of what went wrong. My question is > - I overlooked to things when re-joing the samba server as a member: > 1.) I left share definitions for netlogon and sysvol in the smb.conf > 2.) I left the samba private dir as is after demotion > > Could these be the cause of these problems? I should have probably > started out with an empty private dir or even complete /var/lib/samba as > in a fresh installation, I guess. Is there anything else to consider > when demoting and re-joining as a member?Yes, when switching, it is much safer to clean up your /var/lib/samba. Be sure to recreate the /var/lib/samba/private folder after cleanup, that folder is not recreated automatically most of the time. There is nothing very complicated in what you wanted to do. Just be sure to double check the replication before demoting, be sure to demote to remove all the old DNS entries pointing to your old server, check your DNS config on servers and desktops. I do that regularly, kind of business as usual, but the other way around, from MS-AD to Samba AD... By the way Samba-AD is much more easy to maintain if you are familiar with AD and at easy with command line / scripting. Unless you have a business/corporate requirement expressly needing a MS-AD, I'd say it would be better to stick with Samba-AD. Cheers, Denis> > Thanks, > Andreas >-- Denis Cardon Tranquil IT Systems Les Espaces Jules Verne, bâtiment A 12 avenue Jules Verne 44230 Saint Sébastien sur Loire tel : +33 (0) 2.40.97.57.55 http://www.tranquil-it-systems.fr
Am 15.01.2018 um 11:35 schrieb Denis Cardon via samba:> Yes, when switching, it is much safer to clean up your /var/lib/samba. > Be sure to recreate the /var/lib/samba/private folder after cleanup, > that folder is not recreated automatically most of the time. > > There is nothing very complicated in what you wanted to do. Just be > sure to double check the replication before demoting, be sure to > demote to remove all the old DNS entries pointing to your old server, > check your DNS config on servers and desktops. > > I do that regularly, kind of business as usual, but the other way > around, from MS-AD to Samba AD... By the way Samba-AD is much more > easy to maintain if you are familiar with AD and at easy with command > line / scripting. Unless you have a business/corporate requirement > expressly needing a MS-AD, I'd say it would be better to stick with > Samba-AD.Hello, thanks for your help. For the reasons to do that: until now, I had the impression it was the other way round, MS-AD looked easier to maintain, at least as long as everything works... Part of the problem may be that I am bound to use the samba packages shipped with Debian stable, which is 4.5.12 at the moment. I already encountered several points which were already fixed in newer versions, but I would have to wait for Debian 10 to get these. But I am more familiar with Linux and the command line, so I am considering your words and staying with samba. What is absolutely required is to have domain members running Windows 10 and Server 2016, and I am unsure whether this works with this rather old version of samba. Bye, Andreas