[Samba] Questions regarding upgrading existing PDC to Active Directory

[Bruce Vrieling]

Hi all,


I have an existing CentOS server at my school running Samba 4.8.8 as a PDC and using the Tranquil RPM’s (so they support AD). Samba has worked great for me for more than a decade with the users stored now in tdbsam (have not used LDAP, hope not to). This summer I want up upgrade the domain to an AD, and have some questions I was hoping someone could answer:

  1.  TWO SERVERS: At the moment I have a single server (called Bigfoot) which acts as the PDC, file server, print server, pretty much everything. Given that in an AD world a DC should not also be a fileserver (we use Unix ACL’s exclusively, not Windows ACL’s), I plan to create a new server to be the DC (called Heimdall) and then Bigfoot will just be a domain member “file and email server” (I assume many single-server PDC setups take a route something like this when upgrading to AD). In order to kick this off, I plan to a) transplant my existing Samba PDC setup on Bigfoot to Heimdall, b) classicupgrade it to AD to be the new DC; and then c) create a new, virgin Samba config on Bigfoot before joining Bigfoot to the AD domain as a member server. There are a lot of specifics I am missing, but does this approach generally sound right?
  2.  NSSWITCH.CONF: Our users will continue to need to scp and ssh into Bigfoot. In order to allow AD domain users to authenticate to Bigfoot as unix users, do I just have to play with /etc/nsswitch.conf (assuming a valid winbind configuration)? Some sources say I also have to play with files in /etc/pam.d. Do I?
  3.  EXISTING UNIX INFORMATION: I understand that the DC on Heimdall will now contain all my Windows authentication information, and that if add RFC2307 extensions to the directory, will also be able to store unix UID and GID information. Question: I have 500 existing users. Should I be stuffing their existing UID and GID information into the AD before I let them log into Bigfoot? Or when someone ssh’s into Bigfoot, and winbind sees that user already exists locally, would it stuff this information itself automatically if it doesn’t exist yet?
  4.  VALID UID’s: My existing unix uid’s on bigfoot start at 500 (that is how CentOS started numbering them many years ago). Is that a problem? I thought I saw somewhere that starting at 1000 is the new normal.
  5.  NEW USERS AND /ETC/PASSWD: Suppose I create a totally new user in the AD. Then they connect/authenticate to bigfoot for the first time. Do they get entries in /etc/passwd and others? If I am understanding the purpose of a directory properly, I am thinking *not*. So, when do their uid and gid get stuffed into the AD? Will this happen automagically or do I have to do this manually?
  6.  EXTENT OF NSSWITCH.CONF: Suppose I create a totally new Windows user in AD on my DC, they have not yet logged into Bigfoot, and an email arrives at Bigfoot addressed to them. Does the nsswitch.conf magic also ensure that sendmail/procmail/dovecot will realize that this email is for a real user and accept it?


I do plan to model this all in VM’s before I actually do this in production, but I am trying to understand the process as much as possible before I begin.


If it helps, this is my current smb.conf. Pardon any cruft, this has grown over the years.


[global]

notify:inotify = false

private dir = /etc/samba

passdb backend = tdbsam

interfaces = ens1

bind interfaces only = yes

unix extensions = no

follow symlinks = yes

wide links = yes

delete veto files= yes

workgroup = TDCH

server string = File and Print Server

security = user

load printers = yes

log file = /var/log/samba/%m.log

max log size = 50

local master = no

os level = 33

domain master = yes

preferred master = yes

domain logons = yes

logon script = %U.bat

logon path =

wins support = yes

wins proxy = yes

name resolve order = wins host

dns proxy = yes

add machine script = /usr/sbin/adduser -n -g machines -c Machine -d /dev/null -s /bin/false %u


[homes]

   comment = Home Directories

   path = /home/%S/files

   browseable = no

   writable = yes


[netlogon]

   comment = Network Logon Service

   path = /home/netlogon

   guest ok = yes

   browseable = yes

   writable = no

etc


Thanks a lot for any insight you might be able to provide.


…Bruce