[ale] Switching from Server 2003 to Samba

Mon Jul 14 15:42:55 EDT 2014

Has anyone run across a good Samba 4 tutorial on the web for setting up an AD domain for someone not already very familiar with the Windows Active Directory stuff? I've mostly taken care of the Linux side in the past. I have some exp. with Samba 3--I could get it to run as a file/print share but that was about it. Our Win7 boxes (both of them!) currently all have individual logins and user databases but I'd like to learn how to set up Samba 4 as an AD alternative. I'm not that familiar with all the terms and concepts, and the Samba 4 tutorials I've seen seem to assume that knowledge. 

Scott 
----- Original Message -----

From: "Michael Trausch" <mike at trausch.us> 
To: "Atlanta Linux Enthusiasts" <ale at ale.org> 
Sent: Saturday, July 12, 2014 2:55:23 PM 
Subject: Re: [ale] Switching from Server 2003 to Samba 

Testing, testing, testing. 

Before I go further: I can't speak to anything more recent than about 18 
months ago, as I haven't had to admin a setup like this for a while. 
however, it doesn't appear that much has changed. 

Since you have an existing system and you need to migrate, you *NEED* to be 
given a lab environment that allows you to deploy a mirror of the current 
AD domain, so that you can test migrating it to e.g., Samba 4. Users need 
to ensure that all of their applications work correctly, as well. Windows 
and applications that run on it make many assumptions that may or may not 
hold true under Samba 4 for a variety of reasons (not the least of which is 
the fact that it is a different implementation than Microsoft Windows). 

That said, I've had good luck. The major sticking points I ran into: 

- File permissions are an issue. Ensure that you're using POSIX ACLs, 
and ensure that your Samba configuration is suitably configured to use 
them. Note, however, that POSIX filesystem permissions and Win32 
filesystem permissions are two very different beasts, and there will be 
issues in mapping. Samba 4 does a much better job than Samba 3, but as of 
the last I used it, they're still not perfect. 
- Some AD functionality is stubbed out. Ensure that none of the 
functionality that your users depend on is missing/stubbed. 
- It's relatively easy to get it to function for UNIX systems as well, 
but it's better to use FreeIPA to create a trust with the AD server and 
re-export that way. 
- In fact, if you're doing this and not going to be running Windows 
clients after the migration (or are going to be doing this in order to 
support the addition of UNIX/Linux clients to the network) just deploy a 
FreeIPA domain. 
- Also, pay very close attention to the Samba/AD replication. In order 
to replace the AD server, you're going to have to have Samba 4 configured 
as a secondary controller, synchronize it with the domain, and then promote 
it. After promotion of Samba 4, you can demote the Windows box, and then 
retire it. 
- Multiple users attempting to work on the same document at the same 
time was quite broken in Samba 3. It seems to work halfway in Samba 4; 
instead of fully supporting concurrent access, the first time a file is 
opened, that process gets the ability to read/write it; all other processes 
are not allowed to write the file at all. 

Samba 4.1 has support for efficient hosting on top of btrfs and claims 
better AD replication support, as well as SMB3 encrypted connections. You 
should be able to implement VSS and server-side copy operations now with 
Samba 4. (This is on my todo-list to try out.) This means that it can 
function as a backup destination for the Windows machines on the network, 
too. 

Full disclosure: The last version of Samba I've had the pain of having to 
administer was 4.0.3—Samba 4.1 appears to be much better and if it works as 
advertised, should provide for you a much smoother transition than was 
previously possible. The network that I had to administer was a Samba 3 
network for a long time simply because all the systems in the network were 
happy with NT4-style domains. 

One other thing to note: deploying AD with Samba first seems to be much, 
much more difficult than installing a temporary microsoft domain controller 
and then using Samba to take over from it. This seems to have to do with 
the setup of a lot of the AD-things that Samba 4.0 had stubbed out. This 
may have changed since then. 

On Sat, Jul 12, 2014 at 11:42 AM, Michael Trausch <mike at trausch.us> wrote: 

> I can't do so right this second, but I will post a decent write up of my 
> experiences for you later today. 
> 
> Sent from my iPhone 
> 
> > On Jul 10, 2014, at 3:53 PM, Edward Holcroft <eholcroft at mkainc.com> 
> wrote: 
> > 
> > All, 
> > 
> > The time has finally come to ditch our Micro$haft file servers as another 
> > increment towards weaning ourselves of our Windows habit. For now, I have 
> > to keep Active Directory in the picture, although I have managed to 
> reduce 
> > the AD server footprint from 18 servers down to 4. Corporate mindset 
> issues 
> > demand small steps. 
> > 
> > Question: Is it better to go with an "appliance solution" such as FreeNAS 
> > vs. distro+Samba? 
> > 
> > I played around with FreeNAS a bit and while it has great automation of 
> > things like AD integration (which I will need to do for now) and a great 
> > web interface, it seems less flexible when it comes to e.g. backup 
> options. 
> > It seems a simple Ubuntu/Samba box gives me many options on how to handle 
> > our daily backups to USB, while FreeNAS can potentially close doors to 
> me, 
> > or at least make things harder. That's just one example that I ran into. 
> > 
> > So, I'd like to hear from you about experiences/pros-cons of 
> appliance-type 
> > options vs the manual way. I've tried both at a simple test level. They 
> > both seem viable and I really want to like FreeNAS, but just cannot seem 
> to 
> > get comfortable with it - little glitches seem to pop up that have the 
> > potential to be major sticking points. So right now I'm leaning towards 
> > distro+Samba. 
> > 
> > Feel free to suggest other options besides the two mentioned here. 
> Whatever 
> > solution I deploy I have to be able to use Windows ACL's on the shares 
> ... 
> > for now. 
> > 
> > cheers 
> > ed 
> > 
> > -- 
> > Edward Holcroft | Madsen Kneppers & Associates Inc. 
> > 11695 Johns Creek Parkway, Suite 250 | Johns Creek, GA 30097 
> > O (770) 446-9606 | M (770) 630-0949 
> > 
> > -- 
> > MADSEN, KNEPPERS & ASSOCIATES USA, MKA Canada Inc. 
> WARNING/CONFIDENTIALITY 
> > NOTICE: This message may be confidential and/or privileged. If you are 
> not 
> > the intended recipient, please notify the sender immediately then delete 
> it 
> > - you should not copy or use it for any purpose or disclose its content 
> to 
> > any other person. Internet communications are not secure. You should scan 
> > this message and any attachments for viruses. Any unauthorized use or 
> > interception of this e-mail is illegal. 
> > -------------- next part -------------- 
> > An HTML attachment was scrubbed... 
> > URL: < 
> http://mail.ale.org/pipermail/ale/attachments/20140710/5da89949/attachment.html 
> > 
> > _______________________________________________ 
> > Ale mailing list 
> > Ale at ale.org 
> > http://mail.ale.org/mailman/listinfo/ale 
> > See JOBS, ANNOUNCE and SCHOOLS lists at 
> > http://mail.ale.org/mailman/listinfo 
> 
-------------- next part -------------- 
An HTML attachment was scrubbed... 
URL: <http://mail.ale.org/pipermail/ale/attachments/20140712/ea68a15e/attachment.html> 
_______________________________________________ 
Ale mailing list 
Ale at ale.org 
http://mail.ale.org/mailman/listinfo/ale 
See JOBS, ANNOUNCE and SCHOOLS lists at 
http://mail.ale.org/mailman/listinfo 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20140714/e8cb4576/attachment.html>