On Sun, 8 Apr 2018 09:05:46 +0000 Praveen Ghimire <PGhimire at sundata.com.au> wrote:> Hi Rowland, > > I have gone through that link a few times and have done both the TDB > to AD and also LDAP to AD migration a few times. > > The AD migration is the second stage. > > Let me explain the situation. The Production server is a Samba 3 box > which acts as the DC (TDB) and file share. We decided to to add a > Samba 4 box to that classic domain and make it a PDC. Having gone > through various documents , which suggested to not use TDB for a PDC > BDC setup, we are looking at using LDAP. The plan is to make the old > PDC a member server as it still has all the files.I repeat, you do not need to move to LDAP before the upgrade to AD. All you are doing is adding an LDAP PDC to the domain and after you upgrade to AD, you will have an AD DC using the same workgroup name and SID as the NT4-style PDC and you will then have turn the PDC off (Note: I am referring to the NT4-style PDC, not the AD DC. An AD DC should NEVER be referred to as a PDC.), you cannot have an NT4-style PDC and an AD DC with the same SID in the same domain.> > The adding new box and making it a PDC using LDAP works. > Authentication of the users who were in TDB works too. The issue is > any newly created users in LDAP. Hence the question.If you are upgrading to AD, you do not need to bother about any other Unix machines, just alter the smb.conf (for info, see here: https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member ) to be an AD Unix domain member and join them to the new AD domain, it will work. Rowland
Hi Rowland, If we need to shut the NT4 PDC down after the migration it makes a lot of sense to separate the roles of the existing NT4 PDC. Hence why we are adding a new Samba box with a view that it becomes the PDC and the existing PDC become a member server. The main reasons is that it has a lot of files which cannot be moved easily. So the question is with the new PDC we stick with TDB? Separate the roles, migrate to AD and shut the PDC down. Then join the member server to AD. Sorry about the confusion. Regards, Praveen Ghimire -------- Original message -------- From: Rowland Penny <rpenny at samba.org> Date: 8/04/2018 8:19 PM (GMT+10:00) To: Praveen Ghimire <PGhimire at sundata.com.au> Cc: samba at lists.samba.org Subject: Re: [Samba] FW: LDAP getent issues On Sun, 8 Apr 2018 09:05:46 +0000 Praveen Ghimire <PGhimire at sundata.com.au> wrote:> Hi Rowland, > > I have gone through that link a few times and have done both the TDB > to AD and also LDAP to AD migration a few times. > > The AD migration is the second stage. > > Let me explain the situation. The Production server is a Samba 3 box > which acts as the DC (TDB) and file share. We decided to to add a > Samba 4 box to that classic domain and make it a PDC. Having gone > through various documents , which suggested to not use TDB for a PDC > BDC setup, we are looking at using LDAP. The plan is to make the old > PDC a member server as it still has all the files.I repeat, you do not need to move to LDAP before the upgrade to AD. All you are doing is adding an LDAP PDC to the domain and after you upgrade to AD, you will have an AD DC using the same workgroup name and SID as the NT4-style PDC and you will then have turn the PDC off (Note: I am referring to the NT4-style PDC, not the AD DC. An AD DC should NEVER be referred to as a PDC.), you cannot have an NT4-style PDC and an AD DC with the same SID in the same domain.> > The adding new box and making it a PDC using LDAP works. > Authentication of the users who were in TDB works too. The issue is > any newly created users in LDAP. Hence the question.If you are upgrading to AD, you do not need to bother about any other Unix machines, just alter the smb.conf (for info, see here: https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member ) to be an AD Unix domain member and join them to the new AD domain, it will work. Rowland ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________
On Sun, 8 Apr 2018 10:39:41 +0000 Praveen Ghimire <PGhimire at sundata.com.au> wrote:> Hi Rowland, > > If we need to shut the NT4 PDC down after the migration it makes a > lot of sense to separate the roles of the existing NT4 PDC. Hence why > we are adding a new Samba box with a view that it becomes the PDC and > the existing PDC become a member server. The main reasons is that it > has a lot of files which cannot be moved easily.There you go, I said don't refer to an AD DC as a PDC and the first thing you do, call an AD DC a PDC. A PDC and an AD DC are TOTALLY different things, what you have at the moment is a PDC, what you will end up with, after the classicupgrade, is an AD DC. If you then add another DC to the AD domain, you will not have a PDC and a BDC, you will have TWO DCs. All DCs are equal EXCEPT for the FSMO roles (there are 7 of these) and these can be shared out amongst your DCs. You could have seven DCs, each holding a FSMO role and whilst one of the roles is the 'PDC emulator role', NONE of the DCs would be a PDC, they would all just be DCs.> > So the question is with the new PDC we stick with TDB? Separate the > roles, migrate to AD and shut the PDC down. Then join the member > server to AD. >Not a problem. I take it your users and groups have uidNumbers & gidNumbers, so set up the old PDC as a Unix domain member using the winbind 'ad' backend. Rowland