[Samba] Replace SBS2003 with Samba4
Mark Foley
mfoley at ohprs.org
Thu Aug 11 23:38:27 UTC 2016
Anastasios,
I've done exactly what you want to do, only starting from SBS2008. Our office went down this
road in 2014 when we investigated upgrading from SBS2008 only to find that MS replacement,
Server Essentials, did not support Exchange. We currently have a "no cloud" policy, so going
to Office 365, as you have done, was not an option (and btw, have you not considered Server
Essentials since you don't need Exchange?).
We've been running Samba4 AD/DC as a SBS2008 replacement (DNS server, redirected folders, mail
server, ...) for nearly 2 years with no problems whatsoever, and without the domain users
noticing a sinle hiccup.
I'll share the basics of what we did. My internal documentation is 49 pages long, so this
message will, of necessity, be abbreviated.
After trying other distros I settled on Slackware64 14.1 where everything pretty much worked
out of the box. Your favorite distro should also work, but I'll stick with describing what I
have hands-on knowledge about and you'll have to figure out the differences.
What I cannot help you with is setting up a secondary DC (I've not done that, though it is
clear from this list that others have), nor anything to do with DirSync - no experience with
that at all. But first things first!
I used the Samba wiki as my "bible" to get started: https://wiki.samba.org/index.php/User_Documentation,
plus many other helpful sites.
I started by creating an isolated test network with my future Samba4 AC/DC and 2 eventual
domain member test workstations; one Windows 7, one XP (remember, this was 2 years ago. We
still had XP workstations).
I first configured the "server" for plain, vanilla DNS and DHCP serving. Samba4 AD/DC can do
DNS and is apparently recommended, but I did not do that to start -- baby steps. Here are my
non-DC named.conf and zone files. Sorry, they are a bit lengthly, but are very "standard". If
you're familiar with named these might be helpful. If not, you'll need to do some reasearch (or
send me questions directly) as we'll not have space for a DNS tutorial.
=============SNIP====================
# /etc/named.conf: options {
directory "/var/named";
forwarders { // These are the ISP provided name servers 66.193.88.3;
66.192.88.4;
};
allow-query { // Permit querying by others in the domain 192.168.0.0/24;
127.0.0.1;
};
};
zone "localhost" IN {
type master;
file "db.local"; };
zone "127.in-addr.arpa" IN {
type master;
file "db.127"; };
zone "hprs.local" in {
type master;
allow-update { 192.168.0.2; 127.0.0.1; }; // local DHCP server
file "/etc/bind/db.hprs.local";
};
zone "0.168.192.in-addr.arpa" in {
type master;
allow-update { 192.168.0.2; 127.0.0.1; }; // local DHCP server
file "/etc/bind/db.192.168.0";
};
=============SNIP====================
# /var/named/db.local
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA localhost. root.localhost. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
@ IN A 127.0.0.1
@ IN AAAA ::1
=============SNIP====================
# /var/named/db.127
;
; BIND reverse data file for local loopback interface
;
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
1.0.0 IN PTR localhost.
=============SNIP====================
# /var/named/db.hprs.local:
$ORIGIN .
$TTL 4H
hprs.local IN SOA mail.hprs.local. sysadmin.mail.ohprs.org. (
100 ; serial
3H ; refresh (3 hours)
1H ; retry (1 hour)
8H ; expire (1 week)
1H ; minimum (1 hour)
)
NS mail.hprs.local.
$ORIGIN hprs.local.
$TTL 4H
mail A 192.168.0.2
richo A 192.168.0.20
=============SNIP====================
# /etc/bind/db.192.168.0:
$ORIGIN .
$TTL 4H
0.168.192.in-addr.arpa IN SOA mail.hprs.local. sysadmin.mail.ohprs.org. (
100 ; serial
3H ; refresh (3 hours)
1H ; retry (1 hour)
8H ; expire (1 week)
1H ; minimum (1 hour)
)
NS mail.hprs.local.
$ORIGIN 0.168.192.in-addr.arpa.
$TTL 4H
2 PTR mail.hprs.local.
20 PTR richo.hprs.local.
=============SNIP====================
Another reason I've included these is that very few tweaks to these files are needed to get
them working with Samba4.
The DC requires ACL to be enabled. So, make sure you've formatted your drive with ext4, and add
acl to your mount options in /etc/fstab. E.g.:
dev/md0 / ext4 defaults,acl 1 1
Now you're ready to provision the domain. I ran:
/usr/local/samba/bin/samba-tool domain provision --use-rfc2307 \
--server-role='dc' --realm=hprs.local --domain=HPRS \
--adminpass='password' --dns-backend=BIND9_FLATFILE \
--option="interfaces=lo eth1" --option="bind interfaces only=yes"
Of course, use your own realm and domain names. I picked hprs.local because that was exactly
how our SBS2008 had the name and I was afraid to mess with that. It turns out having .local in
your FDQN is not recommended and will cause future problems with the nsswitch.conf line:
hosts: files mdns4_minimal [NOTFOUND=return] dns
which will have to be replaced with:
hosts: files dns
I had to do this on a Ubuntu domain member workstation. See
http://www.linuxquestions.org/questions/linux-networking-3/ping-does-not-resolve-name-while-nslookup-does-251446/
for a discussion. If you can make the realm something other than xyz.local, do so.
I used --dns-backend=BIND9_FLATFILE, which will use named and the DNS config files I created.
I did this for a couple of reasons. For one thing, I wasn't able to get the Samba Internal DNS
or BIND_DLZ working -- probably lack of experience on my part. Secondly, I'm doing some
special things with DNS and DHCP peculiar to our office and felt I had better control that way.
See https://wiki.samba.org/index.php/DNS for more information on this. Using my existing
(proven working!) bind9 settings was dead simple.
My AD/DC has 2 network cards: one Internet facing (email) and one LAN facing. I had to specify
--option="interfaces=lo eth1" to get it to pick the correct (LAN facing) interface.
The provision command will output a lot of information. One line is:
A Kerberos configuration suitable for Samba 4 has been generated at
/etc/samba/private/krb5.conf
You should copy or symlink that to /etc/krb5.conf. You'll likely need this later if you have
programs (mail MDA?) that want to do any local kerberos authentication.
This may now have made it into the wiki docs, but change your /etc/nsswitch.conf to have the
following:
passwd: compat winbind
shadow: compat winbind
group: compat winbind
Adding the winbind method to these will permit local programs like sendmail to authenticate
with AD authentication.
Maybe things have changed now, but the default provisioning does not create suitable Group ID
or starting User ID numbers. Correct initial values need to be set before adding domain users.
To do this edit the sam.ldb database file:
$ ldbedit -H /etc/samba/private/sam.ldb
Search for "dn: cn=hprs,cn=ypservers".
scroll down to "msSFU30Domains:". Add the following lines under this (If they do not already
exists):
msSFU30MaxGidNumber: 10001
msSFU30MaxUidNumber: 10001
Close/Save.
The "msSFU30MaxGidNumber: 10001" will be the starting User ID for domain users. The
"msSFU30MaxUidNumber: 10001" will be the Group ID for all domain users. It is important that
these values be set before adding new users to the domain!
See: https://wiki.samba.org/index.php/Setup_a_Samba_AD_Member_Server
Now, to get DNS working with Samba4 ...
In the named.conf file I listed above, remove the line "directory /var/named".
remove the local zone file definitions for e.g. hprs.local and 0.168.192.in-addr.arpa, keep the
localhost and 127.in-addr.arpa zone file definitions.
At the bottom of the named.conf, add the line:
include "/etc/samba/private/named.conf";
The provisioning step will have created this file. In /etc/samba/private/named.conf, make the
following changes:
==================ADD/CHANGE=================
zone "hprs.local." IN {
type master;
allow-update { 192.168.0.0.24; 127.0.0.1; };
file "/etc/samba/private/dns/hprs.local.zone";
# comment out the following line:
# include "/etc/samba/private/named.conf.update";
/* we need to use check-names ignore so _msdcs A records can be created */
check-names ignore;
};
==================SNIP=================
The allow-updates line will permit the local DHCP server to update. Of course you are welcome
to experiment with other methods such as using a gss key.
The domain Windows workstations will want to update the zone files. If they cannot, you will
continuously get the syslog message:
syslog:Jul 30 20:35:20 mail named[792]: client 192.168.0.101#58026: update 'hprs.local/IN' denied
This can be fixed by permitting these updates; hence the addition of 192.168.0.0/24 to the
allow-updates directive which will allow any workstation on the subnet to update.
I've also configured the "optional" reverse zone file:
==================ADD=================
zone "0.168.192.in-addr.arpa" in {
type master;
allow-update { 192.168.0.0/24; 127.0.0.1; }; // local DHCP server
file "/etc/samba/private/dns/db.192.168.0";
};
==================SNIP=================
The samba-tool provisioning step will also create a /etc/samba/private/dns/hprs.local.zone
file.
I'll not go into detail about the dhcpd.conf file, but the following were lines I needed to
add:
ddns-updates on;
update-static-leases on;
allow unknown-clients;
ddns-update-style interim;
zone hprs.local. { primary 192.168.0.2; }
zone 0.168.192.in-addr.arpa. { primary 192.168.0.2; }
subnet 192.168.0.0 netmask 255.255.255.0 {
option routers 192.168.0.2;
range 192.168.0.100 192.168.0.254;
option domain-name-servers 192.168.0.2;
66.193.88.3; option domain-name "hprs.local";
ddns-domainname = "hprs.local.";
ddns-rev-domainname = "in-addr.arpa.";
}
btw - the local IP of my AD/DC is 192.168.0.2, probably should have mentioned that earlier.
Now you're ready to fire up the AD/DC. You'll need an init script for your distro. I can send
you the one I have for Slackware if you need a starting template. Basically, you just run the
command `samba`.
Reboot.
Run `smbclient`, to check if Samba provides the AD DC default shares 'netlogon' and 'sysvol'
created in your 'smb.conf' during provisioning/upgrading:
$ smbclient -L localhost -U%
Domain=[HPRS] OS=[Unix] Server=[Samba 4.1.11]
Sharename Type Comment
--------- ---- -------
netlogon Disk
sysvol Disk
IPC$ IPC IPC Service
Domain=[HPRS] OS=[Unix] Server=[Samba 4.1.11]
Server Comment
--------- -------
Workgroup Master
--------- -------
To test that authentication is working, you should try to connect to the netlogon share,
using the Domain Administrator account, created during provisioning:
$ smbclient //localhost/netlogon -UAdministrator -c 'ls'
Enter Administrator's password:
Domain=[HPRS] OS=[Unix] Server=[Samba 4.1.11]
. D 0 Fri Jun 27 13:43:19 2014
.. D 0 Fri Jun 27 14:01:34 2014
36003 blocks of size 2097152. 32095 blocks available
There are various additional test to perform, see: https://wiki.samba.org/index.php/Samba_AD_DC_HOWTO
Set Administrator Password to not Expire:
$ samba-tool user setexpiry administrator --noexpiry
Expiry for user 'administrator' disabled.
Assuming your AD/DC is now working, you'll now you'll have to set things up for domain users.
While samba-tool works ... ish, it's easier to use RSAT.
https://wiki.samba.org/index.php/Installing_RSAT.
Do you do Remote Desktop? Following these instructions EXACTLY:
http://www.dannyeckes.com/server-2012-enable-remote-desktop-rdp-group-policy-gpo/
I use Remote Desktop to access workstations externally. Most people feel VPN is a better
choice. If you want to use Remote Desktop let me know and I'll give you info on what I did to
duplicate the functionality of Remote Web Workplace. If you have Mac workstations, Apple has a
"Microsoft Remote Desktop" at the Apple App Store. I have 2 users accessing their Windows 7
desktop from their home Mac computer with that.
Set up redirected folder:
http://www.alexwyn.com/computer-tips/folder-redirection-samba4-active-directory-domain-controller
If your users use MS Office you'll have to set up an MS Office 'Protected View' and 'Trust
Center' GPO. Let me know if you need instructions on that.
Note that on your backup, you'll want to save ACLs. I can show you what I did if want to do the same.
Now, add computers and workstations. For your "real" domain, you'll first want to remove each
workstation from your existing domain. Of course, you'll need the workstation's machine admin
ID and password to be able to log in once you're off the domain.
Physically connect your new Samba4 AD/DC to the real office LAN and boot. One by one, join each
workstation to the domain.
IMPORTANT! time synchronization needs to be maintained between the AD/DC and worksations. Of
course, make sure ntpd is running on the AD/DC. However, Windows does not play nicely with ntpd,
see: https://www.meinbergglobal.com/english/info/ntp-w32time.htm
To fix this, log into the workstation as the domain administrator, get to a command prompt, and
enter the following commands:
> w32tm /config /manualpeerlist:mail,0x8 /syncfromflags:MANUAL
> w32tm /config /update
Add Domain Users
In RSAT, Active Directory Users and Computers, Add new user. Enter whatever you want for name,
password, etc., but some particulars:
If you want to permit Remote Desktop, add the user to that group you created (above) in 'Member
Of'.
Note! Do not add users to the "Administrators" Group! This will cause any files the user
creates in MAIL:/redirectedFolders (Desktop) to be created with the Administrator's UID of
3000000, not with their own UID. This will then cause problems when opening documents such as
"Opening in Protected View" or "This file came from the Internet ...".
On the Unix Attributes tab, confirm that the user will be added with the next domain UID
starting at 10001, and the group name is "Domain Users". The NIS domain should be the domain
you configured during provisioning. Set the user's shell to e.g. /bin/bash, and the user's
home directory to "/home/yourdomain/username", which should be defaulted and you shouldn't have
to fill it in.
You may have to update the group policies (gpupdate) to get this to take sooner rather than
later.
On the DC, check the user's info:
$ wbinfo -i username
HPRS\username:*:10001:10000:A Domain User:/home/HPRS/username:/bin/bash
Probably, adding this user will cause a new folder to be created on the workstation in C:\Users
when they log in the first time, e.g. C:\Users\joe.0000 (versus just 'joe'). That means the
user's desktop will be empty. What I did was copy the user's Desktop, Documents, Favorites,
Photos, Music, etc. while still connected to the old SBS2008. I even snagged their Outlook
autocomplete file. Then, I copied the files to the users' redirected folders on the Samba4
server -- make sure to set the ownership correctly. That worked for me. Do one user at a time,
to verify.
That should do it! There are certaily details you'll either need to figure or post another
message. All this worked for me pretty much without any real problem. And, as I've said, we've
been running for 2 years trouble-free (and SBS free!).
Good luck --Mark
-----Original Message-----
> From: Anastasios Papadopoulos <tpapad at gmail.com>
> Date: Fri, 29 Jul 2016 18:20:14 +0300
> To: samba at lists.samba.org
> Subject: [Samba] Replace SBS2003 with Samba4
>
> Hello all,
>
> I'm currently investigating the option to completely replace a SBS2003 DC
> with a Samba4 DC. My research (mostly on samba.org guides) shows that it is
> feasible, however I'd like to get feedback from the community on my goals.
>
> Current status:
> A Windows SBS 2003 is the PDC and a W2008 R2 server is acting as secondary
> DC. Domain operational level is 2003.
> There are ~40-50 users/workstations using the SBS as file server.
> Until recently, SBS was also the mail server (built-in Exchange 2003) but a
> couple of months ago we migrated to Office 365. The migration included the
> setup of DirSync so our AD syncs with O365 for users/groups/password etc.
> Exchange is still running but w/o any mailbox or clients using it.
>
> My goals (please fill free to correct the order or comment on the
> feasibility of each step):
>
> - Setup a new Samba4 DC
> - Join the Samba4 to the domain
> - Assume all roles from SBS2003 (FSMO)
> - Configure DirSync so that it still syncs AD changes to Office 365
> - Migrate all files from SBS to Samba4 (either to Samba PDC or a new
> Samba4 member server)
> - Demote the SBS2003 server (and eventually recycle it...)
> - Demote the W2008 R2 server (so it only serves as member server, i.e.
> SQL Server). A second Samba4 DC can be installed to achieve redundancy
> - (Optional) Continue using current ADUC console for user management etc
>
> I guess the really tricky part would be to maintain DirSync functionality
> while replacing the DCs.
>
> I'd like to hear your thoughts: Are those goals doable? What should I watch
> for or avoid?
>
> Thank you very much,
>
> --
> Tasos
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba
>
More information about the samba
mailing list