[OpenAFS] New "B" question: Samba versus AFS.

[David Bear]

On Sat, Nov 30, 2002 at 02:49:49PM -0600, Charles Clancy wrote:
> On Sat, 30 Nov 2002, Tino Schwarze wrote:
> 
> > One setup has two Linux servers (one of them is "the AFS server") and
> > only Win98 clients which access files via Samba.
> 
> The problem such a setup is that you must use unencrypted passwords, which
> only increases the samba's lack of security.  Plus, when using unencrypted
> passwords, you can't use samba as a PDC, leaving you with needing to find
> some other way to get people logged into their windows workstations (such
> as a local account).
> 
> IMHO, Samba should only be used sparingly, for clients who abosultely
> can't run the OpenAFS client.  If all your clients are Windows machines
> and you don't want to run the OpenAFS client, you might as well just set
> up an active directory server and stick with a pure Microsoft environment.
> 

forgetting samba advantages
1) client software for winblows is already there -- you don't need to added any software
2) samba plays well in existing ms controlled environments with domain style accounts
3) samba has file locking!!! something afs cant and wont do
4) samba is a more secure server than a microsoft server -- you can run samba under its own uid/gid, you can run it jailed and chroot if on bsd, you can allow/deny specific networks -- and most important
5) the configuration is transparent, ie is well documented, in plain text, and the code has been peer reviewed  (something you will never get with non-open source software)
6) samba plays well in the unix realm -- as an add on application -- if you already know unix, samba is just another app... not a whole new os.
7) we can fight over security issues but samba IS secure when setup that way, ie to use nt password hashes only instead of lanman -- (kerberos is a probably a better authentication mechanism, but nt hashing still okay -- chances that you'll have a poor password is greater than cracking an nt hash)  

samba weaknesses
1) no unix dialect of smb, so sharing file systems between unix systems is not a complete home run -- you can do it but you get dumbed down to FAT style file semantics
2) server base URI's -- this is where the global namespace of AFS really shines.  With samba (and all SMB base servers I know of) the location of the file is based on servername/fspathname .. I don't see any change to this unless IBM can help with some code from there Domain style share names from WARP -- 
3) sometimes there may be issue with differences in the semantics between the way an NT server and a samba server define atime, mtime, ctime... we've had probably with this --  of course, FAT style mode bits don't directly map into unix mode bits either..
4) file permission control is based in a weak unix group model... this is were AFS protection groups really shine..

There may be others, but these are things I can think of real quick.

> [ t charles clancy ]--[ tclancy@uiuc.edu ]--[ www.uiuc.edu/~tclancy ]
> 
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info