samba - Oct 2003 - Suggestions for argument for Samba over Windows 2003?

Hi

We've recently been through a merger of 2 equal sized Schools,
 . one School was using Windows 2000 servers and W2K desktops, AD etc
 . the other was using Samba 2.x servers to control a "domain",
   with mostly Windows 98 desktops. 

We then worked out what services were running and deliberated on
where to run them in the new merged systems. As it turned out, the
decision was to go for Windows Server 2003 for email, printing,
virus scanning and so on.   However Web, Web Proxy, DHCP, DNS etc
will continue to live on Unix. 

The shared network drives might end up on Unix, or Windows.
It depends if people need fine-grained ACLs which Windows offers,
or maybe even if end-users themselves need to be able to apply the
ACLs, rather than IT admins having to do it.

The Home directories however, are still a sticking point...

I'm currently running a RedHat 9 (which means Samba 2.2.7) on a DELL
server.  The hardware should be fine to handle the load for the whole
school, which comprises about 200 - 250 users.   (This server is currently
controlling the Samba "domain" for one of the former schools).

We're getting close to making a final determination of whether the Home
directories should stay on this box, or move them to a box running
Windows Server 2003.  I've been using Samba as my Domain Controller
with a lot of good results and very little pain for a long time,
so my preference is to stay with it (and Unix-like systems).

However the new domain will be one controlled by AD, the IT guys 
from the other School aren't Unix-skilled, and so I need to produce
sound technical arguments for keeping Samba, not just my personal
preference based on what is familiar/known...

Reasons FOR moving the home dirs to Windows 2003 are largely the
same ones which got it decided upon in the first place.
 ie. stability;  reliability;  complete integration with AD;
     only one password source and so a single password across servers;
     that it is adminnable by any IT support staff, not just Unix guys;
     that it is an officially supported product.

The other side of the coin, concerns against keeping it on Unix include
     that home directories are absolutely vital which MUST NOT break;
     that a hetrogenous mix of servers must somehow lead to problems
     which won't arise if all servers run the same OS;
     that we will have users and/or passwords stored in 2 places, so
     they will get out of sync, or only Unix guys will be able to 
     fix things, or that we won't be able to use the Windows Admin
     tools to admin everything, or that end users won't be able to
     use the Windows change password utils, but will instead have to
     use a custom web page or something;

The advantages for us of Samba, as far as I can see, are that
     some of our admins have experience in it, know it, and like it;
     we can restrict access to SMB services based on IP ranges;
     we can automatically run scripts when shares are mounted/umounted,
     so we can make truly dynamic shares based on user privs;
     the new version integrates with AD, so password syncing issues
     should all go away, at least as far as end users are concerned;
     we could probably use SWAT to give non-Unix guys admin access;

Problem is, that to management types, I dunno if these sorts of reasons
are going to outweigh the safety/security of a more homogenous environment.

I apologise for the length of this post, but I'd also like to give the
people who have coordinated the Samba 3 documentation a huge rap.
Documentation isn't fun or sexy, and previously there were lots of
small docs, which were correct at the time of writing, and written
with good intentions, but which had been superceded and were in many
cases erroneous.  And at the end of the day, it doesn't matter how
brilliant the software is if the only people who know how to utilitise
it, are the people who coded it.

So the new "Samba Project Doco" is brilliant!  It's big and
I'm still
ploughing through it, but so far it's doing a great job of explaining
the underlying issues and then getting into the technical nitty gritty.
It brings you up to speed, so you can then consult the man pages for the
exact specifics of what is needed.  Congratulations to John/Jerry et al

So, anyway, from my reading of the doco so far, it would seem that
we could integrate the Unix box one of two ways:

 . Upgrade it to Samba 3, and have it join the Win 2003 domain.
   Since the only access we're supporting into the box is SMB,
   we don't need to worry about setting or syncing the Unix password.

   I still need some way to create the underlying unix account though,
   preferably with consistent, rather than randomly assigned uids/gids.

   I could use normal Unix commands to manually create the Unix accounts,
   but since I have previously set up an OpenLDAP box and made accounts
   on it for everyone, I could probably homebrew some sort of
   web-based  makeuser  script, and point NSS at it.

 . leave it on Samba 2.2.7, leave it off the whole domain thingo,
   set  security=server  and point the password server at one of
   the AD boxes, and touch wood.  

   Even if we don't have 2 passwords and password syncing, we still
   have a small issue of having 2 sets of accounts, and needing to
   create/delete accounts in 2 places.

Any comments appreciated.

cheers,
/\ndy

