Hi Guys, I have three Samba file servers running different versions of CentOS and Samba. They are all joined to a proper Windows 2003 domain. I'd like to migrate the WIndows domain to 2016 and all the Linux servers to CentOS 7. I can do Windows 2003->2012->2016 without too much trouble. I'm concerned about the Samba side. The servers are all using extended file system permissions and extensive windows groups/permissions. Would the "idmap" range change? Is there any way to mitigate this risk? I realize I can follow the steps here: https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member to create the new servers and rsync the files/acls but how do I ensure the permissions don't get lost and continue to work? getfacl/setfacl? Something else? Any suggestions would be appreciated.
Hi Scott, Am 12.02.2018 um 06:46 schrieb Scott Whitten via samba:> I can do Windows 2003->2012->2016 without too much trouble.Can't you join 2016 to the 2003 domain, demote 2003, and raise the functional levels? Or join a Samba AD DC and continue without MS. ;-)> I'm concerned about the Samba side. The servers are all using extended > file system permissions and extensive windows groups/permissions. Would > the "idmap" range change?No need to worry here: * idmap_ad (RFC2307): IDs are stored within AD. Windows doesn't change the values of these attributes. * idmap_autorid: IDs are generated based on the RIDs in Windows object's SID. If Windows would change them, all permissions on Windows would be lost, too. * idmap_rid: Same as for autorid, the IDs are generated based on the RID of AD objects. However, they will only be the same, if you set exactly the same range for the domain in the new server's smb.conf as you have on the old one.> I realize I can follow the steps here: > https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member > to create the new servers and rsync the files/acls but how do I ensure the > permissions don't get lost and continue to work? getfacl/setfacl? > Something else?IDs of domain users and groups: No real reason to worry here. See above. Local Samba users on your domain member: Copy the passdb.tdb file stored in PRIVATE_DIR (# smbd -b | grep PRIVATE_DIR) to the new host. Files: Use a tool that preserves the permissions when you copy the files. For POSIX ACLs, this should be supported by all tools. For fine-granular Windows ACLs, you need to make sure that you preserve the extended attributes as well. For example, if you use rsync, pass the --xattrs parameter to the command. The Samba domain member server part is something you can easily test, for example, in a VM: - Setup CentOS 7 - Install Samba - Copy smb.conf from an existing server - Set a different host name in smb.conf - Update the ID mapping configuration in smb.conf, if it still uses the old format. I think the new format is mandatory since 3.6 (or was it 4.0?) - Join the machine to the domain - Verify IDs (getent passwd / getent group) - Copy some file - Check if the permissions are correct. Regards, Marc
Thanks Marc, I'll give things a try your way tomorrow and see where we end up. FYI you cannot go directly from 2003->2016. I tried this and Windows Server 2016 just laughed at me. You can't even join it to the domain. :) 2003->2012->2016 is the way, Scott On Mon, Feb 12, 2018 at 10:31 AM, Marc Muehlfeld <mmuehlfeld at samba.org> wrote:> Hi Scott, > > Am 12.02.2018 um 06:46 schrieb Scott Whitten via samba: > > I can do Windows 2003->2012->2016 without too much trouble. > > Can't you join 2016 to the 2003 domain, demote 2003, and raise the > functional levels? > > Or join a Samba AD DC and continue without MS. ;-) > > > > > I'm concerned about the Samba side. The servers are all using extended > > file system permissions and extensive windows groups/permissions. Would > > the "idmap" range change? > > No need to worry here: > > * idmap_ad (RFC2307): IDs are stored within AD. Windows doesn't change > the values of these attributes. > > * idmap_autorid: IDs are generated based on the RIDs in Windows object's > SID. If Windows would change them, all permissions on Windows would be > lost, too. > > * idmap_rid: Same as for autorid, the IDs are generated based on the RID > of AD objects. However, they will only be the same, if you set exactly > the same range for the domain in the new server's smb.conf as you have > on the old one. > > > > > I realize I can follow the steps here: > > https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member > > to create the new servers and rsync the files/acls but how do I ensure > the > > permissions don't get lost and continue to work? getfacl/setfacl? > > Something else? > > IDs of domain users and groups: No real reason to worry here. See above. > > Local Samba users on your domain member: Copy the passdb.tdb file stored > in PRIVATE_DIR (# smbd -b | grep PRIVATE_DIR) to the new host. > > Files: Use a tool that preserves the permissions when you copy the > files. For POSIX ACLs, this should be supported by all tools. For > fine-granular Windows ACLs, you need to make sure that you preserve the > extended attributes as well. For example, if you use rsync, pass the > --xattrs parameter to the command. > > > > The Samba domain member server part is something you can easily test, > for example, in a VM: > - Setup CentOS 7 > - Install Samba > - Copy smb.conf from an existing server > - Set a different host name in smb.conf > - Update the ID mapping configuration in smb.conf, if it still uses the > old format. I think the new format is mandatory since 3.6 (or was it 4.0?) > - Join the machine to the domain > - Verify IDs (getent passwd / getent group) > - Copy some file > - Check if the permissions are correct. > > > Regards, > Marc >