Working with Samba
Samba is more than abundantly documented, so we won't rehash the basics. See the excellent tutorial "Using Samba as a primary domain controller". Two of the primary functions of my own little test network are fine-tuning Samba's abilities as a primary domain controller, and testing different uses as a stand-alone server.
Samba documentation is quite thorough on the server side, but not so complete on how to connect Windows clients. Each version of Windows implements networking, managing shared resources, and connecting to domains and workgroups differently. Windows 9x is the easiest to connect to anything; it's wide open. Windows NT4 and 2000 go well with Samba, as it is based on the NT4 domain model. Windows XP introduces some new, er, challenges.
Probably the most common problem for Samba admins is making passwords work correctly with Windows clients. These versions of Windows do not support encrypted passwords:
- Windows 95 pre-OSR2
- Windows NT 3x
- Windows NT 4 pre- SP3
Samba cannot accept both cleartext and encrypted passwords; you must choose one or the other. If you really want to mix these old things on a LAN with newer ones that use encrypted passwords, encryption must be disabled. Look in /usr/share/doc/samba-doc/Registry for files containing registry hacks to enable cleartext passwords for the various Windows. They look something like this:
Too many protocols:
One common source of trouble is having too many network protocols installed on Windows clients. Too many protocols means time wasted trying to make connections on the wrong ones. Install only what will be used.
Set your NICs explicitly to their highest performance specs, such as "100 TX Full Duplex," rather than using Auto-Detect.
Rather than using SWAT, Webmin, or editing the sample smb.conf, start fresh with a clean new smb.conf. This will prevent many headaches, and will be easier to troubleshoot. One of the most useful Samba utilities is
Samba's built-in smb.conf checker:
# testparm /etc/smb.conf
testparm will find syntax errors. This does not guarantee that the commands are
good, only the syntax!
Network configuration errors:
Too big a topic to go into here; the good news is diagnosis is straightforward, because we are dealing with native environments, and have not introduced the complexity that comes with virtual environments.
Windows NT 4/2000:
When logging into a Samba PDC for the first time, be sure to log in as root. This will set up the machine account, and then other users on the machine can access the domain.
Windows XP Home:
XP Home has the newfangled Simple Sharing. Simple Sharing offers zero granularity: shared files are accessible to everyone. It's about at the level of sharing in Windows 9x, except that the Program Files directory, the Windows directory, and Administrative shares are not accessible. XP Home cannot join a domain, neither Windows nor Samba domains, so if domain access is needed, XP Home will not work.
XP Pro comes with the full complement of Microsoft networking protocols, minus one: Netbeui. If you really really want Netbeui on either version of XP, it is included in the CD-ROM of the full retail versions only. See q301041.
To join a Samba domain, XP Pro needs a bit of fine-tuning. (Same for a Windows domain, so don't feel picked on.) Just like everyone else who administers XP, I get different results on different systems. Here are things to try:
-Sharing is not enabled by default, as it is in NT and 2000. Not even administrative shares. Turn on sharing. Right-click the drive, then choose "Sharing And Security". On the "Sharing" tab, there are scary warnings. Ignore them and proceed. On the "Local sharing and security- Network sharing and security" tab, configure your shares.
To log into a Samba domain:
- Turn off Simple File Sharing. Open Windows Explorer, Tools >Folder Options >View. SFS totally gets in the way of proper domain account and user management; it's a simpler model for simpler needs. It cannot be running if you want to join a domain.
- XP Pro by default is configured to the Windows 2000 domain model, which means it expects the signing and sealing of netlogon packets across the network. Since Samba emulates a Windows NT 4.0 PDC, which does not use this, it's registry hack time. Look for /usr/share/doc/samba-doc/Registry/WinXP_SignOrSeal.reg, which looks something like this:
; This registry key (gathered from the Samba-tng lists) is needed ; for a Windows XP client to join and logon to a Samba domain ; HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\netlogon\parameters "RequireSignOrSeal"=dword:00000000
Some users report that ControlSet001 & ControlSet003 also need this key.
Some users report that the Local Policy setting in the Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network Security:Lan Manager Authentication level should be set to "Send LM & NTLM responses".
Another fun use for our compact test network is to beta-test Samba 3, which adds all kinds of new features and improvements on existing features. It will support Unicode, trust relationships, and add substantial integration with Active Directory. Samba 2.2 has already proven its stability, scalability, and high performance. 3.0 promises to be even better.