> Hi
>
> I'm currently running a RedHat 9 (which means Samba 2.2.7) on a DELL
> server.  The hardware should be fine to handle the load for the whole
> school, which comprises about 200 - 250 users.   (This server is currently
> controlling the Samba "domain" for one of the former schools).
> So, anyway, from my reading of the doco so far, it would seem that
> we could integrate the Unix box one of two ways:
>
>  . Upgrade it to Samba 3, and have it join the Win 2003 domain.
>    Since the only access we're supporting into the box is SMB,
>    we don't need to worry about setting or syncing the Unix password.
>
>    I still need some way to create the underlying unix account though,
>    preferably with consistent, rather than randomly assigned uids/gids.
>
>    I could use normal Unix commands to manually create the Unix accounts,
>    but since I have previously set up an OpenLDAP box and made accounts
>    on it for everyone, I could probably homebrew some sort of
>    web-based  makeuser  script, and point NSS at it.
>
>  . leave it on Samba 2.2.7, leave it off the whole domain thingo,
>    set  security=server  and point the password server at one of
>    the AD boxes, and touch wood.
>
>    Even if we don't have 2 passwords and password syncing, we still
>    have a small issue of having 2 sets of accounts, and needing to
>    create/delete accounts in 2 places.
If you were living in northern Germany, I would invite you to come to my
site, so we could discuss that with a working setup at hands.
I am running at this school a setup with a PDC (1GHz HP, 1GB RAM) and a
BDC (similar, but P4) with a user base of about 7000. Only about 1500 are
active users, as user-accounts are created by a perl script, 40 accounts
per class.
Every user has of course his/her own homedirectory and as far as I know,
all users are more satisfied with this network as they were before
(Netware, W2k Advanced Server). We had a license of w2k advanced server
and I am glad that I never gave it a try, though I never had set up a
samba-PDC before (I just told them it was no problem :-))
I am just about to switch completely to samba3.0.1pre1 (I know it's not
for productive, but we don't produce here anything ;-) ) and it seems to
be worth it for the smaller load concerning ldap. The CPU-load wasn't a
problem, but I always had to have an eye on it, sometimes it was at 100%,
as many users log in at the same moment in school-environments.
In my Opinion masses of accounts are better handled by some scripts than
by GUI and I find it easier to write those scripts on unix. Further more,
OpenLDAP is better documented and more standard-conformant, its easier to
extend it with my own schemas (For problem-reporting and management,
login-script storage) plus standard schemas for mail-routing.
Difficulties with samba will occour, but they do as well with Windows
whatsoever, be it 2000, XP or 2003. Actually, few people here know that
the servers are running Linux/Samba...

Sincerely,
Malte M?ller

On Friday 17 October 2003 00:32, Andy Jones wrote:
> We then worked out what services were running and deliberated on
> where to run them in the new merged systems. As it turned out, the
> decision was to go for Windows Server 2003 for email, printing,
> virus scanning and so on.   However Web, Web Proxy, DHCP, DNS etc
> will continue to live on Unix.
First a disclaimer - although I've set up many Windows PDC's/Exchange
Servers,
etc. and now several Samba PDC installations they have all been for small 
businesses. Only one of the clients was sizeable enough to install a BDC.

With a Windows AD and also Exchange (you didn't specify which email server 
app) you may as well hand over the DNS, and possibly the DHCP, reigns over to 
the Windows guys as well as I believe (maybe wrongly so) that although you 
can allow dynamic updates from the clients they will not be secure. Plus you 
have to screw with all of those _ service zones. Maybe I'm all wet and it
all
works OK (I would like that to be the case), but I think there's a possible 
trap in the current assignment division.

Unless the plan is Exchange with Outlook for the groupware capabilities it 
would be much more preferable to put the email on the nix boxes.
> However the new domain will be one controlled by AD, the IT guys
> from the other School aren't Unix-skilled, and so I need to produce
> sound technical arguments for keeping Samba, not just my personal
> preference based on what is familiar/known...
The dangers of monoculture might be brought up. If something did take out 
every Windows box you could still get some work done with the nix boxes. With 
every system/user getting authenticated by the AD there would be no cost 
savings from a CAL viewpoint.
> Reasons FOR moving the home dirs to Windows 2003 are largely the
> same ones which got it decided upon in the first place.
>  ie. stability;  reliability;  complete integration with AD;
>      only one password source and so a single password across servers;
This would not be affected if you used winbind on the Samba box.
>      that it is adminnable by any IT support staff, not just Unix guys;
Are the Windows boxes adminable by any IT support staff, not just the Windows 
guys?
>      that it is an officially supported product.
Maybe it's just my experience but I've been on the horn to Redmond a few
times
and when you really have a Windows problem Google is a much better friend 
than Microsoft.
> So, anyway, from my reading of the doco so far, it would seem that
> we could integrate the Unix box one of two ways:
>
>  . Upgrade it to Samba 3, and have it join the Win 2003 domain.
>    Since the only access we're supporting into the box is SMB,
>    we don't need to worry about setting or syncing the Unix password.
Gets my vote.
>    I still need some way to create the underlying unix account though,
>    preferably with consistent, rather than randomly assigned uids/gids.
Doesn't Winbind handle all of this? If you got the email task with Cyrus
then
you may need to "manually" set up the Cyrus accounts.
>  . leave it on Samba 2.2.7, leave it off the whole domain thingo,
>    set  security=server  and point the password server at one of
>    the AD boxes, and touch wood.  
Doesn't sound pretty.
-- 
Chris

Do not reply to the email address.
Please use the contact page below for any desired direct replies.
Apologies for the inconvenience.

realcomputerguy dot com slash contact dot html