[Samba] Questions regarding upgrading existing PDC to Active Directory
- Date: Wed, 2 Jan 2019 19:44:56 +0000
- From: Bruce Vrieling via samba <samba@xxxxxxxxxxxxxxx>
- Subject: [Samba] Questions regarding upgrading existing PDC to Active Directory
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.
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
comment = Home Directories
path = /home/%S/files
browseable = no
writable = yes
comment = Network Logon Service
path = /home/netlogon
guest ok = yes
browseable = yes
writable = no
Thanks a lot for any insight you might be able to provide.
To unsubscribe from this list go to the following URL and read the